Kubernetes readiness probe hataları Pod'ları trafikten çıkarır, container'ları yeniden başlatmaz

Bir dev.to yazısı, Kubernetes operasyonlarındaki en kalıcı yanılgılardan birine parmak basıyor: başarısız bir readiness probe'un container'ı yeniden başlatacağı varsayımı. Yazıya göre readiness'in yeniden başlatmayla hiçbir ilgisi yok. Amacı, bir Pod'un Service'lerden trafik alıp almayacağını belirlemek; yeniden başlatmalar ise liveness probe'ların ve süreç denetiminin işidir.

Bir readiness probe aslında neyi kontrol eder

dev.to yazarının açıkladığı gibi, kubelet her container'ın readiness probe'unu, probe yapılandırmasının belirttiği programa göre çalıştırır. Başarılı bir probe, Kubernetes'in container'ı ready olarak işaretlemesini sağlar ve bir Pod'un gerektirdiği tüm readiness koşulları karşılandığında, Ready durumu true olur. Probe başarısız olmaya başladığında container not-ready durumuna geçer ve bu genellikle tüm Pod'u da not-ready yapar.

Bu durum değişikliği, süreci öldürecek bir anahtar değil, servis keşfine verilen bir sinyaldir. Controller'lar eşleşen EndpointSlice'ları güncelerek not-ready Pod'u normal Service trafiği için uygun backend'ler arasından çıkarır; kube-proxy gibi — ya da cluster'da Service yönlendirmesini hangi uygulama üstleniyse o — bileşenler yeni endpoint durumuna yakınsar.

Container çalışmaya devam eder

Yazıya göre tüm bunlar container'ın kendisine dokunmaz. Süreç öldürülmez, filesystem sıfırlanmaz ve readiness başarısız olduğu için restart sayacı yerinde kalır. Kubelet basitçe probe'lamaya devam eder. Uygulama toparlanır ve probe yeniden başarılı olursa, Pod hiç yeniden başlatılmadan ready durumuna dönebilir ve Service'in backend havuzuna yeniden katılabilir.

Yazar, bu davranışın readiness probe'ları geçici olarak hizmet verememe durumları için doğru araç haline getirdiğini savunuyor. Bir uygulama, istekleri geçici olarak işleyemezken hâlâ çalışıyor olabilir — yapılandırma yeniden yükleniyor, bir bağımlılığa bağlantı yeniden kuruluyor, cache ısınıyor veya işler boşaltılıyor olabilir. Readiness başarısızlığı, o örneği yeni trafikten yalıtırken devam eden bellek içi kurtarma çalışmalarını da korur.

Endpoint kaybetmek, trafiği durdurmakla aynı şey değildir

Yazının altını çizdiği bir nüans, Service endpoint'lerinden çıkarılmanın anında bir iptal mekanizması olmadığıdır. Endpoint güncellemelerinin yayılması gerekir ve zaten kurulmuş bağlantılar açık kalabilir. Uzun ömürlü bir TCP bağlantısına sahip bir istemci, Pod ready olmaktan çıktıktan çok sonra bile istekleri aynı Pod'a göndermeye devam edebilir. Readiness yönlendirme kararlarını yönlendirir; trafiğin probe tam başarısız olduğu anda duracağını garanti etmez.

Yeniden başlatma ne zaman gerçekten istenir

Sağlıksız bir container'a verilmek istenen yanıt sonlandırma ve ardından temiz bir başlangıçsa, yazı bu politika için mekanizma olarak liveness probe'lara işaret ediyor. Bir liveness kontrolü başarısız olduğunda, kubelet Pod üzerinde belirlenen restart politikasına uyarak container'ı yeniden başlatabilir. Yazar, altta yatan durumun kendi kendine düzeleceği hallerde liveness'a yönelmeye karşı uyarıyor: böyle yapmak, bir readiness probe'un tam da koruyacağı kurtarma ilerlemesini yok eden restart döngülerine davetiye çıkarır.

Düzeltilmiş pratik kural: başarısız bir readiness probe, Pod'u normal Service trafiğinden çıkarır ve başka hiçbir şey yapmaz — container çalışmaya devam eder.

Neden önemli

İki probe türünü karıştırmak gerçek operasyonel maliyetler taşır. Readiness hatalarının container'ları yeniden başlatacağını bekleyen ekipler, panellerini yanlış okur: sabit bir restart sayacı, Pod Service'in dışında sessizce hiç trafik almazken bile sağlıklı görünür. Daha kötüsü, kendi kendine düzelen durumlar için liveness probe'larla yeniden başlatma dayatmak, kısa bir yavaşlamayı bir restart döngüsüne dönüştürebilir; devam eden kurtarma çalışmalarını çöpe atar ve olayı büyütür. Bu ayrımı net tutmak, operatörlerin probe'u hata moduna eşlemesini sağlar — toparlanabilir durumlar için rotasyondan zarifçe çıkarma, yalnızca kendi kendine geri gelemeyecek container'lar için yeniden başlatma.