In June 2014, Google publicly announced a container orchestration system built on lessons from its internal Borg and Omega platforms. A little over a year later, on 21 July 2015, Kubernetes 1.0 shipped alongside the launch of the Cloud Native Computing Foundation. Few infrastructure projects have moved from announcement to industry default that quickly, and fewer still have stayed there for a decade.
The name itself is Greek for “helmsman” or “pilot,” which explains the abbreviation K8s: eight letters sit between the K and the s. That small piece of trivia is a good entry point, because Kubernetes is fundamentally about steering many moving parts at once. This article looks at what Kubernetes actually does, how its architecture fits together, the mistakes teams make most often, and what the platform demands in return for its benefits. (Kubernetes Documentation)
What Kubernetes Actually Does
Kubernetes is a system for running containers across a group of machines and keeping them in the state you declared. You describe the desired outcome, such as “three copies of this web service should always be running,” and the platform works continuously to make reality match that description.
That declarative model is the conceptual leap many newcomers miss. Traditional deployment scripts say do this, then do that. Kubernetes says here is what the world should look like, and its controllers reconcile endlessly toward that target. If a pod crashes, a controller notices and replaces it. If a node disappears, workloads reschedule elsewhere. Nobody has to write a script for each failure scenario.
The platform also handles service discovery, load balancing, rolling updates, secret distribution, and horizontal scaling. Each of those capabilities exists in simpler tools, but Kubernetes bundles them behind one API, which is why it became the common language for infrastructure teams.
Inside a Cluster: Control Plane and Nodes
A Kubernetes cluster splits into two halves, and understanding the split prevents a lot of confusion later.
The control plane is the brain. It runs the API server, which every request passes through; etcd, the distributed key-value store holding cluster state; the scheduler, which decides where new pods land; and the controller manager, which runs the reconciliation loops. The worker nodes are the muscle. Each node runs kubelet, an agent that talks to the control plane, plus a container runtime reached through the Container Runtime Interface, or CRI.
That CRI detail matters more than it used to. The dockershim was deprecated in Kubernetes 1.20 in December 2020 and removed in 1.24 in May 2022, which pushed the default runtime path toward CRI-compliant options such as containerd and CRI-O. Teams that upgraded without checking their runtime configuration learned this the hard way. Anyone planning a version jump today should treat runtime compatibility as a first-class checklist item, much like the preparation covered in this walkthrough of an EKS cluster upgrade to Kubernetes 1.37 in 13 steps. (Kubernetes)
The table below summarizes how responsibilities divide.
| Layer | Main Components | Job |
|---|---|---|
| Control plane | API server, etcd, scheduler, controller manager | Store desired state, schedule work, reconcile reality |
| Worker nodes | kubelet, container runtime (CRI), kube-proxy | Run pods, report status, route traffic |
| Workload objects | Deployments, StatefulSets, DaemonSets, Jobs | Describe how applications should be managed |
| Networking | Services, Ingress, CNI plugins | Connect pods to each other and the outside world |
Why the Supporting Tools Grew So Fast
Kubernetes graduated from CNCF in March 2018, a signal that the project had reached maturity and broad production adoption. It is licensed under Apache 2.0 and hosted by the Linux Foundation, which means no single vendor controls its direction. That neutral governance is a large part of why cloud providers, hardware vendors, and startups all built around the same API instead of fragmenting into competing standards.
The release cadence has held a steady pace. Since roughly 2016, the project has shipped about three minor releases per year, with each release supported for around fourteen months. That rhythm gives users predictable upgrade windows, but it also means clusters fall out of support quickly if nobody owns the upgrade calendar. A cluster two or three versions behind may be stale, and it may also be running without security patches.
The tools around the core have grown into a sprawling toolset for observability, policy, service mesh, GitOps, and cost management. The trade-off is real: the more tools you adopt, the more surface area you maintain. Mature teams tend to start with the smallest viable stack and add components only when a specific pain point demands them.
Common Mistakes Teams Make in Practice
Most Kubernetes problems are not exotic. They fall into a handful of recurring categories, and nearly all of them are preventable with modest discipline.
Skipping resource requests and limits. Pods without requests let the scheduler make blind placement decisions. Pods without limits can starve neighbors during a memory spike. Setting both is the single highest-value configuration change most clusters need.
Treating namespaces as an afterthought. Namespaces are the basic unit of isolation, quota, and access control. Teams that dump everything into `default` eventually face painful migrations.
Ignoring the upgrade treadmill. Version skew between the control plane and nodes causes subtle failures. So does skipping minor versions, since the project only supports limited skew. Plan upgrades on a calendar, not in a panic.
Storing secrets carelessly. Base64 is encoding, not encryption. Secrets in plain YAML committed to Git are a breach waiting to happen; encryption at rest and an external secret manager are baseline controls.
Over-engineering early. A team running three services does not need a service mesh, a custom operator, and a multi-cluster federation layer on day one. Complexity added before it is needed becomes permanent overhead.
Neglecting cost visibility. Kubernetes abstracts away machines, which also abstracts away the bill. Without per-namespace cost allocation, idle capacity quietly accumulates.
A useful habit is to run a short pre-production review against these six points before any new workload goes live. It takes an afternoon and catches most of the expensive surprises.
What Kubernetes Costs You
Honest assessments of Kubernetes have to include the operational bill. The platform is powerful precisely because it is flexible, and flexibility means decisions. Someone has to choose a networking plugin, a storage model, an ingress strategy, an upgrade cadence, and a logging pipeline. Each choice has consequences and none of them are free.
That burden explains a counterintuitive pattern in modern work: automation often shifts effort rather than eliminating it. Tooling that promises to reduce toil can generate review queues, configuration sprawl, and coordination overhead. Research on how AI assistants reshape knowledge work has found similar dynamics, with productivity gains accompanied by new forms of oversight work, as explored in this analysis of an Anthropic study on AI creating more work. Kubernetes follows the same logic. It removes manual server provisioning and replaces it with declarative configuration management, which is better work but still work.
The practical conclusion is that Kubernetes pays off at a certain scale and with a certain team structure. A small team with a handful of stable services may genuinely be better served by a managed container service or even plain virtual machines. A larger organization with many teams, variable load, and a need for consistent deployment patterns usually finds the platform’s leverage worth the overhead.
Getting Started Without Regret
For teams approaching Kubernetes for the first time, a few practical guidelines hold up well.
- Start with a managed control plane. Running etcd and the API server yourself is a worthwhile learning exercise but a poor first production choice.
- Deploy one real, non-critical service end to end before migrating anything important. Learn the deployment, service, ingress, and secret flow on something that can break safely.
- Write manifests in version control from day one. Imperative `kubectl` commands are fine for debugging and terrible as a deployment strategy.
- Set resource requests and limits before the first production deploy, not after the first outage.
- Establish an upgrade calendar tied to the support window, and assign a named owner.
- Add observability before you need it. Metrics, logs, and traces are cheaper to install during calm periods.
The order matters. Teams that adopt GitOps and policy enforcement before they understand the basics tend to build elaborate systems they cannot debug. Teams that learn the primitives first can add tooling incrementally with confidence.
It also helps to understand the commercial landscape around the platform, since managed offerings differ substantially in pricing and lock-in. Providers such as the cloud vendors behind services like Uber have shaped how orchestration and infrastructure tooling get packaged for enterprises, and the ownership structures behind those companies influence which platforms get long-term investment, a topic covered in this look at who owns Uber. For most buyers, the practical question is not who builds the tool but whether the managed service’s upgrade path, support window, and pricing model match the team’s operational reality.
Conclusion
Kubernetes earned its position through a combination of timing, neutral governance, and a genuinely useful abstraction. Declaring desired state and letting controllers reconcile it is a better model than scripting every step, and the CRI-based architecture has proven adaptable as runtimes evolved. The Apache 2.0 license and CNCF stewardship gave vendors a shared foundation instead of a fragmented market.
But the platform is not self-managing, and it never has been. The three-releases-per-year cadence, the fourteen-month support window, and the steady stream of deprecations mean clusters require ongoing attention. The teams that succeed with Kubernetes are rarely the ones with the most elaborate tooling. They are the ones that set resource limits, keep namespaces tidy, track their versions, and resist adding complexity before it earns its place.
For organizations weighing adoption, the honest framing is this: Kubernetes solves coordination at scale, and it charges for that service in operational discipline. Where the scale exists, the trade is usually worth making. Where it does not, simpler tools remain perfectly respectable choices.
Frequently Asked Questions
What does the name Kubernetes mean?
Kubernetes is Greek for “helmsman” or “pilot,” a fitting name for software that steers containers across a fleet of machines. The common abbreviation K8s comes from counting the eight letters between the K and the final s.
Who created Kubernetes and who maintains it now?
Google announced the project publicly in June 2014, drawing on experience from its internal Borg and Omega systems. Google donated it to the Cloud Native Computing Foundation, which the Linux Foundation hosts, and the project graduated from CNCF in March 2018. It is licensed under Apache 2.0 and governed by community contributors rather than a single vendor.
How often does Kubernetes release new versions?
Since roughly 2016 the project has shipped about three minor releases per year, and each release is supported for around fourteen months. That means clusters can fall out of support within a year and a half if upgrades are not scheduled, so a named owner and a calendar are essential.
What happened to Docker support in Kubernetes?
The dockershim component was deprecated in Kubernetes 1.20 in December 2020 and removed in version 1.24 in May 2022. Clusters now use CRI-compliant runtimes such as containerd or CRI-O. Docker images still work fine; what changed is the runtime layer that executes them.
Is Kubernetes worth it for a small team?
Often not, at least not at first. The platform’s value comes from coordinating many services, teams, and variable workloads. A small team with a few stable services may get better results from a managed container service or plain virtual machines, then adopt Kubernetes when coordination costs justify it.
What is the most common Kubernetes mistake?
Missing resource requests and limits is the most frequent and most costly error. Without requests, the scheduler places pods blindly. Without limits, one memory-hungry pod can destabilize its neighbors. Setting both takes minutes and prevents a large share of production incidents.
