Kubernetes (K8s) is an orchestrator of containers. It supports various container technologies, but here we'll concentrate on Docker.

So let's have a look at the Kubernetes architecture:

As in nearly every cluster infrastructure, there exists a master node managing the whole of the cluster. So let's have a brief look at the responsibilities of each of its components:

• API server: The API server provides a means of communication between the Kubernetes cluster and external system administrators. It provides a REST API used by the kubectl command line tool. This API can also be used by other consumers, making it possible to plug-in Kubernetes in existing infrastructures and automated processes.
• Controller manager: The controller manager is responsible for managing the core controller processes within a Kubernetes cluster.
• Scheduler: The scheduler is responsible for matching the supply of resources provided by the aggregated set of Kubernetes nodes to the demand of resources of the currently undeployed pods (pods are the basic scheduling units of Kubernetes; more on this later).
  In addition, the scheduler also needs to keep track of the user-defined policies and constraints, such as node affinity or data locality, in order to take the correct decisions as to where to place the container.

• Etcd: Etcd is a reliable key-value store, storing the overall state of the cluster and all deployed applications at any given point in time.

But without any workers, a cluster manager is useless, so let's have a look at the components running on the Kubernetes nodes:

• POD: PODs are the basic scheduling units of Kubernetes. A POD consists of at least one or more containers, which are co-located on the same node, so that they can share resources. Such resources include IP addresses (in fact, one physical IP is assigned to each POD so no port conflicts arise between them) and local disk resources which are assigned to all containers of the POD.
• Kublet: The kublet is the Kubernetes manager for each Kubernetes node. It is responsible for starting and stopping containers as directed by the controller. It is also responsible for maintaining a PODs state (for example, the number of active containers) and monitoring. Through regular heartbeats, the master is informed about the states of all PODs managed by the kublet.
• Kube-proxy: The kube-proxy serves as a load balancer among the incoming requests and PODs.

There exists an abundance of additional components supporting very complex deployment scenarios, but for the sake of simplicity, we'll skip those here.