Kubernetes特性：配置Pod初始调度至指定Worker节点的方法

Great question! The default Kubernetes scheduler relies on a set of built-in priorities to pick nodes, but you can absolutely override this behavior to make your pods land directly on Worker2 right from the start. Here are the most practical and effective ways to achieve this:

1. Node Affinity (Flexible Scheduling Controls) #

Node affinity lets you define custom rules that the scheduler uses to match pods to nodes. You can set either required rules (pod must run on a matching node) or preferred rules (scheduler tries to match but will fall back if necessary).

First, add a unique label to Worker2 so the scheduler can easily identify it:

kubectl label nodes worker2 node-tier=high-cpu

Then, include node affinity in your pod or deployment spec. For example, to force the pod to run only on Worker2:

apiVersion: v1
kind: Pod
metadata:
  name: my-targeted-pod
spec:
  containers:
  - name: my-app-container
    image: nginx
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: node-tier
            operator: In
            values:
            - high-cpu

If you want a softer preference (scheduler prioritizes Worker2 but can use Worker1 as a fallback), use preferredDuringSchedulingIgnoredDuringExecution instead:

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      preference:
        matchExpressions:
        - key: node-tier
          operator: In
          values:
          - high-cpu

2. Taints and Tolerations (Block Scheduling on Worker1) #

If you want to prevent most pods from scheduling on Worker1 entirely (only allow specific pods there if needed), you can add a taint to Worker1. Pods without a matching toleration will be automatically excluded from scheduling on this node.

Add a taint to Worker1:

kubectl taint nodes worker1 cpu-tier=low:NoSchedule

Now, the scheduler will skip Worker1 by default and prioritize Worker2 for all pods that don't have a toleration for this taint. If you later need some pods to run on Worker1, you can add a matching toleration to those specific pod specs.

3. Node Selector (Simple Label Matching) #

This is the most straightforward method for basic scheduling control. Start by labeling Worker2:

kubectl label nodes worker2 node-tier=high-cpu

Then add a nodeSelector field to your pod spec to restrict scheduling to nodes with that label:

apiVersion: v1
kind: Pod
metadata:
  name: my-simple-pod
spec:
  containers:
  - name: my-app-container
    image: nginx
  nodeSelector:
    node-tier: high-cpu

This tells the scheduler to only consider nodes tagged with node-tier=high-cpu for this pod.

Which Method Should You Choose? #

• Use node affinity if you need flexible rules (like weighted preferences) or want to combine multiple matching conditions.
• Use taints/tolerations if you want to lock down Worker1 to only specialized workloads and keep it off-limits for most pods.
• Use node selector for simple, no-frills scheduling requirements where you don't need the advanced flexibility of affinity.

All of these approaches will ensure your pods are initially scheduled on Worker2, eliminating the need for post-scheduling migrations from Worker1.

内容的提问来源于stack exchange，提问作者Abhay Nayak