TurboAd GmbH

Bitnami-Aus für freie Container-Images: Was Kubernetes-Teams jetzt tun müssen

27. August 2025 Thomas K.

Ab dem 28. August 2025 stellt Bitnami seinen freien Container-Katalog um: Die meisten Images wandern in ein Archiv und erhalten keine Updates mehr. Wer Bitnami-Images oder -Helm-Charts in Kubernetes einsetzt, sollte Cluster und Pipelines jetzt prüfen, damit Deployments nicht plötzlich mit Pull-Fehlern scheitern.

Was ist passiert?

Bitnami, seit der Übernahme von VMware ein Teil von Broadcom, hat Mitte Juli auf GitHub tiefgreifende Änderungen am öffentlichen Katalog angekündigt. Ab dem 28. August 2025 enthält das Repository docker.io/bitnami nur noch eine kleine Auswahl gehärteter Images, und zwar ausschließlich mit dem Tag latest. Bitnami empfiehlt diese freien Images ausdrücklich nur für Entwicklung und Tests. Die Erstellung der bisherigen Debian-basierten Images wird eingestellt.

Alle übrigen Images, einschließlich der versionierten Tags, werden in das Archiv docker.io/bitnamilegacy verschoben. Dort gibt es keine Updates und keinen Support mehr. Bitnami bezeichnet das Archiv als vorübergehende Hilfe für die Migration. Tags auf Basis seit Jahren veralteter Distributionen wie Debian 10 oder CentOS 7 werden gar nicht erst übernommen. Wer weiterhin den vollen Katalog mit stabilen Versions-Tags und Sicherheitsupdates nutzen möchte, verweist Bitnami auf das kostenpflichtige Angebot Bitnami Secure Images.

Auch die Helm-Charts sind betroffen: Bereits veröffentlichte Charts bleiben als OCI-Artefakte unter docker.io/bitnamicharts abrufbar, werden aber nicht mehr aktualisiert. Weil sie auf Images verweisen, die es im Hauptkatalog nicht mehr gibt, können Installationen ohne angepasste Image-Angaben fehlschlagen. Zusätzlich hat Bitnami sogenannte Brownouts angekündigt, bei denen ausgewählte Images zeitweise nicht verfügbar sind. Der erste ist für den 28. August, 08:00 UTC, bis zum 29. August, 08:00 UTC, geplant.

Wichtig: Der Quellcode der Images und Charts bleibt unter der Apache-2.0-Lizenz auf GitHub verfügbar. Nicht betroffen sind laut Bitnami unter anderem Sealed Secrets und minideb.

Warum betrifft Sie das?

Bitnami-Charts für PostgreSQL, Redis, RabbitMQ, Kafka oder Keycloak sind in vielen Kubernetes-Setups Standard, oft auch versteckt als Abhängigkeit anderer Charts. Typische Folgen der Umstellung sind ImagePullBackOff-Fehler beim nächsten Neustart eines Pods, beim Skalieren eines Nodes oder beim Aufbau einer neuen Umgebung. Wer kurzfristig auf das Legacy-Archiv ausweicht, betreibt Software ohne Sicherheitsupdates. Das ist für Produktivsysteme keine Dauerlösung.

Was Sie jetzt tun sollten

  • Inventur im Cluster: Ermitteln Sie alle laufenden Bitnami-Images, inklusive Init- und Sidecar-Container:
Terminal
kubectl get pods -A -o jsonpath="{..image}" \
  | tr -s '[:space:]' '\n' | sort -u | grep bitnami
  • Helm-Releases und Abhängigkeiten prüfen: Durchsuchen Sie helm list -A, Ihre Chart.yaml-Dateien und GitOps-Repositories nach Bitnami-Charts und Subcharts.
  • CI/CD und Dockerfiles prüfen: Auch Basis-Images in Build-Pipelines und Testumgebungen mit Docker Compose können betroffen sein.
  • Images spiegeln und pinnen: Kopieren Sie benötigte Images in Ihre eigene Registry und referenzieren Sie sie per Version oder Digest statt über latest:
Terminal
crane copy docker.io/bitnamilegacy/postgresql:<tag> \
  registry.example.com/mirror/postgresql:<tag>
  • Übergangslösung bewusst einsetzen: Bitnami beschreibt, wie man bestehende Charts per --set image.repository=bitnamilegacy/... auf das Archiv umstellt. Nutzen Sie das nur, um Zeit für die eigentliche Migration zu gewinnen.
  • Dauerhafte Alternative wählen: Je nach Komponente kommen offizielle Images der Projekte, Upstream-Charts, Kubernetes-Operatoren, verwaltete Cloud-Dienste, eigene Builds auf Basis des Apache-2.0-Quellcodes oder ein kommerzielles Abonnement infrage.
  • Testen vor dem Rollout: Validieren Sie Änderungen mit helm template und in einer Staging-Umgebung, bevor Sie Produktion umstellen.

Fazit

Die Umstellung ist kein Grund zur Panik, aber ein klarer Handlungsauftrag. Wer jetzt inventarisiert, kritische Images spiegelt und einen Migrationsplan aufsetzt, vermeidet Ausfälle und reduziert gleichzeitig die Abhängigkeit von einem einzelnen Anbieter. Der Fall zeigt auch, wie wichtig eine eigene Registry und gepinnte Image-Versionen für jeden Kubernetes-Betrieb sind. Wenn Sie Unterstützung bei Inventur oder Migration Ihrer Helm-Charts brauchen, sprechen Sie uns an.

Quellen

Zurück zu News