Die deklarative Bereitstellung von Objekten ist eines der wichtigsten Features in Kubernetes. Wir stellen euch die wichtigsten Deployment-Strategien vor.
- Was ist eine Deployment Strategie
- Rolling Deployment
- Recreate Update
- Blue/Green Deployment
- Canary Deployment
- Fazit
Was ist eine Deployment Strategie?
Die Wahl einer geeigneten Deployment-Strategie kann Ausfallzeiten minimieren, die Zuverlässigkeit von Anwendungen verbessern und ganz allgemein dabei helfen, Kopfschmerzen im DevOps-Alltag zu verhindern. In diesem Beitrag beschäftigen wir uns deshalb mit den gängigen Deployment-Konzepten in Kubernetes.
Das Wichtigste zuerst – was genau bedeutet Deployment im Kubernetes-Ökosystem? Das Deployment beschreibt mittels einer deklarativen Anweisung – meist als YAML-Datei – den gewünschten Zustand des Systems. Nutzer geben nicht vor, wie ein Update ausgeführt wird, sondern deklarieren einen Endpoint, woraufhin der Kubernetes-Controller den Ist-Zustand dem Soll-Zustand anpasst. Über Deployments wird der Lifecycle von Pod-Instanzen und Clustern automatisiert. Sie ermöglichen eine schnellere Bereitstellung und helfen dabei, Fehler zu vermeiden.
Kubernetes bietet verschiedene Deployment-Strategien, mit denen Systeme auf unterschiedliche Weise und je nach Anforderungen aktualisiert werden können. Wir erklären die wichtigsten Strategien, zeigen Vor- und Nachteile und helfen euch dabei, eine geeignete Strategie für die Bereitstellung euerer Anwendungen zu finden.
Rolling Deployment
Das Rolling-Deployment ist Kubernetes default Strategie für Updates und dementsprechend einfach zu implementieren. Ausfallzeiten werden vermieden und die Performance-Einbußen sind meist überschaubar.
Nach und nach wird jeder einzelne Pod vom Kubernetes-Controller abgeschaltet und anschließend in der aktualisierten Version wieder neu gestartet. Dieser Prozess dauert an, bis alle Pods dem im Deployment deklarierten Zustand entsprechen. Aus diesem Vorgehen ergibt sich auch der größte Vorteil des Rolling Deployments – das System an sich bleibt die ganze Zeit über aktiv, wenn auch nicht bei voller Leistungsfähigkeit. Und sollte doch einmal etwas schiefgehen, sind Rollbacks verhältnismäßig einfach durchführbar. Mit steigender Größe der Anwendung steigt jedoch auch das Risiko, dass ein Rolling Update Fehler verursacht.
Beispiel:
spec: replicas: 10 strategy: type: RollingUpdate rollingUpdate: maxSurge: 3 maxUnavailable: 1Recreate Update
Neben dem Rolling Deployment gehört Recreate zu den am häufigst genutzten Update-Strategien. In einem Recreate-Deployment werden alle bestehenden Instanzen eines Pods, die nicht dem deklarierten Zustand entsprechen, gleichzeitig deaktiviert. Anschließend erstellt der Kubernetes-Controller die neuen, aktualisierten Pods. Für die Dauer dieses Prozesses ist das System nicht erreichbar, weshalb diese Strategie meist in Entwicklungsumgebungen zum Einsatz kommt oder wenn eine kurze Downtime für das Unternehemen vorteilhafter ist, als eine Periode eingeschränkter Erreichbarkeit und Performance-Einbußen. Sind die genannten Nachteile für Anwender hinnehmbar, profitieren besonders umfangreiche und große Anwendungen von einem Recreate Update.
Beispiel:
spec: replicas: 3 strategy: type: RecreateBlue/Green Deployment
Beim Blue/Green Deployment werden zwei Produktionsumgebungen parallel bereitgestellt. Die derzeitige stable v1 einer Anwendung nennt man Blue-Deployment, das Green-Deployment beinhaltet den neuen Code, bzw. den im Deployment deklarierten Soll-Zustand. Das Green-Deployment wird ausgiebig getestet und der eingehende Traffic bis auf Weiteres vollständig zum Blue-Deployment geroutet. Erst nach einer erfolgreich absolvierten Testphase, folgt die Umleitung des Traffics zum Green-Deployment und das Blue-Deployment wird für eventuelle, spätere Rollbacks archiviert.
Da der Zustand des Clusters in einem Schritt geändert wird, lassen sich Versionierungs-Fehler weitestgehend vermeiden und die Migration an sich ist schnell und unkompliziert. Allerdings birgt diese Strategie nicht unerhebliche Risiken, da auch Test-Protokolle sich immer wieder als fehlerhaft bzw. unvollständig herausstellen können. Der Einsatz von zwei vollwertigen Produktionsumgebungen erfordert natürlich auch den doppelten Ressourceneinsatz und ist dementsprechend kostenintensiv.
Beispiel Blue Deployment:
Service Selector
kind: Servicemetadata: name: frontend-01 labels: app: web-appselector: app: frontend version: v1.0.0Deployment
kind: Deploymentmetadata: name: frontend-01spec: template: metadata: labels: app: frontend version: "v1.0.0"Sobald die Test-Phase beendet ist, wird der Traffic auf das Green Deployment geroutet.
Beispiel Green Deployment:
Service Selector
kind: Servicemetadata: name: frontend-02 labels: app: web-appselector: app: frontend version: v2.0.0Deployment
kind: Deploymentmetadata: name: frontend-02spec: template: metadata: labels: app: frontend version: "v2.0.0"Canary Deployment
Das Canary-Deployment ähnelt in vielen Bereichen dem Rolling-Deployment, mit dem entscheidenden Unterschied, dass die Anwendung in kleinen Schritten einer festgelegten Anzahl von Nutzern (z.B. 5%, 10%, 25%) bereitgestellt wird. Im Unterschied zum Blue/Green-Deployment lassen sich Updates auf diesem Weg von echten Nutzern und unter realen Bedingungen testen. Im Vergleich zu allen anderen Deployment-Strategien ist das Canary-Deployment dank des hohen Maßes an Kontrolle mit dem geringsten Risiko verbunden.
Verlaufen die Tests zufriedenstellend, wird die neue Version schrittweise immer mehr Benutzern zugänglich gemacht und letztendlich wird das Canary-Deployment zur neuen Produktiv-Version. Canary-Deployments sind besonders hilfreich, wenn größere Updates, neue Features oder experimentelle Funktionen getestet werden sollen. Den Vorteilen stehen die hohen Ressourcen-Anforderungen gegenüber. Außerdem sind die Anforderungen an das Traffic Routing anspruchsvoll.
Original Deployment:
spec: replicas: 9Neues Deployment:
spec: replicas: 1Fazit: die richtige Strategie finden
Wir haben in diesem Artikel einige der meistgenutzten Deployment-Strategien in Kubernetes besprochen und für euch die jeweiligen Vor- und Nachteile erörtert. Dabei wird deutlich, dass es bei der Wahl einer geeigneten Strategie darauf ankommt, die Ansprüche der eigenen Anwendungen und der Nutzer genau zu verstehen und darauf aufbauend eine Entscheidung zu treffen, die Vor- und Nachteile in der Wage hält.
