azure - 当达到节点卷限制时如何触发AKS集群自动缩放

Question

在 Azure Kubernetes 服务中，可以附加到节点的 Azure 磁盘数量取决于 VM 大小。例如。 https://learn.microsoft.com/en-us/azure/virtual-machines/dv4-dsv4-series 。请参阅数据磁盘列。

我有使用 disk.csi.azure.com 配置程序附加磁盘的 Pod。 只要这样的并发 Pod 数量少于 4 个就可以了。 第五次失败并出错，因为我们使用的 VM 大小仅支持 4 个磁盘。

如何在考虑磁盘限制的情况下调度 Pod，以便在所有节点上达到磁盘限制时自动缩放器扩展集群？

基于this我希望 AKS 将此限制公开为扩展资源，但节点的容量状态中没有任何提示。 Affinities似乎是在节点上放置 pod 的二进制规则；我看不出有什么办法可以模拟“最多 x 个 pod 可以访问一个节点”。

编辑上下文:Pod 是由 gitlab-runner 生成的 CI 作业。我想使用持久卷作为构建区域，以避免在每个作业中从头开始克隆整个项目。从 Kubenernetes 的角度来看，这看起来像是动态生成的 Pod，每个 Pod 都请求挂载先前定义的一组持久卷声明中的一个。 PVC:s 是可替换的(它们缓存相同的克隆)，但配置强制我们为每个 pod 通过某个特定名称请求一个。

更新:我正在探索基于 Extended Resources 的解决方案。我尝试通过 Kyverno 根据 VM 大小标签设置它们，但似乎 Kyverno 对改变现有资源的支持不适用于状态子资源。或者至少我的配置成功更新了现有节点上的标签以及新节点上的扩展资源，但没有在现有节点上设置扩展资源。这是我的尝试:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: azure-disk-resource-limit
spec:
  mutateExistingOnPolicyUpdate: true
  background: true
  rules:
  - name: add-disk-limit
    match:
      any:
      - resources:
          kinds:
          - Node
          - Node/status
    mutate:
      targets:
        - apiVersion: v1
          kind: Node
        - apiVersion: v1
          kind: Node/status
      patchStrategicMerge:
        metadata:
          labels:
            kyverno-dummy: "babar1"
        status:
          capacity:
            kyverno-dummy: 9
#      patchesJson6902: |-
#          - path: "/status/capacity/kyverno-dummy"
#            op: add
#            value: 8

注意:我必须编辑 Kyverno 设置才能启用对节点的更改:1) 我更改了资源过滤器并删除了隐藏节点的过滤器。 2)我给了后台和准入 Controller 编辑节点的权限:

# In values.yml for the kyverno chart:
admissionController:
  rbac:
    clusterRole:
      extraResources:
        - apiGroups:
            - ''
          resources:
            - nodes
            - nodes/status
            - namespaces
          verbs:
            - update
            - patch
backgroundController:
  nodeSelector:
    kubernetes.io/os: linux
  rbac:
    clusterRole:
      extraResources:
        - apiGroups:
            - ''
          resources:
            - nodes
            - nodes/status
            - namespaces
          verbs:
            - update
            - patch

我正在考虑创建一个自定义 Controller 来设置扩展资源，但这感觉不太明智。

PS。我发现请求 AKS 的 UserVoice 会自动添加限制:https://feedback.azure.com/d365community/idea/02e94731-f824-ec11-b6e6-000d3a4f0da0 .

Answer 1

您可以考虑使用 S3 存储桶而不是附加磁盘，它们可能更适合需要使用特定于 Pod 的命名约定进行存储的大量(未知)Pod。

另一种可能性是尝试topologyKey“节点”的拓扑扩展约束，例如

kind: Pod
apiVersion: v1
metadata:
  name: mypod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 4
    topologyKey: node
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/#example-one-topologyspreadconstraint