Kubernetes-Operatoren mit Go entwickeln

Operator-Entwicklung setzt auf Go; dieses Modul ordnet die Sprach- und Nebenläufigkeitskonzepte ein, die Sie im weiteren dreitägigen Workshop benötigen. Sie wenden Structs*, Interfaces und *Error Handling in kleinen Beispielen an, betrachten Goroutines und Channels und verfolgen, wie das client-go-SDK diese Muster nutzt. In der Lernumgebung ändern Sie Beispiele und besprechen, wie Sie Code lesen und Fehler eingrenzen.

Wann lohnt sich der Aufwand, einen Operator zu schreiben, und wann reicht ein Helm Chart oder ein einfacher Controller? Dieses Modul klärt die Begriffe, zeigt das Operator Pattern und das Operator Maturity Model und gibt Ihnen eine Entscheidungshilfe für Ihre eigenen Projekte. Sie analysieren zwei reale Beispiele aus dem CNCF-Ökosystem und ordnen sie ein.

Custom Resource Definitions erweitern die Kubernetes-API um eigene Ressourcentypen. Sie modellieren eine CRD mit Group, Version, Kind, Spec, Status und Subresources und registrieren sie im Cluster. In der Lernumgebung erzeugen und prüfen Sie Instanzen mit kubectl und untersuchen, wie Schema und API-Konventionen die folgenden Controller-Aufgaben begrenzen.

Kubebuilder erzeugt die Grundstruktur für API, Controller, Konfiguration und Programmstart. Sie scaffolden ein Projekt, verfolgen die Registrierung von Scheme, Manager und Reconciler und unterscheiden generierten von eigenem Code. Im DevNinjas Dojo, unserer Cloud-Lernumgebung, ergänzen Sie API-Felder und prüfen, wie controller-runtime den Controller mit der Kubernetes-API verbindet.

Reconciliation nähert den beobachteten Clusterzustand wiederholt dem gewünschten Zustand an. Sie implementieren eine Reconcile-Funktion, lesen Custom Resources über den gecachten Client und lösen passende Änderungen aus. In der Lernumgebung verfolgen Sie Ereignisse, Requests und erneute Durchläufe und ordnen ein, warum Controllerlogik nicht von einem einmaligen Aufruf ausgehen darf.

Operatoren verwalten häufig Deployments, Services oder ConfigMaps als abhängige Objekte. Sie setzen Owner References für die Kubernetes Garbage Collection und Finalizers für explizite Aufräumarbeiten außerhalb dieses Lebenszyklus ein. In der Lernumgebung untersuchen Sie Erzeugung und Löschung und begrenzen den Finalizer so, dass fehlgeschlagene Bereinigung sichtbar und wiederholbar bleibt.

Ein Reconciler verarbeitet dasselbe Objekt wiederholt und muss gleiche Eingaben kontrolliert behandeln. Sie vergleichen vorhandene und gewünschte Ressourcen, nutzen geeignete Create-, Patch- oder Update-Schritte und pflegen den Status getrennt von der Spec. Im Cloud-Lab analysieren Sie einen fehlerhaften Loop und verfolgen, wie Resource Versions, Statusänderungen und unbedachte Schreibzugriffe weitere Durchläufe auslösen.

CRDs können Eingaben über Schemas und CEL-Regeln prüfen; Webhooks ergänzen programmierbare Validierung oder Defaulting. Sie implementieren beide Varianten, betrachten Zertifikate und Fehlerpfade eines Webhooks und vergleichen deren Betriebsaufwand. In der Lernumgebung testen Sie gültige sowie ungültige Ressourcen und leiten Kriterien für schema-nahe Regeln oder externe Admission-Logik ab.

Controller benötigen explizite Rechte für gelesene, erzeugte und veränderte Ressourcen. Sie leiten RBAC-Regeln aus den Reconcile-Schritten ab, erzeugen Manifeste mit Kubebuilder-Markern und prüfen den tatsächlichen Zugriff eines Service Accounts. Im Cloud-Lab reduzieren Sie eine zu breite Rolle und betrachten getrennt, wie der Zugriff auf Metriken authentifiziert und autorisiert werden kann.

Controllerlogik benötigt neben kleinen Unit Tests auch Prüfungen gegen das Verhalten der Kubernetes-API. Sie richten envtest mit API-Server und etcd ein, laden CRDs und testen Reconciliation sowie Statusänderungen über den Client. In der Lernumgebung strukturieren Sie positive und negative Fälle und grenzen bewusst ab, welche Clusterkomponenten envtest nicht bereitstellt.

Ein Operator beginnt mit einer API, deren gewünschter Zustand und beobachtbarer Status verständlich bleiben müssen. Sie entwerfen Spec-Felder, Status Conditions und Beziehungen zu abhängigen Ressourcen, treffen bewusste Architekturentscheidungen und dokumentieren sie vor der Implementierung. Spec, Status und erzeugte Ressourcen bleiben dabei als unterschiedliche Teile der API-Entscheidung sichtbar.

Aus dem API-Entwurf entsteht ein zusammenhängender Controller mit CRD, Reconcile-Logik, abhängigen Objekten und Statuspflege. Sie implementieren die Schritte gemeinsam in Ihrer Cloud-Lernumgebung und prüfen jeden Übergang am Clusterzustand. Ein gemeinsames Review macht Annahmen, Fehlerpfade und Erweiterungspunkte sichtbar, ohne eine konkrete Produktionsarchitektur vorzugeben.

CRD-Versionen trennen die angebotene API von der im Cluster gespeicherten Darstellung. Sie definieren mehrere Versionen, wählen eine Storage Version und implementieren die Umwandlung über ein gemeinsames Hub-Modell. In der Lernumgebung prüfen Sie Hin- und Rückkonvertierung und untersuchen, welche Datenverluste oder inkompatiblen Änderungen ein Upgrade-Pfad verhindern muss.

Der Betrieb eines Controllers benötigt beobachtbares Verhalten und einen kontrollierten Parallelbetrieb mehrerer Instanzen. Sie ergänzen strukturierte Logs und Metriken, aktivieren Leader Election und ordnen Readiness sowie Fehlerzustände ein. Im Cloud-Lab provozieren Sie eine Störung und verfolgen Reconcile-Ergebnisse, Events und Telemetrie, um Ursache und betroffenen Zustandsübergang systematisch einzugrenzen.

Für das Deployment werden Controller-Code, Image und Kubernetes-Manifeste zu einer versionierbaren Einheit verbunden. Sie bauen das Image, prüfen Kustomize-Ausgaben, konfigurieren Probes und kontrollieren die erzeugten RBAC-Regeln vor der Installation. Zum Abschluss deployen Sie den Operator in der Lernumgebung und grenzen Packaging mit Operator Lifecycle Manager als weiterführendes Thema ab.