Although folks like to talk about Kubernetes as if it’s a singular thing, Kubernetes is actually composed of a multitude of different components. One of the first steps toward mastering Kubernetes is understanding the various parts that – when integrated together – create a Kubernetes environment.

Toward that end, let’s take a look at the various components of Kubernetes, how they fit together, how they compare to each other and some common misconceptions.

What Are the Components of Kubernetes?

The components of Kubernetes fall into three main categories: control plane components, nodes, and optional extensions or addons. We’ll discuss each specific component later in this article, but first, let’s take a look at the high-level component categories.

Kubernetes Control Plane

The Kubernetes control plane is the set of tools that manages clusters and the workloads running on them. It includes (among other things) an API server, a workload scheduler, a key-value store, and an object controller.

Kubernetes Nodes

Kubernetes nodes are the physical or virtual machines that host workloads. There are two types of nodes:

• Master nodes, which host the control plane software.
• Worker hodes, which host individual workloads.

Kubernetes nodes are managed by an agent called Kubelet. Each node also runs a network proxy called Kube-Proxy. The nodes need an operating system and a container runtime, too, in order to host containers.

Optional Kubernetes Extensions

Optionally, a Kubernetes cluster could also include a variety of additional components to handle tasks like logging, monitoring, and Web-based administration.

Understanding Kubernetes, Piece-By-Piece

Now that we know which components Kubernetes includes at a high level, let’s take a detailed look at each of them.

The API Server

Kubernetes’s API server, called (naturally enough) kube-apiserver, is responsible for hosting the APIs that manage the rest of the cluster and allow admins to interact with the cluster. In a sense, kube-api-server is the foundation for everything else that runs in Kubernetes.

The API server is hosted on the master node or (if you have more than one master node) nodes inside your cluster.

The Kubernetes Scheduler

The main reason to use Kubernetes is that it automatically decides how to distribute workloads across a cluster of servers. The scheduler, kube-scheduler, is the piece of software that makes those decisions.

Kube-scheduler constantly monitors the state of pods that run within Kubernetes and decides which nodes should host them (unless admins have specified a node using a DaemonSet or similar configuration). The scheduler’s goal is to balance loads evenly across the cluster, avoid interference between workloads, and ensure that only healthy nodes host workloads.

The Kubernetes Controller

The Kubernetes controller, called kube-controller-manager, is actually a set of controllers. They handle tasks like monitoring nodes and managing endpoints for services and pods.

Etcd

Kubernetes provides a built-in key-value store, called Etcd, which stores the data required to manage clusters.

Importantly, Etcd does not store data associated with applications running in Kubernetes. Any data that applications create, log, or otherwise produce needs to be stored separately. Typically, you’d use some kind of storage volume for this purpose. Storage volumes are distinct from Etcd, which is responsible only for hosting the data required to track cluster state, manage access requests, and so on.

Kubernetes Pods

Kubernetes pods are the objects that host workloads. Pods are defined via YAML files, which identify the container or containers that each pod should run, as well as optional configuration data like networking ports to expose or commands to execute.

Pods are the main building blocks for workloads in Kubernetes. Any applications you want to run in Kubernetes are hosted in pods. So are utilities that you may need to help manage your applications, such as logging agents.

Kubernetes Nodes

Nodes are the main infrastructure building blocks in Kubernetes. They are physical or virtual machines that are responsible for hosting both the Kubernetes control plane software and pods.

As noted above, there are two types of nodes: master and worker nodes. Master nodes have to run a Linux-based operating system. Worker nodes can run Linux or Windows.

Although Kubernetes is responsible for keeping track of which nodes are available in a cluster, it’s important to understand that Kubernetes doesn’t manage the nodes themselves. Managing and securing the node operating system, file system, and (if your nodes are VMs) the hypervisor are tasks left up to users.

To use the famous “pets vs. cattle” analogy, Kubernetes just sees nodes as “cattle” that can be joined to a cluster and used to host resources, not “pets” that it needs to treat specially and manage. Kubernetes doesn’t really care what is happening inside a node as long as the node is ready and able to host workloads.

As we also noted above, each node is managed via an agent called Kubelet. A Kubelet instance runs on each node and lets Kubernetes track the status of that node. In addition, each node hosts a network proxy called Kube-proxy, which manages network configurations for pods hosted on nodes.

The Kubernetes DNS Server

For most Kubernetes environments, you’ll need a DNS server that is aware of the internal state of your cluster and can resolve DNS names accordingly. To make this easy, Kubernetes provides its own DNS server, called Cluster DNS.

Some Kubernetes distributions – especially those designed to run in the cloud – provide alternative DNS servers, which can help to reconcile network configurations in cloud-based environments with internal networking for Kubernetes.

The Kubernetes Dashboard

Kubernetes offers a built-in, web-based dashboard. Although not all administrative tasks can be managed using the dashboard (you’ll need to use the Kubernetes CLI tool, kubectl, for some tasks), the dashboard is useful for basic monitoring and management of your cluster.

Some Kubernetes distributions, like OpenShift, offer alternative or customized dashboards.

Kubernetes Component FAQs

If you’ve read (or even just skimmed!) this far, it should be clear that Kubernetes is a complicated, multi-part platform. It’s easy to become confused about how the components fit together or what the differences between them are.

To help clarify things, here are some frequently asked questions about Kubernetes components.

What Is the Difference Between a Kubernetes Cluster, Pod, and Node?

A cluster is a set of nodes that are managed by Kubernetes. Nodes are individual servers within that cluster. Pods are workloads that run on nodes.

You can have a cluster and nodes without pods. But you can’t run pods without nodes, and you can’t create a cluster without nodes. (It’s possible to have a single-node cluster, which is the case by default with lightweight Kubernetes distributions, like Minikube.)

What Does a Kubernetes Master Node Do?

A Kubernetes master node hosts the software that runs the Kubernetes control plane. In single-node clusters, master nodes can also serve as workers by hosting pods; however, to take full advantage of Kubernetes’s automated scheduling and resilience features, you’ll need distinct master and worker nodes.

Which Processes Run on a Kubernetes Node?

The processes running on a node depend on whether it is a master or worker node, as well as how the underlying node operating system is configured.

As we’ve noted, master nodes host control plane software, while worker nodes host pods – and the containers included in those pods.

Can Kubernetes Have Multiple Clusters?

Yes. It’s possible to manage multiple clusters with a single control plane. By default, though, Kubernetes creates just one cluster. And although new tooling is making it easier to manage multiple clusters in Kubernetes, this is still a complex setup that you shouldn’t attempt until you are well versed in the basics.

What Is a Kubernetes Object?

A Kubernetes object is a description of the desired state of a workload. Developers or admins define objects, and Kubernetes then attempts to create a workload that aligns with the desired state of the object.

Thus, objects aren’t a component of Kubernetes as much as they are a type of configuration.