01
Die Ausgangslage
Ein kleines, lange etabliertes Biotech-Unternehmen betrieb seine Anwendungen in zwei Kubernetes-Clustern auf AWS mit RKE1. Mit dem End-of-Life von RKE1 im Jahr 2025 musste eine andere Kubernetes-Distribution her. Dazu kamen Altlasten: Die Jenkins-Agents für die funktionalen Tests liefen noch auf einem lokalen Server, Jenkins selbst ließ sich wegen alter Java-Abhängigkeiten nicht mehr aktualisieren, und schon kleine Änderungen an der Deployment-Pipeline kosteten viel Administrationsaufwand. Zugangsdaten, etwa für die Datenbank, wurden dezentral in den Repositories verwaltet.
02
Unser Vorgehen
- 01 Migration beider Kubernetes-Cluster von RKE1 auf Amazon EKS, ohne Ausfallzeit im laufenden Betrieb
- 02 Umzug der lokalen Jenkins-Agents auf eine EC2-Instanz in AWS als erster Schritt, damit der lokale Server abgeschaltet werden kann
- 03 Aktualisierung von Jenkins und Agents auf eine aktuelle, unterstützte Version
- 04 Umstellung der Deployments von Jenkins auf GitOps mit Rancher Fleet, während die Build-Pipeline für die Docker-Images in Jenkins bleibt
- 05 Zentrales Management der Zugangsdaten in HashiCorp Vault
03
Das Ergebnis
- Zwei Cluster auf Amazon EKS, migriert ohne Ausfallzeit
- Eine unterstützte Kubernetes-Plattform statt einer Distribution am Ende ihres Lebenszyklus
- Jenkins wieder auf einer unterstützten Version und damit mit aktuellen Sicherheitsupdates
- Deployments per GitOps statt aufwendig gepflegter Jenkins-Pipeline
- Zugangsdaten zentral und verschlüsselt in HashiCorp Vault
- Der Weg ist frei, den lokalen Server abzuschalten