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.

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

Merged
merged 3 commits into from
Aug 30, 2017
Merged

Proposal for adding PVC info to VolumeStats #930

merged 3 commits into from
Aug 30, 2017

Conversation

vkamra
Copy link
Contributor

@vkamra vkamra commented Aug 17, 2017

Flushes out details for part 1 of the changes described in
#855

Feature: #363

Flushes out details for part 1 of the changes described in
#855

Feature: kubernetes/enhancements#363
@k8s-ci-robot
Copy link
Contributor

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.


  • If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
  • If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.
  • If you have done the above and are still having issues with the CLA being reported as unsigned, please email the CNCF helpdesk: [email protected]

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.

@k8s-ci-robot k8s-ci-robot added the cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. label Aug 17, 2017
@k8s-github-robot k8s-github-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Aug 17, 2017
@vkamra vkamra closed this Aug 17, 2017
@vkamra vkamra reopened this Aug 17, 2017
@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. and removed cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Aug 17, 2017
@vkamra
Copy link
Contributor Author

vkamra commented Aug 17, 2017

@jingxu97 please review - thanks!

@vkamra
Copy link
Contributor Author

vkamra commented Aug 17, 2017

/cc @jingxu97

@k8s-ci-robot k8s-ci-robot requested a review from jingxu97 August 17, 2017 07:16
- 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
Copy link
Contributor

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?

Copy link
Contributor Author

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.
Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

@wongma7
Copy link
Contributor

wongma7 commented Aug 28, 2017

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
Copy link
Contributor

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

@vkamra
Copy link
Contributor Author

vkamra commented Aug 28, 2017

@wongma7 - we should expose these metrics via prometheus (/metrics API) as well. @jingxu97 details that in #855.

This proposal (and corresponding implementation PR) just gets PVC information into the volume stats.

@wongma7
Copy link
Contributor

wongma7 commented Aug 28, 2017

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 :)

@vkamra
Copy link
Contributor Author

vkamra commented Aug 28, 2017

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 volume_stat_calculator::calcAndStoreStats()

@childsb
Copy link
Contributor

childsb commented Aug 30, 2017

This is for 1.8, correct?

@vkamra i believe the only outstanding change is @wongma7 use case mentioned then we are good to merge.

@vkamra
Copy link
Contributor Author

vkamra commented Aug 30, 2017

@childsb - yes, for 1.8. Updated with the use case - should be good to go. The corresponding implementation of this is in PR 51448 also ready to be merged

@childsb
Copy link
Contributor

childsb commented Aug 30, 2017

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 30, 2017
@k8s-github-robot
Copy link

Automatic merge from submit-queue

@k8s-github-robot k8s-github-robot merged commit f6399e1 into kubernetes:master Aug 30, 2017
k8s-github-robot pushed a commit to kubernetes/kubernetes that referenced this pull request Sep 3, 2017
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
```
@julio-lopez julio-lopez deleted the pvcname_in_volstats branch September 9, 2019 19:36
MadhavJivrajani pushed a commit to MadhavJivrajani/community that referenced this pull request Nov 30, 2021
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants