Understanding the Kubernetes architecture

Kubernetes is a marvel of software engineering. The architecture and design of Kubernetes are a big part in its success. Each cluster has a control plane and data plane. The control plane consists of several components, such as an API server, a metadata store for keeping the state of a cluster, and multiple controllers that are responsible for managing the nodes in the data plane and providing access to users. The control plane in production will be distributed across multiple machines for high availability and robustness. The data plane consists of multiple nodes, or workers. The control plane will deploy and run your pods (groups of containers) on these nodes, and then watch for changes and respond.

Here is a diagram that illustrates the overall architecture:

Let's review in detail the control plane and the data plane, as well as kubectl, which is the command-line tool you use to interact with the Kubernetes cluster.

The control plane

The control plane consists of several components:

• API server
• The etcd metadata store
• Scheduler
• Controller manager
• Cloud controller manager

Let's examine the role of each component.

The API server

The kube-api-server is a massive REST server that exposes the Kubernetes API to the world. You can have multiple instances of the API server in your control plane for high-availability. The API server keeps the cluster state in etcd.

The etcd store

The complete cluster is stored in etcd (https://coreos.com/etcd/), a consistent and reliable, distributed key-value store. The etcd store is an open source project (developed by CoreOS, originally).

It is common to have three or five instances of etcd for redundancy. If you lose the data in your etcd store, you lose your cluster.

The scheduler

The kube-scheduler is responsible for scheduling pods to worker nodes. It implements a sophisticated scheduling algorithm that takes a lot of information into account, such as resource availability on each node, various constraints specified by the user, types of available nodes, resource limits and quotas, and other factors, such as affinity, anti-affinity, tolerations, and taints.

The controller manager

The kube-controller manager is a single process that contains multiple controllers for simplicity. These controllers watch for events and changes to the cluster and respond accordingly:

• Node controller: Responsible for noticing and responding when nodes go down.
• Replication controller: This makes sure that there is the correct number of pods for each replica set or replication controller object.
• Endpoints controller: This assigns for each service an endpoints object that lists the service's pods.
• Service account and token controllers: These initialize new namespaces with default service accounts and corresponding API access tokens.

The data plane

The data plane is the collection of the nodes in the cluster that run your containerized workloads as pods. The data plane and control plane can share physical or virtual machines. This happens, of course, when you run a single node cluster, such as Minikube. But, typically, in a production-ready deployment, the data plane will have its own nodes. There are several components that Kubernetes installs on each node in order to communicate, watch, and schedule pods: kubelet, kube-proxy, and the container runtime (for example, the Docker daemon).

The kubelet

The kubelet is a Kubernetes agent. It's responsible for talking to the API server and for running and managing the pods on the node. Here are some of the responsibilities of the kubelet:

• Downloading pod secrets from the API server
• Mounting volumes
• Running the pod container via the Container Runtime Interface (CRI)
• Reporting the status of the node and each pod
• Probe container liveness

The kube proxy

The kube proxy is responsible for the networking aspects of the node. It operates as a local front for services and can forward TCP and UDP packets. It discovers the IP addresses of services via DNS or environment variables.

The container runtime

Kubernetes eventually runs containers, even if they are organized in pods. Kubernetes supports different container runtimes. Originally, only Docker was supported. Now, Kubernetes runs containers through an interface called CRI, which is based on gRPC.

Each container runtime that implements CRI can be used on a node controlled by the kubelet, as shown in the preceding diagram.

Kubectl

Kubectl is a tool you should get very comfortable with. It is your command-line interface (CLI) to your Kubernetes cluster. We will use kubectl extensively throughout the book to manage and operate Kubernetes. Here is a short list of the capabilities kubectl puts literally at your fingertips:

• Cluster management
• Deployment
• Troubleshooting and debugging
• Resource management (Kubernetes objects)
• Configuration and metadata

Just type kubectl to get a complete list of all the commands and kubectl <command> --help for more detailed info on specific commands.