Develop Kubernetes Operators with Go

Operator development relies on Go; this module introduces the language and concurrency concepts needed for the rest of the three-day workshop. You apply structs*, interfaces, and *error handling in small examples, explore goroutines and channels, and trace how the client-go SDK uses these patterns. In the lab, you modify examples and discuss how to read code and isolate errors.

When is it worth writing an operator, and when does a Helm chart or a simple controller suffice? This module clarifies the terms, introduces the Operator Pattern and the Operator Maturity Model, and gives you a decision framework for your own projects. You analyze two real-world examples from the CNCF ecosystem and classify them.

Custom Resource Definitions extend the Kubernetes API with resource types of your own. You model a CRD with group, version, kind, spec, status, and subresources and register it in the cluster. In the lab environment, you create and inspect instances with kubectl and examine how schemas and API conventions constrain the following controller tasks.

Kubebuilder creates the base structure for the API, controller, configuration, and program entry point. You scaffold a project, trace the registration of its scheme, manager, and reconciler, and distinguish generated code from your own. In the DevNinjas Dojo, our cloud learning environment, you add API fields and inspect how controller-runtime connects the controller to the Kubernetes API.

Reconciliation repeatedly moves the observed cluster state towards the desired state. You implement a Reconcile function, read custom resources through the cached client, and trigger appropriate changes. In the lab environment, you trace events, requests, and repeated runs and examine why controller logic must never assume that it is called only once.

Operators often manage Deployments, Services, or ConfigMaps as dependent objects. You use owner references for Kubernetes garbage collection and finalizers for explicit cleanup outside that lifecycle. In the lab environment, you examine creation and deletion and constrain the finalizer so that failed cleanup remains visible and can be retried.

A reconciler processes the same object repeatedly and must handle identical inputs predictably. You compare existing and desired resources, choose suitable create, patch, or update operations, and maintain status separately from spec. In the cloud lab, you analyse a faulty loop and trace how resource versions, status changes, and careless writes trigger further reconciliation runs.

CRDs can validate input through schemas and CEL rules, while webhooks add programmable validation or defaulting. You implement both options, examine webhook certificates and failure paths, and compare their operational cost. In the lab environment, you test valid and invalid resources and derive criteria for schema-local rules or external admission logic.

Controllers need explicit permissions for every resource they read, create, or modify. You derive RBAC rules from reconciliation steps, generate manifests with Kubebuilder markers, and test the actual access of a service account. In the cloud lab, you reduce an overly broad role and separately examine authentication and authorization options for access to metrics.

Controller logic needs both small unit tests and checks against Kubernetes API behaviour. You configure envtest with an API server and etcd, install CRDs, and test reconciliation and status changes through the client. In the lab environment, you structure positive and negative cases and explicitly identify which cluster components envtest does not provide.

An operator starts with an API whose desired state and observable status must remain understandable. You design spec fields, status conditions, and relationships with dependent resources, make deliberate architecture decisions, and document them before implementation. Spec, status, and generated resources remain visible as distinct parts of the API decision.

Your API design becomes a coherent controller with a CRD, reconciliation logic, dependent objects, and status handling. You implement the steps in your cloud lab and verify every transition against cluster state. A shared review exposes assumptions, error paths, and extension points without prescribing a specific production architecture.

CRD versions separate the served API from the representation stored in the cluster. You define multiple versions, select a storage version, and implement conversion through a shared hub model. In the lab environment, you test conversion in both directions and examine which data loss or incompatible changes an upgrade path must prevent.

Operating a controller requires observable behaviour and controlled parallel operation of multiple instances. You add structured logs and metrics, enable leader election, and examine readiness and error states. In the cloud lab, you trigger a failure and trace reconciliation results, events, and telemetry to isolate its cause and the affected state transition systematically.

Deployment connects controller code, its image, and Kubernetes manifests into a versioned unit. You build the image, inspect Kustomize output, configure probes, and review generated RBAC rules before installation. To conclude, you deploy the operator in the lab environment and identify packaging with Operator Lifecycle Manager as a separate follow-up topic.