Node Affinity

Question 1

What is the primary purpose of the node affinity feature in Kubernetes?

Answer 1

Node affinity is used to ensure that pods are hosted only on particular nodes that match specific label based rules.

Question 2

Why was node affinity introduced when node selectors already existed in Kubernetes?

Answer 2

Node selectors are very simple and cannot express advanced logical expressions such as OR or NOT while node affinity was introduced to provide richer and more flexible placement rules.

Question 3

Where in a pod specification is node affinity configured?

Answer 3

Node affinity is configured under the spec field using affinity and then nodeAffinity beneath that.

Question 4

What is the nodeSelectorTerms field under nodeAffinity used for?

Answer 4

The nodeSelectorTerms field is an array that holds one or more conditions which describe what labels nodes must have for the pod to be scheduled there.

Question 5

How are conditions inside nodeSelectorTerms structured?

Answer 5

Each condition uses a key an operator and an optional list of values so the scheduler can compare node labels against those rules.

Question 6

What does the operator In mean in the context of node affinity?

Answer 6

The operator In means that the pod can be scheduled on any node whose label for the given key matches one of the values in the provided list.

Question 7

In the lecture example how would you allow the data processing pod to run on nodes labeled size large or size medium using node affinity?

Answer 7

You would specify key size with operator In and a values list containing large and medium so the pod can land on either a large node or a medium node.

Question 8

What does the operator NotIn mean in a node affinity rule?

Answer 8

The operator NotIn means that the pod should avoid nodes whose label for the given key matches any of the values in the list so nodes with those values will not satisfy the rule.

Question 9

How did the lecture suggest excluding all small nodes using node affinity?

Answer 9

You could use key size with operator NotIn and a values list containing small so nodes labeled size small would be excluded from matching the rule.

Question 10

Why did the lecture say the Exists operator could be used instead of NotIn in the specific example cluster?

Answer 10

In the example labels were only applied to large and medium nodes while small nodes had no size label so using the Exists operator for key size matched only large and medium nodes and naturally skipped the unlabeled small nodes.

Question 11

What does the Exists operator check in a node affinity rule?

Answer 11

The Exists operator checks only that a label with the given key is present on the node and it does not care about any specific value.

Question 12

Besides In NotIn and Exists what did the lecture recommend regarding other operators?

Answer 12

The lecture mentioned that there are additional operators for node affinity and advised checking the official documentation for full details.

Question 13

What are the two node affinity types that are currently available according to the lecture?

Answer 13

The two available types are requiredDuringSchedulingIgnoredDuringExecution and preferredDuringSchedulingIgnoredDuringExecution.

Question 14

What are the two pod lifecycle phases that matter for understanding node affinity behavior?

Answer 14

The two phases are during scheduling which is when the pod is first created and placed on a node and during execution which is after the pod is already running.

Question 15

What does during scheduling mean in the context of node affinity?

Answer 15

During scheduling means the phase where the pod does not yet exist on any node and the scheduler is deciding where to place it for the first time.

Question 16

With type requiredDuringSchedulingIgnoredDuringExecution what happens if there is no node whose labels match the node affinity rule when the pod is created?

Answer 16

The scheduler will refuse to place the pod on any node so the pod will not be scheduled and will remain pending until a matching node appears.

Question 17

With type preferredDuringSchedulingIgnoredDuringExecution what happens if no node matches the node affinity expression at scheduling time?

Answer 17

The scheduler treats the rule as a soft preference and if it cannot find a matching node it will ignore the preference and place the pod on any available node that has sufficient resources.

Question 18

What does during execution mean in the context of node affinity?

Answer 18

During execution means the phase where the pod is already running and changes occur in the cluster such as labels being added removed or modified on nodes.

Question 19

According to the lecture how do the currently available node affinity types behave during execution if a node label changes and no longer matches the original rule?

Answer 19

Both available types have the execution part set to Ignored so label changes do not cause running pods to be moved or killed and the pods simply continue running on their current nodes.

Question 20

What future node affinity type did the lecture mention as planned but not yet available?

Answer 20

The lecture mentioned a planned type called requiredDuringSchedulingRequiredDuringExecution which would also enforce affinity rules while the pod is running.

Question 21

When should you choose requiredDuringSchedulingIgnoredDuringExecution rather than preferredDuringSchedulingIgnoredDuringExecution for a pod?

Answer 21

You should choose the required type when correct placement on certain nodes is crucial and the pod must not run at all unless a node that matches the affinity rules is available.

Question 22

When might you choose preferredDuringSchedulingIgnoredDuringExecution for a pod?

Answer 22

You might choose the preferred type when it is nice to place the pod on matching nodes but running the workload on some other node is better than leaving the pod unscheduled.

Question 23

CLI command to add a label to node01 colour = blue

Answer 23

kubectl label node node01 color=blue

Question 24

Yaml structure to add an affinity to match the label color=blue

Answer 24

affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: color
operator: In
values:
- blue