Improved matching of HelmRelease with native workloads, more details based on KSM labels

[marians]

Problem

Duplication of info in the deployments overview

Currently we fail to match some deployments (or statefulsets, daemonsets) in the deployments overview to the HelmRelease item that manages them.

This example shows a Deployment that should actually not be shown, as we show the "parent" HelmRelease:

Lack of details for metrics-based deployment items

Currently we cannot show a version for workloads discovered via metrics. Example:

Solution

We should configure hube-state-metrics to provide more labels via the kube_*_labels metrics, so we can match a resource directly to the responsible HelmRelease.

The Deployment shown in the example above has the following labels:

    app: team-stamper
    app.kubernetes.io/instance: flux-giantswarm-team-stamper
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: team-stamper
    app.kubernetes.io/version: 0.0.0-f011e3b5a8a7ee8ef24375f87d22ff3c721aa553
    application.giantswarm.io/branch: 0-0-0-f011e3b5a8a7ee8ef24375f87d22ff3c721aa553
    application.giantswarm.io/commit: 0.0.0-f011e3b5a8a7ee8ef24375f87d22ff3c721aa553
    application.giantswarm.io/team: honeybadger
    helm.sh/chart: team-stamper-0.0.0-f011e3b5a8a7ee8ef24375f87d22ff3c721aa553_a4e
    helm.toolkit.fluxcd.io/name: team-stamper
    helm.toolkit.fluxcd.io/namespace: flux-giantswarm

We may update the kube-state-metrics configuration to include more labels.

• app.kubernetes.io/version to populate the version column
• helm.toolkit.fluxcd.io/name to match the workload to the HelmRelease
• Do we also need helm.toolkit.fluxcd.io/namespace? We already know the namespace the workload resides in.

[marians]

@giantswarm/team-atlas Do you see any issues with enabling these 2 or 3 additional labels in kube-state-metrics in general?

[hervenicol]

How would these change cardinality? Would these labels change more often / independently of other currently existing labels?
It seems to me that the one adding cardinality would be app.kubernetes.io/version. But I expect it to be rather static; it should only change at app upgrades.

Do we have apps that change version at every commit? That could change, say, multiple times an hour? (the 0.0.0-[id] value is intriguing).
Except if you say app version changes continuously, this seems good to me.

[marians]

@hervenicol As you say, the version label is the one that has the most different values. It's the version tag we apply in our CI pipeline on every build and on release. So when a new version gets deployed, the label will have a different value. How often this happens depends on the application's release cycle.