Prevent image pull failures due to Bitnami deprecation in Fusion 5.9.0 - 5.12

Issue

Bitnami is deprecating access to their legacy container image repository on August 28, 2025. After the deadline, any attempt to pull affected images from that source will fail, leading to pod startup and recovery issues in Kubernetes. This creates three critical risk scenarios in Kubernetes environments:

1. Pods with ImagePullPolicy: Always – every pull attempt after the deadline will fail.

2. New pod scheduling on nodes without cached images – common during pod scale-ups or rescheduling.

3. Use of ephemeral/spot instances – fresh nodes will be unable to pull the required images.

However, the problem will surface as soon as a pod needs to run on a node without the cached image or if cached images are evicted. At that point, pulls will fail and pods will be stuck in ImagePullBackOff or ErrImagePull states, blocking scaling and recovery.
 

Goal

Ensure that Fusion deployments using versions 5.9.0 through 5.12 continue to operate without disruption after August 28, 2025, when Bitnami container images will no longer be publicly available. Fusion's Helm charts for supported 5.9.x versions have been updated to reference images in Lucidworks' public repository, but unsupported versions (5.10, 5.11, 5.12) require manual overrides.

Environment

Fusion 5.9.0 to 5.12 running in Kubernetes
Applies to self-hosted Fusion environments
Relevant to clients who are pulling Bitnami container images from public registries

Guide

Review your environment for affected Bitnami images

To verify which Bitnami container images your Fusion deployment is currently using, run the following command:

kubectl get pods -n <fusion-namespace> -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{"\n"}{end}{end}'

Check for any images that begin with bitnami/, particularly:

• bitnami/kubectl

• bitnami/kafka

• bitnami/kafka-exporter

• bitnami/jmx-exporter

• bitnami/bitnami-shell

• bitnami/os-shell

Note that some of these images are pulled in via init containers or hooks, such as bitnami/kubectl used for Solr zone initialization and bitnami/os-shell. These will not appear in the simple scan command above unless you inspect the chart values.

If any of these appear, your environment will be affected by the image removals unless you upgrade or mirror the images.

Fusion 5.9.0 - 5.9.13 

Option 1: Upgrade to Fusion 5.9.14 or later

Fusion 5.9.14 and later remove dependencies on Bitnami-hosted public images. All required images are hosted by Lucidworks.

Upgrading ensures:

• Continued availability of container images

• Access to ongoing fixes and security updates

Refer to the Fusion upgrade documentation for steps specific to your deployment model.

Option 2: Redeploy your current Fusion version

If you must remain on 5.9.0 - 5.9.13, update your Helm release with corrected image overrides.

helm repo update

After updating your charts, use your normal method for deploying. Refer to the Fusion upgrade documentation for steps specific to your deployment model. Then, edit your values.yaml to replace all Bitnami references with Lucidworks-hosted equivalents.

5.9.4

kafka:
  image:
    registry: docker.io
    repository: lucidworks/kafka
    tag: 3.1.0-debian-10-r68

  metrics:
    kafka:
      image:
        registry: docker.io
        repository: lucidworks/kafka-exporter
        tag: 1.4.2-debian-10-r196
    jmx:
      image:
        registry: docker.io
        repository: lucidworks/jmx-exporter
        tag: 0.16.1-debian-10-r259

solr:
  initContainer:
    image:
      repository: lucidworks
      solrzoneImageName: docker.io/lucidworks/kubectl:1.29-debian-11

5.9.7

kafka:
  image:
    registry: docker.io
    repository: lucidworks/kafka
    tag: 3.1.0-debian-10-r68

  metrics:
    kafka:
      image:
        registry: docker.io
        repository: lucidworks/kafka-exporter
        tag: 1.4.2-debian-10-r196
    jmx:
      image:
        registry: docker.io
        repository: lucidworks/jmx-exporter
        tag: 0.16.1-debian-10-r259

solr:
  initContainer:
    image:
      repository: lucidworks
      solrzoneImageName: docker.io/lucidworks/kubectl:1.29-debian-11

