Well, we can choose the following methods to choose where Kubernetes schedules specific Pods:

1. nodeSelector field matching against node labels

Mine k8's environment shared systems where the different teams can operate, and run 10 Nodes behind the scenes. Each team is independent and they just fire some deployment on their namespace and let Kubernetes decide which node pods should run,

TeamA-NamespaceA-Scheduled on Node-1,3,7,4,8
TeamB-NamespaceB-Scheduled on Node-5,1,9,10,6,4,3
TeamC-NamespaceC-Scheduled on Node-1,2,3,4,5,6,7,8

We want to reserve some nodes specific to our team basically any deployment that happened on that namespace should be running on specific nodes, yes I can choose the nodeSelector for the pod deployment spec, for example

TeamD-NamespaceD-Scheduled on Node-5,6

The restriction I need to apply to the other namespace shouldn't be scheduling the pods to the specifically reserved node which is dedicated to the namespace (NamespaceD)

CodePudding user response：

You can use taints and tolerations for this purpose.

Basically, you can taint your nodes with dedicated team name. And if a pod does not have a toleration for that taint it will not be scheduled on that node.

Say, team-d has to use nodes node-5 and node-6. Then you can taint nodes node-5 and node-6 as:

kubectl taint nodes node-5 node-6 team=team-d:NoSchedule

This sets the NoSchedule taint on the node. Meaning, if a pod does not tolerate this, it will "not be scheduled" here.

Then in your pod template inside the deployment you will add something like:

tolerations:
- key: "team"
  operator: "Equal"
  value: "team-d"
  effect: "NoSchedule"

This will make only the pods for this deployment tolerate the taint on node-5 and node-6 and will allow scheduling on those nodes.

This way, you can not only control affinity (where pods should go) but also anti-affinity (where pods shouldn't go). You can read more about taints and tolerations here.