Belajar Kubernetes - Episode 10 - Pengenalan dan Penjelasan Probe

#Pendahuluan

Di episode sebelumnya kita sudah belajar tentang berbagai metode untuk menghapus Pod di Kubernetes. Selanjutnya di episode 10 kali ini, kita akan coba bahas konsep penting untuk memastikan kesehatan dan ketersediaan aplikasi yaitu Probe.

Catatan: Disini saya akan menggunakan Kubernetes Cluster yang di install melalui K3s.

Probe adalah health check yang Kubernetes gunakan untuk menentukan apakah aplikasi kalian berjalan dengan benar. Mereka membantu Kubernetes membuat keputusan intelligent tentang kapan restart container, kapan mengirim traffic ke Pod, dan kapan aplikasi siap menerima request. Memahami Probe sangat penting untuk membangun aplikasi yang resilient dan highly available di Kubernetes.

#Apa Itu Probe?

Probe adalah diagnostic check yang Kubernetes lakukan pada container untuk menentukan status kesehatan mereka. Bayangkan Probe seperti dokter yang memeriksa vital sign kalian - mereka secara periodik memeriksa apakah aplikasi kalian sehat dan berfungsi dengan benar.

Kubernetes menyediakan tiga tipe Probe:

• Liveness Probe - Memeriksa apakah container hidup dan berjalan
• Readiness Probe - Memeriksa apakah container siap menerima traffic
• Startup Probe - Memeriksa apakah aplikasi sudah berhasil start

Setiap tipe Probe memiliki tujuan berbeda dan membantu Kubernetes mengelola application lifecycle kalian secara efektif.

#Kenapa Kita Butuh Probe?

Tanpa Probe, Kubernetes tidak punya cara untuk mengetahui apakah aplikasi kalian benar-benar bekerja dengan benar. Container mungkin berjalan, tapi aplikasi di dalamnya bisa:

• Deadlock - Process berjalan tapi tidak merespons
• Crash - Aplikasi crash tapi container masih berjalan
• Overload - Aplikasi terlalu sibuk untuk handle request baru
• Starting up - Aplikasi masih initialize dan belum siap

Probe membantu Kubernetes mendeteksi situasi ini dan mengambil tindakan yang tepat:

• Restart unhealthy container - Otomatis recover dari failure
• Menghapus unhealthy Pod dari load balancing - Mencegah pengiriman traffic ke Pod yang rusak
• Menunggu slow-starting application - Memberi aplikasi waktu untuk initialize

#Tipe-Tipe Probe

Mari kita explore setiap tipe Probe secara detail:

#Liveness Probe

Liveness Probe menentukan apakah container berjalan dengan benar. Jika Liveness Probe gagal, Kubernetes akan kill container dan restart sesuai dengan restart policy Pod.

Use case untuk Liveness Probe:

• Mendeteksi deadlock aplikasi
• Recover dari application crash
• Restart container yang ada di broken state
• Handle memory leak dengan restart container secara periodik

Contoh skenario: Aplikasi kalian punya memory leak dan menjadi unresponsive setelah berjalan beberapa waktu. Liveness Probe bisa mendeteksi ini dan restart container secara otomatis.

#Readiness Probe

Readiness Probe menentukan apakah container siap menerima traffic. Jika Readiness Probe gagal, Kubernetes akan menghapus Pod dari Service endpoint, mencegah traffic dikirim ke Pod tersebut.

Use case untuk Readiness Probe:

• Menunggu dependency tersedia (database, cache, dll)
• Temporarily menghapus overload Pod dari load balancing
• Mencegah traffic selama application update atau maintenance
• Handle graceful shutdown scenario

Contoh skenario: Aplikasi kalian perlu connect ke database sebelum bisa serve request. Readiness Probe memastikan traffic hanya dikirim setelah database connection established.

Perbedaan kunci dari Liveness Probe: Readiness Probe failure tidak restart container - mereka hanya stop mengirim traffic ke container tersebut.

