Wartung und Betrieb

Ziel

In diesem Projekt geht es um wiederkehrende Betriebsaufgaben in einem mit kubeadm aufgebauten Kubernetes-Cluster. Sie werden:

• den Zustand und die Restlaufzeit der Kubernetes-Zertifikate prüfen
• Zertifikate mit kubeadm rotieren
• ein Snapshot-Backup von ETCD erstellen
• ETCD aus einem Snapshot wiederherstellen

Hilfsmittel

• Versuchen Sie, die unten stehenden Aufgaben mit Hilfe der Schulungsunterlagen und Ihres bisherigen Wissens aus den vorherigen Labs eigenständig zu lösen.
• Sollten Sie dabei Probleme haben, finden Sie bei jeder Aufgabe einen ausklappbaren Block, in dem der Lösungsweg beschrieben wird.

Aufgabe 1 - Zertifikate prüfen

1.1: Ablaufdaten der Kubernetes-Zertifikate anzeigen

• Lassen Sie sich den Status und die Restlaufzeit der durch kubeadm verwalteten Zertifikate anzeigen.
• Nutzen Sie:

kubeadm certs check-expiration

1.2: Zertifikatsdateien direkt inspizieren

• Schauen Sie sich zusätzlich mindestens ein Zertifikat direkt mit openssl an.
• Prüfen Sie Subject, Issuer und Gültigkeitszeitraum.
• Beispiel für das API-Server-Zertifikat:

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text

Aufgabe 2 - Zertifikate rotieren

2.1: Alle durch kubeadm verwalteten Zertifikate erneuern

• Rotieren Sie alle durch kubeadm verwalteten Zertifikate.

kubeadm certs renew all

• Prüfen Sie direkt anschließend erneut die Restlaufzeiten.

kubeadm certs check-expiration

• Die Restlaufzeiten sollten jetzt angepasst sein.

2.2: Statische Pods der Control Plane neu laden

Die Zertifikate sind nun erneuert, die laufenden Komponenten verwenden aber unter Umständen noch die alten Dateien im Speicher. Da die Control-Plane-Komponenten in einem Kubeadm-Cluster typischerweise als statische Pods laufen, müssen diese neu gestartet werden.

• Prüfen Sie die statischen Pod-Manifeste.
• Starten Sie die betroffenen Komponenten kontrolliert neu.

crictl

• Sie können crictl verwenden, um die statischen Pods zu beobachten sicher zu stellen, dass sie komplett entfernt wurden:

crictl ps

• Beobachten Sie, wie die Pods wieder erscheinen.

Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen)

• Die Manifest-Dateien liegen unter:

  ls /etc/kubernetes/manifests
  

• Typischer Inhalt:
  • kube-apiserver.yaml
  • kube-controller-manager.yaml
  • kube-scheduler.yaml
  • etcd.yaml
