Container'daki healthcheck'i Dockerfile'a mı yazmalıyım yoksa Kubernetes probe'larına mı bırakmalıyım?

Kısa cevap: Kubernetes’te readiness/liveness’ı probe’lar sahiplenir; kubelet, imajdaki HEALTHCHECK durumunu tasarım gereği hiç okumaz.

Kısa cevap

Ama HEALTHCHECK’i Compose/düz Docker için tutmakta fayda var — çöp değil, sadece farklı bir runtime içindir. Kafa karışıklığı anlaşılır: iki katman da sağlığı sahipleniyormuş gibi görünür, ama belirli bir runtime’da gerçekten yalnızca biri dikkate alınır. Önce imajın gerçekte hangi runtime’da koşacağını netleştirin; cevap kendiliğinden oradan çıkar. Probe’ların kendi içindeki ayrımı — liveness neyi, readiness neyi ölçmeli — health check tasarımı kaydında ayrıntılandırmıştım.

Neden

1. Kubernetes, Dockerfile HEALTHCHECK’i tasarım gereği yok sayar. kubelet kendi liveness/readiness/startup probe’larını çalıştırır ve imajın HEALTHCHECK sonucunu hiç okumaz. Yani k8s’te bu satır ölü ağırlıktır — zararsız ama trafiği belirleyen şey değildir.
2. Kavramların sahibi Kubernetes tarafıdır. Readiness (trafik geçişi), liveness (restart) ve startup (yavaş boot) kavramlarının hepsi Kubernetes probe kavramlarıdır. “Bu pod servis verebilir mi?” kararını sahiplenen katman budur.
3. Docker/Compose HEALTHCHECK’e uyar. Lokal geliştirmede Compose’un depends_on: condition: service_healthy özelliği ve düz Docker/Swarm, container’ı “healthy” olarak işaretlemek için HEALTHCHECK’i kullanır. Yani işe yaramaz değildir; sadece farklı bir tüketiciye hizmet eder.
4. HEALTHCHECK’in bir bedeli var. CMD curl imajda curl gerektirir (distroless’ta yoktur). Shell formundaki bir HEALTHCHECK ayrıca her interval’da bir süreç başlatır; sonucu hiç okunmayan bir container’da bu boşa iştir.

Ne yapmalı

1. Probe’ları Deployment/Pod spec’inde tanımlayın. Trafiği ve restart’ı asıl belirleyen katman burasıdır; readiness, liveness ve startup’ı burada açıkça yazın.

   # Kubernetes'te trafiği ve restart'ı asıl belirleyen katman budur:
   readinessProbe:
     httpGet: { path: /readyz, port: 8080 }
     periodSeconds: 5
   livenessProbe:
     httpGet: { path: /healthz, port: 8080 }
     periodSeconds: 10

2. Mantığı çoğaltmayın, endpoint’i paylaşın. Aynı /healthz (liveness) ve /readyz (readiness) HTTP endpoint’lerini açın; hem Dockerfile HEALTHCHECK’ini hem de k8s probe’larını bunlara yöneltin. Tek implementasyon, iki tüketici.

3. HEALTHCHECK’i ya doğru biçimde yazın ya da düşürün. CMD curl yerine binary’nizin kendi healthcheck subcommand’ını exec edin; imaj yalnızca k8s’te koşacaksa HEALTHCHECK’i tamamen atın.

   # Yalnızca Compose/düz Docker altında da koşacaksa anlamlı:
   HEALTHCHECK --interval=10s --timeout=2s --retries=3 \
     CMD ["/app/server", "healthcheck"]

4. Probe’ları ucuz ve doğru tutun. Aynı altın kural: liveness bağımlılıksız olsun, readiness bağımlılıkları kontrol etsin ama sonucunu birkaç saniye cache’lesin. Aksi hâlde probe’lar veritabanınızı DDoS’lar.

Sonuç: Ben olsam readiness/liveness/startup’ı Kubernetes probe’ları olarak tanımlardım — çünkü trafiğe ve restart’a karar veren katman odur. HEALTHCHECK’i Dockerfile’da yalnızca aynı imaj Compose/düz Docker altında da koşuyorsa, ikisini de aynı /healthz + /readyz endpoint’lerine bağlayarak tutardım. İmaj sadece k8s içinse, “bir şey yapıyor” yanılsamasını önlemek için HEALTHCHECK’i düşürürdüm.