#Startup Probe

Startup Probe digunakan untuk container yang membutuhkan waktu lama untuk start. Probe ini disable Liveness dan Readiness Probe sampai aplikasi berhasil start.

Use case untuk Startup Probe:

• Aplikasi dengan slow initialization
• Legacy aplikasi yang butuh waktu untuk start
• Aplikasi yang perlu load dataset besar saat startup
• Mencegah premature restart selama initialization

Contoh skenario: Aplikasi kalian perlu load dataset 5GB ke memory saat startup, yang membutuhkan 2 menit. Startup Probe memberi waktu untuk initialize tanpa di-kill oleh Liveness Probe.

#Mekanisme Probe

Kubernetes support tiga mekanisme untuk melakukan Probe:

#HTTP GET Request

Kubernetes mengirim HTTP GET request ke path dan port yang di-specify. Probe succeed jika response status code antara 200 dan 399.

yml

livenessProbe:
    httpGet:
        path: /healthz
        port: 8080
    initialDelaySeconds: 3
    periodSeconds: 3

Terbaik untuk: Web aplikasi, REST API, HTTP service

#TCP Socket

Kubernetes mencoba membuka TCP connection ke port yang di-specify. Probe succeed jika connection established.

yml

livenessProbe:
    tcpSocket:
        port: 3306
    initialDelaySeconds: 5
    periodSeconds: 10

Terbaik untuk: Database, TCP service, aplikasi tanpa HTTP endpoint

#Exec Command

Kubernetes execute command di dalam container. Probe succeed jika command exit dengan status code 0.

yml

livenessProbe:
    exec:
        command:
            - cat
            - /tmp/healthy
    initialDelaySeconds: 5
    periodSeconds: 5

Terbaik untuk: Custom health check, file-based check, complex validation logic

#Parameter Konfigurasi Probe

Semua Probe support parameter konfigurasi ini:

#initialDelaySeconds

Waktu tunggu sebelum melakukan Probe pertama setelah container start.

yml

initialDelaySeconds: 10  # Tunggu 10 detik sebelum check pertama

Default: 0 detik

#periodSeconds

Seberapa sering melakukan Probe.

yml

periodSeconds: 5  # Check setiap 5 detik

Default: 10 detik

#timeoutSeconds

Berapa lama menunggu Probe complete sebelum dianggap gagal.

yml

timeoutSeconds: 3  # Probe harus complete dalam 3 detik

Default: 1 detik

#successThreshold

Minimum consecutive success agar Probe dianggap successful setelah failure.

yml

successThreshold: 1  # Satu success sudah cukup

Default: 1 (harus 1 untuk Liveness dan Startup Probe)

#failureThreshold

Jumlah consecutive failure sebelum mengambil tindakan (restart container atau remove dari Service).

yml

failureThreshold: 3  # Fail 3 kali sebelum ambil tindakan

Default: 3

#Contoh Praktis

Mari kita buat contoh praktis untuk setiap tipe Probe:

#Contoh 1: HTTP Liveness Probe

Buat Pod dengan HTTP Liveness Probe:

liveness-http.yml

apiVersion: v1
kind: Pod
metadata:
    name: liveness-http
    labels:
        app: liveness-demo
spec:
    containers:
        - name: nginx
          image: nginx:1.25
          ports:
              - containerPort: 80
          livenessProbe:
              httpGet:
                  path: /
                  port: 80
              initialDelaySeconds: 3
              periodSeconds: 3
              timeoutSeconds: 1
              failureThreshold: 3

Apply konfigurasi:

bash

sudo kubectl apply -f liveness-http.yml

Verifikasi Pod berjalan:

bash

sudo kubectl get pods

Cek status Probe:

bash

sudo kubectl describe pod liveness-http

Kalian akan melihat event yang menunjukkan Liveness Probe bekerja:

bash

Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  30s   default-scheduler  Successfully assigned default/liveness-http to node1
  Normal  Pulled     29s   kubelet            Container image "nginx:1.25" already present on machine
  Normal  Created    29s   kubelet            Created container nginx
  Normal  Started    29s   kubelet            Started container nginx

#Contoh 2: Simulasi Liveness Probe Failure

Mari kita buat Pod yang akan fail Liveness Probe:

liveness-failure.yml

apiVersion: v1
kind: Pod
metadata:
    name: liveness-failure
spec:
    containers:
        - name: liveness-test
          image: busybox
          args:
              - /bin/sh
              - -c
              - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
          livenessProbe:
              exec:
                  command:
                      - cat
                      - /tmp/healthy
              initialDelaySeconds: 5
              periodSeconds: 5

Pod ini:

1. Membuat file /tmp/healthy
2. Sleep selama 30 detik
3. Menghapus file /tmp/healthy
4. Liveness Probe akan fail setelah file dihapus
5. Kubernetes akan restart container

Apply dan watch:

bash

sudo kubectl apply -f liveness-failure.yml
sudo kubectl get pods -w

Setelah sekitar 30 detik, kalian akan melihat container restart:

bash

NAME               READY   STATUS    RESTARTS   AGE
liveness-failure   1/1     Running   0          20s
liveness-failure   1/1     Running   1          45s
liveness-failure   1/1     Running   2          70s

Cek event:

bash

sudo kubectl describe pod liveness-failure

Kalian akan melihat event yang menunjukkan Liveness Probe gagal dan container di-restart:

bash

Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  2m                 default-scheduler  Successfully assigned default/liveness-failure to node1
  Normal   Pulled     2m                 kubelet            Container image "busybox" already present on machine
  Normal   Created    2m                 kubelet            Created container liveness-test
  Normal   Started    2m                 kubelet            Started container liveness-test
  Warning  Unhealthy  90s (x3 over 100s) kubelet            Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
  Normal   Killing    90s                kubelet            Container liveness-test failed liveness probe, will be restarted

#Contoh 3: Readiness Probe

Buat Pod dengan Liveness dan Readiness Probe:

readiness-probe.yml

apiVersion: v1
kind: Pod
metadata:
    name: readiness-demo
    labels:
        app: readiness-demo
spec:
    containers:
        - name: nginx
          image: nginx:1.25
          ports:
              - containerPort: 80
          livenessProbe:
              httpGet:
                  path: /
                  port: 80
              initialDelaySeconds: 3
              periodSeconds: 3
          readinessProbe:
              httpGet:
                  path: /
                  port: 80
              initialDelaySeconds: 5
              periodSeconds: 5
              failureThreshold: 3

Buat Service untuk melihat bagaimana Readiness Probe mempengaruhi traffic:

readiness-service.yml

apiVersion: v1
kind: Service
metadata:
    name: readiness-service
spec:
    selector:
        app: readiness-demo
    ports:
        - protocol: TCP
          port: 80
          targetPort: 80

Apply keduanya:

bash

sudo kubectl apply -f readiness-probe.yml
sudo kubectl apply -f readiness-service.yml

Cek endpoint:

bash

sudo kubectl get endpoints readiness-service

Kalian akan melihat Pod IP ditambahkan ke endpoint hanya setelah Readiness Probe succeed:

bash

NAME                ENDPOINTS         AGE
readiness-service   10.42.0.15:80     30s

#Contoh 4: Startup Probe untuk Slow-Starting Application

Buat Pod dengan Startup Probe:

startup-probe.yml

apiVersion: v1
kind: Pod
metadata:
    name: startup-demo
spec:
    containers:
        - name: slow-app
          image: nginx:1.25
          ports:
              - containerPort: 80
          startupProbe:
              httpGet:
                  path: /
                  port: 80
              initialDelaySeconds: 0
              periodSeconds: 10
              failureThreshold: 30  # 30 * 10 = 300 detik (5 menit) untuk start
          livenessProbe:
              httpGet:
                  path: /
                  port: 80
              initialDelaySeconds: 0
              periodSeconds: 10
          readinessProbe:
              httpGet:
                  path: /
                  port: 80
              initialDelaySeconds: 0
              periodSeconds: 10

