Introduction
Kubernetes is an open-source and portable container orchestrator and a platform for managing containerized workloads and services. It was open-sourced by Google in 2014 and was donated to CNCF. It is highly performant and optimized to run applications at scale thanks to Google's 15 years of professional experience and best practices from the community. This article explains Kubernetes architecture.
When we deploy Kubernetes, we get a cluster. A cluster is a set of nodes running containerized applications. A cluster can be divided into:
Control Plane
Nodes
There can be multiple control planes and there are multiple nodes. However, if you are working in a local or learning environment, then you only have one node per cluster.
1. Control Plane
It makes global decisions about the cluster. The Control plane is responsible for managing the nodes and the pods inside the cluster. We will have a look into pods later on in this article.
The control plane is made up of multiple components which are as follows.
kube-apiserver
Kube-apiserver is the entry point through which a user interacts with a cluster. It is the only cluster component that provides user-accessible API via Kubernetes cli called kubectl and is the only master component that a user will be able to access. It services REST operations and provides a front-end to the cluster's shared state through which all the other components interact. In short, it is used to create, manage and configure clusters.
kube-scheduler
Kube-scheduler is a control plane component that watches for unscheduled pods and assigns them to a node while balancing resource utilization among them. When our pod is assigned to a new node, our kubelet server running on the node receives a pod definition. With the help of the pod definition, our kubelet creates specific resources and containers. A pod is the smallest deployable unit in Kubernetes where our container is deployed.
kube-controller-manager
Kube-controller-manager is the control plane component that runs controller processes. A controller is a control loop that watches the shared state of the cluster through the apiserver attempting to move the current state to the desired state.
etcd
Etcd is an open-source, consistent and distributed key-value store that provides a reliable way to store data that needs to be accessed by distributed systems or clusters of machines. Etcd is also the primary datastore of Kubernetes.
Read more about etcd on their website: https://etcd.io/
2. Nodes
Kubernetes runs your workload by placing containers into pods to run on nodes. A node may be a physical or virtual machine. Usually, there are multiple nodes in one cluster. However, if on a local system or in a learning environment, you will have just one node per cluster.
kubelet
Kubelet is a node agent which runs on each node of the cluster. It is responsible for making sure that the containers are running in a pod. It receives PodSpecs and makes sure that the containers described in the PodSpecs are running and healthy. PodSpecs is a YAML or JSON file describing a pod. If a container is not responding, the kubelet reports back to the apiserver. The apiserver then signals the scheduler which then handles the issue. The kubelet doesn't handle the containers not created by Kubernetes. Other than PodSpecs, there are three ways that a container manifest can be provided to the server:
File: Path passed as a flag on the command line. This file is rechecked every 20 seconds.
HTTP endpoint: HTTP endpoint passed as a flag in the command line. The endpoint is rechecked every 20 seconds.
HTTP Server: The kubelet listens to HTTP requests and responds to a simple API call to submit a new manifest.
kube-proxy
Kube-proxy is responsible for Kubernetes networking. It maintains network rules on nodes. If the worker node needs to connect to an outside network, it does so with the help of these network rules. It also provides IP addresses to nodes.
Container Runtime
A container runtime is a background process that allows us to interact with the operating system and execute application containers without worrying about "how". It basically, allows us to start and stop containers. Containers are put inside pods and pods are deployed to container runtimes.
Kubernetes supports containerd, CRI-O and other implementations of Kubernetes CRI.
This was a summary of Kubernetes architecture. More blogs are in the queue to be uploaded to the DevOps Explained series. So stay tuned!