-
Notifications
You must be signed in to change notification settings - Fork 40.1k
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
Pass pod metadata to flex plugin #39488
Conversation
cc @kubernetes/sig-storage-misc @childsb |
Pending the build + test failures this seems legit. I'm goign to ask @chakri-nelluri to review. |
@childsb @chakri-nelluri any feedback? |
@childsb @chakri-nelluri friendly ping |
@liggitt changes to support attach/detach in flex volume went in today. PTAL. |
Automatic merge from submit-queue Reserve kubernetes.io and k8s.io namespace for flex volume options Split from #39488. Flex volume already stuffs system information into the options map, and assumes it is free to do so: ``` optionFSType = "kubernetes.io/fsType" optionReadWrite = "kubernetes.io/readwrite" optionKeySecret = "kubernetes.io/secret" ``` this formalizes that by reserving the `kubernetes.io` and `k8s.io` namespaces so that user-specified options are never stomped by the system, and flex plugins can know that options with those namespaces came from the system, not user-options. ```release-note Parameter keys in a StorageClass `parameters` map may not use the `kubernetes.io` or `k8s.io` namespaces. ```
@liggitt is this ready for review now? |
extraOptions[optionKeyPodNamespace] = f.podNamespace | ||
extraOptions[optionKeyPodUID] = string(f.podUID) | ||
// service account metadata | ||
extraOptions[optionKeyServiceAccountName] = f.podServiceAccountName |
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 have not studied this pr closely but am curious about what if in addition to, or instead of a service-account, a pod defines a securityContext? Does that need to be stored here?
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.
fsGroup is already passed in. I'm not sure what else a flexvolume plugin would want/need, but my primary interest is enabling flex volumes to inject pod identity types of things, for which we'd want pod name, namespace, uid, and possibly service account name.
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.
For now, volume drivers don't use service account (though in the future they could). But if we pass service account, should we also pass the secret too?
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.
if we pass service account, should we also pass the secret too?
No, the point is not to let the volume plugin act as the service account, it is to inform the volume plugin which service account the pod is using. Think of a vault plugin that injects credentials from vault for that service account.
Yes |
Interface changes in flexVolume in 1.6 broke several of our home-grown plugins because the volume name must be computed ahead of attach time and our plugin can't do that with little information. We use flexVolume for creating database LVM snapshots for development, creating scratch space from LVM thinpool, and we also use it to clone rbd snapshots for distributing code and data. These plugins can be patched to work by adding unique volume name in flexvolume.options but that is very limiting, and don't support deployment where multiple pods can run on the same node. This PR addresses the challenge by providing pod uid, name, namespace in the options, so the volume name can be derived. |
Review status: 0 of 5 files reviewed at latest revision, 2 unresolved discussions, some commit checks failed. pkg/volume/flexvolume/mounter.go, line 69 at r1 (raw file):
Thanks @liggitt Comments from Reviewable |
@k8s-bot kops aws e2e test this |
I'm specifically interested in this for prototyping flexvolume plugins to inject pod identity. I'm less familiar with the way flexvolume interacts with PV and attach/detach, so I'd rather let someone else add that if it makes sense. |
rebased, retagging |
Yeah I think this can stand on its own - it makes flex volumes more useful for the work sig-auth needs to prototype. |
@k8s-bot kops aws e2e test this |
tagging @chakri-nelluri @saad-ali @MikaelCluseau for approval |
Ok. Sounds good to me. I will make those changes in subsequent PR. Review status: 0 of 5 files reviewed at latest revision, 2 unresolved discussions. Comments from Reviewable |
/lgtm Reviewed 3 of 5 files at r1, 2 of 2 files at r2. Comments from Reviewable |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: chakri-nelluri, liggitt
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
@chakri-nelluri: changing LGTM is restricted to assignees, and only kubernetes org members may be assigned issues. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Automatic merge from submit-queue |
Normal volume plugins get the pod spec to pull information from when setting up their volume, but flex plugins do not.
If a flex volume wants to set up things unique to the pod, or limited in permission based on the service account, the pod namespace, name, uid, and service account name are needed.
This PR adds pod uid, name, namespace, and service account name to the options passed to the plugin available during mounting