What Is Kubernetes?
Container adoption accelerated faster than most infrastructure teams expected. Suddenly there were hundreds of containers per service, dozens of services per team, and no coherent answer to the question of where things ran, how they got there, and what happened when they failed. Kubernetes emerged as the answer the industry converged on, not because it was simple, but because the problem it solve…
- Kubernetes is a reconciliation engine, you declare desired state and the platform works to maintain it.
- RBAC is the security foundation of a Kubernetes cluster, over-permissive service accounts are privilege escalation vectors.
- Self-healing masks problems in the absence of observability, instrument your cluster before you rely on its resilience.
- Label selectors create implicit dependencies between objects, coherence across Deployments, Services, and NetworkPolicies matters.
Kubernetes Is A Reconciliation Engine, Not A Deployment Tool
The mental model most engineers start with is that Kubernetes runs containers. That's true but incomplete in a way that causes operational problems. What Kubernetes actually does is continuously reconcile the observed state of your cluster against a declared desired state. You tell the API server what you want. The control plane works to make reality match the declaration. If something drifts, a pod crashes, a node fails, a container exits, the reconciliation loop notices and acts. This reconci
The Primitives That Actually Matter In Production
Kubernetes has a large API surface area. In practice, most production operations involve a small set of primitives used repeatedly. Pods are the scheduling unit, one or more containers with shared network and storage. Deployments manage rolling updates and replica counts for stateless workloads. Services provide stable network endpoints for pods that come and go. ConfigMaps and Secrets externalize configuration. Namespaces provide a soft isolation boundary for grouping resources. Where teams ge
RBAC Is The Security Foundation You Cannot Skip
Kubernetes Role-Based Access Control governs who can perform which operations on which resources in which namespaces. It's the primary access control mechanism for both human operators and service accounts running inside the cluster. Getting it right is not optional, a misconfigured RBAC policy can let a compromised workload call the Kubernetes API, read secrets from other namespaces, or escalate privileges by creating new RoleBindings. The failure mode I see most often is overly permissive ser
Frequently asked questions
- How long does it realistically take to become operationally competent with Kubernetes?
- Running something in a cluster is a day. Understanding why it's misbehaving in production is six to twelve months of pattern accumulation. The gap is in failure mode recognition, knowing that an 'OOMKilled' event means you need to tune memory limits, that a 'Pending' pod is usually a resource constraint or an affinity conflict, that a 'Terminating…
- Should every team manage their own Kubernetes cluster or use a managed service like EKS or GKE?
- Use a managed service unless you have a very specific reason not to. Managing the control plane, upgrades, etcd backups, API server availability, is a significant operational burden that most product teams should not carry. EKS, GKE, and AKS handle the control plane and give you a mostly-standard Kubernetes API. Your operational scope becomes node…
- How do you handle secrets in Kubernetes without putting them in plaintext YAML?
- Kubernetes Secrets are base64-encoded, not encrypted, which means storing them in Git is not acceptable for sensitive values. The standard approaches are: Vault with the Vault Agent Injector or External Secrets Operator to pull secrets from Vault into pods at runtime; sealed-secrets (Bitnami) to encrypt secrets with a cluster-side key before commi…
- What security controls should every Kubernetes cluster have before it touches production traffic?
- At minimum: RBAC with least-privilege roles (no default service account tokens with cluster-admin), network policies that deny traffic by default and allow it explicitly, image scanning in CI before deployment, and resource quotas per namespace to contain blast radius. Add: admission control via OPA Gatekeeper or Kyverno for policy enforcement, au…
- How do you approach multi-tenancy in Kubernetes, multiple teams sharing one cluster?
- Namespace isolation with RBAC and network policies is the minimum viable approach. Each team gets a namespace with a ResourceQuota, a LimitRange, and RBAC roles scoped to that namespace only. Network policies restrict cross-namespace traffic to what is explicitly needed. The challenge is that Kubernetes namespace isolation is not as hard as a VM b…