Kubernetes is a popular open source platform for container orchestration — that is, for the management of applications built out of multiple, largely self-contained runtimes called containers. Containers have become increasingly popular since the Docker containerization project launched in 2013, but large, distributed containerized applications can become increasingly difficult to coordinate. By making containerized applications dramatically easier to manage at scale, Kubernetes has become a key part of the container revolution.

What is container orchestration?

Containers support VM-like separation of concerns but with far less overhead and far greater flexibility. As a result, containers have reshaped the way people think about developing, deploying, and maintaining software. In a containerized architecture, the different 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?

is an open source project that has become one of the most popular container orchestration tools around; it allows you to deploy and manage multi-container applications at scale. While in practice Kubernetes is most often used with , the most popular 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. And because Kubernetes is open source, with relatively few restrictions on how it can be used, 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 that Google used internally. Google , 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 , which is itself under the umbrella of the Linux Foundation.

Kubernetes vs. other projects

Kubernetes is not the only way to manage containers at scale, although it has emerged as the most common and broadly supported choice. A few of the other options deserve discussion.

Kubernetes vs. Docker and Docker swarm mode

Kubernetes doesn’t replace Docker, but augments it. However, Kubernetes does replace some of the higher-level technologies that have emerged around Docker.

, 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 chosen to make Kubernetes a key part of Docker support going forward.

However, note that Kubernetes is significantly more complex than Docker swarm mode, 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. For development work, and smaller container clusters, Docker swarm mode presents a simpler choice. 

.

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, a lot of different platforms can run within Mesos—.

Kubernetes architecture: How Kubernetes works

Kubernetes’s architecture makes use of various concepts and abstractions. Some of these are variations on existing, familiar notions, but others are specific 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. A Kubernetes cluster must have a master, the system that commands and controls all the other Kubernetes machines in the cluster. A replicates the master’s facilities across multiple machines. But only one master at a time runs the job scheduler and controller-manager.

is used to deal with applications that need persistent state. The is used to scale an app up or down, update an app to a new version, or roll back an app to a known-good version if there’s a problem.

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.

, 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 make this possible.

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, etc.—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 apps running at scale.

Kubernetes 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 “” are expressed in relative terms for CPU (e.g., 50% of a hardware thread) and absolute terms for memory (e.g., 200MB). These limits can be combined with  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. Kubernetes has several components that facilitate this with varying degrees of simplicity and robustness, including NodePort and LoadBalancer, but the component with the most flexibility is . Ingress is an API that manages external access to a cluster’s services, typically via HTTP.

Ingress does require a bit of configuration to set up properly. Matthew Palmer, who wrote a book on Kubernetes development, .

Kubernetes Dashboard

One Kubernetes component that helps you keep on top of all of these other components is , a web-based UI with which you can deploy and troubleshoot apps and manage cluster resources. Dashboard isn’t installed by default, but adding it isn’t too much trouble.

Related video: What is Kubernetes?

In this 90-second video, learn about Kubernetes, the open-source system for automating containerized applications, from one of the technology’s inventors, Joe Beda, founder and CTO at Heptio.

Kubernetes advantages

Because Kubernetes introduces new abstractions and concepts, and because the learning curve for Kubernetes is high, it’s only normal to ask what the long-term payoffs are for using Kubernetes. Here’s a rundown of some of the specific ways running apps inside Kubernetes becomes easier.

Kubernetes manages app health, replication, load balancing, and hardware resource allocation for you

One of the most basic duties Kubernetes takes off your hands is the busywork of keeping an application up, running, and responsive to user demands. Apps that become “unhealthy,” or don’t conform to the definition of health you describe for them, can be automatically healed.

Another benefit Kubernetes provides is maximizing the use of hardware resources including memory, storage I/O, and network bandwidth. Applications can have soft and hard limits set on their resource usage. Many apps that use minimal resources can be packed together on the same hardware; apps 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 the deployment of preconfigured applications with Helm charts

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.

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 app 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 . Another place to look for official Helm charts is the .

Kubernetes simplifies management of storage, secrets, and other application-related resources

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 app.

Kubernetes provides abstractions to allow containers and apps 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 . Normally, volumes are bound to a specific pod, but a volume subtype called a “” can be used for data that needs to live on independently of any pod.

Containers often need to work with “”—credentials like that you don’t want hardcoded into a container or stashed openly on a disk volume. While third-party solutions are available for this, like and , Kubernetes has its own mechanism for natively handling secrets, although it does need to be .

Kubernetes applications can run in hybrid cloud and multicloud environments

One of the long-standing dreams of cloud computing is to be able to run any app 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.