liveness, readiness และ startup probe คืออะไร และคุณใช้แต่ละตัวเมื่อไร?

Question

IT Interview Practice · Accepted Answer

Probe ให้ kubelet ตรวจสุขภาพของ container และดำเนินการตามผล มีสามชนิด: **liveness** (มันยังมีชีวิตอยู่หรือควร restart?), **readiness** (พร้อมรับทราฟฟิกหรือยัง?) และ **startup** (บูตเสร็จหรือยัง?) แต่ละชนิดตอบคำถามที่ต่างกัน

## สาม probe มองผ่าน ๆ

```text
LIVENESS   → "แอปค้าง/deadlock ไหม?"          FAIL → kubelet RESTART container
READINESS  → "รับทราฟฟิกตอนนี้ได้ไหม?"        FAIL → Pod ถูกถอดจาก endpoint ของ Service
                                                       (ไม่ restart)
STARTUP    → "บูตช้าเสร็จหรือยัง?"             รันก่อน; ระหว่างที่รัน liveness &
                                                readiness ถูกหน่วงไว้
```

## Readiness เทียบกับ liveness — ความแตกต่างสำคัญ

```text
Readiness ควบคุมทราฟฟิก (TRAFFIC):
  → Pod ที่ fail readiness จะถูกดึงออกจาก load-balancer ของ Service
    แต่ยังรันอยู่ (เช่น กำลัง warm cache หรือ dependency ล่ม)
Liveness ควบคุมชีวิต (LIFE):
  → Pod ที่ fail liveness จะถูก KILL แล้ว restart (พังเกินกู้)
การใช้ liveness ตรงที่ควรเป็น readiness ทำให้เกิด restart loop โดยไม่จำเป็น
```

## นิยาม probe

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

startupProbe:            # ให้เวลาแอปที่เริ่มช้า ก่อนตัวอื่นเริ่มทำงาน
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = ได้ถึง 5 นาทีในการเริ่ม
        periodSeconds: 10

readinessProbe:          # ควบคุมทราฟฟิก
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # restart ถ้าไม่แข็งแรง
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## กลไกของ probe

```text
httpGet    → GET path หนึ่ง; 2xx/3xx = ผ่าน       (พบบ่อยสุดสำหรับ web app)
tcpSocket  → เปิดการเชื่อมต่อ TCP ได้ไหม?          (สำหรับ service ที่ไม่ใช่ HTTP)
exec       → รันคำสั่ง; exit 0 = ผ่าน               (การตรวจแบบกำหนดเอง)
grpc       → health check แบบ gRPC โดยตรง
ปุ่มปรับสำคัญ: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold
```

## ทำไมจึงมี startup probe

```text
แอปที่เริ่มช้า (JVM warmup, migration ใหญ่) เคยบังคับให้ตั้ง
initialDelaySeconds ที่ใหญ่มากบน liveness — ซึ่งทำให้ตรวจพบ crash จริงช้า
startupProbe แก้ปัญหานี้: มันปกป้องช่วงบูตช้า และเฉพาะหลังจากมันผ่านเท่านั้น
liveness/readiness จึงเริ่มด้วย timing (ที่รัดกุม) ปกติ
```

```bash
kubectl describe pod app     # ดู probe ที่ fail & เหตุผลการ restart ใน events
kubectl get pod app          # คอลัมน์ READY สะท้อน readiness; RESTARTS สะท้อน liveness
```

## ทำไมจึงสำคัญ

Health probe คือวิธีที่ Kubernetes มอบ self-healing และการ route ทราฟฟิกอย่างปลอดภัย ดังนั้นการเข้าใจทั้งสามชนิดและว่าจะใช้แต่ละตัวเมื่อไรจึงเป็นความรู้ด้านความน่าเชื่อถือที่จำเป็น ความแตกต่างที่สำคัญ — ตัวที่ทำให้วิศวกรหลายคนสะดุด — คือระหว่าง **readiness** และ **liveness**: readiness ควบคุม **ทราฟฟิก** (Pod ที่ fail จะถูกดึงออกจาก load-balancer ของ Service แต่ยังรันอยู่ เหมาะเมื่อกำลัง warm up หรือ dependency ล่มชั่วคราว) ขณะที่ liveness ควบคุม **ชีวิต** (Pod ที่ fail จะถูก kill แล้ว restart สำหรับตอนที่มัน deadlock เกินกู้) การสับสนทั้งสอง — ใช้ liveness probe ตรงที่ตั้งใจให้เป็น readiness — ทำให้เกิด restart loop โดยไม่จำเป็นและเกิด outage ดังนั้นการรู้ว่าแต่ละ probe ตอบคำถามใดจึงเป็นเรื่องเชิงปฏิบัติโดยตรง **Startup** probe แก้ปัญหาความเจ็บปวดในประวัติศาสตร์ที่แท้จริง: แอปที่บูตช้าเคยบังคับให้ตั้ง `initialDelaySeconds` ใหญ่มากบน liveness (ซึ่งหน่วงการตรวจพบ crash จริง) ขณะที่ startup probe ปกป้องช่วงบูตและให้ liveness/readiness รันด้วย timing ที่รัดกุมและปกติเฉพาะเมื่อ startup สำเร็จ การเข้าใจกลไก probe (`httpGet`, `tcpSocket`, `exec`, `grpc`) และปุ่มปรับ (`initialDelaySeconds`, `periodSeconds`, `failureThreshold` ฯลฯ) ทำให้คุณตั้งค่า health check ได้ถูกต้องแทนที่จะเดา เพราะ probe กำหนดโดยตรงว่าผู้ใช้จะเข้าถึง Pod ที่แข็งแรงหรือไม่และ Pod ที่พังจะกู้คืนโดยอัตโนมัติหรือไม่ การทำให้มันถูกต้องจึงเป็นรากฐานของการรัน workload ที่น่าเชื่อถือระดับ production บน Kubernetes

สาม probe มองผ่าน ๆ

Readiness เทียบกับ liveness — ความแตกต่างสำคัญ

นิยาม probe

กลไกของ probe

ทำไมจึงมี startup probe

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง