Part 2: What Happens in the Control Plane When You Run kubectl apply -f pod.yaml???????

When you run the command kubectl apply -f pod.yaml, a series of operations take place within the Kubernetes control plane to ensure that the desired state (defined in the pod.yaml file) is reached in the cluster. The control plane, which is composed of multiple components, orchestrates these operations and manages the lifecycle of the resources.

Here is a detailed breakdown of the entire process, focusing on the actions that happen within the control plane:

1. Kubectl Client-Side Processing

Before any action happens in the control plane, the kubectl command processes the provided file (pod.yaml) on the client-side:

• Validation: The client-side checks that the YAML file is well-formed and valid according to Kubernetes resource specifications. It validates the schema to ensure the file is correctly structured.
• API Request Creation: If the file is valid, kubectl generates an HTTP request (a RESTful API call) to send to the Kubernetes API server. This request includes the definition of the Pod as described in the pod.yaml.

Once this request is created, it is sent to the API server, which is the entry point to the Kubernetes control plane.

2. Kubernetes API Server (kube-apiserver)

The API server is the heart of the control plane. It receives and processes all requests to manage and interact with the cluster. Here's what happens when the kubectl apply request arrives:

a) Authentication

The API server first checks who made the request. It performs authentication by verifying the credentials (certificates, tokens, etc.) of the user or service account that initiated the request.

• If authentication fails, the request is denied and an error is returned.
• If authentication succeeds, the process moves to the next step.

b) Authorization

Once authenticated, the API server checks whether the user is authorized to perform the requested action. Kubernetes uses Role-Based Access Control (RBAC) to define who can perform which actions on which resources.

• If the user is not authorized (e.g., lacks permissions to create a Pod), the request is rejected, and an error is returned.
• If authorized, the API server proceeds to admission control.

c) Admission Controllers

Admission controllers are plugins that intercept the request before it is persisted. They apply policies to regulate resource creation, enforce quotas, mutate resources, or add additional defaults. Admission controllers can modify the object or deny the request based on their configuration. Common types include:

• PodSecurityPolicy: Ensures that the Pod complies with security policies.
• ResourceQuota: Ensures that the request does not exceed allocated resources for the namespace.
• Mutating Webhooks: May modify the Pod object before it is stored.
• If any admission controller rejects the request, the process stops, and an error is returned.
• If the request passes all checks, the API server allows the request to proceed.

d) Persisting to etcd

Once all validations, authorizations, and admission controller processes are complete, the desired state (in this case, the Pod definition) is stored in etcd, the cluster's key-value store. etcd acts as the source of truth for the cluster's state, recording the intended state of all resources.

When the Pod specification is written into etcd, it becomes part of the cluster’s desired state.

3. Controller Manager (kube-controller-manager)

After the API server has successfully persisted the Pod definition into etcd, the Controller Manager kicks into action. It constantly watches for changes in the desired state stored in etcd and compares them to the current state of the cluster.

The Controller Manager contains several controllers, and in this case, the Pod Controller and ReplicaSet Controller are particularly relevant:

a) Pod Controller

• The Pod controller notices that there is now a new Pod object in etcd, and it does not yet have a corresponding active Pod in the cluster (the actual Pod does not exist on any node yet).

b) ReplicaSet Controller

• If the Pod is part of a ReplicaSet (which ensures that a specified number of identical Pods are running), the ReplicaSet Controller kicks in. It will create or manage the number of Pod replicas to match the desired state.

c) Node Assignment

• In most cases, the Pod Controller will not directly assign Pods to nodes. Instead, it marks the Pod as pending scheduling, which means that it has no assigned node. The job of deciding which node will run the Pod is delegated to the Scheduler.

4. Kubernetes Scheduler (kube-scheduler)

Once the Pod is marked for scheduling, the Scheduler is responsible for assigning it to a suitable node. The Scheduler's job is to find the best available node to run the Pod based on a number of factors:

a) Node Filtering

The Scheduler starts by filtering out nodes that do not meet the Pod's requirements, including:

• Resource Requests: The Pod's resource requests (CPU, memory) must be met by the node.
• Taints and Tolerations: If a node has certain taints (restrictions), only Pods with matching tolerations can be scheduled on that node.
• Affinity/Anti-Affinity Rules: The Pod may have constraints specifying that it must run near certain other Pods (affinity) or far away from others (anti-affinity).

b) Node Scoring

Once nodes are filtered, the Scheduler scores the remaining nodes based on additional factors such as resource utilization, topology, and policies. The Scheduler selects the node with the highest score and assigns the Pod to it.

c) Updating the Pod Object

After making its decision, the Scheduler updates the Pod object in etcd, specifying which node the Pod is assigned to.

Summary of Control Plane Operations:

1. kubectl sends an API request to the API Server.
2. API Server authenticates, authorizes, and processes the request, running it through admission controllers.
3. The desired state is stored in etcd.
4. The Controller Manager detects the new Pod and marks it for scheduling.
5. The Scheduler assigns the Pod to a node.

Once this is done Data Plane comes in picture which will be explained in next post.