Kubernetes Anwendungsdesign — Multi-Container-Patterns, Jobs & Security Context

Dieses Modul setzt das Aufbaumodul Kubernetes Workloads & Konfiguration — die Objekte für den Alltag voraus. Probes, Rolling Update und der Unterschied zwischen ConfigMap-Volume und ConfigMap-Environment-Variable werden dort erklärt und hier nicht erneut eingeführt.

Wer stattdessen die Betreiber-Perspektive einnehmen will – Namespace/ResourceQuota, RBAC, Cluster-Netzwerk-Grundmodell, Node-Administration und High Availability als Konzept – findet das im gleichrangigen, unabhängigen Vertiefungsmodul Kubernetes Administration — RBAC, Node-Betrieb und Cluster-Netzwerk. Wer 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 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, kubectl top pods, Ephemeral Containers per kubectl debug und die dreistufige Service-Troubleshooting-Kette Port-Forward → Endpoints → DNS-Test-Pod – findet das im weiteren Schwestermodul Kubernetes: Monitoring & Troubleshooting. Wer stattdessen wissen will, wie viel ein Container verbrauchen darf – requests/limits, die drei QoS-Klassen sowie der HorizontalPodAutoscaler – findet das im weiteren Schwestermodul Kubernetes Ressourcenmanagement & Autoscaling — Requests, Limits und HorizontalPodAutoscaler. Wer stattdessen wissen will, wie sich diese Objekte als wiederverwendbares Paket versionieren und verteilen lassen – Chart-Struktur, values.yaml und Release-Verwaltung – findet das im weiteren Schwestermodul Helm — Paketmanagement für Kubernetes. Alle sieben Vertiefungsmodule setzen nur das Workloads-Modul voraus, nicht sich gegenseitig, und lassen sich in beliebiger Reihenfolge buchen.

Wer den hier gelernten securityContext mit RBAC/ ServiceAccounts aus “Kubernetes Administration” 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 Aufbaumodul konkret den securityContext dieses Kurses und RBAC/ServiceAccounts aus “Kubernetes Administration” gleichzeitig voraus, nicht nur das gemeinsame Workloads-Fundament.