Bitnami Apache Kafka alternative
Replacing bitnamilegacy/kafka

Bitnami Apache Kafka variables and their official equivalents

Bitnami Apache Kafka image to official apache/kafka:

What breaks when you switch

• Every KAFKA_CFG_ variable has to be renamed. Missing one silently falls back to a default.
• Bitnami's client and broker credential helpers (KAFKA_CLIENT_USERS, KAFKA_CLIENT_PASSWORDS) have no official equivalent; configure JAAS and SASL directly.
• The official apache/kafka image covers current releases. ZooKeeper-mode 3.x clusters need either a migration to KRaft or a maintained 3.x image.

bitnami/kafka Helm chart values the drop-in image reads

How the bitnami/kafka chart configures brokers depends on its major version. Up to 23.x it runs one StatefulSet and passes broker settings as KAFKA_CFG_* environment variables. From 24.x it splits nodes into <release>-controller and <release>-broker StatefulSets, and a kafka-init init container, started from the same image, writes the server.properties that the broker mounts at /opt/bitnami/kafka/config/server.properties. Both designs rely on the Bitnami entrypoint and paths, which the OSSeva image keeps. The values below are from chart 31.x, the last line for Kafka 3.9.

Apache Kafka versions OSSeva publishes

Each line below has a patched OSSeva image. The second column shows which bitnami/kafka chart releases defaulted to that line, which tells you the chart major to stay on during the swap.

Replication and high availability in the Apache Kafka charts

What happened to the Bitnami Apache Kafka image

How to migrate Apache Kafka off Bitnami safely

1. Find every reference to bitnami/kafka and bitnamilegacy/kafka in running workloads, Helm values files and CI pipelines, including init containers.
2. Record the Apache Kafka version each deployment pins. Versions past upstream end of life are not covered by the free open source images.
3. Take a backup and test a restore before touching a stateful workload.
4. Mirror the replacement container images into your own registry, and scan them before you deploy.
5. Move one replica or one environment at a time, and confirm the data path, file ownership and credentials on the new image.
6. Remove every remaining legacy reference so nothing falls back to the archive on the next deploy.

Your options

Repoint the Bitnami Apache Kafka Helm chart

1. Run helm list to record the chart version, then helm get values <release> to save what is deployed.
2. Keep that chart major. Each Kafka line maps to its own chart majors (see the table), and 32.x removes ZooKeeper.
3. Override image.registry, image.repository and image.tag. With zookeeper.enabled, override zookeeper.image as well, since the subchart pulls its own image.
4. On chart 31.1.0 and later, set global.security.allowInsecureImages to true. Bitnami added that check in December 2024; earlier releases do not have it.
5. Run helm upgrade with --reuse-values and the override. When the rollout finishes, kafka-topics.sh --describe --under-replicated-partitions should return nothing.

# values-osseva.yaml
# helm upgrade my-kafka oci://registry-1.docker.io/bitnamicharts/kafka \
#   --version 31.5.0 --reuse-values -f values-osseva.yaml
image:
  registry: registry.example.com   # OSSeva registry or your mirror of it
  repository: kafka
  tag: "<3.9.x tag>"
zookeeper:                         # only when zookeeper.enabled is true
  image:
    registry: registry.example.com
    repository: zookeeper
    tag: "<zookeeper tag>"
global:
  imagePullSecrets:
    - registry-credentials
  security:
    allowInsecureImages: true      # checked by chart 31.1.0 and later

This works only with an image that keeps Bitnami's layout. With the official image, rewrite the chart or move to an operator. See replacing bitnamilegacy images for the full inventory and rollout steps.