Liveness, readiness ve startup probe'ları nedir ve her birini ne zaman kullanırsınız?

Question

IT Interview Practice · Accepted Answer

Probe'lar, kubelet'in bir container'ın sağlığını kontrol edip sonuca göre hareket etmesini sağlar. Üç tanesi vardır: **liveness** (canlı mı, yoksa restart mı edilmeli?), **readiness** (trafik almaya hazır mı?) ve **startup** (henüz açılışını tamamladı mı?). Her biri farklı bir soruyu yanıtlar.

## Üç probe bir bakışta

```text
LIVENESS   → "App takılı/deadlock'ta mı?"         BAŞARISIZ → kubelet container'ı RESTART eder
READINESS  → "Şu an trafik sunabilir mi?"          BAŞARISIZ → Pod Service endpoint'lerinden çıkarılır
                                                       (RESTART EDİLMEZ)
STARTUP    → "Yavaş açılış bitti mi?"               ÖNCE çalışır; çalışırken liveness &
                                                    readiness bekletilir
```

## Readiness ve liveness — kilit ayrım

```text
Readiness TRAFİĞİ kontrol eder:
  → readiness'i başarısız olan bir Pod, Service load-balancer'dan ÇIKARILIR,
    ama çalışmaya devam eder (örn. cache ısıtıyor veya bir bağımlılık kapalı)
Liveness YAŞAMI kontrol eder:
  → liveness'i başarısız olan bir Pod ÖLDÜRÜLÜR ve restart edilir (kurtarılamaz derecede bozuk)
Readiness demek istediğiniz yerde liveness kullanmak gereksiz restart döngülerine yol açar.
```

## Probe tanımları

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      ports: [{ containerPort: 8080 }]

startupProbe:            # diğerleri devreye girmeden önce yavaş başlayana süre tanır
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = başlamak için 5 dk'ya kadar
        periodSeconds: 10

readinessProbe:          # trafiği denetle
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # sağlıksızsa restart et
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Probe mekanizmaları

```text
httpGet    → bir path'e GET; 2xx/3xx = geçer      (web app'ler için en yaygın)
tcpSocket  → bir TCP bağlantısı açabilir miyiz?    (HTTP olmayan servisler için)
exec       → bir komut çalıştır; exit 0 = geçer    (özel kontroller)
grpc       → yerel gRPC health check
Kilit ayarlar: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## Startup probe'ları neden var

```text
Yavaş başlayan app'ler (JVM ısınması, büyük migration'lar) eskiden liveness'ta çok büyük bir
initialDelaySeconds ayarlamaya zorlardı — bu da gerçek çökmelerin geç tespit edilmesine yol açardı.
startupProbe bunu düzeltir: yavaş açılışı korur ve YALNIZCA geçtikten sonra
liveness/readiness normal (sıkı) zamanlamalarıyla başlar.
```

```bash
kubectl describe pod app     # olaylarda probe hatalarını & restart nedenlerini gör
kubectl get pod app          # READY sütunu readiness'i; RESTARTS liveness'i yansıtır
```

## Neden önemli

Health probe'lar, Kubernetes'in kendini iyileştirmeyi ve güvenli trafik yönlendirmeyi sunma biçimidir; bu yüzden üç tipi ve her birini ne zaman kullanacağını anlamak elzem bir güvenilirlik bilgisidir. Çok önemli ayrım — birçok mühendisi tökezleten — **readiness** ile **liveness** arasındadır: readiness **trafiği** kontrol eder (başarısız bir Pod Service load-balancer'dan çıkarılır ama çalışmaya devam eder; ısınırken veya bir bağımlılık geçici olarak kapalıyken idealdir), liveness ise **yaşamı** kontrol eder (başarısız bir Pod öldürülür ve restart edilir; kurtarılamayacak kadar deadlock'ta olduğunda). İkisini karıştırmak — readiness demek istenen yerde liveness probe kullanmak — gereksiz restart döngülerine ve kesintilere yol açar; bu yüzden her probe'un hangi soruyu yanıtladığını bilmek doğrudan pratiktir. **Startup** probe gerçek, tarihsel bir sıkıntıyı çözer: yavaş açılan app'ler eskiden liveness'ta çok büyük `initialDelaySeconds` değerlerini zorlardı (bu da gerçek çökmelerin tespitini geciktirirdi), oysa bir startup probe açılış penceresini korur ve liveness/readiness'in yalnızca startup başarılı olduktan sonra sıkı, normal zamanlamalarla çalışmasına izin verir. Probe mekanizmalarını (`httpGet`, `tcpSocket`, `exec`, `grpc`) ve ayar düğmelerini (`initialDelaySeconds`, `periodSeconds`, `failureThreshold` vb.) anlamak, health check'i tahminle değil doğru şekilde yapılandırmanızı sağlar. Probe'lar, kullanıcıların sağlıklı Pod'lara ulaşıp ulaşmadığını ve bozuk Pod'ların otomatik kurtarılıp kurtarılmadığını doğrudan belirlediğinden, onları doğru yapmak Kubernetes'te güvenilir, production seviyesinde workload'lar çalıştırmanın temelidir.

Üç probe bir bakışta

Readiness ve liveness — kilit ayrım

Probe tanımları

Probe mekanizmaları

Startup probe'ları neden var

Neden önemli

İlgili sorular