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 containerized applications dramatically easier to manage at scale. It has become a key player in the container revolution.
What is container orchestration?
Similar to virtual machines, containers support the separation of concerns, but they do it with far less overhead and much greater flexibility. As a result, containers have reshaped the way we think about developing, deploying, and maintaining software.
In a containerized architecture, the various services that constitute an application 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 that automates 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. (Podman is another popular container engine that competes with Docker.)
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’s 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. Google sees the adoption of containers, microservices, and Kubernetes as potentially driving customers to its cloud services (although Kubernetes certainly works with Azure and AWS, as well). Kubernetes is 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 higher-level 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 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. Mesos is an Apache project that originally emerged from developers at Twitter; it was actually seen as an answer to the Google Borg project.
Mesos does in fact 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. To that end, many different platforms can run within Mesos—including Kubernetes itself.
Mesos has also received far less development as of late than Kubernetes. Its last significant release was in 2020. Kubernetes, by contrast, continues to be updated regularly.
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 contol plane.
A highly available (HA) Kubernetes setup can replicate the control plane across multiple machines. The configuration data for the cluster (stored in Etcd) 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 that certain containers run only on certain subtrates—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. Pods keep the user’s attention on the application, rather than on the containers themselves. Etcd, a distributed key-value store, keeps details about how Kubernetes should be configured, from the state of pods on up.
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. 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 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 persistent state of some kind, you’d use a StatefulSet controller. There are other controllers that handle other scenarios.
Kubernetes services
Because pods live and die as needed, we need a different abstraction for dealing with the application lifecycle. An application is supposed to be a persistent entity, even when the pods running the containers that comprise the application aren’t themselves persistent. 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 these details.
A few more pieces internal to Kubernetes round out the picture. The scheduler parcels out workloads to nodes so that 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.
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 excessive CPU, memory, process IDs, or disk space, for example. 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
Kubernetes services are thought of as running within a cluster. But 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.
Next up: What are the benefits of using Kubernetes?
