add VolumeAttachment collector #946
Conversation
|
Welcome @JensErat! |
k8s-ci-robot
added
cncf-cla: yes
docs/volumeattachment-metrics.md
Outdated
|
|
||
| | Metric name| Metric type | Labels/tags | Status | | ||
| | ---------- | ----------- | ----------- | ----------- | | ||
| | kube_volumeattachment_info | Gauge | `volumeattachment`=<volumeattachment-name> <br> `attacher`=<attacher-name> <br> `nodeName`=<node-name> | STABLE | |
There was a problem hiding this comment.
These metrics should be EXPERIMENTAL
There was a problem hiding this comment.
I'll switch to EXPERIMENTAL; just to understand the semantics better: I thought it was about stability of the Kubernetes API, or is it also about "being new to kube-state-metrics"?
| @@ -34,6 +34,7 @@ import ( | |||
| extensions "k8s.io/api/extensions/v1beta1" | |||
| policy "k8s.io/api/policy/v1beta1" | |||
| storagev1 "k8s.io/api/storage/v1" | |||
| storagev1beta1 "k8s.io/api/storage/v1beta1" | |||
There was a problem hiding this comment.
I think we can use storagev1 for VolumeAttachment. It has been promoted to v1 since 1.13 if I am not mistaken.
There was a problem hiding this comment.
It should even support the watching and listing of VolumeAttachments created under v1beta1
There was a problem hiding this comment.
Yes, it graduated to GA in 1.13 (as also stated in the PR). I started with storagev1 originally, but it failed in a Kubernetes 1.14 cluster -- kube-state-metrics got v1beta1 objects returned and paniced.
On the other hand, following the compatibility chart from the README we need to support Kubernetes 1.11? In this case, only storagev1beta1 is available.
JensErat
force-pushed
the
jenserat/volumeattachments
branch
from
427aad4
to
eafef8a
Compare
Kubernetes has a new resource type: `VolumeAttachments`. They provide helpful information on where a volume is attached and to alert on unexpected attachment status (for example, differences between information scraped from node-exporter and kube-state-metrics). The collector adds a bunch of new metrics. Each VolumeAttachment (ie., each CSI-attached volume) will have one of each, so we do not overly pollute the metrics space. Most metrics are rather unsurprising. - `kube_volumeattachment_status_attachment_metadata`: provides a label-like export of the attachment metadata map. Generalizing the label-conversion function slightly helps at providing this metric. - `kube_volumeattachment_created`: as VolumeAttachments are automatically created and we already suffered from duplicate `VolumeAttachments`, this can be invaluable for debugging misattachments. - `kube_volumeattachment_spec_source_persistentvolume`: will only be generated when the volume source is of `PersistentVolume` type. The other type `inlineVolumeSpec` is still alpha-level and hard to map to metrics. No end-to-end test manifest was added, as `VolumeAttachment`s are automatically generated when mounting volumes. Signed-off-by: Jens Erat <email@jenserat.de>
JensErat
force-pushed
the
jenserat/volumeattachments
branch
from
eafef8a
to
4e63785
Compare
|
Fixed documentation ( As already mentioned, I'm not sure about going to storage/v1; it didn't work out for me against Kubernetes 1.14 and kube-state-metrics even wants to support Kubernetes 1.11 (or 1.12 with the next release) as I understand, and those generally only support storage/v1beta1 for |
k8s-ci-robot
added
the
do-not-merge/hold
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: JensErat, tariq1890 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
|
lgtm /hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
What this PR does / why we need it:
Kubernetes has a new resource type:
VolumeAttachments. They provide helpful information on where a volume is attached and to alert on unexpected attachment status (for example, differences between information scraped from node-exporter and kube-state-metrics).The collector adds a bunch of new metrics. Each VolumeAttachment (ie., each CSI-attached volume) will have one of each, so we do not overly pollute the metrics space. Most metrics are rather unsurprising.
kube_volumeattachment_status_attachment_metadata: provides a label-like export of the attachment metadata map. Generalizing the label-conversion function slightly helps at providing this metric.kube_volumeattachment_created: as VolumeAttachments are automatically created and we already suffered from duplicateVolumeAttachments, this can be invaluable for debuggingmisattachments.
kube_volumeattachment_spec_source_persistentvolume: will only be generated when the volume source is ofPersistentVolumetype. The other typeinlineVolumeSpecis still alpha-level and hard to map to metrics.No end-to-end test manifest was added, as
VolumeAttachments are automatically generated when mounting volumes.Since kube-state-metrics 1.8.0 wants to support Kubernetes 1.11 onwards, I went for storagev1beta1; the API is GA since Kubernetes 1.13 ( so still some time to go, now matter what version this gets released under).
Important note: I'm on vacation soon. My coworker @sbueringer will take over regarding any issues as soon as I'm gone.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #872 -- mostly follows the ideas discussed in this feature request; I had to deviate in some metrics to follow the other collectors and also properly take specifics of
VolumeAttachments into account.