Kubernetes — 2 | Architecture and kubectl

In this blog, I will provide a detailed insight into the Kubernetes architecture and the kubectl command line tool that is used to interact with the cluster.

Kubernetes Architecture

A Kubernetes cluster consists of two types of nodes. Master nodes (Control plane) and worker nodes. The master nodes/control plane performs the tasks of managing the cluster and the worker nodes run the containerized applications in pods.

Control plane (Master nodes)

Responsible for all the managing processes such as scheduling, monitoring state of pods, restarting pods, etc.

It consists of the following components/processes.

Api Server — The user interacts with the api server using a tool such as kubectl. It is a gateway into the cluster. Initial requests of any updates to the cluster or queries are first sent to the api server. It performs authentication to ensure that only authorized parties have access to the cluster and forwards it to the respective processes.

Client request -> API server -> Validates request -> Required processes -> Pod

Scheduler — Responsible for scheduling pods. It decides which node is the most suitable for a new pod to be started depending on the resources required by the new container and the available resources in the worker nodes. After a node is selected, it will instruct the kubelet in that node to start the pod and the container.

Schedule request -> API server -> Scheduler -> Node selection -> Kubelet starts a pod in selected node

Kube controller manager — Responsible for detecting when running pods die and ensuring that they are rescheduled. Detects cluster state changes and ensures that the cluster recovers and reaches the desired state. When a state change is detected;

Controller manager -> Scheduler -> Kubelet

Cloud Controller manager — The cloud controller manager lets you link your cluster into your cloud provider’s API. It detects cluster state changes by interacting with the cloud provider’s API. If you are running Kubernetes on your own PC, the cluster does not have a cloud controller manager.

etcd — Key value store of a cluster. Every change in the cluster is saved in etcd. Scheduler and controller manager uses the data in etcd to make the decisions. It has data such as cluster health, available resources, changes in cluster state, etc. Note: Application data are not stored in etcd, only data related to the Kubernetes cluster.

A Kubernetes cluster is made up of multiple master nodes to ensure reliability. The api server is load balanced and the etcd store forms a distributed store across all the master nodes.

Worker nodes

The running containers are placed in pods inside worker nodes. Each node can have multiple pods.

Three processors must be installed in each node to schedule and manage the pods.

1. Container runtime (Eg: Docker)
2. Kubelet — The process that schedules and manages the pods. It interacts with both the container and the node. Kubelet is responsible for running a pod from the configuration given and assigning resources such as CPU, RAM from the node to the container inside the pod.
3. Kube proxy — Responsible for forwarding messages from services to the pods. Communication between pods in the same node as well as multiple nodes occur through services. Kube proxy ensures that the forwarding occurs in a low overhead and high performance manner. For example, if a pod attempts to communicate with another pod which has replicas in that node itself as well as other nodes, kube proxy ensures that the message is forwarded to the pod in the node which contains the initial requesting pod.

The hardware resources allocated to master and worker nodes differ. Eventhough master nodes are more important and does important work for the cluster to operate, it does not require high CPU or RAM since the actual applications are not running on them. Worker nodes on the other hand may require high CPU and RAM depending on the application requirements.

Layers of abstraction

The architecture of Kubernetes is such that the user will only be interacting with the deployment layer and not pods directly. Deployment is an abstraction over a pod. The kubectl tool can be used to create deployments directly through the command line or by applying configuration files written in YAML. Everything below that is handled by Kubernetes itself. Kubernetes uses the deployment to create a replica set which will in turn create and manage pods and ensure the system reaches and maintains the final state specified in the deployment.

Kubectl

Kubectl is a command line tool to interact with the Kubernetes cluster. As mentioned above, the kube-api-server is the interface between the user and the Kubernetes cluster. Kubectl connects to the kube-api-sever and allows the user to interact with the Kubernetes cluster. It is what allows the user to create, delete, update components such as deployments, services, configmaps within the cluster.

Functions

• Creating deployments.
• Updating deployments.
• Deleting deployments.
• Getting the status of deployments, nodes, pods, services, etc.
• Debugging pods.

Syntax

kubectl [COMMAND] [TYPE] [NAME] [flags]

COMMAND: Specifies the operation that you want to perform on one or more resources, for example create, get, describe, delete

TYPE: Specifies the resource type. Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. Eg: pods, deployments, services

NAME: Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, for example kubectl get pods displays all the pods.

flags: Specifies optional flags.

Click here for a cheatsheet of Kubernetes commands.