Introduction: When standard objects aren't enough

The vocabulary limit

Up until now, we've used the standard vocabulary that Kubernetes understands out of the box: Pods, Services, Deployments, ConfigMaps, and so on. These general-purpose tools are great for running generic, stateless applications.

But what if you want to manage something complex and domain-specific — like a clustered PostgreSQL database with automatic failover, point-in-time backups, and read replicas? A database isn't just a container you start and forget. It has operational knowledge baked into it: how to promote a replica when the primary fails, how to take a consistent backup without locking writes, how to safely upgrade the engine version with zero downtime.

You could try to jam all that logic into a giant Bash script running inside a standard Pod, but that approach is brittle, hard to test, and nearly impossible to maintain as complexity grows.

The Kubernetes Philosophy

Kubernetes was designed from the ground up to be extensible. The core philosophy is: Don't build every possible feature into the main Kubernetes codebase. Instead, provide powerful, stable extension points that allow users to teach Kubernetes new concepts — both new resource types and new behaviors — without forking or modifying the core.

This philosophy is why you can use the same kubectl apply workflow to deploy a simple web server and to provision a production-grade Kafka cluster managed by a third-party Operator. The interface is identical; only the underlying machinery differs.

The three primary extension mechanisms are: