---

A Kubernetes cluster is composed of master and worker nodes, each with specific components.

Master Node:

• API Server: The front-end of Kubernetes, handling and responding to REST operations in the cluster.

• Scheduler: Assigns workloads to worker nodes based on workload requirements and resource availability.

• Controller Manager: Oversees the various controllers that regulate the state of the cluster and perform routine tasks.

• etcd: A consistent and highly-available key-value store used as Kubernetes’ backing store for all cluster data.

Worker Node:

• Kubelet: An agent that runs on each worker node and communicates with the master node.

• Kube-proxy: A network proxy that maintains network rules on nodes and allows network communication to your Pods from network sessions inside or outside of your cluster.

• Container runtime: The software that is responsible for running containers.

• Pod: The smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your cluster.

• Containers: The smallest units in the Kubernetes ecosystem, housed in pods.

What else does a Kubernetes cluster need?

Persistent storage

Beyond just managing the containers that run an application, Kubernetes can also manage the application data attached to a cluster. Kubernetes allows users to request storage resources without having to know the details of the underlying storage infrastructure. Persistent volumes are specific to a cluster, rather than a pod, and thus can outlive the life of a pod.

Container registry

The container images that Kubernetes relies on are stored in a container registry. This can be a registry you configure, or a third party registry.

Underlying infrastructure

Where you run Kubernetes is up to you. This can be bare metal servers, virtual machines, public cloud providers, private clouds, and hybrid cloud environments. One of Kubernetes’s key advantages is it works on many different kinds of infrastructure.