-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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.
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
fix inconsistency in documentation of default storageclass #48200
base: main
Are you sure you want to change the base?
fix inconsistency in documentation of default storageclass #48200
Conversation
The committers listed above are authorized under a signed CLA. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Welcome @iheartNathan! |
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
Description
fixes this issue
Issue
Closes: #42288