You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/zh-cn/blog/_posts/2022-08-15-meet-our-contributors-APAC-China-region-03.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -69,7 +69,7 @@ Andy 是 Kubernetes 中国社区的活跃成员。
69
69
## [Shiming Zhang](https://github.com/wzshiming)
70
70
71
71
<!--
72
-
Shiming Zhang is a Software Engineer working on Kubernetes for DaoCloud in Shanghai, China.
72
+
Shiming Zhang is a Software Engineer working on Kubernetes for DaoCloud in Shanghai, China.
73
73
74
74
He has mostly been involved with SIG Node as a reviewer. His major contributions have mainly been bug fixes and feature improvements in an ongoing [KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2712-pod-priority-based-graceful-node-shutdown), all revolving around SIG Node.
Currently Jintao is a reviewer for the [ingress-nginx](https://kubernetes.github.io/ingress-nginx/) project.
131
+
Currently Jintao is a maintainer for the [ingress-nginx](https://kubernetes.github.io/ingress-nginx/) project.
132
132
133
133
He suggests keeping track of job opportunities at open source companies so that you can find one that allows you to contribute full time. For new contributors Jintao says that if anyone wants to make a significant contribution to an open source project, then they should choose the project based on their interests and should generously invest time.
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.
22
+
The v1.25 release of Kubernetes introduced an alpha feature to change how a default
23
+
StorageClass was assigned to a PersistentVolumeClaim (PVC). With the feature enabled,
24
+
you no longer need to create a default StorageClass first and PVC second to assign the
25
+
class. Additionally, any PVCs without a StorageClass assigned can be updated later.
24
26
This feature was graduated to beta in Kubernetes 1.26.
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,
33
+
You can read [retroactive default StorageClass assignment](/docs/concepts/storage/persistent-volumes/#retroactive-default-storageclass-assignment)
34
+
in the Kubernetes documentation for more details about how to use that,
32
35
or you can read on to learn about why the Kubernetes project is making this change.
33
36
-->
34
37
有关如何使用的更多细节，请参阅 Kubernetes
@@ -38,18 +41,20 @@ or you can read on to learn about why the Kubernetes project is making this chan
38
41
<!--
39
42
## Why did StorageClass assignment need improvements
40
43
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).
44
+
Users might already be familiar with a similar feature that assigns default StorageClasses
45
+
to **new** PVCs at the time of creation. This is currently handled by the
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.
54
+
But what if there wasn't a default StorageClass defined at the time of PVC creation?
55
+
Users would end up with a PVC that would never be assigned a class.
56
+
As a result, no storage would be provisioned, and the PVC would be somewhat "stuck" at this point.
57
+
Generally, two main scenarios could result in "stuck" PVCs and cause problems later down the road.
53
58
Let's take a closer look at each of them.
54
59
-->
55
60
但是，如果在创建 PVC 时没有定义默认 StorageClass 会怎样？
@@ -66,9 +71,11 @@ With the alpha feature enabled, there were two options admins had when they want
66
71
启用这个 Alpha 特性后，管理员想要更改默认 StorageClass 时会有两个选项：
67
72
68
73
<!--
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.
74
+
1. Creating a new StorageClass as default before removing the old one associated with the PVC.
75
+
This would result in having two defaults for a short period.
76
+
At this point, if a user were to create a PersistentVolumeClaim with storageClassName set to
77
+
<code>null</code> (implying default StorageClass), the newest default StorageClass would be
@@ -77,9 +84,11 @@ At this point, if a user were to create a PersistentVolumeClaim with storageClas
77
84
78
85
<!--
79
86
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.
87
+
This would result in having no default for a short time.
88
+
Subsequently, if a user were to create a PersistentVolumeClaim with storageClassName
89
+
set to <code>null</code> (implying default StorageClass), the PVC would be in
90
+
<code>Pending</code> state forever. The user would have to fix this by deleting
91
+
the PVC and recreating it once the default StorageClass was available.
@@ -89,8 +98,10 @@ The user would have to fix this by deleting the PVC and recreating it once the d
89
98
<!--
90
99
### Resource ordering during cluster installation
91
100
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.
101
+
If a cluster installation tool needed to create resources that required storage,
102
+
for example, an image registry, it was difficult to get the ordering right.
103
+
This is because any Pods that required storage would rely on the presence of
104
+
a default StorageClass and would fail to be created if it wasn't defined.
@@ -101,8 +112,10 @@ This is because any Pods that required storage would rely on the presence of a d
101
112
<!--
102
113
## What changed
103
114
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.
115
+
We've changed the PersistentVolume (PV) controller to assign a default StorageClass
116
+
to any unbound PersistentVolumeClaim that has the storageClassName set to <code>null</code>.
117
+
We've also modified the PersistentVolumeClaim admission within the API server to allow
118
+
the change of values from an unset value to an actual StorageClass name.
### Null `storageClassName` versus `storageClassName: ""` - does it matter? { #null-vs-empty-string }
115
128
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>.
129
+
Before this feature was introduced, those values were equal in terms of behavior.
130
+
Any PersistentVolumeClaim with the storageClassName set to <code>null</code> or <code>""</code>
131
+
would bind to an existing PersistentVolume resource with storageClassName also set to
@@ -123,7 +139,10 @@ Before this feature was introduced, those values were equal in terms of behavior
123
139
124
140
<!--
125
141
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.
142
+
With these constraints in mind, the feature changes the semantics of <code>null</code>.
143
+
If a default StorageClass is present, <code>null</code> would translate to "Give me a default" and
144
+
<code>""</code> would mean "Give me PersistentVolume that also has <code>""</code> StorageClass name."
145
+
In the absence of a StorageClass, the behavior would remain unchanged.
127
146
-->
128
147
启用此新特性时，我们希望保持此行为，但也希望能够更新 StorageClass 名称。
129
148
考虑到这些限制，此特性更改了 `null` 的语义。
@@ -132,7 +151,8 @@ With these constraints in mind, the feature changes the semantics of <code>null<
132
151
所以行为将保持不变。
133
152
134
153
<!--
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.
154
+
Summarizing the above, we've changed the semantics of <code>null</code> so that
155
+
its behavior depends on the presence or absence of a definition of default StorageClass.
136
156
137
157
The tables below show all these cases to better describe when PVC binds and when its StorageClass gets updated.
138
158
-->
@@ -179,7 +199,9 @@ The tables below show all these cases to better describe when PVC binds and when
179
199
<!--
180
200
## How to use it
181
201
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:
202
+
If you want to test the feature whilst it's alpha, you need to enable the relevant
203
+
feature gate in the kube-controller-manager and the kube-apiserver.
204
+
Use the `--feature-gates` command line argument:
183
205
-->
184
206
## 如何使用 {#how-to-use-it}
185
207
@@ -218,15 +240,17 @@ If you would like to see the feature in action and verify it works fine in your
218
240
```
219
241
220
242
<!--
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.
243
+
2. Create the PersistentVolumeClaim when there is no default StorageClass.
244
+
The PVC won't provision or bind (unless there is an existing, suitable PV already present)
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
229
-
pvc-1 Pending
253
+
pvc-1 Pending
230
254
```
231
255
232
256
<!--
@@ -253,7 +277,10 @@ If you would like to see the feature in action and verify it works fine in your
253
277
<!--
254
278
### New metrics
255
279
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.
280
+
To help you see that the feature is working as expected we also introduced a new
281
+
<code>retroactive_storageclass_total</code> metric to show how many times that the
282
+
PV controller attempted to update PersistentVolumeClaim, and
283
+
<code>retroactive_storageclass_errors_total</code> to show how many of those attempts failed.
257
284
-->
258
285
### 新指标 {#new-metrics}
259
286
@@ -264,7 +291,8 @@ To help you see that the feature is working as expected we also introduced a new
264
291
<!--
265
292
## Getting involved
266
293
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).
294
+
We always welcome new contributors so if you would like to get involved you can
0 commit comments