Liveness, Readiness and Startup Probes

บางครั้ง application ไม่ตอบสนองในขณะที่ container อยู่ในสถานะปกติ แต่ไม่สามารถรับและจัดการ request ที่เข้ามาได้ kubernetes มีวิธีในการ detect เพื่อ restart container สำหรับจัดการกับปัญหาเหล่านี้

Liveness Probes

การตรวจสอบสถานะของ contianer ภายใน pod ว่า alive และมี healthy อยู่ไหม

ตัวอย่าง contianer ที่ใช้ HTTP Protocol

livenessProbe:
  httpGet:
    path: /healthz
    port: 3000
  initialDelaySeconds: 3
  periodSeconds: 3
  failureThreshold: 2

httpGet คือการบอกให้ kubernetes request ไปที่ /healthz port 3000 ถ้า HTTP status code ไม่ใช่ 2xx หรือ 3xx จะถือ application หยุดทำงานและ restart container เพื่อเริ่มใหม่

• initialDelaySeconds หลังจาก container ถูกสร้าง ให้รอนานแค่ไหนถึงจะเริ่ม livenessProbe (Default 0) ควรตั้งค่าเพื่อป้องกันการ loop check ตอน application ไม่พร้อมทำงาน

• periodSeconds ไม่ใช่เรื่องดีแน่ถ้า /healthz มีการเรียก 1000 ครั้งต่อวินาที ค่านี้คือการระบุความถี่ในการตรวจสอบ livenessProbe ในตัวอย่างคือ ทุกๆ 3 วินาที (Default 10)

• failureThreshold กำหนดจำนวนครั้งที่ livenessProbe สามารถ fail ได้ (Default 3)

Endpoint /healthz เป็น common practice เหตุผลที่ z เพียงให้แน่ใจว่าจะไม่ชนกับ path ที่มีอยู่

Other Types of Probes

• TCP liveness probe

• gRPC liveness probe

• Liveness command

Readiness Probes

โดยปกติเมื่อ pod เริ่มทำงาน kubernetes จะเริ่มส่ง traffic ให้กับ container ในบางครั้ง ตอนที่เรา start application จะมี process ใน setup ค่าต่างๆ ก่อน ถึงจะเริ่มทำงานได้

readinessProbe:
   tcpSocket:
     port: 8080
   initialDelaySeconds: 5
   periodSeconds: 10

readinessProbe คือการบอกให้ kubernetes รอจนกว่า container ภายใน pod จะพร้อมใช้งาน ค่อยส่ง request มาให้ เพื่อไม่ให้ users เจอ errors ที่เกิดจาก container unready readinessProbe ต่างจาก livenessProbe ตรงที่ จะไม่ kill และ restart ใหม่ จากรูปด้านล่าง container ที่ยังไม่พร้อมใช้งานจะแสดง status running แต่ ready จะแสดง container ที่ไม่พร้อมใช้งาน 1 รายการ

Startup Probes

ในตอนที่ kubernetes start pod ขึ้นมา ถ้า livenessProbe พบว่า failureThreshold ครบจำนวนครั้งที่เราตั้งไว้จะ kill และ restart pod ใหม่ ในบางครั้ง application ก็ไม่สามารถเริ่มทำงานได้ทันที เช่น ต้องรอ initial database, seed data หรือรอ connection ต่างๆ เราสามารถกำหนด startupProbe เพื่อให้ livenessProbe รอจนกว่า startupProbe ตรวจสอบเสร็จ ค่อยเริ่มการตรวจสอบความพร้อมใช้งาน หากไม่สำเร็จจะ kill และ restart pod ใหม่ ตามปกติ

livenessProbe:
  httpGet:
    path: /healthz
    port: 3000
  failureThreshold: 2
  periodSeconds: 1
startupProbe:
  httpGet:
    path: /healthz
    port: 3000
  failureThreshold: 30
  periodSeconds: 10

จากตัวอย่างด้านบน livenessProbe จะพิจารณาว่า pod นั้น unhealthy จาก failureThreshold 2 ครั้ง เราให้เวลาในการ start application มากขึ้น โดยการกำหนด failureThreshold 30 ครั้ง ที่ startupProbe โดยหวังว่าจะป้องการสถานการณ์ที่ pod เริ่มทำงานช้าและ livenessProbe restart ก่อนที่ application จะ setup สำเร็จ ☺️