Question

我们最近将EKS环境升级到v1.12.7。升级后，我们注意到现在有一个名为attachable-volumes-aws-ebs的“可分配”资源，在我们的环境中，每个节点上都有许多EBS卷（它们都是通过PVC动态生成的）。

但在“分配的资源”部分的每个节点上，它显示0个附加卷：

Allocatable:
 attachable-volumes-aws-ebs:  25
 cpu:                         16
 ephemeral-storage:           96625420948
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      64358968Ki
 pods:                        234
...
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource                    Requests           Limits
  --------                    --------           ------
  cpu                         5430m (33%)        5200m (32%)
  memory                      19208241152 (29%)  21358Mi (33%)
  attachable-volumes-aws-ebs  0                  0

因此，调度程序将继续尝试将新卷附加到已附加25个卷的节点上。

我们如何让kubernetes识别所连接的卷，以便调度程序可以相应地采取行动？

Answer 1

首先检查您的广告连播状态，他们可以处于待处理状态，这就是为什么您的音量可能不计算在内的原因。当同时使用多个 PersistentVolumeClaim 时，您的卷也可能停留在附加状态。

由于 NodeWithImpairedVolumes = true：NoSchedule 标志以及同时 attachable-volumes-aws-ebs 的编号，您的卷可能未连接。

尝试执行：

$ kubectl taint nodes node1 key:NoSchedule-

在每个带有此标签（NodeWithImpairedVolumes = true：NoSchedule）的节点上。

如果使用 awsElasticBlockStore ，则使用awsElasticBlockStore卷时会受到一些限制：

节点必须是AWS EC2实例这些实例必须与EBS卷位于相同的区域和可用区中 EBS仅支持安装卷的单个EC2实例。

您可以使用 count / * 资源配额，如果对象存在于服务器存储中，则会根据该配额收费。这些配额类型对于防止使用 count / persistentvolumeclaims count / persistentvolumeclaims 的存储资源的耗尽非常有用。

可分配表将由Kubelet计算并报告给API服务器。定义为：

[可分配] = [节点容量]-[保留Kube]-[系统保留]-[强制逐出阈值]

注意：由于内核使用情况可能会发生变化并且不受kubernetes的控制，因此它将被报告为一个单独的值（可能通过指标API）。报告内核使用情况不在此建议范围之内。

Answer 2

目前最好的选择似乎是使用带有新 --volume-attach-limit 标志的 EBS CSI 驱动程序 https://github.com/kubernetes-sigs/aws-ebs-csi-driver/pull/522

AWS EKS节点-卷连接限制

2 个答案: