-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
Proposal for adding PVC info to VolumeStats #930
Proposal for adding PVC info to VolumeStats #930
Conversation
Flushes out details for part 1 of the changes described in #855 Feature: kubernetes/enhancements#363
Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please follow instructions at https://github.com/kubernetes/kubernetes/wiki/CLA-FAQ to sign the CLA. It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.
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. |
@jingxu97 please review - thanks! |
/cc @jingxu97 |
- The limitation of this approach is that we're limited to reporting only what is available in the pod spec (Pod namespace and PVC claimname) | ||
|
||
### Option 2 | ||
- Modify the ```volumemanager::GetMountedVolumesForPod()``` (or add a new function) to return additional volume information from the ASOW/DSOW caches |
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.
Could you use actual and desired state instead of ASOW/DSOW?
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.
@jingxu97 - addressed.
``` | ||
|
||
## Implementation | ||
2 options are described below. Option 1 supports current requirements/requested use cases. Option 2 supports an additional use case that was being discussed and is called out for completeness/discussion/feedback. |
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.
Agree use case of getting metrics by PV name is iffy, it could be left as the responsibility of the higher-level tool (heapster?) to do that, since it should be trivial for them to find the PVC to which PV is bound.
If not option 2 sounds good to me, the PV name is right there in volume spec, it just needs to be plumbed through GetMountedVolumesForPod.
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.
PV name is not available in volume spec, I think. We have to retrieve through API server to get the PVC object first to get PV name, I think?
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.
from asw.attachedVolumes we can check attachedVolume.spec.PersistentVolume (attachedVolume.spec is volume.Spec https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/plugins.go#L277), so option #2 is possible w/o API call
so I think we have "option #1 + API get
" or "option #2" if we want metrics indexed by PV name. I prefer option #2
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.
Agreed - given that we're already populating these caches via API calls - option #2 would be preferred rather than adding API calls in the volume stats collector.
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.
you are right, I got confused. @vkamra I think we could add a separate function to get a list of PV name indexed by outerVolumeSpecName similarly to ListVolumesForPod. Then we can add the PV name information 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.
👍 - that's what I have in option 2. We should do that incrementally though if we need to return PV. For now, PVC seems good enough.
Do we care about exposing these metrics via prometheus? Is there any other case where we expose the same metrics via kubelet summary API and via prometheus directly, or is that unwanted duplication? I am not too familiar with the metrics stack. |
- This allows us to get information not available in the Pod spec such as the PV name/UID which can be used to label metrics - enables exposing/querying volume metrics by PV name | ||
- It's unclear whether this is a use case we need to/should support: | ||
* Volume metrics are only refreshed for mounted volumes which implies a bound/available PVC | ||
* We expect most user-storage interactions to be via the PVC |
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.
One use-case to call out is admins monitoring PVs so that they know when their users are running out of space and they can immediately find the PV's backing storage to resize
I see, thanks. I would like to see that for 1.8, do you plan to implement it too? Else I can have a try after your PR merges, though I'm not sure where to register those prometheus metrics tbh :) |
I've looked at it but haven't had a chance to work on it for 1.8 Prometheus metrics are registered in https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/metrics/metrics.go. After registering them there, we could observe/update those in |
/lgtm |
Automatic merge from submit-queue |
Automatic merge from submit-queue Expose PVC metrics via kubelet prometheus This depends on #51448, opening early though. second commit is mine and mostly a copy/paste job. implements metrics listed in here kubernetes/community#855 following method here kubernetes/community#930 (comment) **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: kubernetes/enhancements#363 **Special notes for your reviewer**: **Release note**: ```release-note PersistentVolumeClaim metrics like "volume_stats_inodes" and "volume_stats_capacity_bytes" are now reported via kubelet prometheus ```
Automatic merge from submit-queue Proposal for adding PVC info to VolumeStats Flushes out details for part 1 of the changes described in [kubernetes#855](kubernetes#855) Feature: [kubernetes#363](kubernetes/enhancements#363)
Flushes out details for part 1 of the changes described in
#855
Feature: #363