# 特定于节点的卷数限制

LLMS index: [llms.txt](/llms.txt)

---

<!--
reviewers:
- jsafrane
- saad-ali
- thockin
- msau42
title: Node-specific Volume Limits
content_type: concept
weight: 90
-->

<!-- overview -->

<!--
This page describes the maximum number of volumes that can be attached
to a Node for various cloud providers.
-->
此页面描述了各个云供应商可挂接至一个节点的最大卷数。

<!--
Cloud providers like Google, Amazon, and Microsoft typically have a limit on
how many volumes can be attached to a Node. It is important for Kubernetes to
respect those limits. Otherwise, Pods scheduled on a Node could get stuck
waiting for volumes to attach.
-->
谷歌、亚马逊和微软等云供应商通常对可以挂接到节点的卷数量进行限制。
Kubernetes 需要尊重这些限制。否则，在节点上调度的 Pod 可能会卡住去等待卷的挂接。

<!-- body -->

<!--
## Kubernetes default limits

The Kubernetes scheduler has default limits on the number of volumes
that can be attached to a Node:
-->
## Kubernetes 的默认限制   {#kubernetes-default-limits}

Kubernetes 调度器对挂接到一个节点的卷数有默认限制：

<!--
<table>
  <tr><th>Cloud service</th><th>Maximum volumes per Node</th></tr>
  <tr><td><a href="https://aws.amazon.com/ebs/">Amazon Elastic Block Store (EBS)</a></td><td>39</td></tr>
  <tr><td><a href="https://cloud.google.com/persistent-disk/">Google Persistent Disk</a></td><td>16</td></tr>
  <tr><td><a href="https://azure.microsoft.com/en-us/services/storage/main-disks/">Microsoft Azure Disk Storage</a></td><td>16</td></tr>
</table>
-->
<table>
  <tr><th>云服务</th><th>每节点最大卷数</th></tr>
  <tr><td><a href="https://aws.amazon.com/ebs/">Amazon Elastic Block Store (EBS)</a></td><td>39</td></tr>
  <tr><td><a href="https://cloud.google.com/persistent-disk/">Google Persistent Disk</a></td><td>16</td></tr>
  <tr><td><a href="https://azure.microsoft.com/en-us/services/storage/main-disks/">Microsoft Azure Disk Storage</a></td><td>16</td></tr>
</table>

<!--
## Dynamic volume limits
-->
## 动态卷限制   {#dynamic-volume-limits}








  <div class="feature-state-notice feature-stable">
      <span class="feature-state-name">特性状态：</span>
      <code>Kubernetes v1.17 [stable]</code>
    </div>
  



<!--
Dynamic volume limits are supported for following volume types.
-->
以下卷类型支持动态卷限制。

- Amazon EBS
- Google Persistent Disk
- Azure Disk
- CSI

<!--
For volumes managed by in-tree volume plugins, Kubernetes automatically determines the Node
type and enforces the appropriate maximum number of volumes for the node. For example:
-->
对于由树内插件管理的卷，Kubernetes 会自动确定节点类型并确保节点上可挂接的卷数目合规。例如：

