CKA Day 13 — Static Pods, Manual Scheduling, Labels, and Selectors in Kubernetes

Day 13 of the 40-day CKA challenge by Tech Tutorials with Piyush. This session covers the low-level scheduling primitives that underpin every Kubernetes cluster: how Pods are assigned to nodes, how labels create the “glue” between resources, and how static Pods boot the control plane itself.

Key Concepts Covered

1. Static Pods

Static Pods are Pods managed directly by the kubelet on a specific node, without any involvement from the API server or the Kubernetes scheduler. The kubelet watches a designated directory on the node (typically /etc/kubernetes/manifests) for Pod manifest files. When it detects a new YAML file, it creates the Pod locally. When the file is removed, it destroys the Pod.

This is the mechanism that brings the Kubernetes control plane to life on a node. In a kubeadm cluster, kube-apiserver, kube-scheduler, and kube-controller-manager all run as Static Pods. If you SSH into a control plane node and list files in /etc/kubernetes/manifests, you will see the raw YAML definitions of the control plane itself.

Exam Trap: Static Pods appear in kubectl get pods output (because the kubelet reports them to the API server for visibility), but they cannot be managed through the API. You cannot kubectl delete a Static Pod — the command will hang or the Pod will instantly recreate because the kubelet still sees the manifest file. To delete a Static Pod, you must remove its manifest from the node filesystem.

2. Manual Scheduling

By default, Kubernetes uses the kube-scheduler to decide which node should run a newly created Pod. The scheduler evaluates resource requests, taints, tolerations, affinity rules, and node conditions. However, you can bypass the scheduler entirely with two manual techniques:

• nodeName field: In the Pod spec, setting nodeName: node-1 tells the kubelet on that node to run the Pod immediately. No scheduler evaluation occurs. This is the simplest form of manual scheduling but offers no validation — if the node is down or out of resources, the Pod will be stuck.
• nodeSelector: A label-based filter. You label a node (kubectl label node node-1 disk=ssd), then in the Pod spec you set nodeSelector: {disk: ssd}. The scheduler is still involved, but it is constrained to only consider nodes matching the selector. This is the recommended approach for simple affinity needs.

Manual scheduling is useful for testing, node-local debugging, and scenarios where you want to pin a specific workload to a specific node (e.g., a GPU workload on a GPU node).

3. Labels and Selectors

Labels are key-value pairs attached to Kubernetes objects (Pods, Nodes, Services, Deployments). They carry no semantic meaning to Kubernetes itself; they are purely metadata that you and the controllers use to organize and select resources.

metadata:
  labels:
    app: frontend
    tier: web
    env: production

Selectors are the query mechanism that filters resources by their labels. They are the binding layer of Kubernetes: every controller uses selectors to know which Pods it owns, and every Service uses selectors to know which Pods it should route traffic to.

Selector Type	Syntax	Example
Equality-based	=, ==, !=	app=nginx selects Pods where app equals nginx
Set-based	in, notin, exists	env in (production, staging)

Critical Distinction: A Service uses selector: {app: nginx} (plain key-value pairs). A ReplicaSet or Deployment uses selector: matchLabels: {app: nginx}. This is a frequent exam and real-world mistake.

4. Annotations vs Labels

Annotations are also key-value metadata, but they are not used for selection. They hold arbitrary non-identifying data:

• Build metadata (build-version: 1.2.3)
• Release notes or contact information
• Third-party tool metadata (e.g., ingress class, last-applied configuration)

On the CKA exam, you will use labels far more often than annotations. The most common label task is filtering resources with kubectl get pods -l app=nginx.

Synthesis

Day 13 bridges the gap between high-level controllers (Deployments, DaemonSets) and the node-level reality of the cluster. Understanding Static Pods is essential for troubleshooting control plane failures — if the API server is down, you may need to inspect its Static Pod manifest on the node. Understanding labels and selectors is essential for every other topic in Kubernetes, because every object relationship (Service → Pod, Deployment → ReplicaSet → Pod, NetworkPolicy → Pod) is built on label matching. Manual scheduling is a less common production pattern, but it is a guaranteed exam topic because it tests your understanding of the scheduler’s role in the architecture.

See Also

Wiki Concepts

• Kubernetes Static Pods — deep dive into node-managed Pods and control plane bootstrapping
• Kubernetes Labels and Selectors — the metadata and query system that binds all objects
• Kubernetes Manual Scheduling — nodeName, nodeSelector, and bypassing the scheduler
• Kubernetes Architecture — how kubelet and the scheduler interact
• Pod Fundamentals — the object that labels and scheduling act upon
• Deployment, ReplicaSet & Replication Controller — controllers that rely on label selectors
• Kubernetes Services — networking abstraction driven by label selectors
• Kubernetes DaemonSet — node-level controller that uses selectors and node constraints
• Kubernetes Namespaces — scoping labels and selectors within a boundary
• CKA Certification — exam overview and domain weightings
• CKA Study Roadmap — Day 13 in the 40-day plan

Related Sources

• CKA Day 12 — DaemonSet, Job & CronJob Explained — the preceding day in the course
• CKA Day 5 — Kubernetes Architecture Explained — control plane component placement

Creator / Entity

• Tech Tutorials with Piyush — part of the 40-day CKA free course

---

Tags: kubernetes cka static-pods manual-scheduling labels selectors devops kubelet scheduler