Konfigurasi ini:

• Memberi aplikasi sampai 5 menit untuk start (30 failure × 10 detik)
• Liveness dan Readiness Probe di-disable sampai Startup Probe succeed
• Setelah startup, Liveness dan Readiness Probe mengambil alih

#Contoh 5: TCP Socket Probe untuk Database

Buat Pod dengan TCP Socket Probe:

tcp-probe.yml

apiVersion: v1
kind: Pod
metadata:
    name: mysql-pod
spec:
    containers:
        - name: mysql
          image: mysql:8.0
          env:
              - name: MYSQL_ROOT_PASSWORD
                value: "password123"
          ports:
              - containerPort: 3306
          livenessProbe:
              tcpSocket:
                  port: 3306
              initialDelaySeconds: 30
              periodSeconds: 10
          readinessProbe:
              tcpSocket:
                  port: 3306
              initialDelaySeconds: 10
              periodSeconds: 5

Ini memeriksa apakah MySQL menerima connection di port 3306.

#Contoh 6: Exec Command Probe

Buat Pod dengan custom health check script:

exec-probe.yml

apiVersion: v1
kind: Pod
metadata:
    name: exec-probe-demo
spec:
    containers:
        - name: app
          image: busybox
          command:
              - /bin/sh
              - -c
              - |
                  # Buat health check script
                  cat > /usr/local/bin/health-check.sh << 'EOF'
                  #!/bin/sh
                  # Custom health check logic
                  if [ -f /tmp/healthy ]; then
                      exit 0
                  else
                      exit 1
                  fi
                  EOF
                  chmod +x /usr/local/bin/health-check.sh
                  
                  # Jaga container tetap berjalan dan buat healthy file
                  touch /tmp/healthy
                  sleep 3600
          livenessProbe:
              exec:
                  command:
                      - /usr/local/bin/health-check.sh
              initialDelaySeconds: 5
              periodSeconds: 5

#Menggabungkan Multiple Probe

Di production, kalian biasanya menggunakan ketiga tipe Probe bersama-sama:

complete-probes.yml

apiVersion: v1
kind: Pod
metadata:
    name: complete-probes
    labels:
        app: web-app
spec:
    containers:
        - name: app
          image: nginx:1.25
          ports:
              - containerPort: 80
          # Startup Probe - untuk slow-starting application
          startupProbe:
              httpGet:
                  path: /healthz
                  port: 80
              initialDelaySeconds: 0
              periodSeconds: 10
              failureThreshold: 30  # 5 menit untuk start
          # Liveness Probe - restart jika unhealthy
          livenessProbe:
              httpGet:
                  path: /healthz
                  port: 80
              initialDelaySeconds: 0
              periodSeconds: 10
              timeoutSeconds: 5
              failureThreshold: 3
          # Readiness Probe - remove dari load balancer jika not ready
          readinessProbe:
              httpGet:
                  path: /ready
                  port: 80
              initialDelaySeconds: 0
              periodSeconds: 5
              timeoutSeconds: 3
              failureThreshold: 3

#Best Practice untuk Probe

#Gunakan Endpoint Berbeda untuk Probe Berbeda

Buat endpoint terpisah untuk Liveness dan Readiness:

• /healthz - Liveness check (basic health)
• /ready - Readiness check (dependency ready)

yml

livenessProbe:
    httpGet:
        path: /healthz
        port: 8080
readinessProbe:
    httpGet:
        path: /ready
        port: 8080

#Jaga Probe Check Tetap Lightweight

Probe check harus cepat dan tidak mengkonsumsi resource signifikan:

yml

# Bagus - simple check
livenessProbe:
    httpGet:
        path: /healthz
        port: 8080
    timeoutSeconds: 1  # Fast timeout
 
# Buruk - complex check yang mungkin timeout
livenessProbe:
    exec:
        command:
            - /bin/sh
            - -c
            - "complex-database-query.sh"  # Terlalu lambat!
    timeoutSeconds: 1

#Set Timeout yang Tepat

Beri Probe cukup waktu untuk complete, tapi tidak terlalu banyak:

yml

livenessProbe:
    httpGet:
        path: /healthz
        port: 8080
    timeoutSeconds: 3      # Reasonable timeout
    periodSeconds: 10      # Check setiap 10 detik
    failureThreshold: 3    # Fail 3 kali sebelum restart

#Gunakan Startup Probe untuk Slow Application

Jangan buat Liveness Probe menunggu terlalu lama - gunakan Startup Probe:

yml

# Pendekatan yang bagus
startupProbe:
    httpGet:
        path: /healthz
        port: 8080
    periodSeconds: 10
    failureThreshold: 30  # 5 menit untuk start
livenessProbe:
    httpGet:
        path: /healthz
        port: 8080
    periodSeconds: 10
    failureThreshold: 3   # Quick failure setelah startup

#Jangan Check External Dependency di Liveness Probe

Liveness Probe hanya harus check apakah aplikasi itu sendiri sehat:

yml

# Buruk - check external database
livenessProbe:
    exec:
        command:
            - check-database-connection.sh  # Jangan lakukan ini!
 
# Bagus - check hanya application health
livenessProbe:
    httpGet:
        path: /healthz  # Return 200 jika app berjalan
        port: 8080

Check external dependency di Readiness Probe:

yml

# Bagus - Readiness check dependency
readinessProbe:
    exec:
        command:
            - check-database-connection.sh  # OK untuk readiness

#Set initialDelaySeconds dengan Tepat

Beri aplikasi kalian waktu untuk start sebelum Probe pertama:

yml

livenessProbe:
    httpGet:
        path: /healthz
        port: 8080
    initialDelaySeconds: 30  # Tunggu 30 detik sebelum check pertama
    periodSeconds: 10

#Gunakan Readiness Probe untuk Zero-Downtime Deployment

Readiness Probe memastikan traffic hanya dikirim ke ready Pod:

yml

readinessProbe:
    httpGet:
        path: /ready
        port: 8080
    initialDelaySeconds: 5
    periodSeconds: 5
    failureThreshold: 1  # Remove dari load balancer immediately

#Kesalahan Umum dan Pitfall

#Kesalahan 1: Tidak Ada Probe Sama Sekali

Menjalankan Pod tanpa Probe berarti Kubernetes tidak bisa mendeteksi failure.

Problem: Aplikasi crash tapi container tetap berjalan. Kubernetes tidak tahu dan tetap mengirim traffic.

Solusi: Selalu implementasikan setidaknya Liveness dan Readiness Probe.

#Kesalahan 2: Menggunakan Endpoint yang Sama untuk Liveness dan Readiness

Menggunakan endpoint yang sama tidak membedakan antara "app is alive" dan "app is ready".

Problem: Database down, Readiness fail, tapi Liveness juga fail dan restart container secara tidak perlu.

Solusi: Gunakan endpoint berbeda dengan logic berbeda.

#Kesalahan 3: Probe Timeout Terlalu Pendek

Setting timeout terlalu pendek menyebabkan false failure.

Problem: Probe timeout selama operasi normal, menyebabkan restart yang tidak perlu.

Solusi: Set realistic timeout berdasarkan response time aplikasi kalian.

#Kesalahan 4: Check External Dependency di Liveness Probe

Liveness Probe hanya harus check aplikasi itu sendiri.

Problem: Database temporarily unavailable, Liveness fail, container restart, tapi database masih unavailable - restart loop.

Solusi: Check external dependency hanya di Readiness Probe.

#Kesalahan 5: Tidak Menggunakan Startup Probe untuk Slow Application

Menggunakan initialDelaySeconds tinggi di Liveness Probe delay failure detection.

