Training Module

Kubernetes CRDs & Operator Pattern — Kubernetes um eigene Objekte erweitern

In diesem 100-Minuten-Modul erweitert ihr Kubernetes um eigene Objekttypen. Los geht es mit der Begriffsklärung, die im Alltag am häufigsten durcheinandergeht: Custom Resource (CR) ist eine konkrete Instanz – reine Daten –, die CustomResourceDefinition (CRD) ist das Schema, das diesen neuen Objekttyp beim API-Server registriert, und der Controller ist der laufende Prozess, der Ist- und Soll-Zustand angleicht – genau die Reconciliation-Loop, die ihr aus dem GitOps-Kurs bereits für ArgoCD kennt, jetzt allgemein auf CRDs übertragen. Im Hands-on schreibt ihr eine eigene Minimal-CRD (das Standardbeispiel CronTab aus der offiziellen Kubernetes-Dokumentation), wendet sie mit kubectl apply an und bedient euer eigenes Kind mit kubectl get – Kubernetes behandelt es danach wie jede eingebaute Ressource. Danach ordnet ihr CRD-Versionierung ein: mehrere Versionen über spec.versions mit served/storage -Flags, plus Conversion-Webhooks als Konzept-Ausblick ohne Hands-on, für den Fall, dass sich das Schema zwischen v1alpha1 und v1 tatsächlich ändert – → vertieft im Aufbaumodul Kubernetes Operator härten: Admission- & Conversion-Webhooks mit Kubebuilder mit echtem Conversion-Webhook-Code. Das Operator-Pattern lernt ihr nicht an einem Spielzeugbeispiel, sondern an eurem eigenen, bereits laufenden Cluster: kubectl get crd zeigt euch die Application -CRD, die ArgoCD dort seit dem GitOps-Kurs betreibt – Operator ist damit kein neuer Begriff, sondern die Zusammenfassung von etwas, das ihr längst benutzt habt. Zum Abschluss eine ehrliche Build-vs-Buy-Abwägung: wann ein Helm-Chart oder eine ConfigMap als reiner Datenspeicher reicht, und wann ein eigener, typischerweise mit Kubebuilder oder Operator SDK gebauter Operator gerechtfertigt ist – ohne eigenen Go-Code-Hands-on in diesem Modul, das würde das Modul “Go-Grundlagen” voraussetzen. Wer den fehlenden Controller tatsächlich selbst schreiben will, findet ihn im Aufbaumodul Kubernetes Operator entwickeln mit Kubebuilder (Go) – dort baut ihr genau an dieser Stelle weiter, an derselben CronTab-CRD. Voraussetzung ist das Modul “Kubernetes GitOps — Deklaratives Deployment mit ArgoCD” – die Session läuft weiterhin vollständig lokal über Minikube, ohne Cloud-Account und ohne Kostenwirkung.

Academy Briefing vereinbaren

Oder sofort per Mail an kontakt@codecraft.academy

Format

100 Minuten, live (remote oder vor Ort), Input & Hands-on

Teilnehmende

Entwickler:innen und Ops, die eigene Kubernetes-Objekttypen verstehen und einordnen wollen, ob ein eigener Operator gerechtfertigt ist

Voraussetzungen

Abgeschlossenes Modul “Kubernetes GitOps — Deklaratives Deployment mit ArgoCD” (Pflicht), lauffähige lokale Docker-Umgebung für Minikube

Warum dieses Training für deine Organisation wirkt

Eigene Objekte, nicht nur eigene Werte

Eine ConfigMap speichert Werte – eine CRD definiert einen ganz neuen Objekttyp mit eigenem Schema, eigener Validierung und eigenem kubectl get. Wer den Unterschied nicht kennt, versteht auch nicht, warum kubectl get application oder kubectl get rollout überhaupt funktionieren.

Operator-Pattern erkennen statt neu erfinden

