Kubernetes Operator-Entwicklung mit Go

Nein, Go-Vorkenntnisse sind nicht erforderlich. Der Workshop beginnt mit einem Go-Crashkurs, der die für die Operator-Entwicklung relevanten Konzepte abdeckt: Structs, Interfaces, Error Handling und Concurrency-Grundlagen.

Sie sollten allerdings Erfahrung mit mindestens einer Programmiersprache mitbringen (z.B. Python, Java, TypeScript). Die Go-Syntax lernen Sie im Workshop, aber Grundkonzepte wie Variablen, Funktionen und Kontrollstrukturen sollten Ihnen vertraut sein. Wollen Sie Go vorab gründlich lernen, empfehlen wir unsere Golang Schulung (DW17).

kubectl-Erfahrung reicht. Sie sollten sicher mit kubectl arbeiten und die Kernkonzepte kennen (Pods, Deployments, Services, ConfigMaps, RBAC) sowie YAML-Manifeste routiniert erstellen. Das programmatische API-SDK client-go setzen wir nicht voraus.

Den Umgang mit client-go und controller-runtime lernen Sie im Workshop: vom Lesen und Schreiben von Ressourcen bis zu Informers und Caches im Reconciliation Loop. Sie brauchen also kein Go-API-Vorwissen, sondern nur das Cluster-Grundverständnis, das Sie aus dem täglichen kubectl-Betrieb mitbringen.

Helm Charts verpacken und deployen Kubernetes-Ressourcen. Das reicht für die meisten Anwendungen. Ein Operator wird dann sinnvoll, wenn Ihre Anwendung laufende Verwaltungslogik braucht: automatische Backups, Failover, Skalierung nach eigenen Regeln oder das Management von Ressourcen außerhalb des Clusters.

Die Faustregel: Wenn Sie nach dem Deployment regelmäßig manuell eingreifen müssen, ist das ein Signal für einen Operator. Wenn kubectl apply und ein paar Values reichen, bleiben Sie bei Helm. Im Workshop arbeiten wir diesen Unterschied anhand konkreter Szenarien heraus, damit Sie die richtige Entscheidung für Ihre Projekte treffen.

Beide Tools nutzen controller-runtime als Grundlage und erzeugen ähnliche Projektstrukturen. Kubebuilder ist das offizielle CNCF-Projekt für Go-basierte Operatoren und konzentriert sich auf Go als einzige Sprache. Das Operator SDK baut auf Kubebuilder auf und erweitert es um Ansible- und Helm-basierte Operatoren sowie den Operator Lifecycle Manager (OLM).

Im Workshop arbeiten wir mit Kubebuilder v4, weil es den direktesten Weg zum Verständnis der zugrundeliegenden Mechanik bietet. Was Sie mit Kubebuilder lernen, lässt sich 1:1 auf das Operator SDK übertragen.

Nach drei Tagen können Sie:

• Eigene Operatoren scaffolden und mit Kubebuilder von der CRD bis zum Reconciliation Loop implementieren
• Abhängige Ressourcen (Deployments, Services, ConfigMaps) erstellen und mit Owner References verwalten
• Validierung und Defaulting mit Admission Webhooks und CEL Rules einrichten
• Automatisierte Tests mit envtest schreiben und in eine CI/CD-Pipeline integrieren
• Operatoren produktionsreif machen mit Prometheus-Metriken, Leader Election und CRD-Versionierung

Realistisch: Nach drei Tagen sind Sie kein Operator-Experte, aber Sie können eigenständig Operatoren für Ihre Projekte entwickeln, testen und deployen. Tiefe Expertise kommt mit der Anwendung in Ihren eigenen Szenarien.

Ja, das Operator SDK unterstützt neben Go auch Ansible- und Helm-basierte Operatoren. Für einfache Anwendungsfälle (z.B. ein Helm Chart mit Status-Reporting) kann das ausreichen.

In der Praxis stoßen Sie mit Ansible und Helm schnell an Grenzen: komplexe Reconciliation-Logik, feingranulares Error Handling und Performance bei vielen Custom Resources sind mit Go deutlich besser lösbar. Die meisten produktionsreifen Operatoren im CNCF-Ökosystem (cert-manager, Prometheus Operator, ArgoCD) sind in Go geschrieben. Deshalb setzt dieser Workshop bewusst auf Go als Grundlage.

Testing ist ein eigener Block am zweiten Tag und kein Randthema. Sie schreiben Unit Tests für einzelne Funktionen, Integration Tests mit envtest (einem lokalen API-Server ohne echten Cluster) und strukturieren alles mit Ginkgo und Gomega.

Das Ergebnis ist ein Test-Setup, das Sie direkt in Ihre CI/CD-Pipeline übernehmen können. Die meisten Operator-Kurse behandeln Testing bestenfalls am Rande. Wir halten es für den Unterschied zwischen einem Prototyp und einem produktionsreifen Operator.

Alle Praxisübungen finden im DevNinjas Dojo statt, unserer browserbasierten Cloud-Lernumgebung. Jeder Teilnehmer erhält eigene dedizierte Ressourcen: eigene Kubernetes-Cluster, VMs, Container (je nach Workshop-Thema). Sie arbeiten nicht in einer geteilten Umgebung, sondern haben volle Kontrolle über Ihre eigene Infrastruktur.

Vorteile:

• Eigene Cluster & Server: Sie bekommen dedizierte Ressourcen für Ihre Übungen
• Keine Software-Installation nötig: Alles läuft im Browser
• Funktioniert überall: Auch in strengen Enterprise-Netzwerken mit VPN, Proxy und Firewalls
• Offene Protokolle: SSH, HTTPS, standardisierte Web-Terminals (kein proprietärer Client)
• Sofort startklar: Login und direkt mit der Übung beginnen

Sie benötigen lediglich einen modernen Browser (Chrome, Firefox, Edge) und Internetzugang. Das Dojo steht Ihnen während des gesamten Workshops zur Verfügung.

Wir empfehlen maximal 8 Teilnehmer pro Schulung, damit jeder Teilnehmer individuell betreut werden kann. Bei Firmenschulungen sind Absprachen für größere Gruppen möglich.

Ja, Sie erhalten nach Abschluss ein offizielles Teilnahmezertifikat von DevNinjas als PDF. Dieses bestätigt Ihre erfolgreiche Teilnahme und die behandelten Themen. Das Zertifikat eignet sich ideal für Gespräche mit Ihrem Arbeitgeber und Ihre Personalakte.

Zusätzlich erhalten Sie ein verifiziertes digitales Badge, das Sie direkt in Ihr LinkedIn-Profil einbinden können (Sektion "Lizenzen & Zertifizierungen"). Das Badge folgt dem Open Badges 2.0 Standard und ist durch QR-Code jederzeit verifizierbar. So machen Sie Ihre Qualifikation sichtbar und positionieren sich bei Recruitern.