Ask a platform team what they built last year, and the list likely includes a Kubernetes controller that creates a few objects in order and copies fields between them. No business logic, just wiring. A Deployment, a Service in front of it, and a ConfigMap whose one interesting value is the hostname the Service reports in its status. Kubebuilder turns building the first controller into a pleasant afternoon. The tenth brings its own reconcile bugs, upgrade path, and on-call rotation. It’s the same controller. It’s slightly different each time, and it exists in thousands of organizations.

Kubernetes has the ingredients: CRDs define new types. Controllers give them behavior. Server-side apply tracks who owns each field. CEL evaluates expressions, and OpenAPI schemas type every field. What Kubernetes does not provide is the recipe. Nothing says that several resources form one thing, or that a value in one comes from the status of another and must wait for it.

KubeCon + CloudNativeCon is taking place in Salt Lake City from November 9 to 12. Register now!

Every tool that manages a set of resources builds that piece itself, and keeps adding to it. Helm does it at render time, and Helm 4 added server-side apply and waiting on resource status. Argo CD has sync waves, hooks , and health checks because manifests cannot say what order they need or when they are done. Crossplane has compositions and functions , and v2 composes native Kubernetes resources directly. Operators do it in Go, by hand.

Source link