Skip to content

Commit ded6436

Browse files
my-git9my-git9
committed
[zh-cn] Add blog: 2025-05-05-Honor-Persistent-Volume-Reclaim-Policy-Graduate-to-GA.md
Signed-off-by: xin.li <[email protected]>
1 parent fe22810 commit ded6436

File tree

1 file changed

+220
-0
lines changed

1 file changed

+220
-0
lines changed

‎content/zh-cn/blog/_posts/2025-05-05-Honor-Persistent-Volume-Reclaim-Policy-Graduate-to-GA.md

Lines changed: 220 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,220 @@
1+
---
2+
layout: blog
3+
title: 'Kubernetes v1.33：防止无序删除时 PersistentVolume 泄漏特性进阶到 GA'
4+
date: 2025-05-05T10:30:00-08:00
5+
slug: kubernetes-v1-33-prevent-persistentvolume-leaks-when-deleting-out-of-order-graduate-to-ga
6+
author: >
7+
Deepak Kinni (Broadcom)
8+
translator: >
9+
[Xin Li](https://github.com/my-git9) (DaoCloud)
10+
---
11+
<!--
12+
layout: blog
13+
title: 'Kubernetes v1.33: Prevent PersistentVolume Leaks When Deleting out of Order graduates to GA'
14+
date: 2025-05-05T10:30:00-08:00
15+
slug: kubernetes-v1-33-prevent-persistentvolume-leaks-when-deleting-out-of-order-graduate-to-ga
16+
author: >
17+
Deepak Kinni (Broadcom)
18+
-->
19+
20+
<!--
21+
I am thrilled to announce that the feature to prevent
22+
[PersistentVolume](/docs/concepts/storage/persistent-volumes/) (or PVs for short)
23+
leaks when deleting out of order has graduated to General Availability (GA) in
24+
Kubernetes v1.33! This improvement, initially introduced as a beta
25+
feature in Kubernetes v1.31, ensures that your storage resources are properly
26+
reclaimed, preventing unwanted leaks.
27+
-->
28+
我很高兴地宣布，当无序删除时防止
29+
[PersistentVolume](/zh-cn/docs/concepts/storage/persistent-volumes/)（简称 PV）
30+
泄漏的特性已经在 Kubernetes v1.33 中进阶为正式版（GA）！这项改进最初在
31+
Kubernetes v1.31 中作为 Beta 特性引入，
32+
确保你的存储资源能够被正确回收，防止不必要的泄漏。
33+
34+
<!--
35+
## How did reclaim work in previous Kubernetes releases?
36+
37+
[PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#Introduction) (or PVC for short) is
38+
a user's request for storage. A PV and PVC are considered [Bound](/docs/concepts/storage/persistent-volumes/#Binding)
39+
if a newly created PV or a matching PV is found. The PVs themselves are
40+
backed by volumes allocated by the storage backend.
41+
-->
42+
## 以前的 Kubernetes 版本中 reclaim 是如何工作的？
43+
44+
[PersistentVolumeClaim](/zh-cn/docs/concepts/storage/persistent-volumes/#Introduction)（简称 PVC）
45+
是用户对存储的请求。如果创建了新的 PV 或找到了匹配的 PV，则认为 PV 和 PVC
46+
是[绑定](/zh-cn/docs/concepts/storage/persistent-volumes/#Binding)的。
47+
PV 本身由存储后端分配的卷支持。
48+
49+
<!--
50+
Normally, if the volume is to be deleted, then the expectation is to delete the
51+
PVC for a bound PV-PVC pair. However, there are no restrictions on deleting a PV
52+
before deleting a PVC.
53+
-->
54+
通常，如果卷需要被删除，则预期是删除绑定的 PV-PVC 对的 PVC。但是，
55+
删除 PVC 之前并没有限制不能删除 PV。
56+
57+
<!--
58+
For a `Bound` PV-PVC pair, the ordering of PV-PVC deletion determines whether
59+
the PV reclaim policy is honored. The reclaim policy is honored if the PVC is
60+
deleted first; however, if the PV is deleted prior to deleting the PVC, then the
61+
reclaim policy is not exercised. As a result of this behavior, the associated
62+
storage asset in the external infrastructure is not removed.
63+
-->
64+
对于一个“已绑定”的 PV-PVC 对，PV 和 PVC 的删除顺序决定了是否遵守 PV 回收策略。
65+
如果先删除 PVC，则会遵守回收策略；然而，如果在删除 PVC 之前删除了 PV，
66+
则不会执行回收策略。因此，外部基础设施中相关的存储资源不会被移除。
67+
68+
<!--
69+
## PV reclaim policy with Kubernetes v1.33
70+
71+
With the graduation to GA in Kubernetes v1.33, this issue is now resolved. Kubernetes
72+
now reliably honors the configured `Delete` reclaim policy, even when PVs are deleted
73+
before their bound PVCs. This is achieved through the use of finalizers,
74+
ensuring that the storage backend releases the allocated storage resource as intended.
75+
-->
76+
## 在 Kubernetes v1.33 中的 PV 回收策略
77+
78+
随着在 Kubernetes v1.33 中升级为 GA，这个问题现在得到了解决。
79+
Kubernetes 现在可靠地遵循配置的 `Delete` 回收策略（即使在删除 PV
80+
时，其绑定的 PVC 尚未被删除）。这是通过使用 Finalizer 来实现的，
81+
确保存储后端如预期释放分配的存储资源。
82+
83+
<!--
84+
### How does it work?
85+
86+
For CSI volumes, the new behavior is achieved by adding a [finalizer](/docs/concepts/overview/working-with-objects/finalizers/) `external-provisioner.volume.kubernetes.io/finalizer`
87+
on new and existing PVs. The finalizer is only removed after the storage from the backend is deleted. Addition or removal of finalizer is handled by `external-provisioner`
88+
89+
An example of a PV with the finalizer, notice the new finalizer in the finalizers list
90+
-->
91+
### 它是如何工作的？
92+
93+
对于 CSI 卷，新的行为是通过在新创建和现有的 PV 上添加
94+
[Finalizer](/zh-cn/docs/concepts/overview/working-with-objects/finalizers/)
95+
`external-provisioner.volume.kubernetes.io/finalizer` 来实现的。
96+
只有在后端存储被删除后，Finalizer 才会被移除。
97+
98+
下面是一个带 Finalizer 的 PV 示例，请注意 Finalizer 列表中的新 Finalizer：
99+
100+
```
101+
kubectl get pv pvc-a7b7e3ba-f837-45ba-b243-dec7d8aaed53 -o yaml
102+
```
103+
104+
```yaml
105+
apiVersion: v1
106+
kind: PersistentVolume
107+
metadata:
108+
annotations:
109+
pv.kubernetes.io/provisioned-by: csi.example.driver.com
110+
creationTimestamp: "2021-11-17T19:28:56Z"
111+
finalizers:
112+
- kubernetes.io/pv-protection
113+
- external-provisioner.volume.kubernetes.io/finalizer
114+
name: pvc-a7b7e3ba-f837-45ba-b243-dec7d8aaed53
115+
resourceVersion: "194711"
116+
uid: 087f14f2-4157-4e95-8a70-8294b039d30e
117+
spec:
118+
accessModes:
119+
- ReadWriteOnce
120+
capacity:
121+
storage: 1Gi
122+
claimRef:
123+
apiVersion: v1
124+
kind: PersistentVolumeClaim
125+
name: example-vanilla-block-pvc
126+
namespace: default
127+
resourceVersion: "194677"
128+
uid: a7b7e3ba-f837-45ba-b243-dec7d8aaed53
129+
csi:
130+
driver: csi.example.driver.com
131+
fsType: ext4
132+
volumeAttributes:
133+
storage.kubernetes.io/csiProvisionerIdentity: 1637110610497-8081-csi.example.driver.com
134+
type: CNS Block Volume
135+
volumeHandle: 2dacf297-803f-4ccc-afc7-3d3c3f02051e
136+
persistentVolumeReclaimPolicy: Delete
137+
storageClassName: example-vanilla-block-sc
138+
volumeMode: Filesystem
139+
status:
140+
phase: Bound
141+
```
142+
143+
<!--
144+
The [finalizer](/docs/concepts/overview/working-with-objects/finalizers/) prevents this
145+
PersistentVolume from being removed from the
146+
cluster. As stated previously, the finalizer is only removed from the PV object
147+
after it is successfully deleted from the storage backend. To learn more about
148+
finalizers, please refer to [Using Finalizers to Control Deletion](/blog/2021/05/14/using-finalizers-to-control-deletion/).
149+
150+
Similarly, the finalizer `kubernetes.io/pv-controller` is added to dynamically provisioned in-tree plugin volumes.
151+
-->
152+
[Finalizer](/zh-cn/docs/concepts/overview/working-with-objects/finalizers/)
153+
防止此 PersistentVolume 从集群中被移除。如前文所述，Finalizer 仅在从存储后端被成功删除后才会从
154+
PV 对象中被移除。进一步了解 Finalizer，
155+
请参阅[使用 Finalizer 控制删除](/blog/2021/05/14/using-finalizers-to-control-deletion/)。
156+
157+
同样，Finalizer `kubernetes.io/pv-controller` 也被添加到动态制备的树内插件卷中。
158+
159+
<!--
160+
### Important note
161+
162+
The fix does not apply to statically provisioned in-tree plugin volumes.
163+
-->
164+
### 重要提示
165+
166+
此修复不适用于静态制备的内置插件卷。
167+
168+
<!--
169+
## How to enable new behavior?
170+
171+
To take advantage of the new behavior, you must have upgraded your cluster to the v1.33 release of Kubernetes
172+
and run the CSI [`external-provisioner`](https://github.com/kubernetes-csi/external-provisioner) version `5.0.1` or later.
173+
The feature was released as beta in v1.31 release of Kubernetes, where it was enabled by default.
174+
-->
175+
## 如何启用新行为？
176+
177+
要利用新行为，你必须将集群升级到 Kubernetes 的 v1.33 版本，
178+
并运行 CSI [`external-provisioner`](https://github.com/kubernetes-csi/external-provisioner)
179+
5.0.1 或更新版本。
180+
此特性在 Kubernetes 的 v1.31 版本中作为 Beta 版发布，并且默认启用。
181+
182+
<!--
183+
## References
184+
185+
* [KEP-2644](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2644-honor-pv-reclaim-policy)
186+
* [Volume leak issue](https://github.com/kubernetes-csi/external-provisioner/issues/546)
187+
* [Beta Release Blog](/blog/2024/08/16/kubernetes-1-31-prevent-persistentvolume-leaks-when-deleting-out-of-order/)
188+
-->
189+
## 参考
190+
191+
* [KEP-2644](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2644-honor-pv-reclaim-policy)
192+
* [卷泄漏问题](https://github.com/kubernetes-csi/external-provisioner/issues/546)
193+
* [Beta 版发布博客](/zh-cn/blog/2024/08/16/kubernetes-1-31-prevent-persistentvolume-leaks-when-deleting-out-of-order/)
194+
195+
<!--
196+
## How do I get involved?
197+
198+
The Kubernetes Slack channel [SIG Storage communication channels](https://github.com/kubernetes/community/blob/master/sig-storage/README.md#contact) are great mediums to reach out to the SIG Storage and migration working group teams.
199+
200+
Special thanks to the following people for the insightful reviews, thorough consideration and valuable contribution:
201+
-->
202+
## 如何参与？
203+
204+
Kubernetes Slack 频道
205+
[SIG Storage 交流渠道](https://github.com/kubernetes/community/blob/master/sig-storage/README.md#contact)是接触
206+
SIG Storage 和迁移工作组团队的绝佳方式。
207+
208+
特别感谢以下人员的深入审查、细致考虑和宝贵贡献：
209+
210+
* Fan Baofa (carlory)
211+
* Jan Šafránek (jsafrane)
212+
* Xing Yang (xing-yang)
213+
* Matthew Wong (wongma7)
214+
215+
<!--
216+
Join the [Kubernetes Storage Special Interest Group (SIG)](https://github.com/kubernetes/community/tree/master/sig-storage) if you're interested in getting involved with the design and development of CSI or any part of the Kubernetes Storage system. We’re rapidly growing and always welcome new contributors.
217+
-->
218+
如果你对 CSI 或 Kubernetes 存储系统的任何部分的设计和开发感兴趣，
219+
可以加入 [Kubernetes 存储特别兴趣小组（SIG）](https://github.com/kubernetes/community/tree/master/sig-storage)。
220+
我们正在迅速成长，并且总是欢迎新的贡献者。

0 commit comments

Comments
 (0)