Node Selectors, Labels, Selectors, Static Pods, and Manual Scheduling

Hello everyone, welcome back to the CK 2024 series!! Today we will cover node selectors, labels and selectors, static pods, and manual scheduling. I highly recommend you read through the previous blogs to grasp the concepts thoroughly before proceeding with this one.

Kubernetes Architecture Recap

To begin, let's revisit a familiar diagram from previous videos - the Kubernetes sample architecture, the control plane components, and the worker nodes running various workloads. One key component in the control plane is the scheduler, which decides which pod goes on which node.

When you create a new pod using the kubectl command, the request goes to the API server. The API server creates an entry in the etcd database, and the scheduler then decides which node the new pod should be scheduled on. It sends the request to the kubelet on the chosen node, which then runs the pod.

Static Pods

A critical aspect of Kubernetes is how control plane components are managed. These components, such as the scheduler, API server, and controller manager, are often run as static pods. Static pods are not managed by the scheduler but by the kubelet directly. This ensures that essential control plane components are always running, even if the scheduler itself is down.

Static pods are defined in YAML files located in a specific directory on the control plane node, typically /etc/kubernetes/manifests. The kubelet monitors this directory and ensures that all the pods defined there are running.

Hands-On Demo: Static Pods

Let's look at a hands-on demo to understand static pods better:

1. Accessing the Control Plane Node: If you're using a kind cluster, which runs Kubernetes in Docker containers, you can access the control plane node with the docker exec command.

docker exec -it <control-plane-container-name> bash

1. Verifying Static Pods: Once inside the control plane node, navigate to the /etc/kubernetes/manifests directory.

cd /etc/kubernetes/manifests

1. Managing Static Pods: You can see YAML files for various control plane components. For example, to stop the scheduler, you can move its YAML file out of this directory.

mv kube-scheduler.yaml /tmp/

This action will stop the scheduler pod. You can verify this by checking the pods in the kube-system namespace.

kubectl get pods -n kube-system

1. Restarting Static Pods: To restart the scheduler, move the YAML file back to the manifests directory.

mv /tmp/kube-scheduler.yaml /etc/kubernetes/manifests/

Manual Scheduling

Let's walk through manual scheduling with a demo:

1. Create a Pod YAML: Generate a YAML file for a new pod.

kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml

1. Edit the YAML: Open the YAML file and add the nodeName field under the spec section to specify the node.

spec:
  containers:
  - image: nginx
    name: nginx
  nodeName: worker-node1

1. Apply the YAML: Deploy the pod using the edited YAML file.

kubectl apply -f pod.yaml

1. Verify Pod Scheduling: Check that the pod is running on the specified node.

kubectl get pods -o wide

Labels and Selectors

Labels and selectors are key in Kubernetes for organizing and managing resources. Labels are key-value pairs attached to objects, and selectors allow you to filter resources based on these labels.

1. Add Labels: Add labels to your pod.

metadata:
  labels:
    tier: frontend
    app: nginx

1. Apply Changes: Update the pod with new labels.

kubectl apply -f pod.yaml

1. Use Selectors: Filter pods using labels.

kubectl get pods -l tier=frontend

Conclusion

In our latest discussion, we delved into several essential concepts for managing and optimizing Kubernetes deployments: node selectors, labels and selectors, static pods, and manual scheduling. Understanding these elements is crucial for effectively handling your Kubernetes environment.

Thank you for reading, and stay tuned for our next blog post!

For further reference, check out the detailed YouTube video here: