Today I worked on three important Kubernetes concepts:

Manually scheduling a Pod Static Pods and control-plane components Kubernetes Labels and Label Selectors

This was a hands-on session, so I wanted to document what I learned.

1. Manually Scheduling a Pod

Normally, when we create a Pod, the Kubernetes Scheduler decides which worker node should run it.

For this exercise, I learned how a Pod can be scheduled manually by specifying the nodeName in the Pod specification.

For example:

apiVersion: v1 kind: Pod metadata: name: pod1 labels: env: test spec: containers:

• image: nginx name: pod1 nodeName: cka-3-worker

Here, instead of allowing the Scheduler to select a node, I specified:

nodeName: cka-3-worker

This helped me understand the difference between normal scheduling and manually assigning a Pod to a specific node.

1. Understanding Static Pods

I also explored Static Pods and the control-plane components.

On my control-plane node, I checked the default static Pod manifest directory:

ls -lh /etc/kubernetes/manifests/

I found the manifests for components such as:

etcd.yaml kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yaml

I also experimented with moving the kube-scheduler.yaml file out of the manifests directory and then putting it back:

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

and later:

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

This helped me understand that the kubelet watches the static Pod manifest directory and that changes to these manifests can affect the corresponding control-plane components.

1. Creating Pods with Labels

Next, I created three Nginx Pods with different environment labels.

kubectl run pod1 --image=nginx --labels="env=test"

kubectl run pod2 --image=nginx --labels="env=dev"

kubectl run pod3 --image=nginx --labels="env=prod"

The Pods were:

pod1 → env=test pod2 → env=dev pod3 → env=prod

I verified the labels using:

kubectl get pods -o wide --show-labels

The output showed that all three Pods were running and had the expected labels.

1. Filtering Pods Using Labels

After creating the Pods, I learned how to use label selectors with kubectl.

To find the development Pod:

kubectl get pod -l env=dev

Output:

NAME pod2

To find the production Pod:

kubectl get pod -l env=prod

Output:

NAME pod3

I also tested:

kubectl get pod -l env=test

which returned:

NAME pod1

This showed me how useful labels are when we have many Kubernetes resources and need to find a specific group of them.

What I Learned Today

My main takeaways from Day 14 are:

The Kubernetes Scheduler normally decides which node should run a Pod. A Pod can be manually assigned to a node using nodeName. Static Pod manifests are stored on the node and watched by the kubelet. Kubernetes control-plane components such as the Scheduler can run as static Pods. Labels provide a way to organize and identify Kubernetes resources. Label selectors allow us to filter resources using kubectl.

The biggest takeaway for me today was understanding that Kubernetes labels are much more than simple metadata. They become very useful when we need to select and manage specific resources.

Conclusion

Day 14 gave me a better understanding of what happens behind the scenes when Kubernetes schedules Pods and manages control-plane components.

I'm still learning Kubernetes, but doing these exercises practically is helping me connect the concepts with what actually happens inside a cluster.

On to the next day of the #40DaysOfKubernetes journey! 🚀

Thanks to Piyush Sachdeva and CloudOps Community for creating this learning challenge.

#40daysofkubernetes #Kubernetes #DevOps #CloudComputing #LearningInPublic