Rawpixel - Fotolia

Wie Container den Netzwerkbetrieb revolutionieren

Linux-Container erleben ihr großes Comeback. Nicht nur Entwickler sollten deshalb aufhorchen, Containernetzwerke ändern auch Rechenzentren erheblich.

Es ist kaum möglich, eine beliebige Technologiekonferenz zu besuchen und nicht mindestens einmal die Worte Docker und Container zu hören. Container sind eine alte Technologie, die eindeutig eine Nische bediente, bis Docker mit einem neuen Einsatzszenario auf den Plan trat und die Karten neu mischte. Die Software läutete eine neue Ära von DevOps ein, indem Entwickler ihre Anwendungen schnell in Pakete verpacken und bereitstellen konnten.

Beim Open-Source-Projekt von Docker handelt es sich nicht um die einzige Containertechnologie. Sie trägt aber dazu bei, die Containerbewegung insgesamt zu beflügeln, weil verschiedene Anbieter und Endnutzerorganisationen versuchen, von den Vorteilen zu profitieren, die Container ermöglichen.

Und während der Einsatz der Containertechnologie bislang weitgehend durch Entwickler vorangetrieben wurde, bestimmen die Popularität und umfangreichen Bereitstellungen von Containern zunehmend anspruchsvolle Netzwerkanforderungen. Container bieten unzählige Möglichkeiten für Netzwerktechniker, um komplexe Herausforderungen im Netzwerk zu vereinfachen.

Eric Hanselman, leitender Analyst bei 451 Research, beschäftigt sich mit Containern und wie sie sich von anderen Formen der Virtualisierung unterscheiden, insbesondere von virtuellen Maschinen (VMs).

„Die Funktionalität von Containernetzwerken ist weitaus simpler als das, was in ausgereifteren virtuellen Umgebungen zur Verfügung steht“, sagt Hanselman. „Dies mag zwar beim Arbeiten an der größeren Skalierbarkeit von Containern nützlich sein, bedeutet jedoch einen höheren Aufwand, um jede Form von Komplexität in die Umgebung zu integrieren.“

In Bare-Metal- und physischen Umgebungen funktionieren Containernetzwerke ähnlich wie der Netzwerkbetrieb unter VMware – mit zwei Abweichungen, wie Brandon Philips, CTO von CoreOS, einem Anbieter für Containerplattformen, feststellt. Erstens, so erklärt Philips, wechseln Container häufiger als dies bei VMs der Fall ist. Also muss das Netzwerkdesign diesem Umstand Rechnung tragen. Zweitens führen die Anwender sehr viel mehr Container aus als VMs. Aus diesem Grund ist der Adressbereich, den eine Containerumgebung belegt, höchstwahrscheinlich größer.

Bei einer VM wird ein Betriebssystem in der Regel als Teil des VM-Anwendungs-Images bereitgestellt. Das Containermodell hingegen verlässt sich hinsichtlich der Betriebssystemfunktionen auf das Hostsystem. Das Image einer Containeranwendung kann kleiner ausfallen, da es kein eigenes Betriebssystem als Teil eines Anwendungsimages benötigt. Gleichzeitig kann die entsprechende Dichte einer Containerbereitstellung höher sein als eine Umgebung, die auf VMs basiert. Es ist ebenfalls anzumerken, dass Container und VMs sich nicht gegenseitig ausschließen. Im Gegenteil: Häufig ist es eine empfohlene Best Practice, dass Container innerhalb einer VM laufen.

Containernetzwerke: Lücken und Chancen

Im Container selbst stellt eine IP-Schnittstelle die einzige Sorge für den Entwickler dar, wie Hanselman erläutert. Aber um Containern, insbesondere Docker-Containern, Ausfallsicherheit oder Mehrinstanzfähigkeit hinzuzufügen, benötigt man deutlich mehr als die native Netzwerkfunktionalität.

„Die Netzwerkkonfigurationen einer großen Anzahl von Containern zu automatisieren, ist entscheidend, um kompliziertere Anwendungsarchitekturen in Angriff zu nehmen“, meint Hanselman.

Vergleich VMs und Container.
Abbildung 1: Vergleich VMs und Container.

Das ist ein Gebiet, auf dem noch einiges zu erledigen ist. Hier eröffnet sich eine Chance für Drittanbieter, die Lücke mit Open-Source-Projekten für Containernetzwerke zu füllen. Beispiele hierfür sind Weave Net von Weaveworks und Flannel von CoreOS.

Der Kern, auf dem Dockers Netzwerktechnologie hauptsächlich basiert, nennt sich libnetwork. Die Komponente wurde erstmalig zusammen mit Docker 1.7 im Juni 2015 angekündigt und im November desselben Jahres mit dem Release von Docker 1.9 als stabiles Verfahren in das Hauptprojekt übernommen.