Statt einer abstrakten Definition zeigen wir das Pattern an eurem eigenen, aus dem GitOps-Kurs bereits laufenden ArgoCD – die Application-CRD als Daten, der ArgoCD-Controller als Verhalten. Der Aha-Moment kommt aus dem eigenen Cluster, nicht aus einer Folie.

Build-vs-Buy ehrlich beantwortet

Ein eigener Operator ist ein ernstzunehmendes Software-Projekt, kein Konfigurationstrick. Wer nach diesem Modul weiß, wann ein Helm-Chart reicht und wann Kubebuilder/Operator SDK die Investition wert ist, trifft diese Entscheidung nicht aus Trend, sondern aus Bedarf.

Was Teilnehmende mitnehmen

  • Custom Resource (CR), CustomResourceDefinition (CRD) und Controller/Operator als drei unterschiedliche Dinge klar benennen und auseinanderhalten.
  • Eine eigene Minimal-CRD schreiben: Group/Version/Kind, scope: Namespaced vs. Cluster, sowie ein OpenAPI-v3-Schema unter spec.versions[].schema.openAPIV3Schema.
  • Die eigene CRD mit kubectl apply registrieren und das eigene Kind mit kubectl get genauso bedienen wie eine eingebaute Ressource.
  • Die aus dem GitOps-Kurs bekannte Reconciliation-Loop allgemein auf CRDs übertragen: Custom Resource als Soll-Zustand (Daten), Controller als Prozess, der ihn durchsetzt (Verhalten).
  • CRD-Versionierung von v1alpha1 zu v1 einordnen: mehrere Versionen über served/storage-Flags, Conversion-Strategie None vs. Webhook als Konzept-Ausblick ohne Hands-on.
  • Das Operator-Pattern am bereits im eigenen Cluster laufenden Beispiel erkennen: kubectl get crd zeigt die Application-CRD aus ArgoCD (und ggf. die Rollout-CRD aus Argo Rollouts, falls bereits belegt).
  • Build-vs-Buy einordnen: wann ein Helm-Chart oder eine ConfigMap als reiner Datenspeicher reicht, und wann ein eigener, mit Kubebuilder/Operator SDK gebauter Operator gerechtfertigt ist – ohne eigenen Go-Code in diesem Modul, den echten Reconciler dazu liefert das Aufbaumodul Kubernetes Operator entwickeln mit Kubebuilder (Go).

Für wen dieses Modul ideal ist

  • • Entwickler:innen und Ops mit abgeschlossenem Modul “Kubernetes GitOps — Deklaratives Deployment mit ArgoCD” oder gleichwertigen Vorkenntnissen zu CRDs
  • • Alle, die in Tutorials oder bei Tools wie ArgoCD, Argo Rollouts oder Cert-Manager auf kubectl get <eigenes-kind> gestoßen sind und endlich verstehen wollen, wie das funktioniert
  • • Teams, die vor der Entscheidung stehen, ob sich ein eigener Operator lohnt, und das nicht aus Bauchgefühl entscheiden wollen

Rahmendaten

  • • Dauer: 100 Minuten live (remote oder vor Ort)
  • • Format: Input, Live-Demo im eigenen Cluster, ein Hands-on-Block zur eigenen Minimal-CRD
  • • Voraussetzungen: abgeschlossenes Modul “Kubernetes GitOps — Deklaratives Deployment mit ArgoCD” (Pflicht), lauffähige lokale Docker-Umgebung, keine Cloud-Kostenwirkung

