gjp311 - stock.adobe.com
Bei Containernetzwerken gleich die Skalierung einplanen
Wer Containernetzwerke mit Kubernetes und Docker aufbaut, sollte deren spätere Skalierung von Anfang an mit ins Netzwerkkonzept einbeziehen und beim Design von Adressräumen berücksichtigen.
IT-Organisationen entscheiden sich häufig für Docker-fähige Netzwerk- und Scheduling-Technologien. Sie setzen solche Umgebungen für skalierbare Installationen, Reinstallationen funktionsunfähiger Komponenten, gemeinsam genutzte Mikroservices und die unternehmensweite Anwendungsintegration ein. Besonders wichtig sind dabei die kritischen Gebiete Adress- und Workflow-Management. Kubernetes löst die meisten Probleme und Aufgaben rund um Docker-Containernetzwerke, sofern Anwender ihr Kubernetes-Anwendungsmodell sorgfältig planen.
Docker-Netzwerke sind im Prinzip einfach. Ein Docker-Host ist im Grunde ein privates IP-Subnetz, wie viele Heimnetze. Innerhalb des Subnetzes kann alles miteinander kommunizieren, nichts kann von außen in das Subnetz hineinsehen, wenn nicht ein interner Port bewusst geöffnet wird. Das Design von Kubernetes-Netzen setzt voraus, dass jeder Container mit jedem anderen reden kann. Es mag so scheinen, als ob Kubernetes-Vernetzung mehr als Docker bietet, aber beide sind lediglich unterschiedlich. Für eine funktionierende Installation kann man zusätzliche Werkzeuge und Technologien verwenden, die das Containernetz unterstützen.
Die wichtigste Entscheidung bei der Installation von Containern ist wahrscheinlich, wie man das Kubernetes-Netzwerk aufbaut. Seine Gestaltung muss dem Kubernetes-Netzwerkmodell universeller Verbundenheit zwischen den Containern gehorchen, aber auch den Anwendern die richtigen Applikationen zur Verfügung stellen, Verbindungen mit Komponenten außerhalb von Kubernetes ermöglichen und die Integration mit der Public Cloud für manche Applikationskomponenten unterstützen.
Zahlreiche Tools eignen sich, um Container zu vernetzen. Eine Herangehensweise verwendet externe Steuerung und Software-definierte Vernetzung (SDN). Entsprechende Werkzeuge sind Cisco Application Centric Infrastructure (ACI), VMware NSX, Juniper Contrail und Nokia Nuage. Ein anderes Modell favorisiert die direkte Nutzung von Kubernetes. Beliebte Beispiele sind Kube-Router, Multus und andere Kubernetes-Plug-ins. SDN-basierte Vernetzung ist bei weitem am flexibelsten und wird sehr wahrscheinlich den bestehenden unternehmensweiten Vernetzungsbedarf befriedigen. Deshalb sollte man ernsthaft über SDN nachdenken.
Kubernetes-Funktionen für das Container-Management
Um containerisierte Applikationen für Kubernetes-Anwender sichtbar zu machen, verwendet man Services. Das sind Abstraktionen von Komponentenschnittstellen, die auf Kubernetes-Pods abgebildet werden. Diese Pods unterstützen auf einer Seite die Komponentenschnittstelle, auf der anderen eine externe Schnittstelle. Die externe Schnittstelle kann eine private Intracluster-Adresse ansprechen (das entspricht dem Standard), eine externe Adresse oder einen Lastverteiler, der die Verarbeitungslast an eine Instanz des Service weiterleitet.
Diese servicebasierte Herangehensweise ermöglicht auch die Skalierung der Container. Dabei verbindet die Lastverteilerschnittstelle einen Service mit einer elastischen Gruppe von Pods. Der Lastverteiler verteilt die Verarbeitungslasten; Anwender können dessen Liste verfügbarer Ressourcen aktualisieren, indem sie neue Ressourcen und Container in Betrieb nehmen. Diese neuen Ressourcen werden dort eingesetzt, wo sie gehostet sind. Will man das Netzwerk herunterskalieren, werden die Ressourcen sowohl vom Pod, der sie hostet, als auch aus der Ressourcenliste des Lastverteilers gestrichen.
Den Überblick über das Containernetzwerk zu behalten, ist eine Herausforderung, und es kommen weitere Aspekte hinzu.
Das Kubernetes Container Networking Interface ist eine Methode, Netzwerkaufgaben innerhalb von Kubernetes zu automatisieren und zu orchestrieren. Dazu gehört die Zuweisung von Services an Schnittstellen. Doch der Anwender muss das spezifische, dafür benötigte Netzwerk-Tool erst bereitstellen, beispielsweise eines der oben erwähnten SDN-Produkte. Er muss deren Adressräume verwalten, so dass alle Komponenten eindeutig adressierbar sind. Die meisten Kubernetes-Anwender verwenden private IP-Adressen für ihre Cluster und legen die Adressen von Mitarbeitern und Elementen außerhalb von Kubernetes auf dem Virtual Private Network (VPN) offen. Zudem ist es oft notwendig, auch Public-Cloud-Ressourcen anzubinden.
Adressierung in Containernetzwerken
Die Adressierung ist das zweite Schlüsselthema bei der Containervernetzung mit Kubernetes. Ein Containernetzwerk basiert fast immer auf privaten IP-Adressen. Sie sind lokal. Das bedeutet, sie funktionieren nur innerhalb einer Netzwerk-Domain. Diese kann ein Kubernetes-Cluster, ein Unternehmen oder eine andere bestehende Gruppe sein; die lokalen IP-Adressen sind nicht vom Internet oder einem anderen Unternehmen aus ansprechbar.
Der Internet-Standard 1918 (RFC 1918) beschreibt die Auslegung des privaten IP-Adressraums: Eine Class-A-Adresse (16 Millionen Adressen), 16 Class-B-Adressen (mit je 65.000 Adressen) und 256 Class-C-Adressen (mit je 256 Adressen). Die meisten Kubernetes-Anwender wählen die Class-A-Adresse, weil sie ihnen die größte Flexibilität beim weiteren Design ihres Adressraums bietet. Man sollte vermeiden, dass sich private IP-Adressen des VPN und die von Kubernetes oder von getrennten Clustern überschneiden. Für jeden dieser Bereiche sollte ein unterschiedlicher Adressraum oder ein Teil des Klasse-A-Adressraums gewählt werden, um Verwirrung zu vermeiden.
Global handeln, lokal verarbeiten
Kubernetes-Cluster sollten wo immer möglich auf physischen Hosting-Ressourcen aufgebaut werden, die entweder direkt verbunden oder zumindest im Allgemeinen lokal und gut genug angebunden sind, so dass die darin befindlichen Ressourcen untereinander austauschbar arbeiten können. Nähe beseitigt Risiken für die Qualität des Benutzungserlebnisses, die durch die Leistungs- und Kapazitätsgrenzen von Verbindungen innerhalb eines Containernetzwerks verursacht werden.
Sie treten auf, wenn ein Teil einer Applikation auf einem Server im Hintergrund in einem anderen Rechenzentrum installiert ist. Unterschiedliche Cluster sollten verwendet werden, wenn es klare geografische Trennungen innerhalb eines Ressourcen-Pools gibt. Es empfiehlt sich, folgender allgemeinen Regel zu folgen: Cluster brauchen einen gemeinsamen Adressraum. Anschließend entscheidet man, ob spezifische Cluster nur aufeinander bezogene Applikationen und Anwender unterstützen oder ob die Cluster füreinander einspringen sollen.
Ein Kubernetes-Anwender kann Workflows von einem unabhängigen Cluster an einen anderen weiterreichen, indem er deren Schnittstellen für die betreffenden Workflows auf dem VPN des Unternehmens sichtbar macht. Wenn die Cluster sich gegenseitig sichern, kann man auf die Föderationsfunktion von Kubernetes zurückgreifen, um zu bestimmen, welche Applikationen über mehrere Cluster hinweg synchronisiert werden und auf deren Ressourcen Anwender Cluster-übergreifend einheitlich zugreifen. Federation setzt voraus, dass Kubernetes den Status der betreffenden Applikationen Cluster-übergreifend synchronisiert – das kann viel Leistungskapazität beanspruchen. Deshalb sollte man statt dieser Funktion lieber traditionelle Rechenzentrumswerkzeuge oder direkt Kubernetes-Installations-Tools verwenden, um unabhängige Cluster aufzubauen oder Cluster-übergreifend Anwendungsversionen und Datenbanken zu synchronisieren.
Bei großen oder stark wachsenden Container-Installationen beginnt man mit Kubernetes an der Seite von Docker statt nur mit Docker und plant entsprechend dem Kubernetes-Netzwerkmodell, um zunächst das erwartete Wachstum des Containernetzes und dann Stadien darüber hinaus zu managen. Es ist mühselig, ein einmal installiertes Kubernetes-Netzwerkmodell zu verändern, wenn die Installation eine gewisse Größe erreicht hat. Daher erhöht es die Chance für ein gut funktionierendes Containernetzwerk, wenn man dessen Skalierung von Anfang an berücksichtigt.
Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!
