I Think about Kubernetes

How I think about Kubernetes More than a container orchastrator 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 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. Just like a standard type system in a programming language, except instead of types like int , char , and string , you get Pod , Deployment and Service . And just like in a programming language, you can define your own types too. That’s what CRDs are - new resource kinds that extend the API, with operators that implement what those new types mean. Traditionally we think about workloads as processes or containers. Kubernetes still runs those, but it abstracts them away by giving your infrastructure a type system . Runtime # The manifest I showed before is just a file in which you declare a desired state. Now let’s examine what happens when you apply it to your cluster. kubectl apply -f pod.yaml Kubernetes doesn’t execute your YAML the way a script runs. What happens is you submit a typed declaration to a runtime and that runtime continuously works to make the infrastructure match your intent . The API server accepts your object. It parses the request, checks that the object is valid, applies admission and policy rules and then stores it as...

Preview: ~500 words