10: Liveness i Readiness Probes

Sondy w Kubernetes: Liveness i Readiness Probes

Cel zadania

Celem zadania jest zrozumienie jak działają sondy (probes) w Kubernetes, jak je konfigurować oraz jak wpływają na zachowanie aplikacji w klastrze.

Teoria

Sondy w Kubernetes

• Liveness Probe: Sprawdza czy aplikacja żyje - jeśli nie, Kubernetes restartuje kontener
• Readiness Probe: Sprawdza czy aplikacja jest gotowa na przyjmowanie ruchu
• Startup Probe: (opcjonalna) Sprawdza czy aplikacja zakończyła proces startowania

Typy sond i ich zastosowanie

1. HTTP GET
   • Najczęściej używany typ
   • Sprawdza endpoint HTTP w aplikacji
   • Sukces: kod odpowiedzi 200-399
   • Idealny dla aplikacji webowych
2. TCP Socket
   • Sprawdza czy port jest otwarty
   • Nie sprawdza stanu aplikacji
   • Dobry dla baz danych, cache’ów
3. Exec
   • Wykonuje komendę w kontenerze
   • Sukces: kod wyjścia = 0
   • Najbardziej elastyczny

Liveness vs Readiness — co się dzieje przy awarii

graph TD
    subgraph LIV["Liveness Probe — fail"]
        L1["Liveness check fails"] --> L2["failureThreshold przekroczony"]
        L2 --> L3["Kubelet restartuje kontener"]
        L3 --> L4["Pod wraca do Running"]
    end

    subgraph READ["Readiness Probe — fail"]
        R1["Readiness check fails"] --> R2["failureThreshold przekroczony"]
        R2 --> R3["Pod usunięty z Endpoints"]
        R3 --> R4["Service nie kieruje ruchu do tego Poda"]
        R4 --> R5["Pod nadal działa!<br/>(nie jest restartowany)"]
    end

    style L3 fill:#ffebee,stroke:#f44336
    style R3 fill:#fff3e0,stroke:#ff9800
    style R5 fill:#e8f5e9

Kluczowa różnica: Liveness → restart, Readiness → usunięcie z ruchu (bez restartu).

Zadanie 1: Testowanie Liveness Probe

1.1. Utwórz plik kuard-liveness-XX.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: kuard-liveness-XX
spec:
  containers:
  - name: kuard
    image: gcr.io/kuar-demo/kuard-amd64:1
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /healthy
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10

1.2. Uruchom test:

Potrzebujesz do tego zadania dwóch terminali

1. W pierwszym terminalu uruchom monitoring podów:

   kubectl get pods -w
   

2. W drugim terminalu utwórz pod:

   kubectl apply -f kuard-liveness-XX.yaml
   

3. Po wystartowaniu poda, uruchom port-forward:

   kubectl port-forward pod/kuard-liveness-XX 8080:8080
   

4. Otwórz http://localhost:8080 i przejdź do zakładki “Liveness Probe”

5. Kliknij “Fail” aby zasymulować awarię

6. W pierwszym terminalu zobaczysz:

   NAME                 READY   STATUS    RESTARTS   AGE
   kuard-liveness-XX   1/1     Running   0          30s
   kuard-liveness-XX   1/1     Running   1          50s    # Pod został zrestartowany
   

Zadanie 2: Testowanie Readiness Probe

2.1. Utwórz plik kuard-readiness-XX.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: kuard-readiness-XX
  labels:
    app: kuard-XX
spec:
  containers:
  - name: kuard
    image: gcr.io/kuar-demo/kuard-amd64:1
    ports:
    - containerPort: 8080
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 2
      periodSeconds: 5

2.2. Uruchom test:

1. W pierwszym terminalu obserwuj endpointy:

   kubectl get endpoints -w
   

2. W drugim terminalu utwórz pod i service:

   kubectl apply -f kuard-readiness-XX.yaml
   kubectl expose pod kuard-readiness-XX --port=8080
   

3. Uruchom port-forward w trzecim terminalu:

   kubectl port-forward pod/kuard-readiness-XX 8080:8080
   

4. Otwórz http://localhost:8080 i przejdź do “Readiness Probe”

5. Kliknij “Fail” i obserwuj endpointy w pierwszym terminalu:

   NAME                ENDPOINTS          AGE
   kuard-readiness-XX  10.244.0.15:8080  30s
   kuard-readiness-XX  <none>            35s    # Pod został usunięty z endpointów
   

Zadanie 3: Pod z obiema sondami

3.1. Utwórz plik kuard-combined-XX.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: kuard-combined-XX
  labels:
    app: kuard-XX
spec:
  containers:
  - name: kuard
    image: gcr.io/kuar-demo/kuard-amd64:1
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /healthy
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 2
      periodSeconds: 5

3.2. Testowanie obu sond:

1. W pierwszym terminalu uruchom monitoring:

   kubectl get pods -w
   

2. W drugim terminalu utwórz zasoby:

   kubectl apply -f kuard-combined-XX.yaml
   kubectl expose pod kuard-combined-XX --port=8080
   

3. W trzecim terminalu obserwuj endpointy:

   kubectl get endpoints -w
   

4. Uruchom port-forward w czwartym terminalu:

   kubectl port-forward pod/kuard-combined-XX 8080:8080
   

5. W przeglądarce testuj obie sondy i obserwuj:
   • Liveness fail → restart poda (terminal 1)
   • Readiness fail → usunięcie z endpointów (terminal 3)

Najczęstsze problemy

Dobre praktyki

1. Zawsze używaj obu sond
   • Liveness do wykrywania deadlocków
   • Readiness do kontroli ruchu
2. Odpowiednie parametry czasowe
   • Ustaw initialDelaySeconds większy niż czas startu
   • Używaj rozsądnych periodSeconds (10-30s)
3. Właściwe endpointy
   • Używaj lekkich endpointów
   • Sprawdzaj tylko krytyczne komponenty

Podsumowanie

• Liveness probe odpowiada za wykrywanie awarii i restart poda
• Readiness probe kontroluje ruch do poda
• Sondy mogą używać różnych mechanizmów (HTTP, TCP, Exec)
• Właściwa konfiguracja jest kluczowa dla stabilności aplikacji