Components of Kubernetes
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.