Probe

Probe adalah pemeriksaan berkala yang dilakukan kubelet terhadap container, dan hasilnya menentukan tindakan pada tingkat Pod, Service, maupun pemeriksaan lain. Topik ini membahas tiga jenis probe beserta metode pemeriksaannya, akibat kegagalan masing-masing, parameter pengaturannya, serta manifest yang menggabungkan semuanya. Transisi keadaan Pod saat probe gagal disimulasikan secara deterministik, sehingga akibatnya dapat dibandingkan tanpa kluster.

Tiga jenis probe#

Kubernetes menyediakan tiga jenis probe dengan tujuan berbeda, yaitu liveness, readiness, dan startup. Ketiganya menggunakan metode pemeriksaan yang sama, sehingga pembedanya terletak pada akibat kegagalan, bukan pada cara memeriksa. Pemilihan jenis yang tepat menentukan apakah Pod direstart, ditarik dari trafik, atau diberi waktu lebih lama untuk bangun.

Setiap probe dinyatakan dengan satu handler. Handler httpGet mengirim permintaan HTTP ke path dan port tertentu lalu menilai kode statusnya, handler tcpSocket hanya menguji apakah port terbuka, dan handler exec menjalankan perintah di dalam container lalu menilai kode keluarnya. Kode status 2xx dan 3xx dianggap berhasil untuk httpGet, sedangkan exec dianggap berhasil apabila perintah berhenti dengan kode keluar nol.

• Probe liveness menilai apakah container masih layak hidup. Kegagalan beruntun di atas ambang yang ditetapkan membuat kubelet merestart container, sehingga keadaan macet yang tidak dapat pulih dengan sendirinya diputus secara paksa.
• Probe readiness menilai apakah Pod siap menerima trafik. Kegagalan beruntun tidak menyentuh container, melainkan mengubah kondisi Ready Pod menjadi false, sehingga Pod dikeluarkan dari daftar backend Service.
• Probe startup melindungi aplikasi yang lambat bangun. Probe liveness dan readiness ditunda sampai startup probe berhasil, sehingga waktu pemuatan yang panjang tidak dihitung sebagai kegagalan.

Perilaku kegagalan tiap probe#

Kegagalan liveness berujung pada restart container oleh kubelet sesuai restartPolicy Pod. Proses yang macet diberi kesempatan memulai dari awal, tetapi permintaan yang sedang diproses saat restart ikut hilang, dan Pod tetap terdaftar pada Service sampai readiness menilai ulang kondisinya. Restart yang berulang terlihat pada kolom RESTARTS perintah kubectl get pods, sehingga pola kegagalannya mudah dikenali.

Kegagalan readiness bekerja pada lapisan lain. Pod tetap berjalan penuh, tetapi kondisi Ready berubah menjadi false, sehingga Pod dihapus dari daftar endpoint Service dan tidak lagi menerima koneksi baru. Setelah probe kembali berhasil, Pod otomatis masuk kembali ke daftar tersebut. Mekanisme ini digunakan untuk menahan Pod agar tidak menerima trafik, misalnya saat Pod sedang memuat data berat atau sedang dimatikan secara teratur.

Kegagalan startup memicu restart container sebagaimana liveness, karena startup probe pada dasarnya adalah liveness yang ditangguhkan untuk masa awal. Sebelum startup berhasil, liveness dan readiness tidak dijalankan sama sekali, sehingga aplikasi yang lambat tidak dianggap gagal selama masih berada dalam toleransi. Diagram berikut merangkum akibat kegagalan ketiga jenis probe.

Parameter pengaturan probe#

Setiap probe menerima parameter yang mengatur ritme pemeriksaannya. Parameter berikut tersedia untuk ketiga jenis probe, dan nilainya ditulis di dalam kunci probe pada spesifikasi container. Nilai yang tidak ditulis mengikuti default pada skema API.

Kombinasi parameter menentukan kepekaan probe. failureThreshold yang kecil dengan periodSeconds pendek membuat kegagalan singkat langsung menimbulkan aksi, tetapi juga meningkatkan risiko restart yang tidak diperlukan. Sebaliknya, ambang yang longgar menunda deteksi kegagalan yang sesungguhnya. Untuk aplikasi yang pemuatannya lama, startupProbe menggantikan initialDelaySeconds yang besar, karena jumlah percobaannya dihitung dari periodSeconds dikali failureThreshold.

Pemeriksaan juga menuntut sumber daya kecil namun nyata, karena httpGet menambah permintaan pada aplikasi yang diperiksa. Interval yang rapat pada ribuan Pod berarti ribuan permintaan tambahan setiap detik. Menyeimbangkan interval dengan risiko deteksi yang lambat menjadi bagian dari desain aplikasi yang berjalan di kluster.

Manifest dan simulasi transisi#

Manifest berikut menggabungkan ketiga jenis probe pada satu Pod web server. Startup probe memeriksa setiap lima detik dengan toleransi tiga puluh kegagalan, readiness memeriksa setiap lima detik, dan liveness memeriksa setiap sepuluh detik setelah jeda awal sepuluh detik. Ketiganya menunjuk handler httpGet yang sama, sehingga perbedaan antarprobe hanya terletak pada parameternya.

apiVersion: v1
kind: Pod
metadata:
  name: web-berprobe
  labels:
    app: web
