如何在节点磁盘配额耗尽时触发AKS集群自动扩容？

问题背景 #

• AKS节点可挂载的Azure Disks数量由VM规格决定，比如dv4/dsv4系列最多支持4块
• 使用disk.csi.azure.com供应器挂载磁盘的Pod，并发数少于4个时正常运行，第5个会因节点磁盘上限停滞报错
• 需求：调度Pod时考虑磁盘限制，所有节点满额时触发集群自动扩容；AKS未将该限制作为扩展资源暴露，Affinity的二进制规则无法实现「单节点最多运行x个挂载磁盘的Pod」的逻辑
• 补充：这些Pod是GitLab Runner生成的CI任务，每个绑定特定名称的PVC（PVC可互换）

现有尝试的问题 #

尝试用Kyverno给节点添加扩展资源，但仅能更新现有节点的标签和新节点的扩展资源，无法修改现有节点的status.capacity；已调整Kyverno的RBAC权限和资源过滤规则，问题仍未解决。

可行解决方案 #

方案1：修正Kyverno配置实现现有节点扩展资源更新 #

Kyverno的patchStrategicMerge对Node/status的修改存在局限，试试拆分规则，单独对Node/status资源使用JSON Patch：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: azure-disk-resource-limit
spec:
  mutateExistingOnPolicyUpdate: true
  background: true
  rules:
  - name: add-disk-capacity-existing-nodes
    match:
      any:
      - resources:
          kinds:
          - Node/status
          selector:
            matchExpressions:
            - key: kubernetes.azure.com/machine-size
              operator: In
              values: ["Standard_D2s_v4", "Standard_D4s_v4"] # 替换为你的VM规格
    mutate:
      targets:
        - apiVersion: v1
          kind: Node/status
      patchesJson6902: |-
          - path: "/status/capacity/azure.com/max-disks"
            op: add
            value: 4 # 对应VM规格的磁盘上限
  - name: add-disk-capacity-new-nodes
    match:
      any:
      - resources:
          kinds:
          - Node
          selector:
            matchExpressions:
            - key: kubernetes.azure.com/machine-size
              operator: In
              values: ["Standard_D2s_v4", "Standard_D4s_v4"]
    mutate:
      targets:
        - apiVersion: v1
          kind: Node
      patchStrategicMerge:
        status:
          capacity:
            azure.com/max-disks: 4

• 逻辑：通过kubernetes.azure.com/machine-size标签匹配对应VM规格，给现有节点的status子资源添加扩展资源，新节点直接用patchStrategicMerge设置

方案2：使用调度器扩展实现自定义调度逻辑 #

如果Kyverno方案无法生效，可开发简单的调度器扩展服务：

• 编写服务接收调度请求，通过K8s API统计节点上已挂载的Azure Disk数量（查询节点上Pod绑定的PVC对应的PV，判断是否为Azure Disk）
• 当节点已用磁盘数达到上限时，拒绝调度该节点，触发Cluster Autoscaler扩容
• 配置AKS调度器使用该扩展

方案3：调整GitLab Runner与PVC策略 #

换个思路规避磁盘数量限制：

• 用Azure Files这类共享存储替代独立Azure Disk，无需纠结单节点磁盘挂载数
• 给GitLab Runner配置临时卷（emptyDir或ephemeral）结合缓存机制，减少PVC挂载需求；或设置PVC回收策略，任务结束后立即释放PVC，降低并发挂载数

方案4：等待AKS原生支持 #

已有用户反馈请求AKS自动将节点磁盘挂载上限作为扩展资源暴露，可关注官方功能更新。

内容的提问来源于stack exchange，提问作者Mitten.O