Kubernetes is most often described as a container orchestration tool, but after you’ve spent some time with it, that mental model doesn’t always feel like the most useful way to think about what’s happening.
In many cases for me Kubernetes feels less like an orchestrator and more like a platform where you declare the desired state of your infrastructure and let the system continuously work to match your intent.
That’s why I like to think of Kubernetes as a runtime for declarative infrastructure with a type system. Let me break it down.
Type System #
Consider this manifest:
apiVersion: v1 kind: Pod metadata: name: nginx labels: app: nginx spec: containers: - name: nginx image: nginx:stable ports: - containerPort: 80 copy
If you’ve spent a bit of time with k8s you probably know what this is. It’s a resource of type Pod - the smallest unit Kubernetes schedules and runs. This one runs an nginx container and declares that the container listens on port 80.
Pods don’t usually live on their own. In real systems you wrap them in higher-level resources: a ReplicaSet to keep N copies around, a Deployment to manage rollouts on top of that, a Service to give them a stable network identity and an Ingress to route traffic between Services.
You see how Kubernetes comes with a whole vocabulary of resource kinds that are responsible for different parts of your infrastructure and the more you think about it, the more that vocabulary starts to behave a lot like a type system.
A Pod isn’t “just a container” and a Deployment isn’t “just a script that creates Pods”. Each one is a type with a strict definition and specific semantics - what it means, what fields are valid, how it’s allowed to change and which other types it composes with.
... continue reading