spec:
  containers:
    - name: web
      image: nginx:1.27
      ports:
        - containerPort: 80
      startupProbe:
        httpGet:
          path: /
          port: 80
        periodSeconds: 5
        failureThreshold: 30
      readinessProbe:
        httpGet:
          path: /
          port: 80
        periodSeconds: 5
      livenessProbe:
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 10
        periodSeconds: 10
        failureThreshold: 3

Susunan parameter pada manifest mengikuti pola yang lazim. Startup probe memberi waktu awal yang longgar, sehingga initialDelaySeconds pada liveness tidak perlu diberi nilai besar. Readiness tanpa initialDelaySeconds membuat Pod masuk ke Service hanya setelah benar-benar siap, sedangkan liveness tetap menangani keadaan macet pada kondisi stabil.

Transisi keadaan Pod ketika probe gagal dapat disimulasikan secara deterministik tanpa kluster. Skrip Python berikut menjalankan dua skenario dengan urutan hasil yang ditetapkan langsung, yaitu liveness dengan failureThreshold 3 dan readiness dengan failureThreshold 2, kemudian mencetak akibat setiap langkahnya.

"""Simulasi deterministik transisi pod ketika probe gagal."""
AMBANG_LIVENESS = 3
AMBANG_READINESS = 2


def jalankan(nama_probe, urutan_hasil, ambang):
    """Mencetak keadaan pod pada setiap langkah pemeriksaan."""
    print(f"Skenario {nama_probe} (failureThreshold {ambang})")
    kegagalan = 0
    restart = 0
    di_endpoint = True
    for langkah, hasil in enumerate(urutan_hasil, start=1):
        if hasil == "gagal":
            kegagalan += 1
        else:
            kegagalan = 0
        if kegagalan >= ambang:
            if nama_probe == "liveness":
                restart += 1
                kegagalan = 0
                print(f"langkah {langkah}: gagal ke-{ambang} -> kubelet merestart container (restart {restart})")
            else:
                di_endpoint = False
                print(f"langkah {langkah}: gagal ke-{ambang} -> pod dikeluarkan dari endpoint (restart tetap {restart})")
        elif nama_probe == "readiness" and not di_endpoint and hasil == "sukses":
            di_endpoint = True
            print(f"langkah {langkah}: sukses -> pod kembali masuk endpoint")
        elif nama_probe == "liveness" and restart > 0 and hasil == "sukses" and langkah > 1:
            print(f"langkah {langkah}: sukses -> probe berjalan kembali setelah restart")
        else:
            print(f"langkah {langkah}: {hasil} -> keadaan tidak berubah (kegagalan {kegagalan}/{ambang})")
    print()


jalankan("liveness", ["sukses", "sukses", "gagal", "gagal", "gagal", "sukses"], AMBANG_LIVENESS)
jalankan("readiness", ["sukses", "gagal", "gagal", "sukses"], AMBANG_READINESS)

Skenario liveness (failureThreshold 3)
langkah 1: sukses -> keadaan tidak berubah (kegagalan 0/3)
langkah 2: sukses -> keadaan tidak berubah (kegagalan 0/3)
langkah 3: gagal -> keadaan tidak berubah (kegagalan 1/3)
langkah 4: gagal -> keadaan tidak berubah (kegagalan 2/3)
langkah 5: gagal ke-3 -> kubelet merestart container (restart 1)
langkah 6: sukses -> probe berjalan kembali setelah restart

Skenario readiness (failureThreshold 2)
langkah 1: sukses -> keadaan tidak berubah (kegagalan 0/2)
langkah 2: gagal -> keadaan tidak berubah (kegagalan 1/2)
langkah 3: gagal ke-2 -> pod dikeluarkan dari endpoint (restart tetap 0)
langkah 4: sukses -> pod kembali masuk endpoint

Keluaran kedua skenario memperlihatkan perbedaan akibatnya. Pada skenario liveness, kegagalan beruntun sampai ambang ketiga memicu restart container oleh kubelet, lalu pemeriksaan berjalan kembali setelahnya. Pada skenario readiness, kegagalan beruntun sampai ambang kedua hanya mengeluarkan Pod dari endpoint dengan jumlah restart tetap nol, dan Pod kembali masuk endpoint begitu probe berhasil lagi. Perbedaan inilah yang menjadi dasar pemilihan jenis probe untuk setiap gejala aplikasi.

Ringkasan#

• Probe adalah pemeriksaan berkala kubelet terhadap container melalui handler httpGet, tcpSocket, atau exec.
• Liveness yang gagal di atas failureThreshold memicu restart container, readiness yang gagal mengeluarkan Pod dari endpoint Service, dan startup menunda keduanya sampai aplikasi siap.
• Parameter initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold, dan successThreshold mengatur kepekaan setiap probe.
• Restart dan pengeluaran Pod dari endpoint merupakan dua mekanisme berbeda yang tidak saling menggantikan, seperti ditunjukkan simulasi dua skenario.

Referensi#

• Configure Liveness, Readiness and Startup Probes — Kubernetes Docs — Panduan memasang ketiga jenis probe beserta contoh manifest dan handler-nya.
• Pod Lifecycle — Kubernetes Docs — Kondisi container, kondisi Pod Ready, dan peran probe dalam siklus hidup Pod.
• Pod v1 — Kubernetes API Reference — Skema field probe pada API v1 beserta default setiap parameter.