← Tüm yazılar

DevOps

Container sağlık kontrolleri

15 July 2026

Docker HEALTHCHECK ve Kubernetes liveness, readiness ile startup probe'larının doğru yapılandırılması, yaygın hatalar ve üretim senaryoları.

Bir container çalışıyor görünse bile uygulama içeride yanıt vermiyor olabilir. Tersine, uygulama henüz başlatma aşamasındayken trafik almaya başlarsa hata fırtınası oluşur. Sağlık kontrolleri (health checks), orchestrator'ın container'ın gerçek durumunu anlamasını sağlar ve otomatik iyileştirme kararlarının temelini oluşturur.

Docker HEALTHCHECK

Docker, Dockerfile içinde HEALTHCHECK talimatı ile container sağlığını izler. Orchestrator kullanılmayan ortamlarda bile bu mekanizma docker ps çıktısında HEALTHY/UNHEALTHY durumunu gösterir.

HEALTHCHECK --interval=30s --timeout=5s --start-period=60s --retries=3 \
  CMD curl -f http://localhost:8080/health || exit 1

Parametrelerin anlamı:

interval: Kontroller arası süre (varsayılan 30s)
timeout: Tek kontrol için maksimum bekleme
start-period: Başlangıç tolerans süresi; bu süredeki hatalar sayılmaz
retries: UNHEALTHY sayılması için gereken ardışık hata

Health endpoint hafif olmalıdır: veritabanı bağlantısı kontrol edilebilir, ancak ağır sorgu çalıştırılmamalıdır.

Kubernetes probe türleri

Kubernetes üç farklı probe türü sunar; her birinin farklı amacı vardır:

Liveness probe

Container'ın canlı olup olmadığını kontrol eder. Başarısız olursa kubelet container'ı yeniden başlatır. Yanlış yapılandırılmış liveness probe, yavaş yanıt veren ama sağlıklı uygulamaların sürekli restart döngüsüne girmesine neden olur.

Readiness probe

Container'ın trafik almaya hazır olup olmadığını kontrol eder. Başarısız olursa Service endpoint listesinden çıkarılır; trafik yönlendirilmez. Veritabanı migration'ı veya cache ısıtma sırasında readiness false döndürülebilir.

Startup probe

Yavaş başlayan uygulamalar için tasarlanmıştır. Startup probe başarılı olana kadar liveness ve readiness devreye girmez. .NET uygulamalarında JIT derleme ve ilk istek gecikmesi startup probe ile yönetilir.

livenessProbe:
  httpGet:
    path: /health/live
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 15
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
  periodSeconds: 10
  failureThreshold: 2

startupProbe:
  httpGet:
    path: /health/ready
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

Probe mekanizmaları

Kubernetes dört probe mekanizması destekler:

httpGet: HTTP endpoint'e GET isteği; 200-399 arası başarılı
tcpSocket: Port dinleniyor mu kontrolü
exec: Container içinde komut çalıştırma
grpc: gRPC health checking protokolü (K8s 1.24+)

HTTP probe en yaygın ve okunabilir olanıdır. TCP probe yalnızca port dinlemesini doğrular; uygulama mantığı hatalı olsa bile başarılı dönebilir.

ASP.NET Core health check entegrasyonu

ASP.NET Core built-in health check altyapısı sunar:

builder.Services.AddHealthChecks()
    .AddNpgSql(connectionString, name: "postgres")
    .AddRedis(redisConnection, name: "redis");

app.MapHealthChecks("/health/live", new HealthCheckOptions {
    Predicate = _ => false  // sadece process canlı mı
});
app.MapHealthChecks("/health/ready", new HealthCheckOptions {
    Predicate = check => check.Tags.Contains("ready")
});

Liveness endpoint yalnızca uygulama process'inin ayakta olduğunu doğrulamalıdır. Readiness endpoint bağımlılıkları (veritabanı, cache, mesaj kuyruğu) kontrol edebilir.

Yaygın hatalar ve çözümleri

Liveness'e bağımlılık kontrolü koymak

Veritabanı geçici olarak erişilemez olduğunda liveness başarısız olursa, tüm pod'lar restart döngüsüne girer. Bu durum sorunu büyütür. Bağımlılık kontrolleri yalnızca readiness'te olmalıdır.

Timeout değerlerini düşük tutmak

GC pause veya anlık yük artışı probe timeout'una takılabilir. Timeout, uygulamanın p99 yanıt süresinin üzerinde ayarlanmalıdır.

Start-period eksikliği

Container başlar başlamaz probe çalışırsa, uygulama henüz dinlemiyor olabilir. initialDelaySeconds veya startup probe kullanılmalıdır.

Aynı endpoint'i üç probe için kullanmak

Her probe farklı soru sorar; farklı endpoint'ler veya predicate filtreleri kullanılmalıdır.

Graceful shutdown ile ilişki

Pod silindiğinde Kubernetes önce SIGTERM gönderir ve readiness'i false yapar. Endpoint'lerden çıkarılması için terminationGracePeriodSeconds süresi tanınır. Uygulama bu sürede devam eden istekleri tamamlamalıdır. Probe yapılandırması shutdown süreciyle uyumlu olmalıdır; aksi halde trafik kesilirken yeni istekler hâlâ yönlendirilebilir.

Compose ortamında sağlık kontrolü

Docker Compose v2+, depends_on ile condition desteği sunar:

services:
  api:
    depends_on:
      db:
        condition: service_healthy
  db:
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
      interval: 5s
      retries: 5

Bu sayede API container'ı, veritabanı gerçekten hazır olmadan başlamaz.

İzleme ve alarm

Probe başarısızlıkları metrik olarak izlenmelidir. Kubernetes events ve kube-state-metrics ile restart sayısı, not-ready pod sayısı dashboard'a taşınır. Ani restart artışı deployment sorununa veya bağımlılık kesintisine işaret eder.

Üretim önerileri

Health endpoint'leri authentication gerektirmemeli (kubelet erişir)
Probe path'leri load balancer health check ile uyumlu olmalı
Her deployment sonrası probe davranışı staging'de doğrulanmalı
Startup probe ile yavaş başlayan uygulamalara yeterli tolerans tanınmalı
Runbook'ta probe başarısızlığı senaryosu ve müdahale adımları tanımlı olmalı

Load balancer ve probe uyumu

Kubernetes dışında, cloud load balancer'lar (Azure Application Gateway, AWS ALB) kendi health check mekanizmasına sahiptir. K8s readiness probe ile LB health check path'i aynı endpoint'i hedeflemelidir. Farklı path kullanıldığında pod ready görünürken LB trafiği kesmeye devam edebilir veya tam tersi olur.

Health check aralığı LB tarafında genellikle 15-30 saniyedir. K8s probe period'u ile uyumsuzluk, trafik yönlendirme gecikmelerine neden olur. Her iki taraftaki timeout ve threshold değerleri dokümante edilmelidir.

Sidecar ve init container senaryoları

Service mesh (Istio, Linkerd) sidecar'ı eklendiğinde probe davranışı değişebilir. mTLS devreye girdikten sonra httpGet probe'u sidecar üzerinden geçer. Init container tamamlanmadan uygulama container'ı başlamaz; bu süre startup probe ile kapsanmalıdır.

Init container veritabanı migration çalıştırıyorsa, uygulama container'ının readiness'i migration bitene kadar false kalmalıdır. Aksi halde yarım migration ile trafik alan pod hata üretir.

Performans etkisi ve optimizasyon

Her probe HTTP isteği oluşturur. Saniyede 10 kez çalışan readiness probe, yüksek pod sayısında anlamlı ek yük demektir. Period değerini gereksiz yere düşürmekten kaçının; çoğu uygulama için 10-15 saniye yeterlidir. Health endpoint yanıt süresi 100ms altında tutulmalıdır; ağır kontroller arka planda cache'lenmelidir.

Önbellek stratejisi: veritabanı bağlantı durumu 5 saniyede bir kontrol edilir, probe bu cache'lenmiş sonucu döndürür. Gerçek bağlantı kopması en fazla 5 saniye gecikmeyle tespit edilir; bu trade-off çoğu senaryoda kabul edilebilir.

Debugging probe sorunları

Pod sürekli restart oluyorsa ilk adım olayları incelemektir: kubectl describe pod çıktısında liveness probe failure mesajı görünür. Probe yanıt kodu, response body ve süre loglanmalıdır. Geçici debug için probe'u devre dışı bırakmak yerine failureThreshold artırılır; devre dışı bırakma otomatik iyileştirmeyi tamamen kapatır.

Multi-container pod senaryoları

Bir pod içinde birden fazla container olduğunda probe hangi container'a uygulanacağı belirtilmelidir. Ana uygulama container'ına probe tanımlanır; log toplayıcı sidecar'ına probe konulmaz. Pod seviyesinde restart policy ile probe davranışı birlikte düşünülmelidir.

PodDisruptionBudget (PDB) ile birlikte probe yapılandırması değerlendirilir: readiness false olan pod'lar PDB hesabına dahil edilmez; cluster upgrade sırasında yeterli sağlıklı pod kalmayabilir. minAvailable değeri probe davranışıyla uyumlu olmalıdır.

Üretim vaka analizi

Bir e-ticaret platformunda liveness probe veritabanı kontrolü içeriyordu. Black Friday trafik artışında veritabanı bağlantı havuzu tükendi; tüm pod'lar liveness başarısız sayılıp restart döngüsüne girdi. Çözüm: bağımlılık kontrolünü readiness'e taşımak, liveness'i yalnızca process health ile sınırlamak ve connection pool boyutunu artırmak. Bu olay, probe ayrımının neden kritik olduğunu somut olarak gösterir.

Health check yapılandırması deployment manifest'inin ayrılmaz parçasıdır; kod review'da probe tanımları da incelenmelidir.

Doğru yapılandırılmış sağlık kontrolleri, container orchestration'ın otomatik iyileştirme gücünü gerçekten kullanılabilir kılar. Yanlış yapılandırma ise en sağlıklı uygulamayı bile kararsız hale getirebilir.