CODEWITHSUNDEEP
kubernetes
Buggy B
Buggy B

Reputation: 765

Kubernetes Tolerations - why do we need to defined "Effect" on the pod

When defining the Taints & Tolerations, we defined the Taint as below:

kubectl taint nodes node1 key1=value1:NoSchedule

Now any pod that does not have toleration defined as below will not be scheduled on node1. And the one that has toleration defined, gets scheduled on this node. But, why do we need to define NoSchedule on the POD? It is already defined on the node.

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"

What impact does it have if:

  1. The node effect is NoSchedule
kubectl taint nodes node1 key1=value1:NoSchedule
  1. But the POD toleration is NoExecute
tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"

Note: I understand that it is trying to match not just "taint value" but also the "taint effect". But is there any use case for matching "taint effect" as well?

tolerations.effect (string) Effect indicates the taint effect to match. Empty means match all taint effects. When specified, allowed values are NoSchedule, PreferNoSchedule and NoExecute.

Thanks

Upvotes: 7

Views: 1547

Answers (3)

GuestWithAQuest
GuestWithAQuest

Reputation: 1

Note: I understand that it is trying to match not just "taint value" but also the "taint effect". But is there any use case for matching "taint effect" as well?

A use case that I can think of is having a node with taints of both NoSchedule and PreferNoSchedule for the same key

We can then create 3 "types" of pods

  1. Pods that tolerate both
  • they will freely be scheduled on the node
  1. Pods that tolerate no schedule only
  • they don't tolerate preferNoSchedule so that means they CAN be scheduled there but only if necessary
  1. Pods that don't tolerate either
  • They will never be scheduled on those nodes

It's good to have the control available to you, could be for cost optimisation, could be for tracking resources. In general it's better to have the control and not need it than to need it and not have it

Upvotes: 0

ordem
ordem

Reputation: 160

I also had the same question, and I stumble on this post. I some of this idea help me understand it:

  1. taint and toleration should work together from the docs 3rd paragrah

  2. the effect describe pod-node relationship so they must have an agreement on what action to take.

What impact does it have if:

The node effect is NoSchedule kubectl taint nodes node1 key1=value1:NoSchedule

But the POD toleration is NoExecute

Thus in this case the pod and node doesn't have agreement on what to do, so it same effect as not having macthing key=value at all, so pod will not be scheduled at all.

why do we need to define NoSchedule on the POD? It is already defined on the node.

you don't need to specify the effect on the pod, if you desire the pod has the same effect as whatever the node has.

But you might want to govern another pod differently, I think it makes more sense when multiple taint and toleration comes into play. Reading example on the above docs help me.

That's what I understand. Let me know if there's any misunderstanding.

Upvotes: 1

gohm'c
gohm'c

Reputation: 15548

What impact does it have if:

  1. The node effect is NoSchedule

kubectl taint nodes node1 key1=value1:NoSchedule

  1. But the POD toleration is NoExecute

Pod will not be schedule on the node where it failed to tolerate, eg. your sample pod will not be schedule on node that tainted with NoSchdule because it only tolerates NoExecute.

...use case for matching "taint effect"

Not sure what it means here; but it is possible to tolerate a key with any effect by only specified the key and value.

Upvotes: 2

Related Questions