Build Kubernetes Operators with Controller-Runtime

This skill builds Kubernetes operators using the controller-runtime framework and operator-sdk, covering custom resources, controllers, webhooks, and cloud-native extension patterns. Every controller follows the reconcile-loop pattern - observe, analyze, act - with idempotent operations safe to retry, predicate filtering for efficient event handling, and exponential-backoff error handling. Operators are scoped against a five-level maturity model: basic install, seamless upgrades, full lifecycle management (backup, failure recovery, scaling), deep insights (metrics, alerts, log processing), and full auto-pilot (automatic horizontal and vertical scaling and abnormality detection).

Use it when building a Kubernetes operator that needs a real reconcile loop, status management, and admission webhooks - not a one-off script that just applies a manifest. It is not a substitute for its own testing discipline: controller logic should be tested against a real API server via envtest before shipping, and production deployments should enable leader election and graceful shutdown rather than running a single unguarded replica.

Given a custom resource definition (a spec with validated fields like a replica-count range, a required image, a defaulted and enum-constrained service type, and resource requirements, plus a status with an enum phase, ready-replica count, conditions, and a last-reconcile timestamp), the reconcile function fetches the resource, handles deletion via a finalizer, reconciles the owned Deployment (creating it with an owner reference if missing, updating it only when the spec has actually changed), and updates status - setting a Ready condition once the deployment's ready-replica count matches the desired count, and requeuing every 5 minutes. Admission webhooks validate on create (replicas must be positive, the image must include a tag) and on update (blocking image downgrades), and watch setup restricts reconciliation to generation-changed events with a capped concurrency of 2.

// api/v1/myapp_types.go
type MyAppSpec struct {
    // +kubebuilder:validation:Minimum=1
    // +kubebuilder:validation:Maximum=10
    Replicas *int32 `json:"replicas,omitempty"`
    
    // +kubebuilder:validation:Required
    Image string `json:"image"`
    
    // +kubebuilder:default="ClusterIP"
    // +kubebuilder:validation:Enum=ClusterIP;NodePort;LoadBalancer
    ServiceType corev1.ServiceType `json:"serviceType,omitempty"`
    
    Resources *corev1.ResourceRequirements `json:"resources,omitempty"`
}

type MyAppStatus struct {
    // +kubebuilder:validation:Enum=Pending;Running;Failed
    Phase string `json:"phase,omitempty"`
    
    ReadyReplicas int32 `json:"readyReplicas,omitempty"`
    
    Conditions []metav1.Condition `json:"conditions,omitempty"`
    
    LastReconcileTime *metav1.Time `json:"lastReconcileTime,omitempty"`
}

RBAC is scoped explicitly per resource group (core pods, services, and configmaps, apps deployments, and the operator's own custom resource plus its status and finalizer subresources), and the manager wires in health checks (healthz/readyz probes), a metrics bind address for Prometheus scraping, and leader election for high availability. Production recommendations layer on top: multi-stage Docker builds for smaller images, resource limits and requests, semantically versioned CRDs with conversion webhooks, structured logging, chaos-engineering testing (for example, Chaos Mesh), and distribution via the Operator Lifecycle Manager (OLM).

Platform engineers building Kubernetes operators who need the full production pattern, not just a reconcile function - CRD validation, status conditions, admission webhooks, envtest-based controller testing, RBAC scoping, and observability wired in from the start.