Static Pods, Manual Scheduling, Labels, and Selectors — Kubernetes

🔹 The 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝘀𝗰𝗵𝗲𝗱𝘂𝗹𝗲𝗿 is in charge of scheduling pods onto nodes.

🔹 The K8s scheduler is not responsible for actually running the pod ➡ that’s the 𝗸𝘂𝗯𝗲𝗹𝗲𝘁’𝘀 job. So it just needs to make sure every pod has a node assigned to it. Kubernetes in general has this idea of a "controller".

🔹 Node selection in kube-scheduler. kube-scheduler selects a node for the pod in a 2-step operation:

✅ Filtering
✅ Scoring

🔹 The filtering step finds the set of Nodes where it's 𝗳𝗲𝗮𝘀𝗶𝗯𝗹𝗲 𝘁𝗼 𝘀𝗰𝗵𝗲𝗱𝘂𝗹𝗲 the Pod.

🔹 In the scoring step, the 𝘀𝗰𝗵𝗲𝗱𝘂𝗹𝗲𝗿 𝗿𝗮𝗻𝗸𝘀 the remaining nodes to choose the most suitable Pod placement.

🔹 The scheduler 𝗮𝘀𝘀𝗶𝗴𝗻𝘀 𝗮 𝘀𝗰𝗼𝗿𝗲 𝘁𝗼 𝗲𝗮𝗰𝗵 𝗡𝗼𝗱𝗲 that survived filtering, basing this score on the active scoring rules.

🔹 Finally, the kube-scheduler assigns the Pod to the Node with the highest ranking. If there is more than 𝗼𝗻𝗲 𝗻𝗼𝗱𝗲 𝘄𝗶𝘁𝗵 𝗲𝗾𝘂𝗮𝗹 𝘀𝗰𝗼𝗿𝗲𝘀, the kube-scheduler selects one of these at random.

🔹 Static Pods in Kubernetes are a way to run pods that are 𝗺𝗮𝗻𝗮𝗴𝗲𝗱 𝗱𝗶𝗿𝗲𝗰𝘁𝗹𝘆 𝗯𝘆 𝘁𝗵𝗲 𝗸𝘂𝗯𝗲𝗹𝗲𝘁 𝗼𝗻 𝗮 𝗻𝗼𝗱𝗲, rather than being managed by the Kubernetes control plane.

🔹 Static Pods are not defined in the Kubernetes API server like regular pods but are instead created by placing pod definition files in a specific directory on a node.

🔹 Each Kubernetes node has a directory, typically located at /etc/kubernetes/manifests (or) a directory specified in the Kubelet's configuration. This directory is where you place the static pod definition files.

🔹 If the application pod crashes, kubelet attempts to restart it. kubelet running on the node monitors this directory for changes.

🔹 All the pods that are created are managed by the API server and the scheduler schedules it based on the compute utilization of worker nodes.

🔹 Manual scheduling refers to the scheduling of the pod through the YAML manifest with the keyword nodeName: node_name, which will schedule the pod in a specific node irrespective of the scheduler's availability.