Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
The name Kubernetes originates from Greek, meaning helmsman or pilot. Google open-sourced the Kubernetes project in 2014. Kubernetes combines over 15 years of Google's experience running production workloads at scale with best-of-breed ideas and practices from the community.
In this post, I am going to explain the architecture of Kubernetes
In the first step, we have the
Master Node, and it is responsible for the overall management of the Kubernetes cluster. It got three components that take care of communication, scheduling, and controleer. These are
The API Server,
The API Server:
As the name states, it allows you to interact with Kubernetes API. It is the frontend of Kubernetes Control Plan
The Scheduler watches the created pods that do not have any design yet and design the pods to run on a specific node.
The controller Manager run controller. These are background threads that run threads on the cluster. The controller has a bunch of different roles, but that all compiled into a single binary. The roles include,the node controller, who's responsible for the worker states, the replication controller, which responsible for maintaining the correct number of pods for the replicated controller. The endpoint controller, which joins service and pods together.
Service account and token controller that handles access management
Finally, there is
etcd which is a simple distributed key-value store. Kubernetes uses
etcd as a database and stores all cluster data. Some of the information which might be stored is job scheduling information, pod details, state information, etc.
kubectl is used to interact with
The Master Node. It is a command-line interface for the Kubernetes.
kubectl as a config file called as
kubeconfig. this file has server information as well as authentication information to access
The API Server
A node may be a virtual or physical machine, depending on the cluster. Each node contains the services necessary to run Pods, managed by the control plane.
Worker Node is the node where the application operates. The
Worker Node communicates back to the
Master Node. Communication to worker node from
Master Node is handled by the
It is an agent that communicates with the
API Server to see if the pod has been designed for the node. it executes the pod container via the container engine. It mounts and runs pod volume secrets. Finally, it's away of pods and node states and responds back to master. Its save to say that if
Kubelet is not working correctly in the
Worker Node, you are going to have issues.
Kubernetes is container orchestration, so the expectation is that you have a container-native platform running on your worker node. This is where the docker comes in, and works together with
kubelet to run the container on the node.
Kube-Proxy This process is the network proxy and load balancer for the service. on the single worker node, it handles the network routing for TCP and UDP packet, and it perform connection forwarding.
Having the docker daemon allows containers of an application are tightly coupled together in a pod
Pod A pod is the smallest unit that can be scheduled as deployment in a Kubernetes. It contains a group of containers that share storage, Linux name space, IP addresses among other things. there also co-located and share resources that all are scheduled together.
Once the pod has been deployed and running, the
Kubelet process communicates with pods to check on state and healthy, and kube-proxy route and packet to the pods from other resources that might be wanting to communicate with them.
Worker node can be exposed to the internet via the load balancer, and traffic coming to worker node is also handled by
Kube-Proxy which is how and end-user end up taking wih kubernetes applications
Master Node and
Worker Nodes. On the
Master Node, we have HDD cluster which stores information about the cluster, we have
Scheduler to schedule application or containers on
Worker Nodes. we have different controllers that take care of different functions like the node controllers, replication controllers, etc. We have the Kube API server that is responsible for orchestrating all operations within the cluster.
Worker Node, we have
Kubelet that listens to the instructions from the
Kube API Server and manages containers. Next, we have
Kube-Proxy that helps in enabling communication between services within the cluster.