[Enhancement]: Per broker annotation template

[shk3]

Related problem

Strimzi has an annotations field under the listener brokers to allow us to specify annotations for each broker for things like External DNS. However, this config can only be specified per broker, and we don't really have a way to "template" it like what we do with hostTemplate or advertisedHostTemplate. As a result, it's very tedious and error prone for us to maintain this list of broker annotations.

Suggested solution

Have we considered implementing something similar to hostTemplate and advertisedHostTemplate for annotations? For example, we could have an annotationsTemplate at the parent level, which allows us to use those node IDs and pod names.

We would probably want to add the logic here

strimzi-kafka-operator/cluster-operator/src/main/java/io/strimzi/operator/cluster/model/ListenersUtils.java

Line 409 in b12c2e5

.orElse(Collections.emptyMap());

similar to what's done with hostTemplate here

strimzi-kafka-operator/cluster-operator/src/main/java/io/strimzi/operator/cluster/model/ListenersUtils.java

Line 515 in b12c2e5

host = renderHostTemplate(listener.getConfiguration().getHostTemplate(), node);

.

Thanks!

Alternatives

No response

Additional context

No response

[ppatierno]

Can you provide a little bit more of details for your specific use case about using a template for rendering annotations?

[shk3]

Absolutely! In our case, we are using nodeport listener for our Kafka's external access. We are using External DNS to setup a domain name for each broker, so that the client can connect to the brokers through NodePort via mTLS, and we would only need to sign a TLS server cert for *.kafka.mydomain to pass the client-side hostname verification.

Currently, the annotations cannot be templated, and we would have to configure annotations for each brokers in the KafkaCluster CR by enumerating the brokers and their annotations in the following fashion.

brokers:
- broker: 1
  advertisedHost: b1.kafka.mydomain
  annotations:
    external-dns.alpha.kubernetes.io/hostname: b1.kafka.mydomain.
    external-dns.alpha.kubernetes.io/ttl: "30"
- broker: 2
  advertisedHost: b2.kafka.mydomain
  annotations:
    external-dns.alpha.kubernetes.io/hostname: b2.kafka.mydomain.
    external-dns.alpha.kubernetes.io/ttl: "30"
- broker: 3
  advertisedHost: b3.kafka.mydomain
  annotations:
    external-dns.alpha.kubernetes.io/hostname: b3.kafka.mydomain.
    external-dns.alpha.kubernetes.io/ttl: "30"

When we need to scale up with my brokers, we often missed out adding new brokers to this part of the configs with more annotations with external dns domains.

Ideally, if we can do a template with annotations similar to what we would do with the advertisedHostTemplate: "b{nodeId}.kafka.mydomain", we would just be able to eliminate this whole section of enumeration, and when we need to add a new broker, the annotations can be generated automatically.

annotationsTemplate:
    external-dns.alpha.kubernetes.io/hostname: b{nodeId}.kafka.mydomain.
    external-dns.alpha.kubernetes.io/ttl: "30"

Let me know if this makes sense to you. I could try to come up with a PR too, if this feature makes sense.

[scholzj]

I think this would need a proposal. But it kind of makes sense in general.

However, please keep in mind that in most cases, the per-broker DNS names have a very limited value as they are usually not used anywhere directly. They are just self-discovered from the Kafka metadata. So it typically makes no difference whether it is a nice domain name based on the broker ID or whether it is some random IP or cloud provider DNS (in some cases, those might actually work better because you avoid any delays when propagating DNS changes etc.).

That is pretty much why I considered it when proposing and creating the other templates, but decided against the template for the annotations. But I would likely approve it if someone contributed this as an enhancement.

[ppatierno]

I see your scenario and yes it makes sense to me. But I think it would need a proposal even because it's going to be a change in the API even if backward compatible (I would assume for people who are not going to use the annotations template but just the annotations).

[shk3]

However, please keep in mind that in most cases, the per-broker DNS names have a very limited value as they are usually not used anywhere directly. They are just self-discovered from the Kafka metadata. So it typically makes no difference whether it is a nice domain name based on the broker ID or whether it is some random IP or cloud provider DNS (in some cases, those might actually work better because you avoid any delays when propagating DNS changes etc.).

In our use case, it was because we had to go through hostname verifications for each broker. We cannot sign the TLS certificate for a IP or provider DNS that we don't know before the broker comes up. Therefore, we end up having to sign a wildcard *.kafka.mydomain and then try to configure brokers with DNS under this subzone.

Is there a way to pass through TLS hostname verifications with the random broker IPs approach? If so, we would actually love to consider switching over.

[scholzj]

However, please keep in mind that in most cases, the per-broker DNS names have a very limited value as they are usually not used anywhere directly. They are just self-discovered from the Kafka metadata. So it typically makes no difference whether it is a nice domain name based on the broker ID or whether it is some random IP or cloud provider DNS (in some cases, those might actually work better because you avoid any delays when propagating DNS changes etc.).

In our use case, it was because we had to go through hostname verifications for each broker. We cannot sign the TLS certificate for a IP or provider DNS that we don't know before the broker comes up. Therefore, we end up having to sign a wildcard *.kafka.mydomain and then try to configure brokers with DNS under this subzone.

Is there a way to pass through TLS hostname verifications with the random broker IPs approach? If so, we would actually love to consider switching over.

For most listener types, we automatically issue certificates with the addresses / IPs inside. But yes, for node ports we currently do not support the TLS hostname verification. This is because the certificates are generated before the Pods are scheduled. So we do not know the exact node address where the Pod will be scheduled. And if we generate the certificates with all worker nodes, it might be less secure, but also the worker nodes might come and go in some cases as clusters scale or update/upgrade which would trigger a lot of random changes and rolling updates.

So yeah, if you use node ports and want to have TLS hostname verification, this approach, in combination with a custom wildcard certificate, is pretty reasonable.

[scholzj]

Triaged on 8.1.2026: This makes sense. But as it includes API changes and we should have clarity about the placeholders etc., this should go through the proposal process (https://github.com/strimzi/proposals).

@shk3 Are you interested in contributing this feature? Or should we leave it to someone else?

[shk3]

I do have interests, but I haven't found the time to work on the proposal yet tbh. If there is someone else who has the interests, I'm fine with leaving it to someone else. Otherwise, I can try to pick up later when I get some time to work on it.

…

On Thu, Jan 8, 2026 at 5:56 PM Jakub Scholz ***@***.***> wrote: *scholzj* left a comment (strimzi/strimzi-kafka-operator#12167) <#12167 (comment)> Triaged on 8.1.2026: This makes sense. But as it includes API changes and we should have clarity about the placeholders etc., this should go through the proposal process (https://github.com/strimzi/proposals). @shk3 <https://github.com/shk3> Are you interested in contributing this feature? Or should we leave it to someone else? — Reply to this email directly, view it on GitHub <#12167 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALGKTWJ35YGC754FKDQF534FYSWBAVCNFSM6AAAAACNAMYGDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMRTGA4TKMRWGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[scholzj]

Ok, no problem. I will mark it as help-wanted and we will see when someone from the Strimzi team or some other contibutor find some time to look into it. You can of course get back to it later as well.

[scholzj]

Note: There are also labels ... thy should probably have the same template type option as the annotations.