Addressing Container Label Gaps with Cluster Sensor Post CS 1.44 Version

Overview

We are rolling out an important enhancement to container label support. Today, filtering by Pod, Namespace, and Cluster labels relies exclusively on values supplied by the General Sensor and persisted on the container entity. In the upcoming release, container labels can also be sourced directly from the Cluster Sensor, closing long-standing gaps in label coverage and consistency across deployments.

What’s Changing

• Filtering by labels sourced from the Cluster Sensor is now supported, in addition to filtering by labels sourced from the General Sensor.
• A new container Node label set is being introduced.
• Existing labels continue to work and remain backward compatible.

Compatibility & Upgrade Criteria

• Namespace filtering: requires General Sensor 1.44 or above.
• All other label filters (Container, Pod, Node) continue to be supported on older General Sensor versions.
• All new labels are supported on both the General Sensor and the Cluster Sensor unless explicitly noted.

Sensor Coverage Matrix

The table below shows which sensor surfaces each newly introduced label. When both the General Sensor and the Cluster Sensor are deployed, the platform consolidates the data, and you get the broadest coverage without duplicate ingestion.

Note: Namespace labels are the only category that requires General Sensor 1.44 or above. All other categories work on both old and new General Sensor versions as well as the Cluster Sensor.

Why Deploy the Cluster Sensor?

Deploying the Cluster Sensor is the most efficient way to pull container label metadata at scale. Instead of every node independently deriving and reporting label information through its own General Sensor instance, the Cluster Sensor talks to the Kubernetes API server once and shares that view across the whole cluster.

One API call from the Cluster Sensor vs. one call per node from each General Sensor — lower control-plane load, lower egress, faster propagation, and a single source of truth for cluster-wide labels.

Key Benefits

• Fewer API server calls: metadata is pulled centrally instead of being fetched repeatedly by every node in the cluster.
• Lower control-plane load: scales O(1) with cluster size instead of O(N) per-node — important on large or busy clusters.
• Consistent, cluster-wide view: namespace and node labels reflect the live Kubernetes state, not the per-node cache.
• Broader label coverage: unlocks namespace and node labels without forcing a General Sensor upgrade on every node.
• Simpler operations: a single Cluster Sensor deployment manages label collection instead of relying on each node staying current.

Use Cases

• General Sensor only: workloads on standalone container hosts, or smaller clusters where the General Sensor already covers your use cases.
• Cluster Sensor only: you need cluster-wide label visibility (namespace, node) with minimal footprint per node.
• Both (recommended for Kubernetes): General Sensor handles container-level runtime visibility while Cluster Sensor centralizes label metadata — the platform deduplicates and gives you the broadest, most efficient coverage.

Detailed Label Changes

1. Container Labels

Existing Labels:

container.instance.label.key

container.instance.labels.value

Newly Introduced Label:

container.instance.label = "key:value"

Why: Introduced to provide a consistent representation that combines key and value. Both the legacy key/value labels and the new ‘key:value’ label are supported on older General Sensor versions and on the Cluster Sensor.

2. Container Pod Labels

Existing Labels:

container.cluster.k8s.pod.label.key

container.cluster.k8s.pod.labels.value

Newly Introduced Label:

container.cluster.k8s.pod.label = "key:value"

Why: Mirrors the consistency improvement at the Pod level. Both the legacy key/value labels and the new ‘key:value’ label are supported on older General Sensor versions and on the Cluster Sensor.

3. Container Namespace Labels

Existing Label:

container.cluster.k8s.pod.namespaceMetadata.labels

(Supported by General Sensor only.)

Newly Introduced Label:

container.cluster.k8s.namespace.label = "key:value"

Why: Provides a unified namespace label in ‘key:value’ form. Supported on General Sensor 1.44 and above, and on the Cluster Sensor. This is the only filter that mandates the General Sensor upgrade.

4. Container Node Labels

Newly Introduced Label:

container.cluster.k8s.node.label = "key:value"

Why: A brand-new label set with no prior equivalent on the container entity. Available on both the General Sensor and the Cluster Sensor.

Customer Impact

• No breaking changes: Existing label queries and filters continue to work unchanged.
• Wider label coverage when the Cluster Sensor is deployed alongside the General Sensor.
• Consistent ‘key:value’ label format simplifies query authoring across label categories.
• First-time visibility into Node-level container labels via the new node.label token.

Recommended Actions

• Deploy the Cluster Sensor across your Kubernetes environments to unlock the most efficient label-sourcing path.
• Plan to upgrade the General Sensor to version 1.44 or above if Namespace label filtering is required and you cannot deploy the Cluster Sensor.
• Begin migrating saved queries and dashboards to the new ‘key:value’ label format for consistency.
• Review automation, alerts, and reports that depend on the legacy key/value labels – no immediate change is required, but unifying on the new tokens is recommended.