Skip to content

Commit e609b6e

Browse files
windsonseawindsonsea
committed
[zh] sync blog: 2023-01-05-retroactive-default-storage-class
1 parent 6912a83 commit e609b6e

File tree

1 file changed

+293
-0
lines changed

1 file changed

+293
-0
lines changed

‎content/zh-cn/blog/_posts/2023-01-05-retroactive-default-storage-class.md

Lines changed: 293 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,293 @@
1+
---
2+
layout: blog
3+
title: "Kubernetes 1.26：可追溯的默认 StorageClass"
4+
date: 2023-01-05
5+
slug: retroactive-default-storage-class
6+
---
7+
<!--
8+
layout: blog
9+
title: "Kubernetes 1.26: Retroactive Default StorageClass"
10+
date: 2023-01-05
11+
slug: retroactive-default-storage-class
12+
-->
13+
14+
<!--
15+
**Author:** Roman Bednář (Red Hat)
16+
-->
17+
**作者：** Roman Bednář (Red Hat)
18+
19+
**译者：** Michael Yao (DaoCloud)
20+
21+
<!--
22+
The v1.25 release of Kubernetes introduced an alpha feature to change how a default StorageClass was assigned to a PersistentVolumeClaim (PVC).
23+
With the feature enabled, you no longer need to create a default StorageClass first and PVC second to assign the class. Additionally, any PVCs without a StorageClass assigned can be updated later.
24+
This feature was graduated to beta in Kubernetes 1.26.
25+
-->
26+
Kubernetes v1.25 引入了一个 Alpha 特性来更改默认 StorageClass 被分配到 PersistentVolumeClaim (PVC) 的方式。
27+
启用此特性后，你不再需要先创建默认 StorageClass，再创建 PVC 来分配类。
28+
此外，任何未分配 StorageClass 的 PVC 都可以在后续被更新。此特性在 Kubernetes 1.26 中已进阶至 Beta。
29+
30+
<!--
31+
You can read [retroactive default StorageClass assignment](/docs/concepts/storage/persistent-volumes/#retroactive-default-storageclass-assignment) in the Kubernetes documentation for more details about how to use that,
32+
or you can read on to learn about why the Kubernetes project is making this change.
33+
-->
34+
有关如何使用的更多细节，请参阅 Kubernetes
35+
文档[可追溯的默认 StorageClass 赋值](/zh-cn/docs/concepts/storage/persistent-volumes/#retroactive-default-storageclass-assignment)，
36+
你还可以阅读了解为什么 Kubernetes 项目做了此项变更。
37+
38+
<!--
39+
## Why did StorageClass assignment need improvements
40+
41+
Users might already be familiar with a similar feature that assigns default StorageClasses to **new** PVCs at the time of creation. This is currently handled by the [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass).
42+
-->
43+
## 为什么 StorageClass 赋值需要改进 {#why-did-sc-assignment-need-improvements}
44+
45+
用户可能已经熟悉在创建时将默认 StorageClasses 分配给**新** PVC 的这一类似特性。
46+
这个目前由[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)处理。
47+
48+
<!--
49+
But what if there wasn't a default StorageClass defined at the time of PVC creation?
50+
Users would end up with a PVC that would never be assigned a class.
51+
As a result, no storage would be provisioned, and the PVC would be somewhat "stuck" at this point.
52+
Generally, two main scenarios could result in "stuck" PVCs and cause problems later down the road.
53+
Let's take a closer look at each of them.
54+
-->
55+
但是，如果在创建 PVC 时没有定义默认 StorageClass 会怎样？
56+
那用户最终将得到一个永远不会被赋予存储类的 PVC。结果是没有存储会被制备，而 PVC 有时也会“卡在”这里。
57+
一般而言，两个主要场景可能导致 PVC “卡住”，并在后续造成更多问题。让我们仔细看看这两个场景。
58+
59+
<!--
60+
### Changing default StorageClass
61+
62+
With the alpha feature enabled, there were two options admins had when they wanted to change the default StorageClass:
63+
-->
64+
### 更改默认 StorageClass {#changing-default-storageclass}
65+
66+
启用这个 Alpha 特性后，管理员想要更改默认 StorageClass 时会有两个选项：
67+
68+
<!--
69+
1. Creating a new StorageClass as default before removing the old one associated with the PVC.
70+
This would result in having two defaults for a short period.
71+
At this point, if a user were to create a PersistentVolumeClaim with storageClassName set to <code>null</code> (implying default StorageClass), the newest default StorageClass would be chosen and assigned to this PVC.
72+
-->
73+
1. 在移除与 PVC 关联的旧 StorageClass 之前，创建一个新的 StorageClass 作为默认值。
74+
这将导致在短时间内出现两个默认值。此时，如果用户要创建一个 PersistentVolumeClaim，
75+
并将 storageClassName 设置为 <code>null</code>（指代默认 StorageClass），
76+
则最新的默认 StorageClass 将被选中并指定给这个 PVC。
77+
78+
<!--
79+
2. Removing the old default first and creating a new default StorageClass.
80+
This would result in having no default for a short time.
81+
Subsequently, if a user were to create a PersistentVolumeClaim with storageClassName set to <code>null</code> (implying default StorageClass), the PVC would be in <code>Pending</code> state forever.
82+
The user would have to fix this by deleting the PVC and recreating it once the default StorageClass was available.
83+
-->
84+
2. 先移除旧的默认值再创建一个新的默认 StorageClass。这将导致短时间内没有默认值。
85+
接下来如果用户创建一个 PersistentVolumeClaim，并将 storageClassName 设置为 <code>null</code>
86+
（指代默认 StorageClass），则 PVC 将永远处于 <code>Pending</code> 状态。
87+
一旦默认 StorageClass 可用，用户就不得不通过删除并重新创建 PVC 来修复这个问题。
88+
89+
<!--
90+
### Resource ordering during cluster installation
91+
92+
If a cluster installation tool needed to create resources that required storage, for example, an image registry, it was difficult to get the ordering right.
93+
This is because any Pods that required storage would rely on the presence of a default StorageClass and would fail to be created if it wasn't defined.
94+
-->
95+
### 集群安装期间的资源顺序 {#resource-ordering-during-cluster-installation}
96+
97+
如果集群安装工具需要创建镜像仓库这种有存储要求的资源，很难进行合适地排序。
98+
这是因为任何有存储要求的 Pod 都将依赖于默认 StorageClass 的存在与否。
99+
如果默认 StorageClass 未被定义，Pod 创建将失败。
100+
101+
<!--
102+
## What changed
103+
104+
We've changed the PersistentVolume (PV) controller to assign a default StorageClass to any unbound PersistentVolumeClaim that has the storageClassName set to <code>null</code>.
105+
We've also modified the PersistentVolumeClaim admission within the API server to allow the change of values from an unset value to an actual StorageClass name.
106+
-->
107+
## 发生了什么变化 {#what-changed}
108+
109+
我们更改了 PersistentVolume (PV) 控制器，以便将默认 StorageClass 指定给
110+
storageClassName 设置为 `null` 且未被绑定的所有 PersistentVolumeClaim。
111+
我们还修改了 API 服务器中的 PersistentVolumeClaim 准入机制，允许将取值从未设置值更改为实际的 StorageClass 名称。
112+
113+
<!--
114+
### Null `storageClassName` versus `storageClassName: ""` - does it matter? { #null-vs-empty-string }
115+
116+
Before this feature was introduced, those values were equal in terms of behavior. Any PersistentVolumeClaim with the storageClassName set to <code>null</code> or <code>""</code> would bind to an existing PersistentVolume resource with storageClassName also set to <code>null</code> or <code>""</code>.
117+
-->
118+
### Null `storageClassName` 与 `storageClassName: ""` - 有什么影响？ {#null-vs-empty-string}
119+
120+
此特性被引入之前，这两种赋值就其行为而言是相同的。storageClassName 设置为 `null` 或 `""`
121+
的所有 PersistentVolumeClaim 都会被绑定到 storageClassName 也设置为 `null` 或
122+
`""` 的、已有的 PersistentVolume 资源。
123+
124+
<!--
125+
With this new feature enabled we wanted to maintain this behavior but also be able to update the StorageClass name.
126+
With these constraints in mind, the feature changes the semantics of <code>null</code>. If a default StorageClass is present, <code>null</code> would translate to "Give me a default" and <code>""</code> would mean "Give me PersistentVolume that also has <code>""</code> StorageClass name." In the absence of a StorageClass, the behavior would remain unchanged.
127+
-->
128+
启用此新特性时，我们希望保持此行为，但也希望能够更新 StorageClass 名称。
129+
考虑到这些限制，此特性更改了 `null` 的语义。
130+
具体而言，如果有一个默认 StorageClass，`null` 将可被理解为 “给我一个默认值”，
131+
而 `""` 表示 “给我 StorageClass 名称也是 `""` 的 PersistentVolume”，
132+
所以行为将保持不变。
133+
134+
<!--
135+
Summarizing the above, we've changed the semantics of <code>null</code> so that its behavior depends on the presence or absence of a definition of default StorageClass.
136+
137+
The tables below show all these cases to better describe when PVC binds and when its StorageClass gets updated.
138+
-->
139+
综上所述，我们更改了 `null` 的语义，使其行为取决于默认 StorageClass 定义的存在或缺失。
140+
141+
下表显示了所有这些情况，更好地描述了 PVC 何时绑定及其 StorageClass 何时被更新。
142+
143+
<table>
144+
<!-- PVC binding behavior with Retroactive default StorageClass -->
145+
<caption>使用默认 StorageClass 时的 PVC 绑定行为</caption>
146+
<thead>
147+
<tr>
148+
<th colspan="2"></th>
149+
<th>PVC <tt>storageClassName</tt> = <code>""</code></th>
150+
<th>PVC <tt>storageClassName</tt> = <code>null</code></th>
151+
</tr>
152+
</thead>
153+
<tbody>
154+
<tr>
155+
<td rowspan="2">未设置默认存储类</td>
156+
<td>PV <tt>storageClassName</tt> = <code>""</code></td>
157+
<td>binds</td>
158+
<td>binds</td>
159+
</tr>
160+
<tr>
161+
<td>PV without <tt>storageClassName</tt></td>
162+
<td>binds</td>
163+
<td>binds</td>
164+
</tr>
165+
<tr>
166+
<td rowspan="2">设置了默认存储类</td>
167+
<td>PV <tt>storageClassName</tt> = <code>""</code></td>
168+
<td>binds</td>
169+
<td>存储类更新</td>
170+
</tr>
171+
<tr>
172+
<td>PV without <tt>storageClassName</tt></td>
173+
<td>binds</td>
174+
<td>存储类更新</td>
175+
</tr>
176+
</tbody>
177+
</table>
178+
179+
<!--
180+
## How to use it
181+
182+
If you want to test the feature whilst it's alpha, you need to enable the relevant feature gate in the kube-controller-manager and the kube-apiserver. Use the `--feature-gates` command line argument:
183+
-->
184+
## 如何使用 {#how-to-use-it}
185+
186+
如果你想测试这个 Alpha 特性，你需要在 kube-controller-manager 和 kube-apiserver 中启用相关特性门控。
187+
你可以使用 `--feature-gates` 命令行参数：
188+
189+
```
190+
--feature-gates="...,RetroactiveDefaultStorageClass=true"
191+
```
192+
193+
<!--
194+
### Test drive
195+
196+
If you would like to see the feature in action and verify it works fine in your cluster here's what you can try:
197+
-->
198+
### 测试演练 {#test-drive}
199+
200+
如果你想看到此特性发挥作用并验证它在集群中是否正常工作，你可以尝试以下步骤：
201+
202+
<!--
203+
1. Define a basic PersistentVolumeClaim:
204+
-->
205+
1. 定义一个基本的 PersistentVolumeClaim：
206+
207+
```yaml
208+
apiVersion: v1
209+
kind: PersistentVolumeClaim
210+
metadata:
211+
name: pvc-1
212+
spec:
213+
accessModes:
214+
- ReadWriteOnce
215+
resources:
216+
requests:
217+
storage: 1Gi
218+
```
219+
220+
<!--
221+
2. Create the PersistentVolumeClaim when there is no default StorageClass. The PVC won't provision or bind (unless there is an existing, suitable PV already present) and will remain in <code>Pending</code> state.
222+
-->
223+
2. 在没有默认 StorageClass 时创建 PersistentVolumeClaim。
224+
PVC 不会制备或绑定（除非当前已存在一个合适的 PV），PVC 将保持在 `Pending` 状态。
225+
226+
```
227+
$ kc get pvc
228+
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
229+
pvc-1 Pending
230+
```
231+
232+
<!--
233+
3. Configure one StorageClass as default.
234+
-->
235+
3. 将某个 StorageClass 配置为默认值。
236+
237+
```
238+
$ kc patch sc -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
239+
storageclass.storage.k8s.io/my-storageclass patched
240+
```
241+
242+
<!--
243+
4. Verify that PersistentVolumeClaims is now provisioned correctly and was updated retroactively with new default StorageClass.
244+
-->
245+
4. 确认 PersistentVolumeClaims 现在已被正确制备，并且已使用新的默认 StorageClass 进行了可追溯的更新。
246+
247+
```
248+
$ kc get pvc
249+
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
250+
pvc-1 Bound pvc-06a964ca-f997-4780-8627-b5c3bf5a87d8 1Gi RWO my-storageclass 87m
251+
```
252+
253+
<!--
254+
### New metrics
255+
256+
To help you see that the feature is working as expected we also introduced a new <code>retroactive_storageclass_total</code> metric to show how many times that the PV controller attempted to update PersistentVolumeClaim, and <code>retroactive_storageclass_errors_total</code> to show how many of those attempts failed.
257+
-->
258+
### 新指标 {#new-metrics}
259+
260+
为了帮助你了解该特性是否按预期工作，我们还引入了一个新的 `retroactive_storageclass_total`
261+
指标来显示 PV 控制器尝试更新 PersistentVolumeClaim 的次数，以及
262+
`retroactive_storageclass_errors_total` 来显示这些尝试失败了多少次。
263+
264+
<!--
265+
## Getting involved
266+
267+
We always welcome new contributors so if you would like to get involved you can join our [Kubernetes Storage Special-Interest-Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG).
268+
269+
If you would like to share feedback, you can do so on our [public Slack channel](https://app.slack.com/client/T09NY5SBT/C09QZFCE5).
270+
271+
Special thanks to all the contributors that provided great reviews, shared valuable insight and helped implement this feature (alphabetical order):
272+
-->
273+
## 欢迎参与 {#getting-involved}
274+
275+
我们始终欢迎新的贡献者，如果你想参与其中，欢迎加入
276+
[Kubernetes Storage Special Interest Group（存储特别兴趣小组）](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG)。
277+
278+
如果你想分享反馈，可以在我们的[公开 Slack 频道](https://app.slack.com/client/T09NY5SBT/C09QZFCE5)上反馈。
279+
280+
特别感谢所有提供精彩评论、分享宝贵见解并帮助实现此特性的贡献者们（按字母顺序排列）：
281+
282+
- Deep Debroy ([ddebroy](https://github.com/ddebroy))
283+
- Divya Mohan ([divya-mohan0209](https://github.com/divya-mohan0209))
284+
- Jan Šafránek ([jsafrane](https://github.com/jsafrane/))
285+
- Joe Betz ([jpbetz](https://github.com/jpbetz))
286+
- Jordan Liggitt ([liggitt](https://github.com/liggitt))
287+
- Michelle Au ([msau42](https://github.com/msau42))
288+
- Seokho Son ([seokho-son](https://github.com/seokho-son))
289+
- Shannon Kularathna ([shannonxtreme](https://github.com/shannonxtreme))
290+
- Tim Bannister ([sftim](https://github.com/sftim))
291+
- Tim Hockin ([thockin](https://github.com/thockin))
292+
- Wojciech Tyczynski ([wojtek-t](https://github.com/wojtek-t))
293+
- Xing Yang ([xing-yang](https://github.com/xing-yang))

0 commit comments

Comments
 (0)