Chen Chun, Softwaretechniker bei Tencent – einem in den Geschäftsfeldern Onlinespiele, soziale Netzwerke und Unterhaltung höchst erfolgreichen Konzern mit Sitz im chinesischen Shenzhen –, ist sowohl Nutzer von als auch Mitwirkender bei Docker. Speziell zu libnetwork hat Chun einiges an Code beigetragen. Chun erklärt, dass Tencent, ein Unternehmen, das bestens bekannt ist für seinen Instant Messenger QQ und seinen mobilen Chatdienst WeChat, das von libnetwork bereitgestellte Overlay-Netzwerk nutzt, um Konnektivität für Multihost-Apps zu ermöglichen. Darüber hinaus verwendet Tencent die in Docker eingebauten Funktionen für das Arbeiten mit Bridge-Netzwerken.

„Ein Bridge-Netzwerk erlaubt es uns, ein ungenutztes Host-Port-Mapping dem Port eines Containers zuzuweisen“, sagt Chun. „Das hilft uns, mehrere Instanzen eines Onlinejobs auf demselben Host zu starten.“

Bridging bringt allerdings auch eigene Einschränkungen mit sich. Chun erläutert, dass Bridge-Netzwerke auf Portkonflikten beruhende Probleme lösen und für Container, die auf einem Host laufen, Netzwerkisolation bieten. Trotzdem ist mit Bridging alleine die IP-Adresse des Containers von außerhalb des Hosts nicht sichtbar.

„Das bedeutet Schwierigkeiten, weil viele Webserverprogramme IP-Adressen und Ports in einer Service-Discovery-Schicht registrieren“, sagt Chun. „Daher haben wir ein Docker-Netzwerk-Plug-in für statische IPs entwickelt, um jedem Container eine IP-Adresse zu geben, die routingfähig ist.“

Tencent ist in der Lage, seine Docker-Container mit einer statischen IP-Adresse von jedem internen Rechner aus anzupingen und eine Verbindung per Secure Shell (SSH) zu diesen Containern herzustellen. Möglich wurde das Netzwerk-Plug-in dank libnetwork. Das Plug-in bietet einen skalierbaren Ansatz für individuell angepasste Containernetzwerke.

Auch bei einem anderen wichtigen Netzwerkproblem kann Dockers libnetwork Tencent unter die Arme greifen, um den Betrieb zu vereinfachen: begrenzte IP-Adressressourcen in einem statischen IP-Netzwerk.

„Die gute Nachricht lautet: Das Overlay-Netzwerk ermöglicht uns unbegrenzte IPs“, freut sich Chun.

Er fügt hinzu, dass das IT-Team bei Tencent herausgefunden hat, dass eine Reihe von Anwendungen in einem isolierten Netzwerk ohne externe Konnektivität arbeiten können. Zum Beispiel benötigen einige Test-Apps lediglich eine Verbindung zu einer gemeinsam genutzten Datenbank. Overlay-Netzwerke eignen sich perfekt für solche Szenarien. Ein isoliertes Overlay-Netzwerk bietet einen privaten IP-Adressbereich für verbundene Endpunkte.

Die Rolle von Microservices

Ein Begriff taucht häufig auf, wenn von Containern die Rede ist: Microservices. Die grundlegende Idee hinter Microservices besteht darin, dass man es nicht mit einem monolithischen Anwendungs-Stack zu tun hat. Stattdessen wird jeder einzelne Dienst in einer Application Delivery Chain in separate Einheiten aufgeteilt.

„Wenn die Nutzer Container einsetzen, versuchen sie bewusst, ihre Infrastruktur in verständlichere Komponenten zu untergliedern“, meint Philips von CoreOS. „Ich glaube, dadurch eröffnet sich eine Möglichkeit, dass Netzwerktechnologien Entscheidungen im Interesse des Users treffen, die sie zuvor, als wir uns in einer auf [virtuelle] Maschinen zentrierten Welt befanden, nicht treffen konnten.“

Ein potenzielles Einsatzszenario, das Philips vor Augen schwebt, dreht sich um Kubernetes. Dabei handelt es sich um eine Open-Source-Technologie zur Containerorchestrierung, die ursprünglich von Google stammt, aber jetzt unter Federführung der Cloud Native Computing Foundation (CNCF) steht. Die Foundation selbst arbeitet als Linux Foundation Collaborative Project. Die CNCF erfreut sich der Unterstützung vieler bekannter Namen aus der IT-Branche, einschließlich AT&T, Cisco, eBay, Fujitsu, Google, Huawei, IBM, Intel, Twitter und VMware.

