Training Module

Kubernetes Operator entwickeln mit Kubebuilder (Go)

In diesem 130-Minuten-Modul schließt ihr die Lücke, die das Modul Kubernetes CRDs & Operator Pattern bewusst offengelassen hat: Dort habt ihr eine CronTab-CRD geschrieben, die keinen Controller hatte – reine, wirkungslose Daten. Heute schreibt ihr genau diesen Controller, in echtem Go-Code. Los geht es mit dem Kubebuilder-Projektgerüst: kubebuilder init legt Modul, main.go und Makefile an, kubebuilder create api –group stable –version v1 –kind CronTab ergänzt api/v1/crontab_types.go und controllers/crontab_controller.go – dieselbe Verzeichnisstruktur, die jedes reale Kubebuilder-Projekt hat. Im Kern des Moduls implementiert ihr Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error): das Objekt über den controller-runtime-Client lesen, den Soll- gegen den Ist-Zustand abgleichen und das Ergebnis ausschließlich über die Status-Subresource zurückschreiben (r.Status().Update(…) statt r.Update(…)) – exakt die Trennung Spec/Status, die der CRD-Kurs schon als Konzept eingeführt hat. Statt eine neue, erfundene CRD zu benutzen, baut Modul 4 auf der bereits bestehenden CronTab-Custom-Resource aus dem Vorgängerkurs weiter – derselbe crontabs.stable.example.com-Typ, jetzt zum ersten Mal mit einem laufenden Prozess dahinter. Modul 5 testet diesen Reconciler mit envtest und Ginkgo: ein echter, lokal laufender Kubernetes-API-Server (kein Mock) nimmt eine CronTab entgegen, der Test wartet mit Eventually(…), bis der Controller status.phase auf Ready gesetzt hat. Zum Abschluss ordnet ihr Deployment ein – Container-Build, make deploy, RBAC-Marker-Kommentare, die zu echten ClusterRole-Regeln werden – und eine ehrliche Abgrenzung: Admission- und Conversion-Webhooks, produktive Multi-Version-Conversion (in Kubebuilder eigene Webhook-Scaffolds) und der Operator Lifecycle Manager (OLM) für Distribution/Upgrades sind an keiner Stelle Hands-on, nur benannt. Voraussetzung sind die Module “Kubernetes CRDs & Operator Pattern” UND “Go-Grundlagen” – beide Pflicht, beide werden hier vorausgesetzt und nicht wiederholt. Die Session läuft komplett lokal über Minikube (–driver=docker), ohne Cloud-Account und ohne Kostenwirkung.

Academy Briefing vereinbaren

Oder sofort per Mail an kontakt@codecraft.academy

Format

130 Minuten, live (remote oder vor Ort), Input & drei Hands-on-Blöcke

Teilnehmende

Entwickler:innen, die einen eigenen Kubernetes-Controller tatsächlich in Go schreiben statt nur einzuordnen wollen

Voraussetzungen

Abgeschlossene Module “Kubernetes CRDs & Operator Pattern” UND “Go-Grundlagen” (beide Pflicht), lauffähige lokale Docker-Umgebung für Minikube

Warum dieses Training für deine Organisation wirkt

Von der toten CRD zum laufenden Controller

Der Vorgängerkurs endete bewusst bei einer CRD ohne Verhalten. Dieses Modul liefert genau das Fehlende nach – am selben CronTab-Beispiel, nicht an einem neuen Spielzeug.

Echter Go-Code, kein Pseudocode

Reconcile(), der controller-runtime-Client und die Status-Subresource sind derselbe Code, den Kubebuilder selbst generiert – kein didaktisch vereinfachtes Beispiel, das in der Praxis anders aussieht.

Getestet statt nur geschrieben

envtest startet einen echten API-Server lokal – Teilnehmende sehen, dass ihr Reconciler tatsächlich reagiert, nicht nur, dass er kompiliert.

Was Teilnehmende mitnehmen

  • Ein Kubebuilder-Projekt mit kubebuilder init/kubebuilder create api anlegen und die entstehende Struktur (api/, controllers/, config/, main.go) einem generierten Zweck zuordnen.
  • Einen Reconciler mit der Signatur Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) schreiben, inklusive client.Client-Zugriff (Get/Status().Update) und korrektem ctrl.Result{RequeueAfter: …}.
  • Spec (Soll-Zustand) von Status (Ist-Zustand, geschrieben ausschließlich über die Status-Subresource) im eigenen Code sauber trennen – dieselbe Trennung, die der CRD-Kurs nur konzeptionell eingeführt hat.
  • Den eigenen Controller gegen die aus dem Vorgängerkurs bekannte CronTab-Custom-Resource laufen lassen und über kubectl get ct -o yaml live beobachten, wie status.phase/status.lastReconcileTime entstehen.
  • Einen Reconciler-Test mit envtest (echter lokaler API-Server) und Ginkgo/Gomega schreiben, inklusive Eventually(…) gegen einen asynchron geschriebenen Status.
  • Deployment einordnen: Container-Image bauen, make deploy, die generierte ClusterRole aus den +kubebuilder:rbac-Markern nachvollziehen.
  • Benennen, was dieses Modul bewusst nicht behandelt: Admission-/Conversion-Webhooks, produktive Multi-Version-Conversion und Operator Lifecycle Manager (OLM).

