如何在Kubernetes节点上限制Pod副本的最大数量

Hey there! Let’s work through this problem together. You’ve already got pod anti-affinity working to limit each node to 1 replica of your Deployment, and now you want to loosen that to allow up to 2 per node. It sounds like your topology spread constraints setup wasn’t hitting the mark—let’s fix that first, then cover other options if you need stricter controls.

This is the simplest native way to control pod distribution per node, and it’s likely where your earlier attempt fell short. The key is configuring maxSkew: 1 with the right topology key and label selector to cap pod counts per node at 2 (when you have enough nodes to spread replicas out).

Here’s a working example for your Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-target-deployment
spec:
  replicas: N # Replace with your desired number of replicas
  selector:
    matchLabels:
      app: my-target-app # Match your Deployment's pod labels
  template:
    metadata:
      labels:
        app: my-target-app
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: my-target-app
      containers:
        - name: my-app-container
          image: your-app-image:tag
          # Add your container specs here

What this does: #

• maxSkew: 1: Ensures the difference in pod count between any two nodes is no more than 1. For example:
  • 5 replicas across 3 nodes → 2, 2, 1 (no node has more than 2)
  • 6 replicas across 3 nodes → 2, 2, 2
• topologyKey: kubernetes.io/hostname: Tells Kubernetes to treat each individual node as a topology domain.
• whenUnsatisfiable: DoNotSchedule: Makes this a hard constraint—if Kubernetes can’t place a pod without violating the skew rule, it will hold off scheduling it instead of overloading a node.

Note: If you have fewer nodes than ceil(N/2), this setup will allow nodes to exceed 2 replicas (e.g., 5 replicas on 2 nodes → 3, 2). If you need a strict hard limit of 2 per node no matter what, check out the next method.

Kubernetes doesn’t have a built-in hard constraint for "max X pods of a specific Deployment per node", but you can implement this with minimal custom tooling:

Option A: Node Labeling + Node Affinity #

1. Monitor pod counts: Create a simple controller (you can use a CronJob with kubectl and jq, or a small Go/Python script) that checks how many of your Deployment’s pods are running on each node.
2. Label nodes at capacity: When a node reaches 2 replicas of your Deployment, add a label like my-target-app/max-pods-reached: "true" to it.
3. Add node affinity to your Deployment: Update your pod spec to avoid scheduling on nodes with that label:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: my-target-app/max-pods-reached
                operator: NotIn
                values:
                  - "true"

Option B: Custom Scheduler or Scheduler Plugin #

If you’re open to extending Kubernetes, you can use a scheduler plugin (or build a lightweight custom scheduler) that enforces the 2-pod-per-node limit for your specific Deployment. This is more complex but gives you full control over scheduling logic.

If strict enforcement isn’t critical, you can use preferred pod anti-affinity to prioritize placing pods on nodes with fewer than 2 replicas, while allowing overflows if necessary. Note that the count field used here requires Kubernetes 1.26 or newer:

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector:
              matchLabels:
                app: my-target-app
            topologyKey: kubernetes.io/hostname
            count: 2 # Avoid nodes with 2+ of these pods

The high weight (100) makes this preference a strong signal to the scheduler, but it won’t block scheduling if no other nodes are available.

内容的提问来源于stack exchange，提问作者Oleg Luschan