Wenn ein Administrator für eine bestimmte Anwendung, die auf Kubernetes läuft, 500 MBit/s reserviert, so Philips, kann die Netzwerkkontrollschicht in die Zeitplanung für diese Anwendung einbezogen werden, um den besten Zeitpunkt zu finden, an dem die gewünschte Bandbreite garantiert zur Verfügung steht. Indem sie mit der Kubernetes-API arbeitet, kann eine Netzwerkkontrollschicht auch eingehende Firewall-Regeln erstellen, die die Containeranwendungen erkennen. Laut Philips handelt es sich hierbei durchweg um Szenarien der näheren Zukunft, die dazu beitragen können, Containernetzwerke einfacher bereitzustellen und zu nutzen.

Hoffnungen auf eine gemeinsam genutzte Netzwerkschnittstelle

Eine Reihe von Organisationen verwenden Network Address Translation (NAT) mit Overlays am Backend, damit Container öffentliche IP-Adressen erhalten, sagt Philips.

„Wenn im Laufe der Zeit immer mehr Nutzer ihre Stacks auf Container umstellen, werden sie aus Gründen der Einfachheit, Sichtbarkeit und Geschwindigkeit eine NAT-freie Lösung bevorzugen“, erklärt er.

Unter den NAT-freien Ansätzen befindet sich ein Container Networking Interface (CNI), eine Standardschnittstelle für Containernetzwerke, die fester Bestandteil der CNCF werden soll.

„Bei CNI geht es darum, Netzwerkanbieter in die Lage zu versetzen, ihre Kontrollschicht in das Containerökosystem zu integrieren“, meint Philips. „Die Schnittstelle ist minimal gehalten und wurde in Zusammenarbeit mit etlichen Technikern der Netzwerkanbieter entwickelt.“

Wenn immer mehr Nutzer ihre Stacks auf Container umstellen, werden sie aus Gründen der Einfachheit, Sichtbarkeit und Geschwindigkeit eine NAT-freie Lösung bevorzugen.
Brandon Philips, CoreOS

Philips hofft, dass durch eine gemeinsam genutzte Schnittstelle ein Ökosystem von Netzwerkhardware und -anwendungen entsteht, das man in Kubernetes, Rocket/rkt und jedes andere Containertool, das ein CNI verwendet, integrieren kann.

„Damit das Containerökosystem erfolgreich bleibt, müssen wir diese gemeinsam genutzten Schnittstellen so definieren und fördern, dass sie sich mit Storage- und Netzwerklösungen verbinden lassen, da die Unternehmen ihre vorhandenen Systeme weiterhin werden nutzen wollen“, gibt Philips zu bedenken. „Außerdem bin ich der Ansicht, dass die CNCF gut positioniert und organisiert ist, um diese Anstrengungen zu unterstützen.“

Unter den Netzwerkoptionen, die sich in ein CNI einklinken können, ist das Open-Source-Projekt Flannel von CoreOS, das ursprünglich eingeführt wurde, um User mit Containern und Kubernetes vertraut zu machen. Flannel ist nach Aussage von Philips eine einfache, zusammensetzbare Komponente, die in vorhandene Systeme integriert werden kann. Ab der Docker-Version 1.9 vom November 2015 werden Multihost-Netzwerke nun in der Docker-Engine selbst unterstützt. Das bedeutet, dass die Docker-Engine direkt mit der in Flannel implementierten Funktionalität konkurriert.

Der Containerbereich entwickelt sich rasant, und da Entwicklung und Bereitstellungen andauern, wird es höchstwahrscheinlich zu Verbesserungen bei Containernetzwerken kommen. Für Benutzer wie Chun von der Firma Tencent tragen Docker-Containernetzwerke bereits dazu bei, die Komplexität von Netzwerken zu reduzieren.

Andere jedoch sehen nach wie vor eine Menge latenter Schwierigkeiten für den Netzwerkeinsatz von großen Containerbereitstellungen.

„Die Arbeit rund um absichtsbasierte Netzwerkkonfigurationen kann helfen, dieses Problem in den Griff zu bekommen“, sagt Hanselman von 451 Research. „Wir haben schon erlebt, was mit Pass-Through-Labeln in Kubernetes passiert, und das ist vielversprechend. Die Herausforderung besteht darin, die unterschiedlichen Bemühungen miteinander in Einklang zu bringen, so dass wir mindestens zu einer kleinen Anzahl von Netzwerkmodellen mit Containern kommen.“

Folgen Sie SearchNetworking.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im Mai 2016 aktualisiert

Erfahren Sie mehr über LAN-Design und Netzwerkbetrieb

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close