• Eine einfache Möglichkeit für einen Neustart ist, eine Datei kurz aus dem Manifest-Verzeichnis zu verschieben und danach zurückzulegen. Der Kubelet entfernt den statischen Pod und erstellt ihn anschließend neu.
• Beispiel für den API-Server:

  mkdir -p /etc/kubernetes/manifests.bak
  mv /etc/kubernetes/manifests/* /etc/kubernetes/manifests.bak/
  sleep 20
  mv /etc/kubernetes/manifests.bak/* /etc/kubernetes/manifests/
  

• Beobachten Sie parallel:

  crictl ps
  

Aufgabe 3 - ETCD Snapshot-Backup erstellen

3.1: ETCDCTL und ETCDUTL installieren

• Installieren Sie etcdctl und etcdutl auf der Controlplane Node, um mit ETCD zu interagieren.

cd /root
ETCD_VER=v3.6.9
ARCH=amd64

curl -L "https://github.com/etcd-io/etcd/releases/download/${ETCD_VER}/etcd-${ETCD_VER}-linux-${ARCH}.tar.gz" -o etcd.tar.gz
tar -xzf etcd.tar.gz
cd etcd-${ETCD_VER}-linux-${ARCH}

cp etcdctl etcdutl /usr/local/bin/

3.2: Funktionsprüfung nach der Zertifikatsrotation

• Vergewissern Sie sich, dass alle Nodes und System-Pods wieder betriebsbereit sind.

kubectl get nodes
kubectl get pods -n kube-system

• Prüfen Sie zusätzlich die ETCD-Health.

export ETCDCTL_API=3
etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
  --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
  endpoint health

3.3: ETCD-Zugangsdaten aus dem statischen Pod-Manifests ermitteln

• Öffnen Sie das ETCD-Manifest.

  cat /etc/kubernetes/manifests/etcd.yaml
  

• Identifizieren Sie:
  • den Datenpfad
  • den Listen-Port
  • die Zertifikatsdateien für etcdctl
• Achten Sie insbesondere auf:
  • --data-dir=...
  • --listen-client-urls=...
  • --cert-file=...
  • --key-file=...
  • --trusted-ca-file=...
• In vielen Kubeadm-Umgebungen sind dies:
  • Datenverzeichnis: /var/lib/etcd
  • Endpoint: https://127.0.0.1:2379
  • CA: /etc/kubernetes/pki/etcd/ca.crt
  • Cert: /etc/kubernetes/pki/etcd/healthcheck-client.crt
  • Key: /etc/kubernetes/pki/etcd/healthcheck-client.key

3.4: Snapshot sichern

• Erstellen Sie ein Snapshot-Backup von ETCD.
• Speichern Sie dieses z. B. unter /opt/backup/etcd-snapshot.db:
  • Legen Sie zuerst ein Backup-Verzeichnis an:

    mkdir -p /opt/backup
    

  • Setzen Sie die API-Version:

    export ETCDCTL_API=3
    

  • Erstellen Sie das Snapshot-Backup:

    etcdctl \
      --endpoints=https://127.0.0.1:2379 \
      --cacert=/etc/kubernetes/pki/etcd/ca.crt \
      --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
      --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
      snapshot save /opt/backup/etcd-snapshot.db
    

3.5: Snapshot verifizieren

• Prüfen Sie, dass das Snapshot erfolgreich erstellt wurde.
• Lassen Sie sich die Metadaten des Snapshots anzeigen.
  • Zeigen Sie den Status an:

    export ETCDCTL_API=3
    etcdutl snapshot status /opt/backup/etcd-snapshot.db -w table
    

Aufgabe 4 - Daten verändern, um ein Restore nachvollziehen zu können

Damit der Effekt des Restores sichtbar wird, verändern Sie den Clusterzustand nach dem Backup.

4.1: Testressource anlegen

• Erstellen Sie einen Namespace und einen Testpod
• Prüfen Sie, dass die Ressource im Cluster vorhanden ist.
• Löschen Sie einen Pod im default Namespace, z.B. den Pod nginx-test.

Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen)

• Beispiel:

  kubectl create namespace restore-demo
  kubectl -n restore-demo run test-pod --image=nginx
  

• Prüfen Sie:

  kubectl get ns
  kubectl -n restore-demo get pods
  

• Löschen Sie einen Pod im default Namespace, z.B. den Pod nginx-test:

  kubectl delete pod nginx-test
  

• Prüfen Sie, dass der Pod gelöscht wurde:

  kubectl get pods
  

Aufgabe 5 - ETCD Restore durchführen

Wichtiger Hinweis

Ein Restore von ETCD ist ein tiefgreifender Eingriff in die Control Plane. Führen Sie diese Schritte in Produktionsumgebungen nur mit großer Vorsicht und vorheriger Absicherung durch Backups durch.

5.1: ETCD stoppen

• Stoppen Sie zunächst alle static Pods. Hier ist insbesondere der kube-apiserver wichtig.

Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen)

• Verschieben Sie das Manifest temporär aus dem Manifest-Verzeichnis:

  mkdir -p /etc/kubernetes/manifests.bak
  mv /etc/kubernetes/manifests/* /etc/kubernetes/manifests.bak/
  

• Prüfen Sie crictl bis die Pods gestoppt sind:

  crictl ps
  

5.2: Bestehendes Datenverzeichnis sichern

• Sichern Sie das aktuelle ETCD-Datenverzeichnis, bevor Sie den Restore ausführen.

mv /var/lib/etcd /var/lib/etcd.bak

5.3: Snapshot wiederherstellen

• Stellen Sie das Snapshot wieder her:

  export ETCDCTL_API=3
  etcdutl snapshot restore /opt/backup/etcd-snapshot.db \
    --data-dir /var/lib/etcd
  

5.4: ETCD wieder starten

• Starten Sie die statischen Pods wieder, indem Sie die Manifest-Dateien zurück in das Verzeichnis verschieben:

  mv /etc/kubernetes/manifests.bak/* /etc/kubernetes/manifests/
  

• Warten Sie, bis die Static Pods wieder laufen und der API-Server erreichbar ist.

• Prüfen Sie den Clusterzustand nach dem Restore.

Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen)

• Beobachten Sie zunächst lokal den Container- oder Pod-Status mit crictl ps.
• Sobald der API-Server wieder erreichbar ist, prüfen Sie:

  kubectl get nodes
  kubectl get pods
  kubectl get ns
  

Abschluss

Sie haben in diesem Hands-On zwei zentrale Betriebsaufgaben für Kubeadm-basierte Kubernetes-Cluster durchgeführt:

• Sie haben Kubernetes-Zertifikate geprüft und rotiert.
• Sie haben ein ETCD-Snapshot erstellt, validiert und wiederhergestellt.

Diese beiden Aufgaben gehören zu den wichtigsten administrativen Tätigkeiten in der Absicherung und Wartung einer Kubernetes-Control-Plane.