Improving readability and introducing type safety with external tools
like kubeval.
I needed to make change the import to an absolute one, but instead
rather removed the import to begin with, as we're getting rid of ksonnet
for most things now anyway.
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>
Sharding and autosharding introduced a number of manifests that are
very similar, but not identical to the standard manifests. This
introduces generating all manifests using jsonnet and moves them to
the explicit `/examples` directory.