Health check tasarımı: Liveness ve Readiness ayrımını nasıl yaparım?

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ı?”.

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.

1. Liveness = “süreç takıldı mı?” — ucuz ve bağımlılıksız tut. Burada DB’yi, cache’i, kuyruğu kontrol etme. Liveness’a bağımlılık koyarsan, anlık bir DB kesintisi tüm sağlıklı pod’ları sonsuz bir restart döngüsüne sokar. Liveness sadece “süreç yanıt veriyor mu?” sorusuna bakmalı.
2. Readiness = “şu an istek alabilir miyim?” — kritik bağımlılıkları kontrol et. 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.
3. İkisinin sonucunu doğru bağla. 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.
4. Readiness’ı ucuz tut ve sonucunu cache’le. Kontrolü kısa timeout’la yap ve sonucu birkaç saniye cache’le. Yoksa her replica’nın probe’u her birkaç saniyede Postgres’e gerçek bir sorgu atar; 50 pod × sürekli probe = veritabanını sen çökertirsin. Sadece hizmet için gerçekten gerekeni kontrol et.
5. 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ın 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.