What is Kubernetes? Your next application platform

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?

Benefits of using Kubernetes

Because Kubernetes introduces new abstractions and concepts, and because the learning curve is high, it’s only normal to ask what the long-term payoffs are for using it. Here are 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 the busy work of keeping an 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 often be packed 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 is 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 external storage volumes. 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 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—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 third-party solutions are available for this, like Docker secrets and HashiCorp Vault, Kubernetes has its own mechanism for natively handling secrets, although it does need to be configured with care.

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 clouds public or private. 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, as of September 2023, the KubeFed project has been archived. The widely expressed feeling was that the project was overly broad and stagnant. Other projects have emerged as possible successors. One is Karmada, which uses Kubernetes-native APIs to synchronize applications across clusters, and requires no changes to applications themselves.

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.
• If you’re using Docker: Docker’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 tutorial

Now that you’ve got the basics under your belt, are you ready to get started with Kubernetes? A variety of tutorials can help you play around with Kubernetes and learn how to use it in your own work. 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 repo, which has something for everyone.

Kubernetes certification

If you feel like you have a good handle on how Kubernetes works and you want to be able to demonstrate your expertise to employers, you might want to 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 $395 each. There are also accompanying training courses, which can serve as a good, structured way to learn more about Kubernetes.