Problem: Aplikasi crash setelah startup, tapi Liveness Probe menunggu 5 menit sebelum check.

Solusi: Gunakan Startup Probe untuk initialization, jaga Liveness Probe responsive.

#Kesalahan 6: Probe Check Terlalu Mahal

Heavy Probe check mengkonsumsi resource dan memperlambat aplikasi.

Problem: Liveness Probe menjalankan complex database query setiap 5 detik, overload database.

Solusi: Jaga Probe check tetap lightweight dan cepat.

#Monitoring Status Probe

#Check Status Probe di Pod Description

bash

sudo kubectl describe pod <nama-pod>

Cari section Probe:

bash

Containers:
  app:
    Liveness:     http-get http://:8080/healthz delay=0s timeout=1s period=10s #success=1 #failure=3
    Readiness:    http-get http://:8080/ready delay=0s timeout=1s period=5s #success=1 #failure=3
    Startup:      http-get http://:8080/healthz delay=0s timeout=1s period=10s #success=1 #failure=30

#Check Event untuk Probe Failure

bash

sudo kubectl get events --sort-by='.lastTimestamp'

Cari event seperti:

bash

Warning  Unhealthy  Liveness probe failed: HTTP probe failed with statuscode: 500
Warning  Unhealthy  Readiness probe failed: Get http://10.42.0.15:8080/ready: dial tcp 10.42.0.15:8080: connect: connection refused

#Watch Pod Restart

bash

sudo kubectl get pods -w

Frequent restart menunjukkan Liveness Probe failure:

bash

NAME      READY   STATUS    RESTARTS   AGE
app-pod   1/1     Running   5          10m

#Penutup

Pada episode 10 ini, kita telah membahas Probe di Kubernetes secara mendalam. Kita sudah belajar tentang tiga tipe Probe (Liveness, Readiness, dan Startup), tujuan mereka, dan cara mengkonfigurasi mereka secara efektif.

Key takeaway:

• Liveness Probe - Restart unhealthy container
• Readiness Probe - Kontrol traffic routing ke Pod
• Startup Probe - Handle slow-starting application
• Gunakan endpoint berbeda untuk tipe Probe berbeda
• Jaga Probe check tetap lightweight dan cepat
• Jangan check external dependency di Liveness Probe
• Gunakan timeout dan failure threshold yang tepat
• Kombinasikan ketiga Probe untuk production application

Probe sangat essential untuk membangun aplikasi resilient dan self-healing di Kubernetes. Dengan properly mengkonfigurasi Probe, kalian memastikan bahwa Kubernetes bisa otomatis mendeteksi dan recover dari failure, maintain high availability, dan menyediakan experience yang lebih baik untuk user kalian.

Bagaimana, makin jelas kan tentang Probe di Kubernetes? Pada episode berikutnya (Episode 11), kita akan membahas konsep fundamental lain yang membawa Kubernetes lebih dekat ke janji intinya yaitu infrastruktur yang dapat memperbaiki diri sendiri: ReplicationController.

ReplicationController adalah salah satu mekanisme paling awal di Kubernetes yang dirancang untuk memastikan bahwa sejumlah replika pod yang ditentukan selalu berjalan. Alih-alih membuat dan memantau pod satu per satu secara manual, Anda mendeklarasikan jumlah replika yang diinginkan, dan Kubernetes terus berupaya mempertahankan keadaan tersebut. Jika sebuah pod mengalami crash, terhapus, atau sebuah node gagal, ReplicationController secara otomatis membuat pod baru untuk menggantikannya.

Dengan kata lain, ReplicationController memperkenalkan ide penting di Kubernetes:

Keadaan yang diinginkan secara deklaratif.

Anda tidak memberi tahu Kubernetes bagaimana cara memulihkan diri ketika terjadi kerusakan—Anda cukup mendeklarasikan berapa banyak pod yang harus ada, dan Kubernetes memastikan sistem selalu kembali ke keadaan tersebut.