Support populating containerd labels with pod's metadata->labels?

[shapirus]

Currently, only a few hardcoded labels make it into the containerd container labels section, for example:

# ctr --address /run/containerd/containerd.sock -n k8s.io containers info e4d35794a41cb3998eef8b0cec0d233a64b021582fabee90885ef0aaaa767ebd
{
    "ID": "e4d35794a41cb3998eef8b0cec0d233a64b021582fabee90885ef0aaaa767ebd",
    "Labels": {
        "io.cri-containerd.kind": "container",
        "io.kubernetes.container.name": "xxxxx",
        "io.kubernetes.pod.name": "xxxxx-5658cff946-lkwdx",
        "io.kubernetes.pod.namespace": "yyyyy",
        "io.kubernetes.pod.uid": "c4d0196a-2d04-4841-917c-5f4aaaabe9b9"
    },

It makes it impossible to read custom labels defined in pod's metadata->labels for using them in metrics collection, for example, cadvisor, which has a bunch of related issues open: https://github.com/google/cadvisor/issues?q=is%3Aissue%20state%3Aopen%20in%3Atitle%20label%20

These labels are apparently hardcoded in https://github.com/kubernetes/kubelet/blob/master/pkg/types/labels.go

Would it be feasible to extend it to automatically add whatever is available in the metadata labels section?

[shapirus]

There is also some inconsistency.

Sometimes kubelet (if I am not mistaken in that it's done by kubelet) does populate those labels!

But it happens in one case and one case only: for the pause hidden container.

Example:

{
    "ID": "b44cc87cd486d68b3ce6859acb2a7f14fcb3b9cc9135977beb1cbb7c6da84ea6",
    "Labels": {
        "controller-revision-hash": "66b865f48",
        "grafana-agent": "grafana-agent",
        "io.cri-containerd.kind": "sandbox",
        "io.kubernetes.pod.name": "grafana-agent-55l6x",
        "io.kubernetes.pod.namespace": "monitoring",
        "io.kubernetes.pod.uid": "1a9ca378-76fb-4c37-93a1-f648f2acbaad",
        "pod-template-generation": "9"
    },
    "Image": "registry.k8s.io/pause@sha256:7031c1b283388d2c2e09b57badb803c05ebed362dc88d84b480cc47f72a21097",

Note how the controller-revision-hash, pod-template-generation and grafana-agent labels successfuly made it there.

But other containers from the same pod do not have them, e.g.

{
    "ID": "4845e707e948dc19b5bb469224bcfdeea38f8a6b33a289a1153b5caea3ce0613",
    "Labels": {
        "io.cri-containerd.kind": "container",
        "io.kubernetes.container.name": "grafana-agent",
        "io.kubernetes.pod.name": "grafana-agent-55l6x",
        "io.kubernetes.pod.namespace": "monitoring",
        "io.kubernetes.pod.uid": "1a9ca378-76fb-4c37-93a1-f648f2acbaad",
        "org.opencontainers.image.ref.name": "ubuntu",
        "org.opencontainers.image.source": "https://github.com/grafana/agent",
        "org.opencontainers.image.version": "23.04"
    },
    "Image": "docker.io/grafana/agent:v0.36.2",

(also note how this one has io.kubernetes.pod.name set, unlike the pause container.)

I think all the containers deserve to have all pod labels, not just the pause container, unless there is a valid important reason why it was implemented like this.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[shapirus]

/remove-lifecycle stale

besides, this harmful robot should be disabled. legit issues should not be automatically closed simply because they have not seen any attention yet.

[wannfq]

Hey @shapirus this repo is not monitored. Please raise the issue on https://github.com/kubernetes/kubernetes/issues