<!--
* On
<a href="https://cloud.google.com/compute/">Google Compute Engine</a>,
up to 127 volumes can be attached to a node, [depending on the node
type](https://cloud.google.com/compute/docs/disks/#pdnumberlimits).
-->
* 在 <a href="https://cloud.google.com/compute/">Google Compute Engine</a> 环境中，
  [根据节点类型](https://cloud.google.com/compute/docs/disks/#pdnumberlimits)最多可以将
  127 个卷挂接到节点。

<!--
* For Amazon EBS disks on M5,C5,R5,T3 and Z1D instance types, Kubernetes allows only 25
volumes to be attached to a Node. For other instance types on
<a href="https://aws.amazon.com/ec2/">Amazon Elastic Compute Cloud (EC2)</a>,
Kubernetes allows 39 volumes to be attached to a Node.

* On Azure, up to 64 disks can be attached to a node, depending on the node type. For more details, refer to [Sizes for virtual machines in Azure](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes).
-->
* 对于 M5、C5、R5、T3 和 Z1D 实例类型的 Amazon EBS 磁盘，Kubernetes 仅允许 25 个卷挂接到节点。
  对于 <a href="https://aws.amazon.com/ec2/">Amazon Elastic Compute Cloud (EC2)</a>
  上的其他实例类型，Kubernetes 允许 39 个卷挂接至节点。

* 在 Azure 环境中，根据节点类型，最多 64 个磁盘可以挂接至一个节点。
  更多详细信息，请参阅
  [Azure 虚拟机的数量大小](https://docs.microsoft.com/zh-cn/azure/virtual-machines/windows/sizes)。

<!--
* If a CSI storage driver advertises a maximum number of volumes for a Node (using `NodeGetInfo`), the <a class='glossary-tooltip' title='控制平面组件，负责监视新创建的、未指定运行节点的 Pod，选择节点让 Pod 在上面运行。' data-bs-toggle='tooltip' data-bs-placement='top' href='/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/' target='_blank' aria-label='kube-scheduler'>kube-scheduler</a> honors that limit.
Refer to the [CSI specifications](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo) for details.

* For volumes managed by in-tree plugins that have been migrated to a CSI driver, the maximum number of volumes will be the one reported by the CSI driver.
-->
* 如果 CSI 存储驱动（使用 `NodeGetInfo`）为节点通告卷数上限，则
  <a class='glossary-tooltip' title='控制平面组件，负责监视新创建的、未指定运行节点的 Pod，选择节点让 Pod 在上面运行。' data-bs-toggle='tooltip' data-bs-placement='top' href='/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/' target='_blank' aria-label='kube-scheduler'>kube-scheduler</a>
  将遵守该限制值。参考
  [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo)获取更多详细信息。

* 对于由已迁移到 CSI 驱动的树内插件管理的卷，最大卷数将是 CSI 驱动报告的卷数。

<!--
### Mutable CSI Node Allocatable Count
-->
### 可变的 CSI 节点可分配数   {#mutable-csi-node-allocatable-count}








  <div class="feature-state-notice feature-stable" title="特性门控： MutableCSINodeAllocatableCount">
              <span class="feature-state-name">特性状态：</span> 
              <code>Kubernetes v1.36 [stable]</code>（默认启用）</div>


<!--
CSI drivers can dynamically adjust the maximum number of volumes that can be attached to a Node at runtime. This enhances scheduling accuracy and reduces pod scheduling failures due to changes in resource availability.

To use this feature, you must enable the `MutableCSINodeAllocatableCount` feature gate on the following components:
-->
CSI 驱动可以在运行时动态调整可以挂载到 Node 的最大卷数量。
这提高了调度准确性，并减少了由于资源可用性变化导致的 Pod 调度失败。

要使用此特性，你必须在以下组件上启用 `MutableCSINodeAllocatableCount`
特性门控：

- `kube-apiserver`
- `kubelet`

<!--
#### Periodic Updates

When enabled, CSI drivers can request periodic updates to their volume limits by setting the `nodeAllocatableUpdatePeriodSeconds` field in the `CSIDriver` specification. For example:
-->
#### 定期更新

当启用时，CSI 驱动可以通过在 `CSIDriver` 规约中设置
`nodeAllocatableUpdatePeriodSeconds` 字段来请求定期更新其卷限制。
例如：

```yaml
apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: hostpath.csi.k8s.io
spec:
  nodeAllocatableUpdatePeriodSeconds: 60
```

<!--
Kubelet will periodically call the corresponding CSI driver’s `NodeGetInfo` endpoint to refresh the maximum number of attachable volumes, using the interval specified in `nodeAllocatableUpdatePeriodSeconds`. The minimum allowed value for this field is 10 seconds.
-->
kubelet 将使用 `nodeAllocatableUpdatePeriodSeconds`
中指定的时间间隔，定期调用相应的 CSI 驱动的 `NodeGetInfo`
端点来刷新可挂接卷的最大数量。此字段允许的最小值为 10 秒。

<!--
If a volume attachment operation fails with a `ResourceExhausted` error (gRPC code 8),
Kubernetes triggers an immediate update to the allocatable volume count for that Node.
Additionally, kubelet marks affected pods as Failed, allowing their controllers to
handle recreation. This prevents pods from getting stuck indefinitely in the
`ContainerCreating` state.
-->
如果卷挂载操作失败并返回 `ResourceExhausted` 错误（gRPC 代码 8），
Kubernetes 会立即触发对此节点可分配卷数量的更新。此外，kubelet
会将受影响的 Pod 标记为 Failed，从而使它们的控制器处理重新创建。
这防止了 Pod 无限期地停留在 `ContainerCreating` 状态。

<!--
### Preventing Pod placement without CSI driver
-->
### 防止在未安装 CSI 驱动程序的情况下放置 Pod








  <div class="feature-state-notice feature-alpha" title="特性门控： VolumeLimitScaling">
              <span class="feature-state-name">特性状态：</span> 
              <code>Kubernetes v1.35 [alpha]</code>（默认禁用）</div>


<!--
If `VolumeLimitScaling` [feature gate](/docs/reference/command-line-tools-reference/feature-gates#VolumeLimitScaling)
is enabled and a CSI driver has corresponding `CSIDriver` object installed with `spec.preventPodSchedulingIfMissing`
set to true then scheduler will prevent pod placement to nodes that do not yet have CSI driver installed.
For example:
-->
如果启用了 `VolumeLimitScaling`
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates#VolumeLimitScaling)，
并且已安装了相应的 `CSIDriver` 对象，且 `spec.preventPodSchedulingIfMissing`
设置为 true，则调度器将阻止将 Pod 放置到尚未安装 CSI 驱动程序的节点上。
例如：

```yaml
apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: hostpath.csi.k8s.io
spec:
  preventPodSchedulingIfMissing: true
```

<!--
This limitation only applies to pods that require corresponding CSI volume.
-->
此限制仅适用于需要相应 CSI 卷的 Pod。

<!--
### CSI volume attach limits and cluster autoscaler

If `--enable-csi-node-aware-scheduling` option is enabled in cluster-autoscaler,
then cluster-autoscaler can accurately calculate number of nodes required to
satisfy pending pods that require CSI volumes.
-->
### CSI 卷附加限制和集群自动扩缩器

如果在 cluster-autoscaler 中启用了 `--enable-csi-node-aware-scheduling` 选项，
则 cluster-autoscaler 可以准确地计算满足需要 CSI 卷的待处理 Pod 所需的节点数。

<!--
If you are using cluster-autoscaler in your
Kubernetes cluster, we do not recommend preventing pod placement via `PreventPodSchedulingIfMissing` field,
unless cluster-autoscaler also has `--enable-csi-node-aware-scheduling` command line option enabled.
Underlying reason for this limitation while `VolumeLimitScaling`
feature remains in alpha is - preventing pod placement can break scheduling
simulation cluster-autoscaler runs if cluster-autoscaler is not already aware of CSI volume limits.
We expect this limitation to go away once `--enable-csi-node-aware-scheduling`
becomes enabled by default in cluster-autoscaler.
-->
如果你在 Kubernetes 集群中使用 cluster-autoscaler，
我们不建议通过 `PreventPodSchedulingIfMissing` 字段阻止 Pod 部署，
除非 cluster-autoscaler 同时启用了 `--enable-csi-node-aware-scheduling`
命令行选项。此限制的根本原因是，在 `VolumeLimitScaling` 特性仍处于
Alpha 测试阶段时，阻止 Pod 部署可能会破坏 cluster-autoscaler 运行的调度模拟，
尤其是在 cluster-autoscaler 尚未感知 CSI 卷限制的情况下。
我们预计，一旦 cluster-autoscaler 默认启用 `--enable-csi-node-aware-scheduling`，
此限制将不复存在。

<!--
Command line `--enable-csi-node-aware-scheduling` in cluster-autoscaler can be
enabled regardless of `VolumeLimitScaling` feature state in Kubernetes.
We recommend enabling it if your cluster is
using CSI volumes and you are running into issues related to, too many pods
crowding a node when a new node is spun via cluster-autoscaler, because current version of
cluster-autoscaler does not compute correct number of nodes required to satisfy all pending pods.
-->
无论 Kubernetes 中的 `VolumeLimitScaling` 特性状态如何，
都可以在 cluster-autoscaler 中启用命令行参数
`--enable-csi-node-aware-scheduling`。
如果你的集群使用 CSI 卷，并且遇到通过 cluster-autoscaler
启动新节点时，节点上 Pod 过多导致资源占用过高的问题，我们建议启用此特性，
因为当前版本的 cluster-autoscaler 无法正确计算满足所有待处理 Pod
所需的节点数量。