Scheduler
- By default Pods gets scheduled based on node availability for the scheduler
- There may be cases where in one of the node has more resources and the pod required to be scheduled on this node
- There are two ways to achieve this
- Node Selector
- Node Affinity
Node Affinity
- The primary purpose of node affinity is to make sure that pods are hosted correctly on the nodes
- Assume that during pod creation the affinity rules match and the pod is created, what if the node labels are changed after the pod creation
- What happens to pod depends on the nodeAffinity values set. These are
- requiredDuringSchedulingIgnoredDuringExecution
- preferredDuringSchedulingIgnoredDuringExecution
- requiredDuringSchedulingRequiredDuringExecution
- 3rd option still does not exist in Kubernetes, it will be/or is already released in the future releases
- Operators can be In, NotIn, Exists
- For Exists, we don't need to specify any value in the pod-definition. This is because affinity rules only check if the key exists, it does not look for any values
pod-definition.yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: nginx-container
image: nginx
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: size
operator: In
values:
- Large
- Medium
How to force a pod to schedule on a node?
- With taints & toleration, only the pod that can tolerate a taint gets scheduled on that node.
- But the pod can be scheduled on a node that has no taint defined
- With node selectors, only the pod that matches the with the node label gets scheduled on that node.
- But a pod with no selector rules can be scheduled on a node with label
- So a combination of taints and toleration along with node selector has to be used
- With taint & toleration only pods that can tolerate the taint will be scheduled and
- with node selector pod will be scheduled only on the node it is supposed to
Comments
Post a Comment