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
The v1.25 release of Kubernetes introduced an alpha feature to change how a default StorageClass was assigned to a PersistentVolumeClaim (PVC).
11
-
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.
10
+
The v1.25 release of Kubernetes introduced an alpha feature to change how a default
11
+
StorageClass was assigned to a PersistentVolumeClaim (PVC). With the feature enabled,
12
+
you no longer need to create a default StorageClass first and PVC second to assign the
13
+
class. Additionally, any PVCs without a StorageClass assigned can be updated later.
12
14
This feature was graduated to beta in Kubernetes 1.26.
13
15
14
-
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,
16
+
You can read [retroactive default StorageClass assignment](/docs/concepts/storage/persistent-volumes/#retroactive-default-storageclass-assignment)
17
+
in the Kubernetes documentation for more details about how to use that,
15
18
or you can read on to learn about why the Kubernetes project is making this change.
16
19
17
20
## Why did StorageClass assignment need improvements
18
21
19
-
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).
22
+
Users might already be familiar with a similar feature that assigns default StorageClasses
23
+
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?
22
27
Users would end up with a PVC that would never be assigned a class.
@@ -29,33 +34,47 @@ Let's take a closer look at each of them.
29
34
With the alpha feature enabled, there were two options admins had when they wanted to change the default StorageClass:
30
35
31
36
1. Creating a new StorageClass as default before removing the old one associated with the PVC.
32
-
This would result in having two defaults for a short period.
33
-
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.
37
+
This would result in having two defaults for a short period.
38
+
At this point, if a user were to create a PersistentVolumeClaim with storageClassName set to
39
+
<code>null</code> (implying default StorageClass), the newest default StorageClass would be
40
+
chosen and assigned to this PVC.
34
41
35
42
2. Removing the old default first and creating a new default StorageClass.
36
-
This would result in having no default for a short time.
37
-
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.
38
-
The user would have to fix this by deleting the PVC and recreating it once the default StorageClass was available.
39
-
43
+
This would result in having no default for a short time.
44
+
Subsequently, if a user were to create a PersistentVolumeClaim with storageClassName
45
+
set to <code>null</code> (implying default StorageClass), the PVC would be in
46
+
<code>Pending</code> state forever. The user would have to fix this by deleting
47
+
the PVC and recreating it once the default StorageClass was available.
40
48
41
49
### Resource ordering during cluster installation
42
50
43
-
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.
44
-
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.
51
+
If a cluster installation tool needed to create resources that required storage,
52
+
for example, an image registry, it was difficult to get the ordering right.
53
+
This is because any Pods that required storage would rely on the presence of
54
+
a default StorageClass and would fail to be created if it wasn't defined.
45
55
46
56
## What changed
47
57
48
-
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>.
49
-
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.
58
+
We've changed the PersistentVolume (PV) controller to assign a default StorageClass
59
+
to any unbound PersistentVolumeClaim that has the storageClassName set to <code>null</code>.
60
+
We've also modified the PersistentVolumeClaim admission within the API server to allow
61
+
the change of values from an unset value to an actual StorageClass name.
50
62
51
63
### Null `storageClassName` versus `storageClassName: ""` - does it matter? { #null-vs-empty-string }
52
64
53
-
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>.
65
+
Before this feature was introduced, those values were equal in terms of behavior.
66
+
Any PersistentVolumeClaim with the storageClassName set to <code>null</code> or <code>""</code>
67
+
would bind to an existing PersistentVolume resource with storageClassName also set to
68
+
<code>null</code> or <code>""</code>.
54
69
55
70
With this new feature enabled we wanted to maintain this behavior but also be able to update the StorageClass name.
56
-
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.
71
+
With these constraints in mind, the feature changes the semantics of <code>null</code>.
72
+
If a default StorageClass is present, <code>null</code> would translate to "Give me a default" and
73
+
<code>""</code> would mean "Give me PersistentVolume that also has <code>""</code> StorageClass name."
74
+
In the absence of a StorageClass, the behavior would remain unchanged.
57
75
58
-
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.
76
+
Summarizing the above, we've changed the semantics of <code>null</code> so that
77
+
its behavior depends on the presence or absence of a definition of default StorageClass.
59
78
60
79
The tables below show all these cases to better describe when PVC binds and when its StorageClass gets updated.
61
80
@@ -96,7 +115,9 @@ The tables below show all these cases to better describe when PVC binds and when
96
115
97
116
## How to use it
98
117
99
-
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:
118
+
If you want to test the feature whilst it's alpha, you need to enable the relevant
119
+
feature gate in the kube-controller-manager and the kube-apiserver.
@@ -121,7 +142,9 @@ If you would like to see the feature in action and verify it works fine in your
121
142
storage: 1Gi
122
143
```
123
144
124
-
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.
145
+
2. Create the PersistentVolumeClaim when there is no default StorageClass.
146
+
The PVC won't provision or bind (unless there is an existing, suitable PV already present)
147
+
and will remain in <code>Pending</code> state.
125
148
126
149
```
127
150
$ kc get pvc
@@ -146,11 +169,15 @@ If you would like to see the feature in action and verify it works fine in your
146
169
147
170
### New metrics
148
171
149
-
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.
172
+
To help you see that the feature is working as expected we also introduced a new
173
+
<code>retroactive_storageclass_total</code> metric to show how many times that the
174
+
PV controller attempted to update PersistentVolumeClaim, and
175
+
<code>retroactive_storageclass_errors_total</code> to show how many of those attempts failed.
150
176
151
177
## Getting involved
152
178
153
-
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).
179
+
We always welcome new contributors so if you would like to get involved you can
The Kubernetes project runs a community-owned image registry called `registry.k8s.io` to host its container images. On the 3rd of April 2023, the old registry `k8s.gcr.io` will be frozen and no further images for Kubernetes and related subprojects will be pushed to the old registry.
10
+
The Kubernetes project runs a community-owned image registry called `registry.k8s.io`
11
+
to host its container images. On the 3rd of April 2023, the old registry `k8s.gcr.io`
12
+
will be frozen and no further images for Kubernetes and related subprojects will be
13
+
pushed to the old registry.
11
14
12
-
This registry `registry.k8s.io` replaced the old one and has been generally available for several months. We have published a [blog post](/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/) about its benefits to the community and the Kubernetes project. This post also announced that future versions of Kubernetes will not be available in the old registry. Now that time has come.
15
+
This registry `registry.k8s.io` replaced the old one and has been generally available
16
+
for several months. We have published a [blog post](/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/)
17
+
about its benefits to the community and the Kubernetes project. This post also
18
+
announced that future versions of Kubernetes will not be available in the old
19
+
registry. Now that time has come.
13
20
14
21
What does this change mean for contributors:
15
-
- If you are a maintainer of a subproject, you will need to update your manifests and Helm charts to use the new registry.
22
+
23
+
- If you are a maintainer of a subproject, you will need to update your manifests
24
+
and Helm charts to use the new registry.
16
25
17
26
What does this change mean for end users:
27
+
18
28
- 1.27 Kubernetes release will not be published to the old registry.
19
-
- Patch releases for 1.24, 1.25, and 1.26 will no longer be published to the old registry from April. Please read the timelines below for details of the final patch releases in the old registry.
20
-
- Starting in 1.25, the default image registry has been set to `registry.k8s.io`. This value is overridable in `kubeadm` and `kubelet` but setting it to `k8s.gcr.io` will fail for new releases after April as they won’t be present in the old registry.
21
-
- If you want to increase the reliability of your cluster and remove dependency on the community-owned registry or you are running Kubernetes in networks where external traffic is restricted, you should consider hosting local image registry mirrors. Some cloud vendors may offer hosted solutions for this.
29
+
- Patch releases for 1.24, 1.25, and 1.26 will no longer be published to the old
30
+
registry from April. Please read the timelines below for details of the final
31
+
patch releases in the old registry.
32
+
- Starting in 1.25, the default image registry has been set to `registry.k8s.io`.
33
+
This value is overridable in `kubeadm` and `kubelet` but setting it to `k8s.gcr.io`
34
+
will fail for new releases after April as they won’t be present in the old registry.
35
+
- If you want to increase the reliability of your cluster and remove dependency on
36
+
the community-owned registry or you are running Kubernetes in networks where
37
+
external traffic is restricted, you should consider hosting local image registry
38
+
mirrors. Some cloud vendors may offer hosted solutions for this.
22
39
23
40
## Timeline of the changes
24
41
@@ -31,8 +48,8 @@ What does this change mean for end users:
31
48
32
49
## What's next
33
50
34
-
Please make sure your cluster does not have dependencies on old image registry. For example, you can run this command to list the images used by pods:
35
-
51
+
Please make sure your cluster does not have dependencies on old image registry.
52
+
For example, you can run this command to list the images used by pods:
36
53
37
54
```shell
38
55
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"|\
@@ -41,10 +58,22 @@ sort |\
41
58
uniq -c
42
59
```
43
60
44
-
There may be other dependencies on the old image registry. Make sure you review any potential dependencies to keep your cluster healthy and up to date.
61
+
There may be other dependencies on the old image registry. Make sure you review
62
+
any potential dependencies to keep your cluster healthy and up to date.
45
63
46
64
## Acknowledgments
47
65
48
-
__Change is hard__, and evolving our image-serving platform is needed to ensure a sustainable future for the project. We strive to make things better for everyone using Kubernetes. Many contributors from all corners of our community have been working long and hard to ensure we are making the best decisions possible, executing plans, and doing our best to communicate those plans.
66
+
__Change is hard__, and evolving our image-serving platform is needed to ensure
67
+
a sustainable future for the project. We strive to make things better for everyone
68
+
using Kubernetes. Many contributors from all corners of our community have been
69
+
working long and hard to ensure we are making the best decisions possible,
70
+
executing plans, and doing our best to communicate those plans.
49
71
50
-
Thanks to Aaron Crickenberger, Arnaud Meukam, Benjamin Elder, Caleb Woodbine, Davanum Srinivas, Mahamed Ali, and Tim Hockin from SIG K8s Infra, Brian McQueen, and Sergey Kanzhelev from SIG Node, Lubomir Ivanov from SIG Cluster Lifecycle, Adolfo García Veytia, Jeremy Rickard, Sascha Grunert, and Stephen Augustus from SIG Release, Bob Killen and Kaslin Fields from SIG Contribex, Tim Allclair from the Security Response Committee. Also a big thank you to our friends acting as liaisons with our cloud provider partners: Jay Pipes from Amazon and Jon Johnson Jr. from Google.
72
+
Thanks to Aaron Crickenberger, Arnaud Meukam, Benjamin Elder, Caleb Woodbine,
73
+
Davanum Srinivas, Mahamed Ali, and Tim Hockin from SIG K8s Infra, Brian McQueen,
74
+
and Sergey Kanzhelev from SIG Node, Lubomir Ivanov from SIG Cluster Lifecycle,
75
+
Adolfo García Veytia, Jeremy Rickard, Sascha Grunert, and Stephen Augustus from
76
+
SIG Release, Bob Killen and Kaslin Fields from SIG Contribex, Tim Allclair from
77
+
the Security Response Committee. Also a big thank you to our friends acting as
78
+
liaisons with our cloud provider partners: Jay Pipes from Amazon and Jon Johnson
0 commit comments