What is Kubernetes?
Kubernetes is an open-source platform that runs containerized applications across a group of machines, called a cluster, and keeps them in the state you declare. You describe the outcome, for example three replicas of a web service with 512 MiB of memory each, and Kubernetes places the containers on machines, restarts them when they fail and replaces them when a machine dies. The name comes from the Greek word for helmsman or pilot, and “K8s” stands for the eight letters between the K and the s.
How Kubernetes works
Kubernetes is declarative. You submit objects such as a Deployment or a Service to the Kubernetes API, and the cluster stores them as desired state. A set of controllers then compares that desired state with what is actually running and acts on the difference: it starts missing containers, stops surplus ones and moves work away from failed machines. The Kubernetes documentation describes this as “a set of independent, composable control processes that continuously drive the current state towards the provided desired state”.
A cluster has two parts. The Kubernetes control plane stores the state and makes the decisions. The worker nodes, which are virtual machines or physical servers, run the containers. Containers run inside Pods, the smallest unit Kubernetes schedules.
What Kubernetes does
The upstream overview lists the capabilities below. All of them ship with Kubernetes itself.
| Capability | What it means in practice |
|---|---|
| Service discovery and load balancing | Each Service gets a stable DNS name and IP address, and traffic is spread across the healthy Pods behind it. |
| Automated rollouts and rollbacks | A new image version replaces the old one at a controlled rate, and you can roll back if it misbehaves. |
| Self-healing | Failed containers restart, containers that fail their health checks are killed, and Pods only receive traffic once they report ready. |
| Bin packing | You state how much CPU and memory each container needs, and the scheduler fits containers onto nodes to use capacity well. |
| Horizontal scaling | Replica counts change by command or automatically, based on CPU usage or other metrics. |
| Storage orchestration | Volumes from local disks or cloud storage are attached to the Pods that claim them. |
| Secret and configuration management | Passwords, tokens and settings are stored separately from images and updated without rebuilding them. |
| Batch execution | Jobs run to completion and are retried on failure, next to long-running services. |
What Kubernetes does not do
The project states plainly that Kubernetes “is not a traditional, all-inclusive PaaS”. According to the Kubernetes documentation, it does not build your application or deploy source code, it does not provide databases, message queues or caches as built-in services, and it does not dictate a logging, monitoring or alerting solution.
In practice, a production cluster needs more than Kubernetes: a container registry, a CI/CD pipeline, an ingress or gateway controller, observability tooling, backups and a way to upgrade the cluster itself. Distributions and managed services exist to fill parts of that gap.
Where Kubernetes came from
Google open-sourced Kubernetes in 2014. It built on more than 15 years of Google’s experience running production workloads, in particular its internal cluster manager Borg. The Cloud Native Computing Foundation (CNCF) accepted Kubernetes on March 10, 2016, and the project reached graduated status on March 6, 2018. Today it is developed in the open by contributors from many companies, and new minor versions ship about three times a year.
Where Kubernetes runs
Kubernetes runs on any public cloud, in private data centers, on bare-metal servers and on small machines at edge sites. The same API and the same manifests work in all of these places, which is the main reason teams pick it: an application packaged for one Kubernetes cluster can be deployed to another with few or no changes. Cloud-specific parts, such as load balancers and storage classes, plug in through standard interfaces.
Ways to run Kubernetes
There are three common ways to get a Kubernetes cluster. They differ mostly in who operates the control plane and who upgrades the cluster.
| Approach | Examples | Who runs the control plane | Typical fit |
|---|---|---|---|
| Upstream, self-assembled | kubeadm on your own machines |
Your team | Learning, full control, specialized environments |
| Distribution | k3s, RKE2, OpenShift | Your team, with vendor tooling and support | On-premises and edge, regulated environments |
| Managed service | Amazon EKS, Google GKE, Azure AKS and others | The provider | Teams that want to run applications, not clusters |
With managed Kubernetes, the provider takes over etcd, certificates, control plane availability and upgrades, which is ongoing work that does not differentiate your product.
When Kubernetes is the wrong tool
Kubernetes adds concepts, components and operational work. For a single application on one server, a static site or a team with no one to own the platform, a simpler option such as a container on a VM, a platform as a service or a serverless runtime is often the better fit. The trade-off shifts as the number of services, environments and machines grows. See whether Kubernetes is overkill for a small team for the signals on both sides.
Kubernetes on Cloudfleet
Cloudfleet Kubernetes Engine (CFKE) is a managed, CNCF-conformant Kubernetes service. A single CFKE control plane can manage nodes in several cloud providers and in your own data centers at the same time. See What is Cloudfleet? for an overview.