Although it’s common to refer to Kubernetes as a singular entity, Kubernetes is much more than just one piece of software. It’s an array of distinct tools and services, which fit together to form the complete Kubernetes architecture.

Understanding Kubernetes, then, starts with understanding the various pieces that go into its architecture. Keep reading for a primer on how Kubernetes works from an architectural perspective.

How to think about Kubernetes architecture

To wrap your mind around the architectural philosophy behind Kubernetes, it’s helpful to compare Kubernetes to other systems when it comes to architecture.

Linux is a good example. A Linux-based operating system requires many resources to make it usable. You need the Linux kernel, of course, but you also need a shell, a series of libraries, a way to install software packages, a file system, a user and access-control framework and so on. It’s only by putting these pieces together that you get a usable Linux system.

Likewise, consider a public cloud. In order to build a viable public cloud environment, you need one or more IaaS services, a management console and/or CLI environment, an IAM framework to manage access control and a metrics and logging service, to name just some of the core components of a cloud-based stack.

The point here is that, although the unique architecture of Kubernetes may seem arcane or overly complex when you first learn about it, Kubernetes isn’t actually all that different from other systems from an architectural perspective. Most complex systems are broken down into discrete parts.

The core components of Kubernetes

That said, the specific architecture used by Kubernetes is unique. Some of the core architectural components of Kubernetes, like the controller manager or the Etcd key-value store, don’t have direct equivalents in other types of architectures.

To understand which components form Kubernetes’s architecture, let’s walk through them piece-by-piece.

#1. The API server

At the very heart of any Kubernetes cluster is the API server. The API server is responsible for accepting, validating and responding to every request made by a user or service within the cluster.

A request could be an action like creating a pod (the type of resource that hosts an application in Kubernetes), viewing information about nodes, setting up a new service or almost any other type of action that a human user or application may want to perform within a cluster.

#2. The Kubernetes scheduler

The Kubernetes scheduler is responsible for deciding which pods to place on which nodes (the Kubernetes term for servers) within a cluster. It makes these decisions by evaluating the state of each node, as well as the workload requirements of pods, then attempting to provide the best configuration for achieving overall workload performance and availability.

#3. The controller manager

As noted above, the controller manager is a somewhat unusual type of component. Its job is to enforce configurations that admins create in order to manage their clusters.

The reason why Kubernetes incorporates the controller manager into its architecture is that a key design goal of Kubernetes is to allow admins to declare the desired configuration of an environment using code, then enforce that configuration automatically. By configuring Kubernetes resources so that they match whichever configurations admins have set, the controller manager makes this declarative management strategy possible.

#4. Etcd

By default, Kubernetes doesn’t include any kind of permanent file system equivalent to what you would expect on a conventional server (although you can set up storage systems and connect them to Kubernetes using storage volumes).

But Kubernetes needs somewhere to store the data required to manage its own operations. Etcd, a lightweight key-value store, fills this role. Etcd is where Kubernetes stores the essential configuration data and metadata that it uses to manage clusters.

#5. Nodes

Again, in Kubernetes, a node is a server within the cluster. Kubernetes nodes come in two forms:

• Master nodes, which host the Kubernetes API server, scheduler, Etcd and other essential management services. You need at least one master node for each cluster, but you can set up more in order to increase the reliability of your cluster by ensuring that the cluster will keep running if one master node fails.
• Worker nodes, which host pods. The more worker nodes you have, the more applications you can host in your cluster.

Technically, you could set up a single-node cluster in which one node serves as both master node and worker node. You might do this if you’re testing out Kubernetes on your laptop, for example. But in a production cluster, you’ll want multiple nodes.

#6. Pods

As noted, pods are the part of the Kubernetes architecture that hosts your actual applications.

A pod can be a single container, or it can be multiple containers that run the same application. You can also technically run virtual machines as pods, rather than using containers, but that use case is uncommon.

#7. Runtime

The runtime is the piece of software that executes your containers. It runs on each worker node.

There are a variety of container runtimes available today, such as CRI-O and containerd. Kubernetes natively supports most of them, meaning you can use the runtime without any special configuration. Runtimes that lack native support in Kubernetes can usually be deployed using a shim, which is a service that serves as a middleman to enable communication between a non-supported runtime and Kubernetes.

External parts of the Kubernetes architecture

The list of Kubernetes components above includes only services or parts that are central to Kubernetes’s core architecture. There are a variety of other tools and services that you’d typically deploy alongside Kubernetes, but which are external to Kubernetes itself.

For example, you may want to use monitoring or observability tools to help manage your clusters. Or, you might use Kubernetes network or storage plugins to integrate Kubernetes with third-party networking and storage services.

So, if you think the core Kubernetes architecture is complex, know that things get even more complicated when you build out a complete, production-ready Kubernetes environment. After all, with great power comes great complexity, and Kubernetes is a powerful tool.