Scheduling and Resource Management

• Scheduler: selects a node for a pod to run on based on resource availability
• Resource management: resource requests and limits, resource quotas

Taint and Toleration

Taints and tolerations are used in Kubernetes to ensure that pods are only scheduled onto nodes that can support them. A taint is a label that is applied to a node, indicating that certain pods should not be scheduled there unless they tolerate the taint. A toleration is a label that is applied to a pod, indicating that it can be scheduled onto nodes with certain taints.

Node Effects can be

• NoSchedule => do not try to schedule the pod on other nodes
• PreferNoSchedule => system will try to not placing the pod but that is not 100%
• NoExecute => new pod will not be scheduled on the node and existing pods on the node will be removed if they do not tolerate the taint

kubectl taint node <node-name> <key>=<value>:<taint-effect>

# Example
kubectl taint node node01 app=blue:NoSchedule 

NOTE: taint and toleration is a technique to tell k8s to prevent some pods from being scheduled on the specific node but it does not guarantee that a pod will be always scheduled on specific node toleration is responsible for that

Node Selector

just use the node selector when you are sure you want to always place a pod on specific node

Node Affinity

use node affinity to give more flexibility to pod to be placed on any node with the condition for example if you want to schedule Pod on node A or node B or if specific node is labeled with specific label example :

apiVersion: v1
kind: Pod
...
...
spec:
	containers:
   ...
   ...
   ...
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: color
            operator: In | NotIn
            values:
            - red

node affinity rules

DuringSceduling means the pod is not placed yet.

During execution means the pod is placed but if some changes happened to the node.

• requiredDuringSchedulingIgnoredDuringExecution

  This means the rule is required during scheduling, so the pod will not be placed anywhere, and if any changes happened to the node do not evict(delete) it from the node

• preferredDuringSchedulingIgnoredDuringExecution

  This means the rule is NOT required so if it doesn’t match then place it anywhere and the pod will not be evicted(deleted) if the label mismatched with the rule.

Static Pods

Static Pods are pods that are created and managed directly by the kubelet daemon on a specific node, without the need for a Kubernetes API server. The kubelet watches a directory on the node's filesystem, and any changes to that directory are reflected in the pods that are running on the node. Static Pods can be useful for running system-level components, such as the kubelet itself or a network plugin, that need to be started before the Kubernetes control plane is up and running. Static Pods are defined as YAML or JSON files on the node's filesystem, and can be managed using the standard kubectl command-line tool, just like regular pods.

to configure static pods

• make sure you are on hte correct node
• run systemctl status kubelet on the node and check —-pod-manifest-path=/……