Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix inconsistency in documentation of default storageclass #48200

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix inconsistency in documentation of default storageclass #48200

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions content/en/docs/reference/access-authn-authz/admission-controllers.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -200,9 +200,9 @@ and automatically adds a default storage class to them.
This way, users that do not request any special storage class do not need to care about them at all and they
will get the default one.

This admission controller does not do anything when no default storage class is configured. When more than one storage
class is marked as default, it rejects any creation of `PersistentVolumeClaim` with an error and an administrator
must revisit their `StorageClass` objects and mark only one as default.
This admission controller does nothing when no default `StorageClass` exists. When more than one storage
class is marked as default, and you then create a PersistentVolumeClaim with no storageClassName set,
Kubernetes uses the most recently created default StorageClass.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure this revision is correct.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the behaviour I experienced when I tested on a cluster.
This is expected behaviour mentioned here - https://kubernetes.io/docs/concepts/storage/persistent-volumes/#class-1

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By design, storage classes are referenced by a PVC which is dynamically provisioned. If a PVC is not dynamically provisioned, a user don't need to care about storageClassName, right?

When documenting a feature, please make sure you understand the use case(s) and what
you write here will not cause further confusion.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think a PVC is what's dynamically provisioned, what's dynamically provisioned is a PV from a storageclass by a PVC.
A storageclass may or may not be referenced by a PVC, if it does reference a storageclass a PV is created from the referenced storageclass, if it doesn't it uses a default storageclass to dynamically provision the PV.
If there are more than one default storageclass , and there is no storageclass referenced by the PVC, the PVC uses the more recently created default stroageclass to dynamically provision the PV (this is made possible by the mutating admission controller - DefaultStorageClass)
This is also documented here - https://kubernetes.io/docs/concepts/storage/storage-classes/#default-storageclass

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A storageclass may or may not be referenced by a PVC, if it does reference a storageclass a PV is created from the referenced storageclass, if it doesn't it uses a default storageclass to dynamically provision the PV.

The point here that not all PV are dynamically provisioned. A PVC which does not reference any StorageClass still has to be dynamically provisioned? I don't believe so.

This admission controller ignores any `PersistentVolumeClaim` updates; it acts only on creation.

See [persistent volume](/docs/concepts/storage/persistent-volumes/) documentation about persistent volume claims and
Expand Down