Skip to content

Commit 9a7f74a

Browse files
authored
Merge pull request #36630 from windsonsea/stocap
[zh] Fix links of /storage/storage-capacity.md
2 parents cb08982 + 8997ec4 commit 9a7f74a

File tree

1 file changed

+24
-13
lines changed

1 file changed

+24
-13
lines changed

content/zh-cn/docs/concepts/storage/storage-capacity.md

Lines changed: 24 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -3,27 +3,37 @@ title: 存储容量
33
content_type: concept
44
weight: 70
55
---
6+
<!--
7+
reviewers:
8+
- jsafrane
9+
- saad-ali
10+
- msau42
11+
- xing-yang
12+
- pohly
13+
title: Storage Capacity
14+
content_type: concept
15+
weight: 70
16+
-->
617

718
<!-- overview -->
819
<!--
920
Storage capacity is limited and may vary depending on the node on
1021
which a pod runs: network-attached storage might not be accessible by
1122
all nodes, or storage is local to a node to begin with.
23+
-->
24+
存储容量是有限的,并且会因为运行 Pod 的节点不同而变化:
25+
网络存储可能并非所有节点都能够访问,或者对于某个节点存储是本地的。
1226

1327
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
1428

29+
<!--
1530
This page describes how Kubernetes keeps track of storage capacity and
1631
how the scheduler uses that information to [schedule Pods](/docs/concepts/scheduling-eviction/) onto nodes
1732
that have access to enough storage capacity for the remaining missing
1833
volumes. Without storage capacity tracking, the scheduler may choose a
1934
node that doesn't have enough capacity to provision a volume and
2035
multiple scheduling retries will be needed.
2136
-->
22-
存储容量是有限的,并且会因为运行 Pod 的节点不同而变化:
23-
网络存储可能并非所有节点都能够访问,或者对于某个节点存储是本地的。
24-
25-
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
26-
2737
本页面描述了 Kubernetes 如何跟踪存储容量以及调度程序如何为了余下的尚未挂载的卷使用该信息将
2838
[Pod 调度](/zh-cn/docs/concepts/scheduling-eviction/)到能够访问到足够存储容量的节点上。
2939
如果没有跟踪存储容量,调度程序可能会选择一个没有足够容量来提供卷的节点,并且需要多次调度重试。
@@ -60,10 +70,10 @@ There are two API extensions for this feature:
6070
## API
6171

6272
这个特性有两个 API 扩展接口:
63-
- [CSIStorageCapacity](/docs/reference/kubernetes-api/config-and-storage-resources/csi-storage-capacity-v1/) 对象:这些对象由
73+
- [CSIStorageCapacity](/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/csi-storage-capacity-v1/) 对象:这些对象由
6474
CSI 驱动程序在安装驱动程序的命名空间中产生。
6575
每个对象都包含一个存储类的容量信息,并定义哪些节点可以访问该存储。
66-
- [`CSIDriverSpec.StorageCapacity` 字段](/docs/reference/kubernetes-api/config-and-storage-resources/csi-driver-v1/#CSIDriverSpec)
76+
- [`CSIDriverSpec.StorageCapacity` 字段](/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/csi-driver-v1/#CSIDriverSpec)
6777
设置为 true 时,Kubernetes 调度程序将考虑使用 CSI 驱动程序的卷的存储容量。
6878

6979
<!--
@@ -89,18 +99,18 @@ decides where to create the volume, independently of Pods that will
8999
use the volume. The scheduler then schedules Pods onto nodes where the
90100
volume is available after the volume has been created.
91101
92-
For [CSI ephemeral volumes](/docs/concepts/storage/volumes/#csi),
102+
For [CSI ephemeral volumes](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes),
93103
scheduling always happens without considering storage capacity. This
94104
is based on the assumption that this volume type is only used by
95105
special CSI drivers which are local to a node and do not need
96106
significant resources there.
97107
-->
98-
## 调度
108+
## 调度 {#scheduling}
99109

100110
如果有以下情况,存储容量信息将会被 Kubernetes 调度程序使用:
101111
- Pod 使用的卷还没有被创建,
102112
- 卷使用引用了 CSI 驱动的 {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}},
103-
并且使用了 `WaitForFirstConsumer` [卷绑定模式](/zh-cn/docs/concepts/storage/storage-classes/#volume-binding-mode)
113+
并且使用了 `WaitForFirstConsumer` [卷绑定模式](/zh-cn/docs/concepts/storage/storage-classes/#volume-binding-mode)
104114
- 驱动程序的 `CSIDriver` 对象的 `StorageCapacity` 被设置为 true。
105115

106116
在这种情况下,调度程序仅考虑将 Pod 调度到有足够存储容量的节点上。这个检测非常简单,
@@ -109,7 +119,8 @@ significant resources there.
109119
对于具有 `Immediate` 卷绑定模式的卷,存储驱动程序将决定在何处创建该卷,而不取决于将使用该卷的 Pod。
110120
然后,调度程序将 Pod 调度到创建卷后可使用该卷的节点上。
111121

112-
对于 [CSI 临时卷](/zh-cn/docs/concepts/storage/volumes/#csi),调度总是在不考虑存储容量的情况下进行。
122+
对于 [CSI 临时卷](/zh-cn/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)
123+
调度总是在不考虑存储容量的情况下进行。
113124
这是基于这样的假设:该卷类型仅由节点本地的特殊 CSI 驱动程序使用,并且不需要大量资源。
114125

115126
<!--
@@ -125,7 +136,7 @@ capacity information, it is possible that the volume cannot really be
125136
created. The node selection is then reset and the Kubernetes scheduler
126137
tries again to find a node for the Pod.
127138
-->
128-
## 重新调度
139+
## 重新调度 {#rescheduling}
129140

130141
当为带有 `WaitForFirstConsumer` 的卷的 Pod 来选择节点时,该决定仍然是暂定的。
131142
下一步是要求 CSI 存储驱动程序创建卷,并提示该卷在被选择的节点上可用。
@@ -149,7 +160,7 @@ another volume. Manual intervention is necessary to recover from this,
149160
for example by increasing capacity or deleting the volume that was
150161
already created.
151162
-->
152-
## 限制
163+
## 限制 {#limitations}
153164

154165
存储容量跟踪增加了调度器第一次尝试即成功的机会,但是并不能保证这一点,因为调度器必须根据可能过期的信息来进行决策。
155166
通常,与没有任何存储容量信息的调度相同的重试机制可以处理调度失败。

0 commit comments

Comments
 (0)