Kubernetes Administration — RBAC, Node-Betrieb und Cluster-Netzwerk

Dieses Modul setzt das Aufbaumodul Kubernetes Workloads & Konfiguration — die Objekte für den Alltag voraus. Pod-Lifecycle, Deployment-Mechanik, Service-Typen sowie ConfigMap/Secret werden dort erklärt und hier nicht erneut eingeführt. Nicht Voraussetzung ist das Modul “Kubernetes Networking Vertiefung” – beide Module sind gleichrangige, voneinander unabhängige Vertiefungen auf demselben Workloads-Fundament und lassen sich in beliebiger Reihenfolge buchen.

Wer stattdessen Service Discovery, DNS-Verhalten und Ingress-Pfadregeln vertiefen will, findet das im Schwestermodul Kubernetes Networking Vertiefung — Service Discovery, DNS und Ingress-Pfadregeln. Wer stattdessen die Anwendungsdesign-Perspektive einnehmen will – Multi-Container-Pod-Patterns, Job/CronJob für Batch-Workloads sowie securityContext und ServiceAccount – findet das im weiteren Schwestermodul Kubernetes Anwendungsdesign — Multi-Container-Patterns, Jobs & Security Context. Wer stattdessen die Storage-Perspektive einnehmen will – emptyDir und hostPath im Vergleich zu PersistentVolume, PersistentVolumeClaim mit Binding-Regel, AccessModes und StorageClass – findet das im weiteren Schwestermodul Kubernetes Storage — Volumes, PersistentVolumes & Claims. Wer stattdessen wissen will, wie sich eine bereits laufende Anwendung diagnostizieren lässt – Prometheus-Scrape-Annotationen, Ephemeral Containers per kubectl debug und die dreistufige Service-Troubleshooting-Kette – findet das im weiteren Schwestermodul Kubernetes: Monitoring & Troubleshooting. Wer stattdessen Requests/Limits, QoS-Klassen, LimitRange und den HorizontalPodAutoscaler vertiefen will – bewusst abgegrenzt von der ResourceQuota dieses Moduls, die ein Namespace-Aggregat begrenzt statt eines Container-Defaults – findet das im weiteren Schwestermodul Kubernetes Ressourcenmanagement & Autoscaling — Requests, Limits und HorizontalPodAutoscaler. Wer stattdessen eigene und fremde Anwendungen als versionierte Releases statt loser Manifest-Dateien betreiben will – Chart/ Release/Repository als Grundbegriffe, Chart-Struktur und Go-Template-Syntax sowie das komplette Lifecycle-Management helm install/upgrade/rollback/history – findet das im weiteren Schwestermodul Helm — Paketmanagement für Kubernetes. Die dort behandelten ServiceAccount/Role/ RoleBinding-Bausteine für Chart-eigene Workloads sind bereits Thema dieses Moduls und werden dort als bekannt vorausgesetzt, nicht erneut eingeführt. Alle sieben Vertiefungsmodule ergänzen sich inhaltlich, keines setzt das andere voraus.

Wer den High-Availability-Block dieses Moduls (Control-Plane-HA, etcd-Raft-Quorum) in die Praxis überführen will – ein echtes etcd-Backup erstellen und einen Cluster daraus wiederherstellen – findet das im aufbauenden Modul Kubernetes Cluster-Recovery: etcd Backup & Restore. Anders als die sechs gleichrangigen Vertiefungsmodule oben setzt dieses Modul konkret die Inhalte dieses Kurses voraus, nicht nur das gemeinsame Workloads-Fundament.

Wer stattdessen den High-Availability-Block als echte Multi-Control-Plane-Topologie selbst aufbauen und das etcd-Raft-Quorum live an einem Node-Ausfall beobachten will – hier bewusst als reiner Frontalteil ohne eigenes Hands-on belassen, weil eine echte Topologie mehrere echte Nodes/VMs braucht – findet das vertieft im Aufbaumodul Kubernetes Hochverfügbarkeit — Multi-Master Control-Plane. Das Modul löst genau die technische Einschränkung dieser Sandbox über einen Werkzeugwechsel auf kind statt Minikube.

Wer RBAC und ServiceAccounts aus diesem Modul mit dem securityContext aus “Kubernetes Anwendungsdesign” zusammenführen und Namespace-weit statt nur pro Workload durchsetzen will – Pod Security Standards und Pod Security Admission mit dem Namespace-Label pod-security.kubernetes.io/enforce=restricted, dazu Secrets-Encryption-at-Rest über eine EncryptionConfiguration jenseits von Base64 – findet das im Aufbaumodul Kubernetes Security Vertiefung — Pod Security Admission & Secrets-Härtung. Anders als die sieben gleichrangigen Vertiefungsmodule oben setzt dieses Modul konkret die RBAC-/ServiceAccount-Inhalte dieses Kurses und den securityContext aus “Kubernetes Anwendungsdesign” gleichzeitig voraus, nicht nur das gemeinsame Workloads-Fundament. Wer von dort aus noch einen Schritt weitergehen will – eigene Cluster-Regeln jenseits der drei festen Pod-Security-Profile, mit Kyverno und OPA Gatekeeper live gegen dieselbe Regel verglichen – findet das im weiterführenden Aufbaumodul Kubernetes Admission Controllers & Policy Engines — Kyverno vs. OPA Gatekeeper.