TL;DR
The author argues Kubernetes is more usefully understood not merely as a container orchestrator but as a runtime that enforces declarative infrastructure through a typed API. Resource kinds act like types, controllers continuously reconcile spec toward actual state, and GitOps fits as the source-of-truth layer that drives desired state back into the cluster.
What happened
The piece reframes Kubernetes from a task-runner into a persistent runtime for declarative infrastructure. Manifests (for example, a Pod definition) are typed declarations that the API server validates and stores as durable cluster state rather than imperative commands to execute. A family of resource kinds—Pods, ReplicaSets, Deployments, Services, Ingresses—functions like a type system with defined semantics; custom resource definitions (CRDs) let operators add new types. Controllers observe declared objects, compare desired (spec) with observed (status) state, and take actions to converge the cluster. The reconciliation loop is continuous: changes in declarations prompt the runtime to act, and transient manual edits can be reverted if they conflict with the declared intent. In this model, GitOps places the canonical desired state in Git while a controller keeps cluster objects aligned with that repository.
Why it matters
- Operators should treat Kubernetes as a system that enforces declared intent, not as an imperative task runner.
- Understanding spec vs. status and reconciliation reduces surprise from transient manual edits or automated reverts.
- GitOps and Kubernetes reconciliations complement each other: Git holds the source of truth while the runtime enforces cluster state.
- Using built-in resource kinds and CRDs encourages clearer ownership and fewer ad-hoc conventions.
Key facts
- Kubernetes resources are typed (examples: Pod, Deployment, Service, Ingress) and carry specific semantics.
- A manifest is a declaration of desired state that the API server validates and persists rather than a script to execute.
- Controllers continuously watch objects and reconcile actual state toward the declared spec.
- The kube-scheduler decides node placement for Pods; kubelet on the node makes containers run according to the cluster’s desired state.
- Custom Resource Definitions (CRDs) allow adding new resource kinds to extend the API and encode custom semantics.
- Spec represents what you want; status reports what the runtime observed and computed.
- Deleting or editing a live object can be undone by the runtime if the declared desired state still demands a different outcome.
- GitOps treats Git as the primary source of desired state and uses a controller to converge cluster objects toward the repository.
What to watch next
- Monitor reconciliation status fields to understand why the runtime isn’t matching spec.
- Make ownership explicit when using GitOps so parallel reconciliations don’t conflict.
- Choose appropriate resource kinds (or CRDs) instead of relying on ad-hoc conventions for lifecycle management.
Quick glossary
- Pod: The basic schedulable unit in Kubernetes, typically grouping one or more containers that share network and storage resources.
- Custom Resource Definition (CRD): A mechanism to extend the Kubernetes API with new resource types that encode custom semantics and are managed by operators or controllers.
- Controller: A control loop that watches for changes to relevant objects and takes actions to reconcile actual state with the declared desired state.
- Spec: The part of a resource that declares the desired configuration or intent.
- Status: The part of a resource that records what the runtime has observed or computed about the resource’s current state.
Reader FAQ
Is Kubernetes just a container orchestrator?
The author argues it is more useful to view Kubernetes as a runtime for declarative infrastructure with a typed API, not merely an orchestrator.
What happens when you apply a manifest?
The API server validates and stores the declared object; controllers then work continuously to reconcile actual state toward that declaration.
Should you edit resources directly with kubectl if you use GitOps?
If resources are managed by GitOps, direct kubectl edits are best used for debugging because the GitOps controller will likely revert changes to match Git.
What are CRDs for?
CRDs let you extend the Kubernetes API with new resource kinds so you can model and manage additional types of infrastructure.
How I think about Kubernetes More than a container orchastrator December 26, 2025 Kubernetes is most often described as a container orchestration tool, but after you’ve spent some time with…
Sources
- I Think about Kubernetes
- Beyond Declarative DSLs In Kubernetes
- 10 Ways for Kubernetes Declarative Configuration …
- Declarative Management of Kubernetes Objects Using …
Related posts
- Experts Explore New Mushroom Which Causes Fairytale-Like Hallucinations
- A Proclamation on Restoring the Em—Dash: Reclaiming the Writer’s Mark
- How Charles Dodgson (Lewis Carroll) developed condensation for determinants