Zum Inhalt

Static Pods

Ziel

In diesem Hands-On lernen Sie, wie die zentralen Komponenten von Kubernetes funktionieren und wie sich deren Verhalten bei Ausfällen oder Änderungen verhält. Sie werden:

  • den kube-apiserver umkonfigurieren und Audit Logging aktivieren
  • den kube-scheduler gezielt stoppen und starten
  • den kubelet deaktivieren und die Auswirkungen analysieren

Vorbereitung

  • Verbinden Sie sich auf die Controlplane-Node:
ssh controlplane-0
  • Setzen Sie die kubeconfig:
export KUBECONFIG=/etc/kubernetes/admin.conf
  • Überprüfen Sie den Clusterzustand:
kubectl get nodes
kubectl get pods -n kube-system

Aufgabe 1 - kube-apiserver umkonfigurieren (Audit Logging)

Der kube-apiserver läuft als Static Pod auf der Controlplane-Node.

1.1: Audit Policy erstellen

  • Erstellen Sie die Datei /etc/kubernetes/audit-policy.yaml mit folgendem Inhalt:
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: Metadata

Diese Audit Policy konfiguriert den kube-apiserver so, dass er Metadaten aller API-Requests protokolliert. Wir müssen nun den kube-apiserver so konfigurieren, dass er diese Audit Policy verwendet und die Logs in einem Verzeichnis auf der Node speichert.

1.2: Audit Logging aktivieren

  • Öffnen Sie das Manifest des kube-apiservers
Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen) 
cd /etc/kubernetes/manifests
ls
nano kube-apiserver.yaml
  • Fügen Sie folgende Parameter unter command: hinzu:
  - --audit-policy-file=/etc/kubernetes/audit-policy.yaml
  - --audit-log-path=/var/log/kubernetes/audit/audit.log
  • Mounten Sie die Audit Policy Datei und das Log-Verzeichnis in den Container, indem Sie folgende volumeMounts hinzufügen:
volumeMounts:
  - mountPath: /etc/kubernetes/audit-policy.yaml
    name: audit
    readOnly: true
  - mountPath: /var/log/kubernetes/audit/
    name: audit-log
    readOnly: false
  • Konfigurieren Sie die hostPath Volumes:
volumes:
- name: audit
  hostPath:
    path: /etc/kubernetes/audit-policy.yaml
    type: File

- name: audit-log
  hostPath:
    path: /var/log/kubernetes/audit/
    type: DirectoryOrCreate

1.3: Verhalten beobachten

  • Lassen Sie sich die laufenden Pods anzeigen und beobachten Sie anschließend die Logs des kube-apiservers:
kubectl get pods -n kube-system
cat /var/log/kubernetes/audit/audit.log | grep kubernetes-admin

Aufgabe 2 - kube-scheduler stoppen und starten

2.1: Scheduler stoppen

  • Stoppen Sie den kube-scheduler
Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen) 
mv /etc/kubernetes/manifests/kube-scheduler.yaml /etc/kubernetes/manifests/.kube-scheduler.yaml

Lassen Sie sich den Status des kube-schedulers anzeigen:

kubectl get pods -n kube-system

2.2: Pod erstellen

Erstellen Sie einen neuen Pod:

kubectl run nginx-test --image=nginx

Beobachten Sie den Status des Pods:

kubectl get pods

👉 Beobachtung: Pod bleibt im Status Pending

2.3: Scheduler wieder starten

  • Starten Sie den kube-scheduler wieder
  • Beobachten Sie den Status des Pods
Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen) 
mv /etc/kubernetes/manifests/.kube-scheduler.yaml /etc/kubernetes/manifests/kube-scheduler.yaml
kubectl get pods -w

👉 Beobachtung: Pod wird geplant und startet

Aufgabe 3 - kubelet stoppen

3.1: kubelet stoppen

  • Loggen Sie sich von der Controlplane-Node ab:
exit
  • Finden Sie heraus, auf welcher Worker-Node der vorher erstellte Pod nginx-test läuft:
Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen) 
kubectl get pods -o wide
  • Stoppen Sie den kubelet Dienst auf der Worker-Node auf der der vorher erstellte Pod nginx-test läuft
Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen) 
ssh <worker-node>
systemctl stop kubelet

3.2: Verhalten beobachten

  • Loggen Sie sich aus der Worker-Node wieder aus:
exit
  • Beobachten Sie den Status der Node:
kubectl get nodes

👉 Beobachtung: Node wird NotReady (Es kann etwas Zeit dauern, bis der Status aktualisiert wird)

3.3: Logs prüfen

  • Lassen Sie sich die Logs des Pods anzeigen
Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen) 
kubectl logs <pod-name>

👉 Beobachtung: Logs nicht verfügbar

3.4: kubelet wieder starten

  • Starten Sie den kubelet Dienst wieder
Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen) 
ssh <worker-node>
systemctl start kubelet
exit
  • Beobachten Sie den Status der Node und des Pods und lassen Sie sich die Logs des Pods anzeigen
Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen) 
kubectl get nodes
kubectl get pods
kubectl logs <pod-name>

👉 Beobachtung: Node wird wieder Ready, Logs sind wieder erreichbar

Zusammenfassung

  • kube-apiserver: zentrale API, konfigurierbar über Static Pods
  • kube-scheduler: entscheidet über Pod-Platzierung
  • kubelet: steuert Pods auf Nodes