Kubernetes Infrastructure as Code — Kustomize, Validierung & E2E-Testing mit Kuttl

In “Kubernetes Workloads & Konfiguration” habt ihr Deployment, Service, ConfigMap und Secret als rohe Manifeste geschrieben und per kubectl apply direkt angewendet. Dieses 150-Minuten-Aufbaumodul dreht die Perspektive um: Statt einzelner Befehle steht das Everything-as-Code-Paradigma im Zentrum – der bewusste Wechsel von der imperativen Befehlskette zur deklarativen Soll-Zustands-Beschreibung, und die Frage, wer die Last trägt, diesen Soll-Zustand dauerhaft durchzusetzen. Ihr seziert den Reconciliation Loop als generisches Steuerungsmuster anhand des TOTE-Modells (Test–Operate–Test–Exit) aus der Kognitionspsychologie und beobachtet live, warum ein imperativ erzeugter Pod ohne übergeordneten Controller nach dem Löschen nicht zurückkommt. Danach rüstet ihr euer YAML-Handwerkszeug auf: Einrückungsregeln, das strikte Tabulator-Verbot, Anchors & Aliases als YAMLs eigenes DRY-Prinzip, sowie das berüchtigte Norwegen-Problem der automatischen Typinferenz (Norway: NO wird von älteren Parsern stillschweigend zu false). Im Kern der Session baut ihr mit Kustomize eine wiederverwendbare base/-Konfiguration und leitet daraus per Overlay und gezieltem Patching zwei eigenständige Umgebungen ab – ein schlankes Dev-Overlay mit configMapGenerator und ein hochverfügbares Prod-Overlay mit externem LoadBalancer-Service –, validiert das generierte Ergebnis mit Kubeconform gegen das offizielle Kubernetes-Schema, bevor irgendetwas den Cluster erreicht, und schließt mit der tatsächlichen Bereitstellung, einer live beobachteten Selbstheilung sowie einem deklarativen End-to-End-Test mit Kuttl (Kubernetes Test Tool) samt kontrolliertem Aufräumen ab. Abgrenzung zu zwei benachbarten Themen: Anders als Terraform-Grundlagen geht es hier nicht um HCL, Provider oder Remote-State für Cloud-Infrastruktur außerhalb des Clusters, sondern ausschließlich um native Kubernetes-Manifeste und das dafür in kubectl eingebaute Kustomize. Und anders als die GitOps-Operator-Module ArgoCD oder Flux, die den Pull-Mechanismus und die Reconciliation im Cluster-Controller behandeln, liegt der Fokus dieses Moduls auf den Werkzeugen davor: den YAML-Manifesten selbst, ihrer strukturierten Overlay-Ableitung und ihrer automatisierten Validierung und Testbarkeit, bevor überhaupt ein GitOps-Controller ins Spiel kommt.