06. Juli 2017

Warum Kubernetes die richtige Plattform für Container ist

Warum Kubernetes die richtige Plattform für Container ist (PIRO4D / pixabay.com)

Wenn Trends aufeinander treffen

Die aktuellen Trends DevOps und Container (Docker) beschäftigen uns in den letzten Monaten intensiv. Wir haben uns Gedanken gemacht, welchen Herausforderungen man begegnet, wenn beide Trends aufeinandertreffen.

Eine Anforderung an DevOPs ist das agile und schnelle Entwickeln und Testen von Software. Hierfür benötigen Entwickler unkomplizierten Zugriff auf eine Testumgebung.

Genau dafür gibt es aber doch Docker, oder? Also wird die Software mal eben in einen Container gepackt, Vagrant installiert und darin ein individueller Docker-Container gestartet. Fertig! Oder doch nicht?! Docker für den Desktop ist doch beliebt und einfach.

Der Irrweg: Docker Desktop

Aber so einfach ist es dann nicht. Denn Docker auf dem Desktop benötigt zum einen Portveröffentlichungen und mehrere Container, die verbunden werden müssen. Selbst mit einem guten Tooling treten dabei immer wieder unterschiedliche lokale Probleme auf. Zudem müssen alle Entwickler tiefergehendes KnowHow von Vagrant, Docker und vom Docker-Netzwerk haben.

Eine weitere Hürde könnte sein, dass die Applikationen die RAM-Kapazität des Desktops überschreiten (aber das wollen wir nicht annehmen). Zusätzlich wird eine lokale Datenbank mit geprüften Test-Datensätzen benötigt.

Und neben vielen anderen Hindernissen ist dieses Docker-Desktop-Setup auch noch grundverschieden von der späteren PROD-Umgebung. Außerdem gilt: je mehr eine moderne Applikation in Microservices aufgeteilt wird, desto höher wird auch deren lokale Komplexität.

Eine Lösung: – Kubernetes von Anfang an

Ein möglicher Weg diese Probleme zu umgehen, ist die Bereitstellung von Kubernetes von Anfang an. Kubernetes (K8s) ist ein Open Source Ökosystem für automatisierendes Deployment, Skalierung und Management von containerisierten Applikationen.

Und wie hilft das unserem Entwickler? Durch die standardisierte Bereitstellung eines Kubernetes (K8s) mit geteilten gemeinsamen Backend-Services und Datenquellen (Datenbanken) und dem „Package Management“ mit Helm ist das Deployment einer Applikation im DEV-Branch nur einen Mausklick entfernt. Das gibt jedem Entwickler seinen eigenen Mikrokosmos zum Testen. Und: dieses Setup entspricht den späteren Staging- und PROD-Umgebungen.

Die Aspekte

  • Provisionierung
  • Scheduling
  • Netzwerkmanagement
  • Service Discovery
  • Lifecycle Management
  • Deploy Chain
  • und Build Tools

sind in diesem Szenario dieselben, wie später in der Produktion. Sie werden in Kombination mit den zentralisierten, geteilten Datenquellen optimal gelöst. Das Deployment in diesem Mikrokosmos entspricht in allen wesentlichen Eckpunkten der Live-Umgebung.

Warum Kubernetes funktioniert

Kubernetes ergänzt aufgrund folgender Eigenschaften (Docker-)Container um wichtige Funktionen für einen stabilen Betrieb:

  • Standardisiert
  • Rockstable mit CoreOS
  • Sicherheit bereits implementiert
  • Namespaces (Netzwerk)
  • Abstraktion und Load Balancing (Services)
  • Deployment und CI-/CD-Schnittstellen inkl. Rolling Updates
  • Ein „Setup“ wird komplett beschrieben und reproduzierbar identisch deployed
  • Alles ist Code – auch eine Applikation aus Dutzenden von Microservices

… und so einfach ist die Nutzung

Zuerst die Applikation als Code beschreiben, d.h. den Bauplan „zeichnen“ (dabei unterstützt Helm). Dann die Applikationsbausteine entwickeln, einchecken und automatisiert in ein Docker Repo legen (Registry).

Danach wird es einfach:

  • Mit nur einem Kommando eine Umgebung bauen;
  • Provisionierung, Schedule und Deployment einer neuen Applikationsversion;
  • Konfiguration der personalisierten Microservices;
  • Die Container mit den geteilten Backend Datenquellen und Services koppeln (für alle Entwicklerumgebungen identisch!);
  • Container inkl. Webserver starten;
  • Netzwerk „exposen“ und Route setzen (später muss noch der DNS-Eintrag gesetzt werden);
  • Optional: SSL-Terminierung.

Bauen, Deployen, Testen – und Live gehen

Eine solche Umgebung wird immer aus den letzten Versionen gebaut, d.h. sowohl aus dem letzten Bauplan als auch aus den aktuellsten Applikationsbausteinen.

Nun kann der lokal entwickelte Code in die nächste Umgebung deployed und dort getestet werden. Ein typischer Workflow kann wie folgt aussehen:

  • Ein Entwickler baut sich eine lokale Umgebung basierend auf dem aktuellsten Mastercode und Containern mit shared Backends;
  • Neue Funktionen werden lokal entwickelt/modifiziert und anschließend automatisch gebaut und deployed;
  • Die Tests können nun gegen den DEV-Branch durchgeführt werden (hier stehen alle Tools des Unit Testing zur Verfügung);
  • Nach erfolgreichen lokalen Tests kann der neue Branch in den zentralen Test-Branch committed werden;
  • Mit einem erfolgreichen Merge in den Master-Branch stehen die Neuerungen für einen erneuten Bau einer lokalen Umgebung wieder zur Verfügung.

Zu guter Letzt kann die neue Version nach ausführlichen Integrationstests live gehen. Da alle „Umgebungen“ aus dem gleichen Code gebaut werden, sind die lokale DEV-Umgebung, die Test- und später die Live-Umgebung 100% codeidentisch. Lediglich die Redundanz-Einstellungen, d.h. wie viele Pods je Service gespornt werden, sind (verständlicherweise) in der PROD-Umgebung etwas großzügiger.

Gerne diskutieren wir mit Ihnen/Dir über den konkreten Einsatz von Kubernetes in agilen DevOps-Teams.

(Volker Müller)

Keine Kommentare


Dein Kommentar:

* Pflichtfelder

Time limit is exhausted. Please reload CAPTCHA.