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

> Liveness'ı bağımlılıksız tutun, bağımlılıkları readiness'ta cache'li yoklayın: liveness fail pod'u restart eder, readiness fail yalnız trafiği keser.

- Soruldu: 2026-06-03
- Yanıtlandı: 2026-06-06
- Soran: Eren
- Etiketler: dayaniklilik, altyapi, kubernetes
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/health-check-tasarimi-liveness-ve-readiness-ayrimi/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**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?


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 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

- [Bir Sistemin "Gereğinden Karmaşık" Olduğunu Gösteren Sinyaller](https://sade.dev/tr/journal/gereginden-karmasik-sistem-sinyalleri) — sade.dev
- [Felaket kurtarma: RTO ve RPO'ya göre aktif-pasif senaryoyu nasıl kurgularım?](https://www.muhammetsafak.com.tr/sor-bakalim/felaket-kurtarma-rto-rpo-ve-aktif-pasif-senaryo/) — Sor Bakalım
- [Log storm ve disk dolma krizini nasıl önlerim?](https://www.muhammetsafak.com.tr/sor-bakalim/log-storm-ve-disk-dolma-krizini-onlemek/) — Sor Bakalım
- [Container'daki healthcheck'i Dockerfile'a mı yazmalıyım yoksa Kubernetes probe'larına mı bırakmalıyım?](https://www.muhammetsafak.com.tr/sor-bakalim/containerdaki-healthchecki-dockerfilea-mi-yazmaliyim-yoksa-kubernetes-probelarina-mi-birakmaliyim/) — Sor Bakalım