What to do about the duplicate template fields in `Kafka` and `KafkaNodePool` resources

[scholzj]

Currently, some template fields are duplicated between the Kafka and KafkaNodePool resources. When set in the Kafka resource, they apply to all Kafka nodes. When set in the KafkaNodePool resource, they apply only to given node pool. But they cannot be set in both as the ones in Kafka would be ignored. That is sometiles causing confusion.

Should we deprecate the in v1 remove the conflciting template fields from the Kafka CRD? Or should we keep both? It seems to add value ... but also cause confusion. So it is not completely obvious what the plan should be.

[ppatierno]

At least for me, the template fields hierarchy across Kafka and KafkaNodePool is clear. As you said whatever you have in Kafka is applied to all nodes but you can override them by specifying the same template fields within the KafkaNodePool (so the ones in Kafka are ignored). It helps to apply something on all nodes avoiding to spread the same field across several node pools while having in just one place (in Kafka). So I am for keeping them.

[scholzj]

As you said whatever you have in Kafka is applied to all nodes but you can override them by specifying the same template fields within the KafkaNodePool (so the ones in Kafka are ignored).

Yeah, but this is not exactly how it works. If the KafkaNodePool has the template field set, the templates from Kafka will be ignored for the given node pool. So if you:

• Configure Pod template in Kafka CR
• Configure Container template in KafkaNodePool CR

What will be the result? The Pod template from the Kafka CR will be ignored for these nodes because the use of the template section in KafkaNodePool effectively resets it. So not sure how clear it is (and some users struggled with it).

TBH, I'm probably also for keeping it as is. But I wanted to raise the discussion as there won't be another chance to change it for a long time.

[ppatierno]

Reading your example it looks like exactly my understanding.

[katheris]

To me it makes sense that I can specify the template.pod in the Kafka CR and then override it for a specific node pool using template.pod in the KafkaNodePool CR.

However to me the template.kafkaContainer property in the KafkaNodePool does seem confusing. How come the env and volumeMounts options are there rather than under template.pod? And what happens if I configure both template.pod.securityContext and template.kafkaContainer.securityContext?

[scholzj]

However to me the template.kafkaContainer property in the KafkaNodePool does seem confusing. How come the env and volumeMounts options are there rather than under template.pod? And what happens if I configure both template.pod.securityContext and template.kafkaContainer.securityContext?

Essentially, every Pod might contain multiple containers. So instead of having some list for (named?) container templates in the templaze.pod, we have separate items for different containers such as the template.kafkaContainer. so anything configured on the whole Pod level is in the Pod template. And anything for the container level is in the container templates. There are no duplicates between these two template types. The securityContext might look that way, but it mirrors the Pod security context and container security context from the Kubernetes level, which are two different things there as well.

To me it makes sense that I can specify the template.pod in the Kafka CR and then override it for a specific node pool using template.pod in the KafkaNodePool CR.

Yeah, that part definitely makes sense.

The more complicated part is the KafkaNodePool template that has only the pod template, also resets, for example, the container template from the Kafka CR, even if it is not set there at all. While it has its own logic, it also has its own confusion potential.

[ppatierno]

If I got it right ...

I have a Kafka with a template.pod and a template.kafkaContainer.
Then I have a KafkaNodePool with just a template.pod.
This way the the fact that KafkaNodePool is missing the template.kafkaContainer actually delete/reset/doesn't apply the template.kafkaContainer we have in Kafka.
I didn't realize that. Why is it this way? Why isn't it applying the template.pod from KafkaNodePool but keeping the template.kafkaContainer we have in Kafka?

[scholzj]

Basically, imagine this situation, which I think is probably the most confusing ...

apiVersion: kafka.strimzi.io/v1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    template:
      pod:
        metadata:
          labels:
            mylabel: myvalue
      # ...
---
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: brokers
  labels:
    strimzi.io/cluster: my-cluster
spec:
  # ...
  template:
    kafkaContainer:
      env:
      - name: EXAMPLE_ENV_1
        value: example.env.one

What is the outcome you expect to see?

1. The label myvalue will be set on the Pods belonging to the node pool and the env var EXAMPLE_ENV_1 will be set in their Kafka containers
2. The env var EXAMPLE_ENV_1 will be set in the Kafka containers of Pods belonging to this Node Pool. But no labels will be set

The actual outcome will be 2, even there is seemingly no overlap (IIRC we will issue some warnings for this to raise awareness, but at the end the Pod template from the Kafka CR will be ignored)

[scholzj]

I have a Kafka with a template.pod and a template.kafkaContainer.
Then I have a KafkaNodePool with just a template.pod.
This way the the fact that KafkaNodePool is missing the template.kafkaContainer actually delete/reset/doesn't apply the template.kafkaContainer we have in Kafka.
I didn't realize that. Why is it this way? Why isn't it applying the template.pod from KafkaNodePool but keeping the template.kafkaContainer we have in Kafka?

Yes, you got this right. Essentially, the template overrides at the template level. So by using a template where kafkaContainer is not set, you reset the value from the Kafka template.

[scholzj]

Discussed on a call on 8.9.2025: We do not want to remove the template APIs from the Kafka CR. We should consider changing how the template is handled, which would be a breaking change, but might improve our UX. A proposal will be needed.