Modulaufbau & Agenda

  1. CR vs. CRD vs. Controller (15 min): Begriffsklärung an der Tafel, Bezug zur aus dem GitOps-Kurs bekannten Reconciliation-Loop.

  2. Hands-on: Minimal-CRD schreiben (20 min, Hands-on): eine eigene CRD mit Group/Version/Kind, OpenAPI-v3-Schema und Scope Namespaced/Cluster schreiben, per kubectl apply/kubectl get gegen das eigene Kind arbeiten.

  3. Versionierung & Conversion-Webhooks (20 min, kein Hands-on): mehrere Versionen über served/storage-Flags, der Weg von v1alpha1 zu v1, Conversion-Webhooks als Konzept-Ausblick – → vertieft im Aufbaumodul Kubernetes Operator härten: Admission- & Conversion-Webhooks mit Kubebuilder.

  4. Operator-Pattern am bekannten Beispiel (20 min): kubectl get crd im eigenen Cluster zeigt bereits laufende CRDs aus ArgoCD (und ggf. Argo Rollouts) – Operator als CR (Daten) plus Controller (Verhalten) erkannt, nicht neu erfunden.

  5. Build-vs-Buy (15 min, ohne eigenen Go-Code in diesem Modul): wann Helm-Chart/ConfigMap reicht, wann ein eigener Operator mit Kubebuilder/Operator SDK gerechtfertigt ist – den eigentlichen Reconciler-Code liefert das Aufbaumodul Kubernetes Operator entwickeln mit Kubebuilder (Go).

  6. Wrap-up & Q&A (10 min).

Dieses Modul setzt das Aufbaumodul Kubernetes GitOps — Deklaratives Deployment mit ArgoCD voraus – nicht nur inhaltlich, sondern technisch: Block 4 nutzt die ArgoCD-Installation aus diesem Vorgängerkurs direkt weiter, statt sie neu aufzusetzen, damit kubectl get crd auf echte, bereits laufende CRDs trifft statt auf einen leeren Cluster.

Abgrenzung, explizit angesagt: Das Modul Kubernetes GitOps — ArgoCD nutzt die Application-CRD bereits ausführlich, erklärt aber nie, was eine CRD strukturell überhaupt ist – dieses Modul liefert genau das nach, statt es zu wiederholen.

Kein Go-Code, kein Kubebuilder-Hands-on in diesem Modul. Einen eigenen Controller zu schreiben und zu testen setzt das Modul Go-Grundlagen voraus – dieses Modul bleibt bewusst bei CRD und Konzept, Block 5 ist eine Einordnung ohne eigenen Code. Den fehlenden Reconciler schreibt ihr im direkten Aufbaumodul Kubernetes Operator entwickeln mit Kubebuilder (Go), das auf diesem Kurs UND auf Go-Grundlagen aufbaut und an derselben CronTab-CRD weiterarbeitet.

Hands-on Inhalte (Auszug)

Eigene CRD schreiben & anwenden

  • Eine CustomResourceDefinition mit apiVersion: apiextensions.k8s.io/v1, eigener Group, scope: Namespaced und einem OpenAPI-v3-Schema für spec schreiben
  • Mit kubectl apply -f anwenden und mit kubectl get crd bestätigen, dass der API-Server das neue Kind kennt

Eigene Custom-Resource-Instanz

  • Eine erste Instanz des eigenen Kinds anwenden und über Plural-, Singular- und Short-Name gleichermaßen abrufen (kubectl get crontabs/crontab/ct)
  • Mit kubectl get ct -o yaml nachvollziehen, dass Kubernetes das eigene Objekt genauso speichert und ausliefert wie eine eingebaute Ressource

Operator-Pattern im eigenen Cluster

  • Mit kubectl get crd die bereits aus dem GitOps-Kurs installierten CRDs von ArgoCD (applications.argoproj.io u. a.) im eigenen Cluster wiederfinden
  • Eine bestehende Application-Instanz als Custom Resource (Daten) dem laufenden ArgoCD-Controller (Verhalten) gegenüberstellen

Build-vs-Buy einordnen

  • Am eigenen CronTab-Beispiel durchspielen, wann eine reine ConfigMap oder ein Helm-Chart als Datenspeicher ausgereicht hätte – und wo eine echte Reconciliation-Loop den Unterschied macht
  • Kubebuilder und Operator SDK als Werkzeuge zum Schreiben eines echten Controllers benennen, ohne sie in dieser Session einzusetzen

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit vom Anwenden der eigenen CRD bis zum ersten erfolgreichen kubectl get auf das eigene Kind) 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