如何限制AKS集群中每个节点挂载Azure磁盘的Pod数量

Hey there, let's fix that frustrating disk attachment limit issue in your AKS cluster! The error you're seeing happens because Azure VMs have hard limits on how many data disks they can mount, and Kubernetes isn't aware of this constraint by default. Here are two solid approaches to solve this, with the first being the most reliable:

1. Use Custom Extended Resources (Recommended) #

This method treats the disk attachment limit as a "resource" that Kubernetes can track and enforce, just like CPU or memory. Here's how to set it up:

Step 1: Add the custom resource to your nodes #

First, we'll define a custom resource (let's call it azure.com/disk-count) that represents the maximum number of disks each node can handle (8 in your case). Run this command to patch all nodes:

kubectl get nodes -o json | jq '.items[] | .metadata.name' | xargs -I {} kubectl patch node {} -p '{"status":{"capacity":{"azure.com/disk-count": "8"}}}'

Note: This change is temporary—nodes will lose this resource if they restart. To make it permanent, deploy a simple DaemonSet that runs on every node and re-applies this patch on startup.

Step 2: Update your Disk-Using Deployments #

Modify the Pod template in your Deployments that use Azure Disks to request 1 unit of this custom resource. This tells Kubernetes to only schedule the Pod on nodes with available disk slots:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: your-disk-using-app
spec:
  template:
    spec:
      containers:
      - name: your-container
        image: your-image
        resources:
          requests:
            azure.com/disk-count: 1 # Request 1 disk slot
      # ... rest of your Pod spec

Now Kubernetes will automatically avoid scheduling more than 8 of these Pods on any single node, completely eliminating that 409 error.

2. Pod Anti-Affinity (Alternative, Soft Limit) #

If you prefer using pod anti-affinity, you can set up a rule that discourages scheduling too many disk-using Pods on the same node. This is a soft limit (Kubernetes will try to follow it but might ignore it if no other nodes are available), so it's less reliable than the resource method, but here's how to configure it:

First, add a label to all your disk-using Pods (e.g., disk-using: "true"). Then add this affinity rule to your Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: your-disk-using-app
spec:
  template:
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: disk-using
                  operator: In
                  values: ["true"]
              topologyKey: kubernetes.io/hostname
              maxSkew: 8
      # ... rest of your Pod spec

The maxSkew: 8 tells Kubernetes to avoid scheduling the Pod on a node that already has 8 more disk-using Pods than the least-loaded node. Again, this is a soft preference, so use it only if the resource method isn't feasible for your setup.

Quick Notes #

• If you have different VM sizes with different disk limits (e.g., some nodes support 16 disks), adjust the disk-count value per node accordingly.
• For the resource method, make sure all disk-using Pods request the custom resource—otherwise, Kubernetes won't count them against the limit.

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