[Enhancement]: Use downward API for configuring rack awareness in Kubernetes >=1.33

[SoerenHenning]

Related problem

For configuring rack awareness, Strimzi uses an init container that requests node labels via the Kubernetes API and exports them to the Kafka brokers. See documentation: Configuring rack awareness and init container images. For this init container certain permissions are required, which would not be required otherwise, and the init container makes the deployment more complicated than non-rack aware deployments.

Suggested solution

Starting with Kubernetes 1.33, node topology labels are available via downward API. This is currently an alpha feature, but it appears to be enabled by default (at least in Amazon EKS).

It would be beneficial if we could support this feature when:

1. a Kubernetes version is used, which supports it, and
2. a topologyKey is used, which actually is exposed through the downward API.

It is important to note that not all node labels are available via the downward API, which means that it will cover only a subset of what is currently supported by Strimzi.

Because of this and because the feature is still alpha and only available in Kubernetes >1.33, I do not propose to remove the existing solution with the init container, but instead leave it to the users to decide how to obtain the topologyKey.

Here is a simple (albeit contrived) example of how this feature could be reflected in the Kafka spec:

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    rack:
      getTopologyKeyViaInitContainer: False
      topologyKey: topology.kubernetes.io/zone

Alternatives

Leave everything as it is, since it works this way. However, utilizing this new feature would lead to more lightweight deployments in some cases.

Additional context

No response

[scholzj]

For configuring rack awareness, Strimzi uses an init container that requests node labels via the Kubernetes API and exports them to the Kafka brokers. See documentation: Configuring rack awareness and init container images. For this init container certain permissions are required, which would not be required otherwise, and the init container makes the deployment more complicated than non-rack aware deployments.

I'm not sure what exactly you mean with this to be honest. From a user perspective, operator does all the work, so what is the problem with it using the init container? From the operator's perspective, having two different ways to do the same thing instead of one certainly is not a simplification but rather a complication. Also, please keep in mind that the operator would still require the same RBAC rights because of the node port listeners.

This issue is useful to track the Kubernetes feature and one day decide on how to proceed. But I'm not sure whether:

• We really want to have different ways to do the same thing as that significantly increases the maintenance efforts
• If we want to have two different ways, do we really want them to be based on some API setting? That does not allow us to migrate to one feature in the future and keeps us locked in a bad state with both features supported (and the resulting maintenance toil)

[ryanfaircloth]

I think the suggestion would be most useful as a feature flag what would be beta until all "supported" k8s up stream versions have the matching feature available so the dual approach would be transitional. The OP is correct this would reduce the require permissions of the kafka pods but not the operator pods. While that may seem small any time we can reduce surface area thats good. The alternative would be to automaticlly use the new feature if it is enabled at the k8s level but that takes away operator choice so feature flag seems better

[scholzj]

The transition to having it fully supported in Kubernetes would take years. So not sure having a feature gate for it the whole time is the idea how the feature gates were designed.

[ryanfaircloth]

1.32 is eom on 28 Feb 2026 so not that far away to have this. Reading the KIP and PR notes it looks like this is fairly stable there seems to be some debate on expanding to allow all labels in the downward API

[scholzj]

1.32 is eom on 28 Feb 2026 so not that far away to have this. Reading the KIP and PR notes it looks like this is fairly stable there seems to be some debate on expanding to allow all labels in the downward API

Strimzi currently supports Kube 1.25+. So it will take some time until we drop support for Kube 1.32. But as far as I remember, the new API is only alpha in 1.33. So we cannot rely on it in 1.33 I think. We need to wait for it to be permanently enabled before being able to build on it.

[katheris]

Triaged on 17/7/25: This feature is still very new, so we should wait until it is at least in beta and more widely supported before making use of it in Strimzi. There are drawbacks to supporting it, such as maintaining two ways of doing things and the fact we would still need the init container and RBAC for other features of Strimzi. So we should review this again in the future and at that point have a proposal to discuss the trade-offs.