[Bug] Strimzi operator doesn't respect .spec.kafka.version for sidecar containers

[vutkin]

Describe the bug Strimzi operator doesn't respect .spec.kafka.version for sidecar containers

To Reproduce Steps to reproduce the behavior:

1. deploy helm chart 0.16.2
2. Create kafka Resource
3. Run command

   
   $ kubectl get pods -o jsonpath="{..image}" |\tr -s '[[:space:]]' '\n' |\sort |\uniq -c | grep strimzi
     **4 strimzi/kafka:0.16.2-kafka-2.3.1
     6 strimzi/kafka:0.16.2-kafka-2.4.0**
     2 strimzi/kafka-bridge:0.15.0
     6 strimzi/operator:0.16.2

$ kubectl get pods --all-namespaces -o=jsonpath='{range .items[]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[]}{.image}{", "}{end}{end}' |\sort | grep strimzi octopus-entity-operator-5686fc6887-whbk2: strimzi/operator:0.16.2, strimzi/operator:0.16.2, strimzi/kafka:0.16.2-kafka-2.4.0, redacted-kafka-0: strimzi/kafka:0.16.2-kafka-2.3.1, strimzi/kafka:0.16.2-kafka-2.4.0, redacted-rest-proxy-bridge-77d748bbb6-8zv5z: strimzi/kafka-bridge:0.15.0, redacted-zookeeper-0: strimzi/kafka:0.16.2-kafka-2.3.1, strimzi/kafka:0.16.2-kafka-2.4.0, strimzi-cluster-operator-676697b947-rvhpk: strimzi/operator:0.16.2,

4. See error
Why I see images strimzi/kafka:0.16.2-kafka-2.4.0 and strimzi/kafka:0.16.2-kafka-2.3.1 in same pod?

**Expected behavior**
I expect to see only images from version 2.3.1. Unfortunately instead I see both from 2.3.1 and 2.4.0.
Could anybody please explain me why?

**Environment (please complete the following information):**
 - Strimzi version: 0.16.2
 - Installation method: Helm chart
 - Kubernetes cluster: Kubernetes 1.14/1.16
 - Infrastructure: Minikube/AKS

**YAML files and logs**

---

Source: kafka-brokers/templates/kafka.yaml

apiVersion: kafka.strimzi.io/v1beta1 kind: Kafka metadata: name: octopus namespace: octopus-cluster spec: kafka: version: 2.3.1 replicas: 1 listeners: plain: {} tls: {} external: type: nodeport tls: false overrides: bootstrap: nodePort: 32100 config: offsets.topic.replication.factor: 1 transaction.state.log.replication.factor: 1 transaction.state.log.min.isr: 1 auto.create.topics.enable: false delete.topic.enable: true log.message.format.version: "2.3" storage: type: jbod volumes:

• id: 0 type: persistent-claim size: 32Gi deleteClaim: true zookeeper: replicas: 1 storage: type: ephemeral entityOperator: topicOperator: {} userOperator: {}

  Source: kafka-brokers/templates/kafkauser.yaml

  apiVersion: kafka.strimzi.io/v1beta1 kind: KafkaUser metadata: name: octopus-user labels: strimzi.io/cluster: octopus spec: authentication: type: scram-sha-512

  
  [report-26-06-2020_03-22-28.zip](https://github.com/strimzi/strimzi-kafka-operator/files/4835607/report-26-06-2020_03-22-28.zip)

Additional context Add any other context about the problem here.

[scholzj]

You are right. This is intentional. The sidecar does not really use anything from Kafka and is independent on it. It runs the Stunnel utility to do the TLS encryption and decryption. So regardless of which image it would use, it would always be the same version of Stunnel with the same configuration. It should not cause any issues or anything. So it does not matter and to use the famous sentence this is not a bug but a feature :-).

[vutkin]

Hi thank you. Just to clarify: So do you guarantee that we could freely use any version of sidecar container for kafka/zookeeper respecting only version of strimzi Operator without any issues from STunnel side?

[scholzj]

Yes. It is using the same container image as Kafka. But it doesn't use anything from the Kafka binaries. In the past we actually had a separate container image for the sidecars. But having too many container images was lot of overhead. So we now use the same image for both despite the sidecar not using anything from Kafka.