Tweak line wrappings in 2 blogs: 0105 and 0206
Michael
parent
ec44c06627
commit
dfcad138f2
|
|
@ -7,16 +7,21 @@ slug: retroactive-default-storage-class
|
|||
|
||||
**Author:** Roman Bednář (Red Hat)
|
||||
|
||||
The v1.25 release of Kubernetes introduced an alpha feature to change how a default StorageClass was assigned to a PersistentVolumeClaim (PVC).
|
||||
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.
|
||||
The v1.25 release of Kubernetes introduced an alpha feature to change how a default
|
||||
StorageClass was assigned to a PersistentVolumeClaim (PVC). 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.
|
||||
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,
|
||||
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,
|
||||
or you can read on to learn about why the Kubernetes project is making this change.
|
||||
|
||||
## Why did StorageClass assignment need improvements
|
||||
|
||||
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).
|
||||
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).
|
||||
|
||||
But what if there wasn't a default StorageClass defined at the time of PVC creation?
|
||||
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.
|
|||
With the alpha feature enabled, there were two options admins had when they wanted to change the default StorageClass:
|
||||
|
||||
1. Creating a new StorageClass as default before removing the old one associated with the PVC.
|
||||
This would result in having two defaults for a short period.
|
||||
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.
|
||||
This would result in having two defaults for a short period.
|
||||
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.
|
||||
|
||||
2. Removing the old default first and creating a new default StorageClass.
|
||||
This would result in having no default for a short time.
|
||||
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.
|
||||
The user would have to fix this by deleting the PVC and recreating it once the default StorageClass was available.
|
||||
|
||||
This would result in having no default for a short time.
|
||||
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. The user would have to fix this by deleting
|
||||
the PVC and recreating it once the default StorageClass was available.
|
||||
|
||||
### Resource ordering during cluster installation
|
||||
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
|
||||
## What changed
|
||||
|
||||
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>.
|
||||
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.
|
||||
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>.
|
||||
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.
|
||||
|
||||
### Null `storageClassName` versus `storageClassName: ""` - does it matter? { #null-vs-empty-string }
|
||||
|
||||
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>.
|
||||
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>.
|
||||
|
||||
With this new feature enabled we wanted to maintain this behavior but also be able to update the StorageClass name.
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
The tables below show all these cases to better describe when PVC binds and when its StorageClass gets updated.
|
||||
|
||||
|
|
@ -96,7 +115,9 @@ The tables below show all these cases to better describe when PVC binds and when
|
|||
|
||||
## How to use it
|
||||
|
||||
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:
|
||||
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:
|
||||
|
||||
```
|
||||
--feature-gates="...,RetroactiveDefaultStorageClass=true"
|
||||
|
|
@ -121,7 +142,9 @@ If you would like to see the feature in action and verify it works fine in your
|
|||
storage: 1Gi
|
||||
```
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
```
|
||||
$ kc get pvc
|
||||
|
|
@ -146,11 +169,15 @@ If you would like to see the feature in action and verify it works fine in your
|
|||
|
||||
### New metrics
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
## Getting involved
|
||||
|
||||
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).
|
||||
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).
|
||||
|
||||
If you would like to share feedback, you can do so on our [public Slack channel](https://app.slack.com/client/T09NY5SBT/C09QZFCE5).
|
||||
|
||||
|
|
|
|||
|
|
@ -7,18 +7,35 @@ slug: k8s-gcr-io-freeze-announcement
|
|||
|
||||
**Authors**: Mahamed Ali (Rackspace Technology)
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
What does this change mean for contributors:
|
||||
- If you are a maintainer of a subproject, you will need to update your manifests and Helm charts to use the new registry.
|
||||
|
||||
- If you are a maintainer of a subproject, you will need to update your manifests
|
||||
and Helm charts to use the new registry.
|
||||
|
||||
What does this change mean for end users:
|
||||
|
||||
- 1.27 Kubernetes release will not be published to the old registry.
|
||||
- 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.
|
||||
- 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.
|
||||
- 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.
|
||||
- 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.
|
||||
- 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.
|
||||
- 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.
|
||||
|
||||
## Timeline of the changes
|
||||
|
||||
|
|
@ -31,8 +48,8 @@ What does this change mean for end users:
|
|||
|
||||
## What's next
|
||||
|
||||
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:
|
||||
|
||||
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:
|
||||
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
|
||||
|
|
@ -41,10 +58,22 @@ sort |\
|
|||
uniq -c
|
||||
```
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
## Acknowledgments
|
||||
|
||||
__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.
|
||||
__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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
|
|
|||
Loading…
Reference in New Issue