Kubernetes is usually deployed across multiple servers sharing workloads, improving reliability and scaling efficiency called cluster.
Kubernetes cluster consist of two different server nodes called:
- Control Plane Node
- Worker Node
Control Plane Node: This manages the entire cluster operations, consider it the "Brain" of the cluster while the Worker Node is responsible for running the applications. They just follow the instructions from the control plane.
Components of the Control Plane Node
- kube-apiserver: This functions as the gatekeeper of the Kubernetes control plane. This is every create, read, update and delete operations on any Kubernetes resource like pods, Deployments, ConfigMaps etc flows through the kube-apiserver. It also ensures that all incoming request undergoes authentication (who is making the request) using mechanism like service accounts, certificates etc and authorization (what actions is the authenticated identity allowed to perform) using access control systems like Role Based Access Control etc. The primary responsibility of the apiserver is to handle RESTful API requests over HTTPS (port 6443).
- kube-scheduler This control plane is responsible for or the decision maker on workload placement. It checks for newly created pods that are yet to be assigned to a node and determines the most suitable nodes for them based on scheduling requirements, constraints and policies. Once a decision has been reached, it updates the Pod specification via the kube-apiserver, recording which node the Pod would run on. After that the kubelet of that specific node takes over.
- kube-controller-manager Think of the kube-controller-manager as a store manager that continuously monitors the goods in the store ensuring that replacement of almost finished goods, taking store counts to ensure that desired state of the store is always maintained. The kube-controller-manager maintains the desired state of the cluster. It continuously monitors the cluster's resources comparing the observed or actual state with the desire configuration and ensuring that actions are taken to maintain the desired state via the collection of controllers it runs. It can be considered the self-healing mechanism of the cluster.
- etcd: This is the central data store of the Kubernetes control plane. It records and maintain desired and observed state of the cluster. It is the single source of truth of the cluster. So, every state changes such as new deployments, deletions or updates on any Kubernetes resource are stored and maintained in the etcd via the kube-apiserver. The kube-apiserver is the only component that directly interacts or communicates with the etcd. Given the sensivity of the etcd operation, it is recommended to deploy it on a control plane node with fast SSD storage and strong backup policies. Regular snapshots of the etcd database should be taken because in the event of a disaster recovery, restoring a corrupted or lost etcd database is the only way to recover the cluster state. ETCD stores data using key-value pairs. The key represents the Kubernetes object or configuration path while the value represents the data in JSON.
Components of the Worker Nodes
- Container runtime: This is the key component in the worker node serving as the engine that runs and manages the container lifecycles within the Pods.
- kubelet: Think of this component as a construction site manager that receives the building architecture from the architect - Control Plane, ensures everything is built and running exactly as planned and detailed in the architecture. So, it ensures that the orders or blueprints like the Pod specifications etc received from the control plane gets done on the assigned node and also ensures that the container is up and healthy.
- kube-proxy: Think of this component as the traffic controller that updates the node's internal routing map to ensure efficient routing of incoming requests to the appropriate pods. It is responsible of the routing and network traffic management between the service and the pods ensuring that incoming requests to the services are properly redirected to the backend pods that implemented that service. Hence, acting as a simple load balancer. It handles TCP, UDP & SCTP traffics, using the operating system's networking layer to enforce packet forwarding rules.
Top comments (0)