多可用区AKS集群：PVC可用区绑定导致节点自动升级停滞

核心原因 #

AKS中使用的多数持久卷（如Azure托管磁盘）会绑定到创建时所在的可用区，只能挂载到同一可用区的节点。当自动升级触发节点排空时，如果Pod被调度到其他可用区，会因为无法访问跨区PV而启动失败，最终导致节点排空超时、升级停滞。

可行解决方案 #

1. 优化调度策略，确保Pod与PV同区部署

通过配置调度规则，强制Pod仅调度到其关联PV所在的可用区，避免跨区调度冲突：

• 使用WaitForFirstConsumer绑定模式：在StorageClass中设置该模式，PVC会等到Pod调度完成后再创建PV，确保PV与Pod处于同一可用区。示例配置：

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: azuredisk-sc
  provisioner: disk.csi.azure.com
  parameters:
    skuname: Standard_LRS
  volumeBindingMode: WaitForFirstConsumer
  allowedTopologies:
    - matchLabelExpressions:
        - key: topology.kubernetes.io/zone
          values:
            - eastus-1
            - eastus-2
            - eastus-3
  

• 配置Pod节点亲和性：在Deployment中添加节点亲和规则，匹配PV的可用区标签，确保Pod仅调度到PV所在的可用区：

  spec:
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
            - matchExpressions:
                - key: topology.kubernetes.io/zone
                  operator: In
                  values:
                    - <PV所在可用区>
  

• 启用拓扑感知调度：AKS默认支持该特性，结合StorageClass的allowedTopologies，可自动匹配Pod与PV的可用区。

2. 拆分单可用区节点池（推荐）

创建3个独立的单可用区节点池（每个可用区一个），通过标签和调度规则让Pod与对应可用区的PV绑定：

• 创建单可用区节点池：

  az aks nodepool add --name nodepool-zone1 --cluster-name myAKSCluster --resource-group myResourceGroup --zones 1
  az aks nodepool add --name nodepool-zone2 --cluster-name myAKSCluster --resource-group myResourceGroup --zones 2
  az aks nodepool add --name nodepool-zone3 --cluster-name myAKSCluster --resource-group myResourceGroup --zones 3
  

• 在Deployment中使用nodeSelector指定对应可用区的节点池：

  spec:
    template:
      spec:
        nodeSelector:
          topology.kubernetes.io/zone: eastus-1
  

该方案优势：

• 每个节点池独立升级，不会因跨区调度问题导致升级停滞；
• 故障隔离性更强，单个可用区节点池故障不影响其他区；
• 调度规则清晰，便于后续维护。

3. 关于“PVC可用区无关”的可行性

目前AKS中主流块存储（如Azure托管磁盘）无法实现完全的可用区无关，这类存储介质本身只能挂载到同一可用区的节点。即使使用区域冗余存储（如ZRS磁盘），PV依然会绑定到特定可用区，无法跨区挂载。若需跨区访问存储，可考虑使用Azure Files（区域冗余版），但需注意其性能和适用场景与块存储的差异，需结合业务需求评估。

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