İçeriğe geç
Muhammet Şafak
en
Soran: Eren Cevaplandı:

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

  1. İ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.
  2. 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.
  3. 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ı

  1. 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ı.
  2. 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.
  3. 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.
  4. 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

Paylaş:

Yorumlar

Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.

Diğer Sorular

Tüm sorular

Sitede Ara

Yazı, proje ve sayfalarda arama yapmak için yazmaya başlayın.

Esc ile kapat Pagefind ile güçlendirildi