Kubernetes In Action
This section will break down how different components within a Kubernetes cluster communicate, focusing on the control plane and how it interacts with worker nodes to execute tasks.
1 – The YAML Configuration File
Purpose: Defines the desired state of Kubernetes resources, such as Deployments, Services, ConfigMaps, and Secrets.
A YAML configuration file includes metadata, specifications, and desired states for objects like:
Pods – Deployments – Services – ConfigMaps – PersistentVolumes, etc.
2 – Applying the Configuration
Purpose: Send the YAML definition to the Kubernetes API Server. The kubectl CLI communicates with the Kubernetes API Server using RESTful API calls.
The API Server:
Validates the YAML syntax.
Checks for RBAC (Role-Based Access Control) permissions.
Stores the object definition in etcd, the cluster’s key-value store.
API Server Handling the Request
Purpose: The Kubernetes API Server acts as the main entry point, validating and storing state changes.
Components involved:
Kube-apiserver: Handles all client requests.
ETCD: Persists the desired state.
Communication Flow:
kubectl apply sends the YAML to the Kube-Apiserver –> The Kube-Apiserver validates and authenticates the request –> The Kube-Apiserver updates the desired state in ETCD.
3 – Controller Manager Watches for Changes
Purpose: Reconciles the actual state with the desired state.
The Controller Manager continuously monitors ETCD for new or modified objects.
The Deployment Controller detects the new Deployment object and creates a ReplicaSet.
4 – Scheduler Assigns Pods to Nodes
Purpose: Distribute workloads across cluster nodes.
The Kube Scheduler checks for unscheduled Pods and assigns them to suitable nodes based on:
Available CPU and memory.
Taints, tolerations, and affinity rules.
Resource requests and limits.
5 – Kubelet on Each Node Ensures Pod Execution
Purpose: The Kubelet on each node pulls configurations and ensures Pods are running.
The Kubelet continuously Watches the API Server for assigned Pods.
Pulls the Pod definition and starts containers using Container Runtime (e.g., Docker, containerd, etc).
Monitors container health using liveness and readiness probes.
6 – Networking Setup & Service Discovery
Purpose: Expose the application to internal and external traffic.
The Kube-Proxy on each node ensures networking rules are updated.
If a Service is defined, Kubernetes updates: ClusterIP or LoadBalancer to route traffic.
Also Kubernetes updates the Endpoints Controller to link the Service to healthy Pods.
Ongoing Monitoring and Auto-reconciliation After Deployment
Purpose: Ensure the cluster remains in the desired state.
Controllers (ReplicaSet, Node, Service, etc.) continuously check for drift from the desired state.
If a Pod fails, The Controller Manager detects it and recreates the Pod. If a Node fails, the Scheduler assigns a replacement node.
This lifecycle ensures desired state enforcement, monitoring, and auto-reconciliation to keep workloads running efficiently in Kubernetes.
Depiction:
