Interview mit Jörg Müller

Tools zur Container-Orchestrierung: Kubernetes oder Docker Swarm?

Hartmut Schlosser

Jörg Müller

Wer vor der Aufgabe steht, mehrere containerisierte Services in einem Cluster zu verwalten, kommt an einer Lösung zur Container-Orchestrierung kaum vorbei. Etabliert haben sich in den letzten Monaten hier vor allem Kubernetes und Docker Swarm. Im Interview mit JAXenter erklärt Jörg Müller, Principal Consultant bei innoQ und Sprecher auf dem Microservices Summit, welches Tool für welchen Einsatzzweck geeignet ist.

JAXenter: Du hältst auf dem Microservices Summit einen zweiteiligen Workshop zu Kubernetes. Für wen ist Kubernetes interessant? Welche Art von Anwendungen bzw. Systemen profitieren besonders davon?

Kubernetes ist für alle interessant, die sich mit dem Betrieb von Software beschäftigen.

Jörg Müller: Kubernetes ist natürlich für alle interessant, die sich mit dem Betrieb von Software beschäftigen. Die Verwaltung einer großen Menge von Services in Containern verteilt auf viele Rechner in einem oder sogar in mehreren Rechenzentren ist eine Herausforderung. Kubernetes bietet dafür eine Lösung, die jeder, der in diesem Bereich tätig ist, gesehen haben sollte. Es ist aber auch für Entwickler sowie Architekten interessant, weil es Lösungen für viele Probleme verteilter Systeme anbietet. Aspekte, die sonst in den Anwendungen selbst gelöst werden müssten, können auf der Ebene der Infrastruktur gelöst werden. So kann die Entwicklerin sich in ihrem Service auf die eigentlichen Geschäftsanforderungen konzentrieren.

Von Kubernetes profitieren vor allem verteilte Anwendungen. Moderne Microservice-Architekturen profitieren mehr als monolithisch aufgebaute Anwendungen. Eine Anwendung, die eine große Anzahl von Rechnern benötigt, um ihre Last zu bewältigen, passt besser zu Kubernetes als eine Anwendung, für die zwei oder drei Hosts vollkommen ausreichen. Die Frage, ob die Anwendungen in der Cloud oder auf eigenen Rechnern betrieben wird, spielt hingegen eine untergeordnete Rolle. Kubernetes bietet eine Abstraktionsschicht, um verteilte Anwendungen zu schneiden, die dann auf den unterschiedlichsten Installationen funktionieren.

JAXenter: Nun ist um die ganze Container-Technologie ein riesiger Hype entstanden – manche sehen in der Containerisierung gar eine Revolution der IT. Was ist dran an diesem Hype? Wo liegt aus deiner Sicht die entscheidende Neuerung?

Jörg Müller: In der Tat hat sich die Containerisierung von Anwendungen erstaunlich schnell durchgesetzt. Das ist insbesondere beim sonst recht konservativen Betrieb bemerkenswert. Docker ist gerade etwas über 5 Jahre alt, und Kubernetes liegt erst seit etwas über zwei Jahren in einer stabilen Version vor. Scheinbar sind diese Technologien auf einen großen Bedarf getroffen. Es sind mehrere Neuerungen, die hier zusammenkommen.

Die Vorteile von Docker zeigen sich sowohl zur Laufzeit als auch bereits davor als Transportformat. Zur Laufzeit bieten Container eine Isolation auf Ebene der Prozesse, des Filesystems und des Netzwerks. Das löst viele Probleme, die beim klassischen Betrieb mehrerer Anwendungen oder Services auf einem Host auftraten. Die Behandlung von Konflikten bei sich überschneidenden Abhängigkeiten auf der selben Maschine wird unnötig. Auch lange Abstimmungslisten zu Port-Nummern im Wiki benötigt man nicht mehr. Eine solche Isolation benötigt sonst virtuelle Maschinen, die jedoch deutlich ressourcenintensiver sind als Container.

Gleichzeitig bietet Docker ein eigenes Transportformat in Form der Images und Lösungen zu deren Speicherung und Deployment. Images bekommen mit einem URI-artigen Format eine eindeutige ID, mit Registries können Images leicht gespeichert und verteilt werden, und schließlich liegt mit dem Dockerfile ein sehr einfaches Format vor, um neue Images zu definieren. Dabei bauen sie aufeinander auf, was Wiederverwendung und zentrales Patchmanagement erlaubt. Viele Aspekte davon wurden vorher bereits durch verschiedene Werkzeuge gelöst, aber jetzt gibt es sie zusammen in einem einfach nutzbaren Paket.

Kubernetes ergänzt das jetzt noch um Abstraktionen, die es erlauben, die gesamte Servicelandschaft mit Code zu beschreiben. Dabei bleibt es aber so einfach, dass es kein tiefes Wissen über die Infrastruktur voraussetzt. Entwicklerinnen beschreiben nur den Teil, der für die Anwendung notwendig ist. Um die Spezifika der jeweiligen Infrastruktur kann sich dann kümmern, wer den Cluster in einer spezifischen Infrastruktur aufsetzt.

JAXenter: Wie setzt du persönlich Kubernetes ein? In welchen Technologie-Setup ist es eingebettet?

Jörg Müller: Ich ganz persönlich nutze Kubernetes sogar privat. So läuft minikube auf meinem Homeserver, um verschiedenste Dienste zu Hause zu betreiben. Das ist eine kleine Variante von Kubernetes, die sich leicht auf einem einzelnen Rechner aufsetzen lässt.

In Projekten ist Kubernetes oft bei einem Cloud-Provider installiert. Das ist meistens der schnellste Weg, die notwendige Infrastruktur zu bekommen. Dabei verwenden wir speziell bei AWS im Moment KOPS als Installationswerkzeug, mit dem sich sehr schnell ein Cluster bei Amazon einrichten lässt. Die AWS eigene Lösung EKS ist zwar angekündigt, aber selbst die Beta-Zugänge sind aktuell noch rar. Oft verwenden wir ein Kubernetes-Cluster in der Cloud, um schnell eine Entwicklungsumgebung in Projekten zu bekommen. Die eigentliche Produktionsumgebung benötigt ein aufwändigeres Setup und läuft dann manchmal auch nicht mehr in einer Public Cloud, sondern wird in anderen Rechenzentren installiert. Dank der einheitlichen Schnittstellen und Abstraktionen kann die bereits erstellte Software trotzdem leicht migriert werden.

JAXentr: Nun hältst du deinen Workshop ja auf einem Microservices Summit. Wo liegt der Zusammenhang zwischen Kubernetes und Microservices-Architekturen?

Kubernetes löst eine Reihe von Problemen, die in jeder Microservice-Infrastruktur gelöst werden müssen.

Jörg Müller: Kubernetes löst eine Reihe von Problemen, die in jeder Microservice-Infrastruktur gelöst werden müssen. Das ist sicher auch ein Grund für die hohe Popularität. Es fängt mit dem Deployment an. Container erlauben das Entwickeln in beliebigen Technologien, was gerade bei Microservices-Architekturen oft beabsichtigt ist. Dabei ermöglicht Kubernetes die unterschiedlichsten Deploymentverfahren für die Software in diesen Containern. Unterbrechungsfreie Rollouts sind so realisierbar, ohne dass sie für jede Technologie neu implementiert werden müssen.

Ein anderes Problem stellt die Konfiguration der Software für unterschiedliche Umgebungen wie z.B. Test oder Produktion dar. Auch hier bietet Kubernetes Lösungen, wie Konfigurationsdaten einheitlich verteilt werden können, ohne dass das die in den Containern laufende Software speziell berücksichtigen muss. Schließlich ist es für Microservices immer auch ein wichtiger Aspekt, wie sie andere Services finden und sich mit ihnen verbinden. Die dazu notwendigen Service-Discovery-Mechanismen und damit verbundenes Load Balancing bringt Kubernetes ebenfalls mit. Hinzu kommt die Überwachung der laufenden Container und das Management, sollte einmal ein Service ausfallen.

All diese Aspekte sind in Microservice-Projekten bisher oft manuell oder mit jeweils spezifischer Software implementiert worden. Die Tatsache, dass Kubernetes dies jetzt von Hause aus mitbringt, hat die Hürde für eine Microservice-Architektur deutlich gesenkt.

JAXenter: Kubernetes konkurriert als Orchestrierungslösung u.a. mit Docker Swarm. Wo liegen hier die Unterschiede?

Jörg Müller: Beide lösen das Problem der Container-Orchestrierung gut, benutzen dabei aber unterschiedliche Philosophien. Docker Swarm setzt auf eine einfache Installation und einen eher monolithischen Ansatz. Alles Notwendige ist in einem Binary enthalten und kann damit leicht auf mehrere Nodes verteilt werden. Auch die Konfiguration folgt diesem Prinzip der einfachen Nutzung. Sie ist in vielen Fällen nicht komplizierter als die Konfiguration mehrerer Container mit Docker-Compose, was viele auch lokal kennen und verwenden.

Kubernetes verfolgt einen kleinteiligen Ansatz. Es besteht aus vielen Komponenten, von denen es oft noch unterschiedliche Implementierungen gibt. So listet die Kubernetes Webseite z.B. aktuell 18 Möglichkeiten, um das Networking zwischen den Nodes zu implementieren. Das macht die Installation aufwendiger und bedingt normalerweise den Einsatz von Installationstools, wie z.B. KOPS. Gleichzeitig ist es dadurch deutlich flexibler und kann den individuellen Bedürfnissen in seiner Umgebung sehr gut angepasst werden.

Ähnlich ist es mit der Konfiguration. Diese ist bei Kubernetes deutlich umfangreicher. Aber auch hier gibt es viel Unterstützung durch Werkzeuge. Die Einstiegshürde ist bei Kubernetes sicher höher als bei Docker Swarm. Letztendlich werden die eigenen Anforderungen an die Anpassungsfähigkeit des Clusters ausschlaggebend für die Entscheidung für die eine oder andere Lösung sein.

JAXenter: Wie sollte sich Kubernetes deiner Meinung nach weiterentwickeln? Was fehlt dir noch an Features?

Jörg Müller: Momentan muss man bei der Installation eines Kubernetes Clusters sehr darauf achten, dass die notwendigen Security-Funktionen installiert und eingerichtet werden. Dabei geht es um Beschränkungen der Möglichkeiten in einzelnen Containern oder Pods, um umfangreiche Einstellungsmöglichkeiten für Nutzerrechte und um Firewall-Regeln innerhalb des Clusters. Inzwischen bieten viele der Installationstools dafür bereits Lösungen, aber oft ist das noch mit Mehraufwand verbunden. Hier kann sich Kubernetes noch deutlich weiter entwickeln. Ein produktionsreifer Cluster auf Knopfdruck sollte in nicht allzu ferner Zukunft möglich sein.

Ein anderer großer Trend sind Service Meshes. Sie nutzen die Möglichkeiten von Kubernetes, um die Kommunikation zwischen Services in einem Cluster zu steuern. Damit werden weitere Bausteine hinzugefügt, die eine Microservice-Architektur vereinfachen. Probleme wie Authentifizierung, Resillience, Handling der Kommunikationsverschlüsselung oder das Tracing von Aufrufen zwischen Services werden dann durch die Infrastruktur zur Verfügung gestellt. Das ist wieder einen Schritt näher zu der Idee, dass sich der Entwickler eines Services nur um die tatsächlich geschäftsrelevanten Teile seiner Anwendung kümmern muss.

JAXenter: Vielen Dank für dieses Interview!

Jörg Müller ist Principal Consultant bei innoQ. Seit mehr als zwanzig Jahren arbeitet er in verschiedenen Rollen in der IT-Beratung und Software-Entwicklung. In den letzten Jahren beschäftigt er sich schwerpunktmäßig mit der Architektur und dem Betrieb von Software as a Service. Aktuelle Themen sind Continuous Delivery, Microservices und Docker. In der Community ist er als Autor aktiv, hält Vorträge und ist beteiligt an der Organisation der JUG Berlin-Brandenburg sowie mehrerer Konferenzen.

 

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Tools zur Container-Orchestrierung: Kubernetes oder Docker Swarm?"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Christian
Gast

„So kann die Entwickler_in_“ Uff! Muss das jetzt auch hier sein? Immerhin besser als Gender-Sternchen, sprachlich ist es aber völliger Unsinn.
http://www.belleslettres.eu/content/deklination/genus-gendersprech.php