Für wen dieses Modul ideal ist

  • • Entwickler:innen mit abgeschlossenen Modulen “Kubernetes CRDs & Operator Pattern” und “Go-Grundlagen” oder gleichwertigen Vorkenntnissen
  • • Alle, die im CRD-Kurs bewusst am “kein Go-Code”-Punkt aufgehört haben und jetzt den fehlenden Controller nachholen wollen
  • • Teams, die einen eigenen Operator ernsthaft in Erwägung ziehen und vor der Investition wissen wollen, wie viel Code wirklich dahintersteckt

Rahmendaten

  • • Dauer: 130 Minuten live (remote oder vor Ort)
  • • Format: Input, Live-Coding, drei Hands-on-Blöcke (Scaffold, Reconciler, Test)
  • • Voraussetzungen: abgeschlossene Module “Kubernetes CRDs & Operator Pattern” UND “Go-Grundlagen” (beide Pflicht), lauffähige lokale Docker-Umgebung für Minikube, keine Cloud-Kostenwirkung

Modulaufbau & Agenda

  1. Kick-off & Abgrenzung (10 min): Rückbezug auf die tote CronTab-CRD aus dem Vorgängerkurs, kein erneutes CR-vs-CRD-vs-Controller, kein Go-Grundlagen-Repetitorium.

  2. Hands-on: Kubebuilder-Projektgerüst (20 min, Hands-on): kubebuilder init, kubebuilder create api, die entstehende Verzeichnisstruktur (api/, controllers/, config/, main.go, PROJECT) Zeile für Zeile einordnen.

  3. Hands-on: Reconciler implementieren (35 min, Hands-on): Reconcile(), client.Client-Zugriff, Status-Subresource-Update, +kubebuilder:rbac-Marker.

  4. Gegen die eigene CronTab-CR reconcilen (20 min, Hands-on): die crd.yaml/my-crontab.yaml aus dem Vorgängerkurs weiterverwenden statt neu zu erfinden, Controller lokal gegen Minikube laufen lassen, Status-Update live per kubectl get ct -o yaml beobachten.

  5. Hands-on: Testing mit envtest & Ginkgo (25 min, Hands-on): envtest.Environment gegen einen echten, lokal gestarteten API-Server, Ginkgo-Describe/It, Eventually(…) gegen den asynchron geschriebenen Status.

  6. Deployment & Abgrenzung (20 min): Container-Build, make deploy, generierte ClusterRole nachvollziehen; explizit NICHT behandelt: Admission-/Conversion-Webhooks, produktive Multi-Version-Conversion, Operator Lifecycle Manager (OLM).

Dieses Modul setzt die Aufbaumodule Kubernetes CRDs & Operator Pattern UND Go-Grundlagen zwingend gleichzeitig voraus. Die Begriffe CR/CRD/Controller aus dem einen und Structs/Interfaces/Error-Handling aus dem anderen Modul gelten als bekannt und werden hier nicht neu erklärt – Modul 4 lebt gerade davon, die im CRD-Kurs bewusst wirkungslos gelassene CronTab weiterzubauen, statt bei einer neuen CRD bei null zu beginnen.

Was dieses Modul bewusst nicht behandelt: Admission- und Conversion-Webhooks als eigenes Kubebuilder-Scaffold (kubebuilder create webhook) – der CRD-Kurs hat Conversion-Webhooks bereits als Konzept-Ausblick eingeordnet, hier folgt kein eigener Webhook-Server; produktive Multi-Version-Conversion zwischen zwei tatsächlich unterschiedlichen Schemas; sowie der Operator Lifecycle Manager (OLM) für Paketierung, Versionierung und Upgrade-Pfade eines Operators im Cluster – alle drei nur benannt, nicht gezeigt. Admission- und Conversion-Webhooks → vertieft im Aufbaumodul Kubernetes Operator härten: Admission- & Conversion-Webhooks mit Kubebuilder weiter, direkt auf derselben CronTab-CRD; der Operator Lifecycle Manager (OLM) → vertieft im Aufbaumodul Kubernetes Operator betreiben: Lifecycle-Management mit OLM weiter, das den Webhook-Kurs zusätzlich voraussetzt.

Hands-on Inhalte (Auszug)

Kubebuilder-Scaffold

  • kubebuilder init –domain example.com –repo example.com/crontab-operator ausführen und main.go/Makefile/PROJECT einordnen
  • kubebuilder create api –group stable –version v1 –kind CronTab ausführen, api/v1/crontab_types.go und controllers/crontab_controller.go als generierten Startpunkt lesen

Reconciler & Status-Subresource

  • Reconcile() mit r.Get(ctx, req.NamespacedName, &cronTab) implementieren, apierrors.IsNotFound für gelöschte Objekte behandeln
  • r.Status().Update(ctx, &cronTab) statt r.Update(…) einsetzen – nur der Status ändert sich, nicht die Spec

Gegen die eigene CronTab reconcilen

  • Denselben my-crontab.yaml aus dem Vorgängerkurs erneut anwenden – diesmal reagiert etwas darauf
  • kubectl get ct -o yaml zeigt status.phase: Ready und status.lastReconcileTime, live vom eigenen Controller geschrieben

Testing mit envtest & Ginkgo

  • envtest.Environment{CRDDirectoryPaths: […]} in BeforeSuite gegen einen echten, lokal gestarteten API-Server hochfahren
  • Mit Eventually(…).Should(Equal(“Ready”)) auf den asynchron vom Reconciler geschriebenen Status warten, statt sofort zu prüfen

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit vom Scaffold bis zum ersten grünen envtest-Lauf) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Bereit, das Modul zu buchen?

Wir passen die Hands-on-Übung auf euren Erfahrungsstand und eure Zielumgebung an.

Academy Briefing anfragen