Apakah itu liveness, readiness, dan startup probe, dan bila anda menggunakan setiap satu?

Question

IT Interview Practice · Accepted Answer

Probe membolehkan kubelet memeriksa kesihatan kontena dan bertindak atas keputusannya. Ada tiga: **liveness** (adakah ia hidup, atau patut di-restart?), **readiness** (adakah ia sedia menerima trafik?), dan **startup** (adakah ia sudah selesai but?). Setiap satu menjawab soalan yang berbeza.

## Ketiga-tiga probe sekilas pandang

```text
LIVENESS   → "Adakah app tersekat/deadlock?"    GAGAL → kubelet RESTART kontena
READINESS  → "Boleh ia layan trafik sekarang?"  GAGAL → Pod dibuang dari endpoint Service
                                                        (BUKAN di-restart)
STARTUP    → "Sudahkah but yang lambat selesai?" jalan DAHULU; semasa ia jalan, liveness &
                                                 readiness ditangguhkan
```

## Readiness berbanding liveness — perbezaan utama

```text
Readiness mengawal TRAFIK:
  → satu Pod yang gagal readiness DIKELUARKAN dari load-balancer Service,
    tetapi terus berjalan (cth. sedang memanaskan cache atau satu kebergantungan down)
Liveness mengawal HAYAT:
  → satu Pod yang gagal liveness DIBUNUH dan di-restart (ia rosak tak boleh pulih)
Menggunakan liveness sedangkan maksud anda readiness menyebabkan gelung restart yang sia-sia.
```

## Takrifan probe

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

startupProbe:            # beri app yang lambat mula masa sebelum yang lain masuk
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = sehingga 5 min untuk mula
        periodSeconds: 10

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

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

## Mekanisme probe

```text
httpGet    → GET satu path; 2xx/3xx = lulus     (paling biasa untuk web app)
tcpSocket  → boleh buka sambungan TCP?           (untuk perkhidmatan bukan HTTP)
exec       → jalankan satu arahan; exit 0 = lulus (semakan tersuai)
grpc       → health check gRPC asli
Tombol utama: initialDelaySeconds, periodSeconds, timeoutSeconds,
              failureThreshold, successThreshold.
```

## Mengapa startup probe wujud

```text
App yang lambat mula (JVM warmup, migrasi besar) dahulu memaksa anda menetapkan
initialDelaySeconds yang sangat besar pada liveness — yang kemudiannya menjadikan crash sebenar lambat dikesan.
startupProbe membetulkan ini: ia melindungi but yang lambat, dan HANYA selepas ia lulus barulah
liveness/readiness bermula dengan pemasaan (ketat) biasa mereka.
```

```bash
kubectl describe pod app     # lihat kegagalan probe & sebab restart dalam events
kubectl get pod app          # lajur READY mencerminkan readiness; RESTARTS mencerminkan liveness
```

## Mengapa ia penting

Health probe ialah cara Kubernetes menyampaikan self-healing dan penghalaan trafik yang selamat, jadi memahami ketiga-tiga jenis dan bila menggunakan setiap satu ialah pengetahuan kebolehpercayaan yang penting. Perbezaan penting — yang menjatuhkan ramai jurutera — ialah antara **readiness** dan **liveness**: readiness mengawal **trafik** (satu Pod yang gagal dikeluarkan dari load-balancer Service tetapi terus berjalan, sesuai ketika ia sedang memanas atau satu kebergantungan sementara down), manakala liveness mengawal **hayat** (satu Pod yang gagal dibunuh dan di-restart, untuk apabila ia deadlock tak boleh pulih). Mengelirukan kedua-duanya — menggunakan liveness probe di tempat readiness dimaksudkan — menyebabkan gelung restart sia-sia dan gangguan, jadi mengetahui soalan mana setiap probe menjawab adalah amat praktikal. Probe **startup** menyelesaikan kesakitan sejarah yang sebenar: app yang lambat but pernah memaksa `initialDelaySeconds` yang besar pada liveness (yang melambatkan pengesanan crash sebenar), sedangkan startup probe melindungi tetingkap but dan membiarkan liveness/readiness berjalan dengan pemasaan ketat dan biasa hanya setelah startup berjaya. Memahami mekanisme probe (`httpGet`, `tcpSocket`, `exec`, `grpc`) dan tombol penalaan (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, dsb.) membolehkan anda mengkonfigurasi semakan kesihatan dengan betul dan bukan secara meneka. Kerana probe secara langsung menentukan sama ada pengguna mencapai Pod yang sihat dan sama ada Pod yang rosak pulih secara automatik, membetulkannya adalah asas untuk menjalankan workload yang boleh dipercayai dan bertaraf production pada Kubernetes.

Ketiga-tiga probe sekilas pandang

Readiness berbanding liveness — perbezaan utama

Takrifan probe

Mekanisme probe

Mengapa startup probe wujud

Mengapa ia penting

Soalan berkaitan