Kafka lief – aber nicht so, wie es sollte.
Als wir den Auftrag eines großen norddeutschen Finanzinstituts erhielten, ein bestehendes Kafka-Cluster in die Azure Cloud zu überführen, war schnell klar: Eine einfache Migration auf virtuelle Maschinen hätte zwar funktioniert – aber auch alle bestehenden Probleme mitgenommen. Stattdessen haben wir die Gelegenheit genutzt, um den gesamten Stack zu modernisieren. Ziel war nicht nur ein Plattformwechsel, sondern ein echter Entwicklungsschritt hin zu Automatisierung, GitOps und DevOps-Prinzipien.
Natürlich wäre der einfache Weg verlockend gewesen: VMs in Azure aufsetzen, Kafka herüberziehen, fertig. Aber: Eine manuell verwaltete Kafka-Installation hätte weder die gewünschte Flexibilität noch die notwendige Stabilität gebracht. Und eine PaaS-Alternative wie die Confluent Cloud? Kam für unseren Kunden nicht infrage – die Bedenken bezüglich der fehlenden Integration von diversen Kafka PaaS-Lösungen in das bestehende Self-Hosted-Setup waren zu groß. Wir entschieden uns daher bewusst für einen Kubernetes-basierten Ansatz auf Azure Kubernetes Service (AKS). So konnten wir Skalierbarkeit, Wiederholbarkeit und Kontrolle über die gesamte Infrastruktur hinweg gewährleisten.
Architektur mit Fokus auf Automatisierung und Sicherheit
Das Herzstück der neuen Architektur bilden drei Technologien: Kubernetes als Orchestrierungsebene, Helm für reproduzierbare, modulare Deployments und ArgoCD zur GitOps-gesteuerten Synchronisation der Umgebung. Ein Kafka Operator übernimmt das vollständige Lifecycle-Management der Cluster-Komponenten – von der automatisierten Bereitstellung bis zum Update. Custom Resource Definitions (CRDs) erlauben es, Kafka-Broker, Schema Registry & Co. direkt als deklarative Ressourcen zu verwalten. Konfigurationen werden über ConfigMaps bereitgestellt, StatefulSets und Persistent Volumes sorgen für stabile Datenhaltung.
Auch in puncto Netzwerk und Sicherheit war ein durchdachtes Konzept gefragt: Die Kommunikation zwischen Komponenten – intern wie extern – wird über Ingress und Services geregelt. Für den Zugriffsschutz setzen wir auf mutual TLS (mTLS) und rollen eine Kombination aus Zertifikatsprüfung und ACL-basierter Autorisierung aus. Nur berechtigte Clients erhalten Zugriff – egal, ob innerhalb des Clusters oder über die externe Bootstrap-URL.
Kafka ist kritisch – Downtime ist keine Option. Genau deshalb war ein zentrales Ziel: nahtlose Deployments ohne Unterbrechungen. Durch die Kombination von Kubernetes-Rollouts, Helm mit integrierten Health Checks und ArgoCD-Automatisierung ist genau das gelungen. Selbst Rollbacks bei Problemen lassen sich schnell, sicher und kontrolliert durchführen.
Mehr als Technik: Ein Schritt in Richtung DevOps-Kultur
Eine der größten Umstellungen war der Wechsel zu GitOps. Statt zentralen CI/CD-Pipelines (z. B. via Azure DevOps oder Jenkins) setzen wir auf eine „Single Source of Truth“ direkt im Git. Alle Änderungen am Cluster laufen über definierte GitFlows – das sorgt für klare Zustände, vermeidet Drifts und erhöht die Nachvollziehbarkeit.
Dieses Projekt war mehr als ein Infrastruktur-Upgrade. Es war ein strategischer Wandel hin zu einer modernen DevOps-Kultur. Heute läuft alles deklarativ, versioniert und nachvollziehbar. Die Umgebung ist automatisiert, skalierbar – und bereit für die Zukunft.
Was wir aus diesem Projekt mitnehmen? Kubernetes lohnt sich auch für komplexe Systeme wie Kafka – wenn man GitOps von Anfang an mitdenkt. Helm und ArgoCD haben sich dabei als verlässliche Werkzeuge für reproduzierbare Deployments mit eingebauter Rollback-Funktion bewährt. Und: Manuelle Deployments auf VMs sind in solchen Szenarien keine echte Option mehr – zu groß die Komplexität, zu hoch die Risiken, zu wenig Wiederverwendbarkeit.