Kubernetes is a popular open source platform for container orchestration—that is, for managing applications built from multiple, largely self-contained runtimes called containers.
Containers have become increasingly popular since Docker launched in 2013, but large applications spread out across many containers are difficult to coordinate.
Kubernetes makes applications dramatically easier to manage at scale. It has become a key player in the container revolution.
What is container orchestration?
Containers are a powerful successor to virtual machines, which are software-based emulations of computers. Both containers and VMs help keep applications discrete, but containers operate at the application level, not the machine level. Containers require far less overhead and grant much greater flexibility than VMs do. They’ve reshaped the way we think about developing, deploying, and maintaining software.
In a containerized architecture, the various services that constitute an application (web interface, database, etc.) are packaged into separate containers and deployed across a cluster of physical or virtual machines. But this gives rise to the need for container orchestration—a tool for automating the deployment, management, scaling, networking, and availability of container-based applications.
What is Kubernetes?
Kubernetes is an open source project that has become one of the most popular container orchestration tools. It allows you to deploy and manage multi-container applications at scale. While in practice Kubernetes is most often used with Docker, the best-known containerization platform, it can also work with any container system that conforms to the Open Container Initiative (OCI) standards for container image formats and runtimes.
Kubernetes has also grown to manage virtual machine workloads side-by-side with containers, by way of projects like KubeVirt. In that sense, it’s also evolving into a general framework for applications, regardless of how they’re hosted. That said, containers are still the first choice for running apps in Kubernetes due to their flexibility and convenience.
Because Kubernetes is open source, with relatively few restrictions, it can be used freely by anyone who wants to run containers, most anywhere they want to run them: on-premises, in the public cloud, or both.
Google and Kubernetes
Kubernetes began life as a project within Google. It is a successor to (though not a direct descendent of) Google Borg, an earlier container management tool that Google used internally. Google open sourced Kubernetes in 2014, in part because the distributed microservices architectures that Kubernetes facilitates makes it easy to run applications in the cloud. Most every cloud vendor, Google included, sees support for containers, microservices, and Kubernetes as big draws for customers. Cloud vendors have gone to great lengths to add this support to their service portfolios.
Kubernetes and many of its related projects are currently maintained by the Cloud Native Computing Foundation, which is itself under the umbrella of the Linux Foundation.
Kubernetes vs. Docker
Kubernetes doesn’t replace Docker but augments it. However, Kubernetes does replace some of the container management technologies that have emerged around Docker.
One such technology is Docker swarm mode, a system for managing a cluster of Docker engines referred to as a “swarm”—essentially a small orchestration system. It’s still possible to use Docker swarm mode instead of Kubernetes, but Docker Inc. has made Kubernetes a key part of Docker support.
On an even smaller scale, Docker also has Docker Compose, a way to bring up a multi-container application on a single host. If you just want to run a multi-container application on one machine, without spreading it across a cluster, Docker Compose covers that scenario.
Kubernetes is significantly more complex than Docker swarm mode or Docker Compose, and it requires more work to deploy. But again, the work is intended to provide a big payoff in the long run—a more manageable, resilient application infrastructure in production. For development work, and smaller container clusters, Docker swarm mode is a simpler choice. And for single-machine deployments of multi-container applications, there’s Docker Compose.
Kubernetes vs. Mesos
Another project you might have heard about as a competitor to Kubernetes is Mesos, an Apache project that originally emerged from developers at Twitter. At one time, Mesos was seen as an answer to the Google Borg project.
Mesos does offer container orchestration services, but its ambitions go far beyond that: It aims to be a sort of cloud operating system that can coordinate both containerized and non-containerized components. Many different platforms can run within Mesos—including Kubernetes itself.
Mesos has also received far less development than Kubernetes recently. Its last significant release was in 2020; its last updates were in 2024. Kubernetes, by contrast, continues to be updated regularly. When combined with projects like KubeVirt, it eclipses much of the functionality Mesos provides.
Kubernetes architecture
The Kubernetes architecture is based on several key concepts and abstractions. Some of these are variations on familiar themes while others are unique to Kubernetes.
Kubernetes clusters
The highest-level Kubernetes abstraction, the cluster, refers to the group of machines running Kubernetes (itself a clustered application) and the containers managed by it. Machines in a cluster are referred to as worker nodes. A Kubernetes cluster must have a master, the system that commands and controls all the other Kubernetes machines in the cluster. This system utilizes an interface called the control plane.
A highly available (HA) Kubernetes setup can replicate the control plane across multiple machines. The configuration data for the cluster can also be replicated across nodes. But at any given time, only one master can run the job scheduler and controller-manager.
Kubernetes nodes and pods
Each cluster contains Kubernetes nodes. Nodes might be physical machines or VMs. Again, the idea is abstraction: Whatever the application is running on, Kubernetes handles deployment on that substrate. Kubernetes even makes it possible to ensure certain containers run only on certain substrates—for example, only virtual machines, or only bare metal.
Nodes run pods, the most basic Kubernetes objects. Each pod represents a single instance of an application or running process in Kubernetes and consists of one or more containers. Kubernetes starts, stops, and replicates all containers in a pod as a group. This way, users don’t need to think at the level of containers for how to abstract their work; instead, they can just think about running application instances.
Pods are created and destroyed on nodes as needed to conform to the desired state, which is specified by the user in the pod definition. Etcd, a distributed key-value store, keeps details about how Kubernetes should be configured, from the state of pods on up. For example, you can state that you want at least two instances of a web front end to satisfy incoming requests, which synchronize with a single instance of a database.
Kubernetes provides an abstraction called a controller that describes how pods are to be spun up, rolled out, and spun down. One simple controller is the Deployment controller, which assumes every pod is stateless (that is, any data is stored outside it) and can be stopped or started as needed. It’s used to scale an application up or down, update an application to a new version, or roll back an application to a known-good version if there’s a problem.
For applications with a persistent state of some kind, you’d use a StatefulSet controller. There are other controllers that handle other scenarios.
Kubernetes services
Pods live and die as needed, so we need a different abstract to deal with the lifecycle of an application as a whole. An app should be persistent even when the pods that comprise it aren’t. To that end, Kubernetes provides an abstraction called a service.
A service in Kubernetes describes how a given group of pods (or other Kubernetes objects) can be accessed via the network. As the Kubernetes documentation puts it, the pods that constitute the back end of an application might change, but the front end shouldn’t have to know about that or track it. Services handle those details.
A few more pieces internal to Kubernetes round out the picture. The scheduler parcels out workloads to nodes so they’re balanced across resources, and so that deployments meet the requirements of the application definitions. The controller manager ensures that the state of the system—applications, workloads, and so on—matches the desired state defined in Etcd’s configuration settings (no more than one database, at least two front-end nodes, etc.).
It is important to keep in mind that none of the low-level mechanisms used by containers, such as Docker itself, are replaced by Kubernetes. Rather, Kubernetes provides a larger set of abstractions for using these mechanisms for the sake of keeping applications running at scale.
Kubernetes policies
Policies in Kubernetes ensure that pods adhere to certain standards of behavior. Policies prevent pods from using excess resources: CPU, memory, process IDs, or disk space. Such “limit ranges” are expressed in relative terms for CPUs (e.g., 50% of a hardware thread) and absolute terms for memory (e.g., 200MB). These limits can be combined with resource quotas to ensure that different teams of Kubernetes users (as opposed to applications generally) have equal access to resources.
Kubernetes Ingress
While Kubernetes services run within a cluster, you’ll want to be able to access these services from the outside world. Several Kubernetes components facilitate this with varying degrees of simplicity and robustness, including NodePort and LoadBalancer. The component with the most flexibility is Ingress, an API that manages external access to a cluster’s services, typically via HTTP.
Ingress requires a bit of configuration to set up properly. Matthew Palmer, who wrote a book on Kubernetes development, steps you through the process on his website.
Kubernetes with Prometheus
A common need with containerized applications, especially at scale, is visibility—knowing what applications are doing and where they may be having problems. Kubernetes components can emit metrics to be used by Prometheus, the open source monitoring tool created to work in conjunction with Kubernetes and other cloud-native technologies.
The Kubernetes Dashboard
One Kubernetes component that helps you stay on top of all of these other components is Dashboard, a web-based UI you can use to deploy and troubleshoot applications and manage cluster resources. Dashboard isn’t installed by default, but adding it isn’t difficult.
Benefits of using Kubernetes
Because Kubernetes introduces new abstractions and concepts, and because the learning curve is high, it’s only normal to ask about the long-term payoffs for using it. Let’s consider some of the benefits of running applications inside Kubernetes.
Kubernetes automates application management
One of the most basic duties Kubernetes takes off your hands is keeping a large, complex application up, running, and responsive to user demands. It automates application health, replication, load balancing, and hardware resource allocation.
Kubernetes applications that become “unhealthy,” or don’t conform to the definition of health you’ve specified for them, can be automatically repaired. Kubernetes also lets you set soft and hard limits on application resource usage, including memory, storage I/O, and network bandwidth. Applications that use minimal resources can be packaged together on the same hardware; ones that need to stretch out can be placed on systems where they have room to grow. And, again, rolling out updates across a cluster, or rolling back if updates break, can be automated.
Kubernetes eases deployment
Package managers such as Debian Linux’s apt and Python’s pip save users the trouble of manually installing and configuring an application. This is especially handy when an application has multiple external dependencies.
Helm is essentially a package manager for Kubernetes. Many popular software applications must run in Kubernetes as a group of interdependent containers. Helm provides a definition mechanism, a “chart,” that describes how an application or service can be run as a group of containers inside Kubernetes.
You can create your own Helm charts from scratch, and you might have to if you’re building a custom application to be deployed internally. But if you’re using a popular application that has a common deployment pattern, there’s a good chance someone has already composed a Helm chart for it and published it in the Artifact Hub.
Another place to look for official Helm charts is the Kubeapps directory, which allows Kubernetes applications to be deployed and installed from within a Kubernetes cluster itself, using a handy web-based interface.
Kubernetes simplifies application resource management
Containers are meant to be immutable; the code and data you put into them isn’t supposed to change. But applications need state, meaning they need a reliable way to deal with data that changes. That’s made all the more complicated by the way containers live, die, and are reborn across the lifetime of an application.
Kubernetes provides abstractions to allow containers and applications to deal with data storage in the same decoupled way as other resources. Many common kinds of storage, from Amazon EBS volumes to plain old NFS shares, can be accessed via Kubernetes storage drivers, called volumes. Normally, volumes are bound to a specific pod, but a volume subtype called a persistent volume (PV) can be used for data that needs to live on independently of any pod.
Containers often need to work with secrets. These are credentials like API keys or service passwords that you don’t want hard-coded into a container or stashed openly on a disk volume. While there are third-party solutions like Docker secrets and HashiCorp Vault, Kubernetes has its own mechanism for natively handling secrets, although it should be configured with care (for instance, by restricting access through RBACs).
Hybrid cloud and multi-cloud deployments
One of the long-standing dreams of cloud computing is to be able to run any application in any cloud, or in any mix of public or private clouds. This isn’t just to avoid vendor lock-in, but also to take advantage of features specific to individual clouds.
For some time, the most common mechanism for keeping multiple clusters in sync with one another across multiple regions and clouds was a Kubernetes SIG project called KubeFed, for Kubernetes Cluster Federation. In a federation, a given application deployment can be kept consistent between multiple clusters, and different clusters can share service discovery so that a back-end resource can be accessed from any cluster. Federations can also be used to create highly available or fault-tolerant Kubernetes deployments, whether or not you’re spanning multiple cloud environments.
However, in September 2023, the KubeFed project was archived. A successor project, Karmada, uses Kubernetes-native APIs to synchronize applications across clusters. It requires no changes to the applications themselves.
Small deployments and edge computing
Kubernetes deployments don’t have to be big to be useful. K3s, for instance, is a tiny Kubernetes deployment—a single 70MB binary—that can run on embedded hardware or low-resource ARM systems (2GB of RAM). Minimal Kubernetes distros have created space for Kubernetes in edge computing—not just in environments with tight hardware constraints, but also minimal or even no external networking.
Where to get Kubernetes
Kubernetes is available in many forms—from open source bits to commercially backed distribution to public cloud service. The best way to figure out where to get Kubernetes is by use case.
- If you want to do it all yourself: The source code, and pre-built binaries for most common platforms, can be downloaded from the GitHub repository for Kubernetes. If you want to try out a tiny instance of Kubernetes on your own system, you can use Minikube to set up a local cluster on a single machine, or use the K3s distribution.
- If you’re using Docker: Docker Desktop’s most recent editions come with Kubernetes as a pack-in. This is ostensibly the easiest way for container mavens to get a leg up with Kubernetes, since it comes by way of a product you’re almost certainly already familiar with. (Docker can also use Minikube for deployments.)
- If you’re deploying on-prem or in a private cloud: Chances are good that any infrastructure you choose for your private cloud has Kubernetes built-in. Standard-issue, certified, supported Kubernetes distributions are available from dozens of vendors.
- If you’re deploying in a public cloud: The three major public cloud vendors all offer Kubernetes as a service. Google Cloud Platform offers Google Kubernetes Engine. Microsoft Azure offers the Azure Kubernetes Service. And Amazon has added Kubernetes to its existing Elastic Container Service. Managed Kubernetes services are also available from many vendors.
Kubernetes tutorials and certifications
Now that you’ve got the basics under your belt, are you ready to get started with Kubernetes? You might want to start off with the simple tutorials on the Kubernetes project site itself; when you’re ready for something more advanced, check out the list of guides in the awesome-kubernetes repository, which has something for everyone. For migration advice, see “How to succeed with Kubernetes.”
If you feel you have a good handle on how Kubernetes works and you want to demonstrate your expertise to employers, certification may be the way to go. Check out the pair of Kubernetes-related certifications offered jointly by the Linux Foundation and the Cloud Native Computing Foundation:
- Certified Kubernetes Administrator: Seeks to “provide assurance that CKAs have the skills, knowledge, and competency to perform the responsibilities of Kubernetes administrators,” including application lifecycle management, installation, configuration, validation, cluster maintenance, and troubleshooting.
- Certified Kubernetes Application Developer: Certifies that “users can design, build, configure, and expose cloud native applications for Kubernetes.”
The certification exams are $445 each. There are also accompanying training courses, which can serve as a structured way to learn more about Kubernetes.