5.9.12

kafka:
  image:
    registry: docker.io
    repository: lucidworks/kafka
    tag: 3.7.0-debian-12-r0

  metrics:
    kafka:
      image:
        registry: docker.io
        repository: lucidworks/kafka-exporter
        tag: 1.7.0-debian-12-r20
    jmx:
      image:
        registry: docker.io
        repository: lucidworks/jmx-exporter
        tag: 0.20.0-debian-12-r11

solr:
  initContainer:
    image:
      repository: lucidworks
      solrzoneImageName: docker.io/lucidworks/kubectl:1.29-debian-11

• kafka.image replaces the main Kafka broker image.
• kafka.metrics.kafka.image replaces Kafka Exporter.
• kafka.metrics.jmx.image replaces JMX Exporter.
• solr.initContainer.image.solrzoneImageName replaces the kubectl init container used in Solr zone initialization.

Note: The guidance isn't EKS-specific. The only thing that is EKS-tied in this examples is the kubectl tag. kubectl image (Solr init, workflows, hooks). Pick the tag to match your Kubernetes control plane minor version, not the cloud. Then use the closest matching tag published by Lucidworks:

• K8s 1.24  lucidworks/kubectl:1.24.8-debian-11-r6

• K8s 1.29  lucidworks/kubectl:1.29-debian-11

• K8s 1.31  lucidworks/kubectl:1.31-debian-12
  If the exact minor isn't available, choose the nearest available tag >= your cluster's minor or mirror the needed upstream image into your private registry.

Fusion 5.10 - 5.12 (Unsupported Versions)

Option 3: Manual Overrides

Fusion versions 5.10, 5.11, and 5.12 are out of support and were never patched. They still reference Bitnami images directly. To prevent pull failures after August 28, 2025, you must manually override these images.

Identify all Bitnami images:

kubectl get deployments -n ns-name -o yaml | grep bitnami

Edit each impacted deployment:

kubectl edit deployment/deployment-name -n ns-name

Replace every bitnami/* reference with the corresponding lucidworks/* image.

Examples:

# Kafka
image: docker.io/bitnami/kafka:3.7.0-debian-12-r0
# to
image: docker.io/lucidworks/kafka:3.7.0-debian-12-r0

# Kafka Exporter
image: docker.io/bitnami/kafka-exporter:1.7.0-debian-12-r20
# to
image: docker.io/lucidworks/kafka-exporter:1.7.0-debian-12-r20

# JMX Exporter
image: docker.io/bitnami/jmx-exporter:0.20.0-debian-12-r11
# to
image: docker.io/lucidworks/jmx-exporter:0.20.0-debian-12-r11

# Solr initContainer kubectl
image: docker.io/bitnami/kubectl:1.27-debian-11
# to
image: docker.io/lucidworks/kubectl:1.27-debian-11

# OS Shell
image: docker.io/bitnami/os-shell:12-debian-12-r34
# to
image: docker.io/lucidworks/os-shell:12-debian-12-r34

# Bitnami Shell (archived)
image: docker.io/bitnami/bitnami-shell-archived:11-debian-11-r99
# to
image: docker.io/lucidworks/bitnami-shell:11-debian-11-r99

Repeat for every deployment where a Bitnami image is found.

If your environment is air-gapped or using a private registry

If your environment already mirrors all required images into a private container registry and does not rely on Docker Hub or Bitnami directly, no additional action is required. However, verify that the following Lucidworks images are available in your private registry before August 28, 2025:

• lucidworks/kafka
• lucidworks/kafka-exporter
• lucidworks/jmx-exporter
• lucidworks/kubectl
• lucidworks/os-shell

Important Note

Manual overrides resolve the immediate Bitnami deprecation issue, but do not change the unsupported status of Fusion 5.10, 5.11, or 5.12. Clients should still plan to upgrade to Fusion 5.9.14 or later for long-term stability, fixes, and security updates.