Netzwerke in Docker
Andockmanöver
Wer Docker-Container betreibt, hat die Wahl zwischen mehreren Netzwerkmodi – eingebauten und über Plug-ins nachrüstbaren. Sie eignen sich jedoch nicht für jeden Einsatzbereich gleich gut.
Oft gerät in Vergessenheit, dass Container an einigen Stellen die inhärente Komplexität von Virtualisierung erben. Zwar sind sie eine viel leichtfüßigere Methode als etwa KVM oder Xen, aber dass beispielsweise virtuelle Netze ein komplexes Thema sind, ändern sie nicht. Klar: Auf einer frischen CentOS- oder Ubuntu-Installation lässt sich ein einzelner Container schnell starten. Der Einsatz in einem produktiven Setup wirft aber zwangsläufig die Frage nach passenden Netzwerkansätzen auf. Das gilt umso mehr, wenn sich verschiedene Nutzer denselben Host teilen sollen.
Docker bietet eine Fülle von Funktionen, aus denen Administratoren schöpfen können – für jeden Einsatzzweck findet sich dabei die passende Technik. In diesem Artikel stellt iX die diversen Ansätze für Netzwerke in Containern mit Docker vor. Explizit kommt die Frage aufs Tapet, welche Option sich für welchen Anwendungsfall am besten eignet.
Was mancher Administrator sich als Wunschszenario ausmalt – eine Network Interface Card (NIC) pro virtueller Maschine oder Container –, ist nicht realistisch. Zum einen würde der Ansatz kaum skalieren, denn für jede neue Instanz müsste man eine passende Netzwerkkarte einbauen. Zum andern wäre die Anzahl der verfügbaren Anschlüsse begrenzt – mehr als sechs Netzwerkkarten wird man kaum verbauen können, und selbst wenn jede davon 4 Ports hat, landet man noch immer bei nur 24 Schnittstellen. Container hingegen lassen sich in einer viel größeren Anzahl auf aktueller Hardware betreiben. Kurz gesagt: Dieser Ansatz ist zum Scheitern verurteilt.
Längst ist es deshalb üblich, den Host mit einer potenten Netzwerkkarte zu versehen und die virtuellen Instanzen mit virtuellen NICs (vNIC) auszustatten, die mit der physischen Netzwerkkarte verbunden sind. Wer in früheren Jahren Virtualisierung betrieben hat, kennt noch den Ansatz: Auf dem Host richtet man eine Netzwerkbrücke ein, die den VMs (oder Containern) als Verbindungspunkt dient. Diese redet direkt mit der Hardware und sorgt letztlich dafür, dass innerhalb der virtuellen Instanzen eine ganz normale Verbindung zur Verfügung steht.
Große skalierbare Umgebungen haben eben dieses Prinzip erweitert – denn wer virtuelle Maschinen per API-Anfrage automatisch starten und stoppen möchte, muss dafür sorgen, dass die virtuellen Netzwerkkarten auf den Hosts automatisch angelegt und mit den neuen, ebenfalls virtuellen Instanzen direkt verbunden sind. Das ist die Domäne des Software-defined Networking (SDN): Eine SDN-Lösung wie Open vSwitch legt auf den Zielsystemen eine Art virtuellen Switch an, der dynamisch um Ports erweitert werden kann, mit denen sich die virtuellen Systeme verbinden. Der Nachteil: SDN-Lösungen sind in aller Regel komplexe Gebilde, deren Verständnis viel Zeit beansprucht und die im Vorfeld sinnvoll geplant sein wollen. Sonst kann es später zu Problemen kommen, die sich eventuell nicht mehr korrigieren lassen.
Die Situation bei Containern
Der beschriebene Effekt gilt wohlgemerkt für virtuelle Maschinen ebenso wie für Container – welche Art von Dienst eine virtuelle NIC am Ende nutzt, ist zunächst irrelevant. Einen Vorteil haben Administratoren von Container-Farmen aber gewöhnlich: Die Setups sind insgesamt viel weniger komplex, etwa weil die Mandantenfähigkeit keine große Rolle spielt. Das wird sehr deutlich, wenn man OpenStack und Kubernetes vergleicht: OpenStack kommt mit vielen Hilfswerkzeugen und unterstützenden Diensten daher, sodass das Setup alleine bereits einigen Aufwand bedingt. Klar, dass die gebaute Plattform aus Sicht des Administrators am Ende mandantenfähig sein soll, damit er diese Arbeit nur einmal leisten muss.
Leicht anders verhält es sich mit Kubernetes: Das bietet weniger Funktionen und kommt mit deutlich geringerem Overhead aus. Viele Unternehmen bauen deshalb bevorzugt einen dedizierten Cluster auf Kubernetes-Basis pro Kunde, statt einen Cluster zwischen mehreren Kunden zu teilen.
Docker selbst bietet fünf Netzwerkmodi, auf die auch Kubernetes zurückgreifen kann. Von Haus aus enthalten sind: bridge, host, overlay sowie macvlan und none. Ergänzend dazu existiert eine Plug-in-Schnittstelle, über die sich externe Funktionen nachrüsten lassen – das gilt explizit auch für Netzwerkfunktionen. Wer etwa eine SDN-Lösung an seine Docker-Umgebung anbinden möchte, erledigt das über ein Plug-in.
Ruhe im Karton
Lediglich der Vollständigkeit halber sei der Netzwerkmodus none kurz erwähnt. Denn nomen est omen: Wer als Netzwerkfunktion für einen Container none definiert, sorgt schlicht dafür, dass dieser keine virtuelle NIC bekommt und mit der Außenwelt folglich nicht kommunizieren kann. Im Einzelfall mag solch eine rigide Abkapselung von der Außenwelt begründet sein, die Regel ist sie definitiv nicht.
Der Bridge-Modus eines Containers implementiert im Wesentlichen das Prinzip der virtuellen Netzwerkbrücken. Das ist zugleich der Standard, falls der Administrator nichts anderes festlegt. Bridges (siehe Abbildung 1) kommen bevorzugt zum Einsatz, wenn mehrere Container auf einem Host miteinander kommunizieren, etwa weil Dienste Daten austauschen. Installiert man Docker aus den Standardpaketen des Anbieters, konfigurieren diese auf dem System eine Standardbrücke namens bridge, mit der sich automatisch alle neuen Container verbinden. Das kann zu Problemen führen: Alle Instanzen auf demselben Host können darüber ungehindert miteinander kommunizieren – auch wenn sie unterschiedlichen Kunden gehören. Denn innerhalb einer Netzwerkbrücke existieren in Docker keine Schranken, die Kommunikation wird also nicht noch beispielsweise nach iptables-Regeln gefiltert.