Apa itu liveness, readiness, dan startup probe, dan kapan masing-masing dipakai?

Question

IT Interview Practice · Accepted Answer

Probe memungkinkan kubelet memeriksa kesehatan sebuah container dan bertindak atas hasilnya. Ada tiga: **liveness** (apakah masih hidup, atau harus di-restart?), **readiness** (apakah siap menerima trafik?), dan **startup** (apakah sudah selesai boot?). Masing-masing menjawab pertanyaan yang berbeda.

## Ketiga probe sekilas

```text
LIVENESS   → "Apakah app macet/deadlock?"         FAIL → kubelet me-RESTART container
READINESS  → "Bisakah melayani trafik sekarang?"  FAIL → Pod dihapus dari endpoint Service
                                                          (TIDAK di-restart)
STARTUP    → "Sudahkah boot yang lambat selesai?"  jalan DULUAN; selama berjalan, liveness &
                                                   readiness ditahan
```

## Readiness vs liveness — perbedaan kuncinya

```text
Readiness mengendalikan TRAFIK:
  → Pod yang gagal readiness ditarik KELUAR dari load-balancer Service,
    tapi tetap berjalan (mis. sedang memanaskan cache atau sebuah dependency mati)
Liveness mengendalikan HIDUP-MATI:
  → Pod yang gagal liveness DIBUNUH dan di-restart (rusak tak bisa pulih)
Memakai liveness padahal maksud Anda readiness menyebabkan restart loop yang sia-sia.
```

## Definisi probe

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

startupProbe:            # beri waktu pada yang lambat start sebelum yang lain aktif
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = hingga 5 menit untuk start
        periodSeconds: 10

readinessProbe:          # saring trafik
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # restart jika tidak sehat
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Mekanisme probe

```text
httpGet    → GET sebuah path; 2xx/3xx = lulus    (paling umum untuk web app)
tcpSocket  → bisakah membuka koneksi TCP?        (untuk service non-HTTP)
exec       → jalankan perintah; exit 0 = lulus   (pemeriksaan kustom)
grpc       → health check gRPC native
Knob utama: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## Mengapa startup probe ada

```text
App yang lambat start (JVM warmup, migrasi besar) dulu memaksa Anda menyetel
initialDelaySeconds yang sangat besar pada liveness — yang lalu membuat crash asli
lambat terdeteksi. startupProbe memperbaiki ini: ia melindungi boot yang lambat, dan
HANYA setelah ia lulus barulah liveness/readiness mulai dengan timing normal (ketat).
```

```bash
kubectl describe pod app     # lihat kegagalan probe & alasan restart di event
kubectl get pod app          # kolom READY mencerminkan readiness; RESTARTS mencerminkan liveness
```

## Mengapa ini penting

Health probe adalah cara Kubernetes menghadirkan self-healing dan routing trafik yang aman, sehingga memahami ketiga tipe dan kapan memakai masing-masing adalah pengetahuan keandalan yang esensial. Perbedaan krusial — yang menjebak banyak insinyur — adalah antara **readiness** dan **liveness**: readiness mengendalikan **trafik** (Pod yang gagal ditarik keluar dari load-balancer Service tapi tetap berjalan, ideal ketika ia sedang warming up atau sebuah dependency sementara mati), sedangkan liveness mengendalikan **hidup-mati** (Pod yang gagal dibunuh dan di-restart, untuk ketika ia deadlock tak bisa pulih). Mengacaukan keduanya — memakai liveness probe padahal readiness yang dimaksud — menyebabkan restart loop dan outage yang sia-sia, sehingga mengetahui pertanyaan mana yang dijawab tiap probe sangat praktis. **Startup** probe memecahkan kepedihan historis yang nyata: app yang lambat boot dulu memaksa `initialDelaySeconds` yang besar pada liveness (yang menunda deteksi crash sungguhan), sedangkan startup probe melindungi jendela boot dan membiarkan liveness/readiness berjalan dengan timing yang ketat dan normal hanya setelah startup berhasil. Memahami mekanisme probe (`httpGet`, `tcpSocket`, `exec`, `grpc`) dan knob penyetelan (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, dll.) memungkinkan Anda mengonfigurasi pemeriksaan kesehatan dengan benar alih-alih menebak-nebak. Karena probe langsung menentukan apakah pengguna mengenai Pod yang sehat dan apakah Pod yang rusak pulih otomatis, menyetelnya dengan tepat adalah fondasi untuk menjalankan workload yang andal dan berkelas production di Kubernetes.

Ketiga probe sekilas

Readiness vs liveness — perbedaan kuncinya

Definisi probe

Mekanisme probe

Mengapa startup probe ada

Mengapa ini penting

Pertanyaan terkait