Bir Pod'un Running görünmesi, uygulamanın kullanıcı isteğini karşılayabildiğini söylemez. Süreç açılmış olabilir ama başlangıç verileri hâlâ yükleniyor olabilir. Tersi de mümkündür: uygulama kısa süreli bir bağımlılık sorunu yaşıyordur, fakat yeniden başlatılmasına gerek yoktur. Probe tasarımında bu durumların birbirinden ayrılması gerekir.
Kubernetes üç farklı soruya cevap arar: uygulama başladı mı, çalışmaya devam edebiliyor mu, şu anda trafik almalı mı? Aynı sağlık adresini her alana yazmadan önce bu soruların uygulama açısından ne anlama geldiği açıklanmalı.
Hangi sonuç hangi tepkiyi doğurur?
Startup probe, başlangıç tamamlanana kadar liveness ve readiness kontrollerini bekletir. Liveness başarısızlığı belirlenen eşiğe ulaştığında container sonlandırılır; yeniden başlatma davranışı ilgili restart politikasına bağlıdır. Readiness başarısızlığı ise container'ı yeniden başlatmaz, normal Service trafiğine uygun olmadığını bildirir. Bu ayrım Kubernetes probe kavramlarında açıklanıyor.
Örneğin bir servis, ilk açılışında uygulama önbelleğini hazırlıyor olsun. Bu sırada liveness'in sürekli başarısız olması bir yeniden başlatma döngüsü doğurabilir. Başlangıç tamamlanmadan süreç öldürüldüğü için uygulama hiçbir zaman hazır olamaz. Startup kontrolünün görevi, bu başlangıç sürecine ayrı bir tolerans tanımaktır.
Sağlık adresinin sözleşmesini yazmak
Liveness endpoint'i, uygulamanın kendi ilerleme kabiliyetini mümkün olduğunca ucuz bir kontrolle ölçmeli. Ortak bir veritabanının kısa kesintisi nedeniyle bütün uygulama örneklerini yeniden başlatmak, sorunu büyütebilir. Yeniden başlatma hangi arızayı düzeltecek? Bu soruya cevap verilemiyorsa o bağımlılığı liveness'e ekleme gerekçesi yeniden düşünülmeli.
Readiness daha farklı bir değerlendirme ister. Uygulama gerekli bir bağımlılığa erişemediğinde hiçbir isteği karşılayamıyorsa trafik dışına çıkması yararlı olabilir. Buna karşılık kısmi hizmet vermeye devam edebiliyorsa her bağımlılığı tek bir hazır olma sonucuna bağlamak gereksiz kesinti oluşturabilir. Uygulama sahibiyle hangi işlevin kritik olduğuna karar verilmelidir.
Kontrolün kendisi de yük üretir. Her çağrıda ağır sorgu çalıştıran, yeni bağlantılar açan veya alt servislere uzun zincirler kuran sağlık adresleri özellikle yoğunluk anında sorun yaratabilir. Yanıtın neyi temsil ettiği ve hangi hata kodunu döndüreceği uygulama sözleşmesinde bulunmalı.
Süreleri tahminle bırakmamak
Başlangıç için ayrılan süre, gözlenen yavaş başlangıç senaryosunu karşılamalı. Dokümandaki failureThreshold ile periodSeconds ilişkisi bunun için bir başlangıç hesabı sağlar. Ancak timeout, başlangıç gecikmesi ve sonlandırma davranışı da birlikte okunmalı. Yapılandırma rehberindeki örnek değerler her uygulamaya doğrudan taşınmamalı.
Üretim öncesi küçük bir deneme listesi hazırlamak daha işe yarar:
- Yavaş açılışta uygulama yeterli süre bekleniyor mu?
- Geçici bağımlılık hatasında gereksiz restart oluşuyor mu?
- Gerçek kilitlenme tespit edilebiliyor mu?
- Hazır olmayan örnek normal Service trafiğinden çıkıyor mu?
- Yoğunluk sırasında probe süresi ve hata oranı değişiyor mu?
Her denemede olay kayıtları, restart sayısı ve uygulama yanıtı birlikte incelenmeli. Kontrolün yeşile dönmesi tek başına yeterli bir kabul ölçütü değildir. Kullanıcının yaptığı temel işlem de doğrulanmalı. Böylece probe ayarları, YAML dosyasındaki zorunlu alanlar olmaktan çıkar ve uygulamanın beklenen davranışını tarif eden küçük bir işletim sözleşmesine dönüşür.
Yorumlar (0)
Henüz onaylanmış yorum yok.