Readiness-, liveness- en startup-probes configureren in Kubernetes

Met probes bepaalt Kubernetes of een pod verkeer mag ontvangen, of een container opnieuw gestart moet worden en hoeveel tijd een applicatie krijgt om op te starten. Zonder goede probes kunnen kapotte pods verkeer blijven krijgen of juist te vroeg worden herstart.

In deze handleiding maak je een eenvoudige demo-workload met alle drie de probe-types. Daarna test je expliciet wat er gebeurt als een pod niet ready is en wat er gebeurt als de liveness-check faalt.

Wanneer gebruik je welk probe-type?

• Readiness: gebruik dit voor web-apps, API's en andere workloads die verkeer via een Service ontvangen.
• Liveness: gebruik dit als een applicatie in een kapotte toestand kan blijven hangen en alleen een restart helpt.
• Startup: gebruik dit voor trage applicaties, zodat liveness niet al faalt tijdens initialisatie, migraties of cache-warmup.

Voor queue workers en batchprocessen is readiness vaak minder belangrijk dan voor web-apps, maar startup en liveness blijven ook daar nuttig om kapotte containers niet eindeloos door te laten draaien.

Een workload maken met alle drie de probes

Stap 1

Verbind met je cluster via kubectl en maak een .yaml-bestand aan (een manifest):

nano probes-demo.yaml

Plaats de volgende configuratie in het bestand:

apiVersion: v1
kind: Namespace
metadata:
  name: kb-probe-test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: probe-demo
  namespace: kb-probe-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: probe-demo
  template:
    metadata:
      labels:
        app: probe-demo
    spec:
      containers:
        - name: app
          image: busybox:1.36
          command: ["/bin/sh", "-c"]
          args:
            - |
              mkdir -p /www
              echo ok > /www/index.html
              (
                sleep 10
                touch /tmp/started
                sleep 10
                touch /tmp/ready
                touch /tmp/healthy
              ) &
              httpd -f -p 8080 -h /www &
              while true; do
                sleep 1
              done
          ports:
            - containerPort: 8080
          startupProbe:
            exec:
              command: ["sh", "-c", "test -f /tmp/healthy"]
            periodSeconds: 5
            failureThreshold: 12
          readinessProbe:
            exec:
              command: ["sh", "-c", "test -f /tmp/ready"]
            periodSeconds: 5
            failureThreshold: 1
          livenessProbe:
            exec:
              command: ["sh", "-c", "test -f /tmp/healthy"]
            periodSeconds: 5
            failureThreshold: 1
---
apiVersion: v1
kind: Service
metadata:
  name: probe-demo
  namespace: kb-probe-test
spec:
  selector:
    app: probe-demo
  ports:
    - port: 8080
      targetPort: 8080

Sla de wijzigingen op en sluit het bestand (ctrl + x > y > enter).

Stap 2

Maak de Deployment en Service aan:

kubectl apply -f probes-demo.yaml
kubectl -n kb-probe-test rollout status deploy/probe-demo --timeout=180s

Omdat de `startupProbe` op dezelfde conditie wacht als de `livenessProbe`, krijgt de applicatie eerst rustig de tijd om een 'healthy' status te bereiken voordat Kubernetes een herstart overweegt.

Stap 3

Controleer of de pod uiteindelijk `Ready` wordt en als endpoint van de Service verschijnt:

kubectl -n kb-probe-test get pods -o wide
kubectl -n kb-probe-test get endpoints probe-demo -o yaml

Zolang de readiness-check slaagt, staat het IP-adres van de pod onder `addresses` in plaats van onder `notReadyAddresses`.

Simuleer een readiness failure

Stap 1

Verwijder de readiness-conditie in de draaiende pod:

kubectl -n kb-probe-test exec deploy/probe-demo -- rm -f /tmp/ready

Stap 2

Controleer een paar seconden later opnieuw de Service-endpoints:

kubectl -n kb-probe-test get endpoints probe-demo -o yaml

De pod hoort nu onder `notReadyAddresses` te verschijnen. Kubernetes stopt dan met het routeren van verkeer via de Service, maar de container blijft draaien. Dit maakt het verschil tussen readiness en liveness.

Stap 3

Herstel tot slot de readiness-conditie:

kubectl -n kb-probe-test exec deploy/probe-demo -- touch /tmp/ready

Simuleer een liveness failure

Stap 1

Verwijder de liveness-conditie:

kubectl -n kb-probe-test exec deploy/probe-demo -- rm -f /tmp/healthy

Stap 2

Controleer of Kubernetes de container opnieuw start:

kubectl -n kb-probe-test get pod -l app=probe-demo -w --request-timeout=15s

Je hoort het aantal herstart te zien oplopen. Daarmee herstelt Kubernetes een container die nog wel draait, maar functioneel kapot is.

Stap 3

Herstel tot slot de liveness-conditie:

kubectl -n kb-probe-test exec deploy/probe-demo -- touch /tmp/healthy

Met een goede combinatie van readiness-, liveness- en startup-probes voorkom je twee veelvoorkomende problemen tegelijk: verkeer naar pods die nog niet klaar zijn, en containers die functioneel stuk zijn maar niet vanzelf stoppen. Daarmee wordt je cluster betrouwbaarder en veiliger tegelijk.