// the find
kubernetes-sigs/controller-tools
Tools to use with the controller-runtime libraries
controller-tools is the code generation side of the kubebuilder ecosystem — it provides controller-gen, which reads Go type annotations (markers) and outputs CRD YAML, RBAC manifests, webhook configurations, and DeepCopy implementations. If you're writing a Kubernetes operator, you almost certainly use this already, probably without knowing it directly because kubebuilder scaffolds the Makefile invocation for you.
The marker system is genuinely well-designed: annotations like `+kubebuilder:validation:Minimum=0` live next to the field they describe and survive refactors better than separate schema files. CRD generation handles tricky Go patterns — embedded structs, external types, multi-version APIs — that would be painful to write by hand. The envtest release matrix (`hack/envtest/_matrix/`) pins binaries per Kubernetes version across Linux/macOS/Windows, which is the most reliable way to run controller integration tests locally. The separation between the generator library (`pkg/`) and the CLI (`cmd/controller-gen`) means you can embed generation into your own tooling without forking.
The version coupling is painful in practice: one minor version of controller-tools supports exactly one minor version of client-go, so upgrading your Kubernetes dependency means upgrading controller-tools and hoping nothing broke in your marker usage. Error messages when a marker is wrong or a type is unsupported are often cryptic — you get a type traversal failure rather than 'this field type cannot be represented in OpenAPI v3'. The README is essentially empty; all real documentation lives in the kubebuilder book, so you're always one tab away from losing context. The `schemapatcher` generator (for patching existing CRDs rather than generating from scratch) is underdocumented and its interaction with structural schema validation is easy to get wrong silently.