Health check tasarımı: Liveness ve Readiness ayrımını nasıl yaparım?
Soru
Kubernetes / Load Balancer arkasındaki konteynerler için `/health` endpoint'leri yazacağız. Ama sadece `{status:ok}` dönmek uygulamanın gerçekte çalışıp çalışmadığını göstermiyor — DB bağlantısı kopmuşsa ama HTTP ayaktaysa yanıltıcı oluyor. Mimari olarak Liveness ve Readiness ayrımını nasıl yaparım? Bu endpoint'lerin DB'ye aşırı yük bindirmemesi için neye dikkat etmeliyim?
Cevap
Kısa cevap: Statik bir {status:ok} yalnızca HTTP sunucusunun ayakta olduğunu kanıtlar, uygulamanın gerçekten hizmet verebildiğini değil. Çözüm, iki farklı soruyu ayırmak: “yaşıyor mu?” ve “hazır mı?”.
Kısa cevap
Asıl mesele şu: Liveness ile Readiness farklı şeyleri ölçer ve karıştırırsan kendi ayağına sıkarsın — özellikle bağımlılık kontrolünü yanlış probe’a koyarsan. Readiness’ın “beni rotasyondan çıkar ama öldürme” davranışı, autoscaling sırasında pod kapanırken trafiği boşaltma mantığının aynısıdır; o tarafı SIGTERM ile graceful shutdown kaydında ayrıca ele almıştım.
Neden
- İki probe’un sonucu farklı yaptırıma bağlanır. Liveness fail olursa Kubernetes pod’u restart eder; readiness fail olursa sadece trafiği keser. Bu ayrım kritik: geçici bir bağımlılık sorununda pod’u yeniden başlatmak istemezsin, sadece trafiği durdurmak istersin.
- Liveness’a bağımlılık koymak restart döngüsü yaratır. Anlık bir DB kesintisi tüm sağlıklı pod’ları sonsuz bir restart döngüsüne sokar — oysa süreçlerin kendisinde bir sorun yoktur.
- Probe’un maliyeti replica sayısıyla çarpılır. Her replica’nın probe’u her birkaç saniyede Postgres’e gerçek bir sorgu atarsa, 50 pod × sürekli probe = veritabanını sen çökertirsin.
Ne yapmalı
- Liveness’ı ucuz ve bağımlılıksız tut. Burada DB’yi, cache’i, kuyruğu kontrol etme. Liveness sadece “süreç yanıt veriyor mu?” sorusuna bakmalı.
- Readiness’ta kritik bağımlılıkları yokla. DB, cache, kuyruk gibi hizmet için gereken bağımlılıkları burada kontrol et. Bir bağımlılık düştüğünde Load Balancer pod’u rotasyondan çıkarsın — ama pod’u öldürmeden. Bağımlılık dönünce pod tekrar trafiğe girer.
- Readiness’ı kısa timeout’la yap ve sonucunu cache’le. Sonucu birkaç saniye cache’le ve sadece hizmet için gerçekten gerekeni kontrol et.
- Yavaş açılış için startup probe ekle. Uygulaman yavaş boot ediyorsa, ayrı bir startup probe kullan ki liveness, uygulama daha açılırken pod’u öldürmesin.
Sonuç: Ben olsam liveness’ı ucuz ve bağımlılıksız, readiness’ı bağımlılık-farkında ama cache’li yapardım. Altın kural: probe’lar asla veritabanını DDoS’lamasın. Kubernetes’in gerçekten gerekip gerekmediğini sade.dev’de ayrıca tartışıyorum; ama bu ayrımı yapmazsan en küçük DB titremesi bütün cluster’ını sallar.
İlgili Yazılar
Yorumlar
Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.