Infrastrukturarchitektur: Container bilden die vierte Ebene

In der herkömmlichen Netzwerkinfrastruktur gibt es im Allgemeinen drei Architekturebenen, die mit der Netzwerkinfrastruktur verbunden sind: Daten, Steuerung und Verwaltung.

Die genauen Definitionen hierfür können je nach Art und spezifischer Implementierung der Infrastruktur variieren, die Archetypen sind jedoch für die meisten Netzwerkinfrastrukturen weitgehend zutreffend.

• Datenebene
  
  • Die Datenebene wird im modernen Sprachgebrauch manchmal als „Datenpfad“ bezeichnet und ist der Pfad, über den Pakete (Daten) weitergeleitet werden. Die Datenebene ist dafür verantwortlich, ein Paket anzunehmen und an das richtige Ziel weiterzuleiten.
• Kontrollebene
  
  • Im Allgemeinen bestimmt die Steuerebene, wohin Daten weitergeleitet werden. Routing-Protokolle und Entscheidungsprozesse höherer Ordnung, die heute möglicherweise dynamischer erfolgen, sind gute Beispiele für die Funktionen einer Steuerebene. Die konkrete Implementierung ist unterschiedlich, kann aber von der Datenebene, die Daten zur Entscheidungsfindung an die Steuerebene weiterleitet, bis hin zur transparenten Beobachtung der Daten durch die Steuerebene und Reaktion auf bestimmte Auslöser reichen. Kontrollebenen sind häufig auch für die Überwachung des Gerätezustands und die Erfassung von Statistiken verantwortlich.
• Verwaltungsebene
  
  • Die Managementebene ist die sichtbarste der drei Ebenen, da wir hier mit der Kontrollebene interagieren. Herkömmliche Verwaltungsebenen verwenden CLI (Befehlszeilenschnittstellen), während moderne Verwaltungsebenen API (Anwendungsprogrammierschnittstellen) bevorzugen. Unabhängig von der verwendeten Methode ermöglicht die Verwaltungsebene den Betreibern, Richtlinien festzulegen, die von der Kontrollebene durchgesetzt werden. Hierzu gehören Konfigurationsoptionen wie Lastausgleichsalgorithmen und Zulassungs-/Ablehnungsrichtlinien basierend auf Merkmalen wie IP-Adresse und Gerätetyp.

Doch dahinter verbirgt sich noch eine andere Art der Orchestrierung, die für die Betreiber weitgehend unsichtbar ist. Es hat nichts mit Management zu tun, außer dass es den menschlichen Bedienern einen Teil ihrer Verantwortung entzieht.

Der Unterschied besteht darin, dass die Aktionen automatisch durch Änderungen an der Umgebung während der Ausführung und nicht als Bereitstellungsereignis ausgelöst werden. Doch die Informationen über die Änderungen sind von entscheidender Bedeutung und müssen daher irgendwo beschafft werden.

In einem herkömmlichen Betriebsmodell stammen diese Informationen normalerweise aus Änderungstickets oder -anfragen. Bei modernen Betriebsmodellen und insbesondere Containern stammen diese Informationen über einen Erkennungsmechanismus aus Service-Registern.

Service-Registries und Discovery

In Containerumgebungen wird grundsätzlich davon ausgegangen, dass IP-Adressen für die Anwendungsumgebung praktisch keine Rolle spielen. Für die Infrastruktur sind sie jedoch von Bedeutung, da Daten weiterhin von Gerät zu Gerät geroutet und weitergeleitet werden müssen, um den Pfad zwischen dem Client und der Anwendung zurückzulegen. In modernen Umgebungen existieren diese IP-Adressen oft nur für kurze Zeiträume (die Lebensdauer eines Containers/Dienstes).

Beachten Sie diese Erkenntnisse von DataDog (Hervorhebung hinzugefügt):

Die schnelle Einführung von Orchestratoren ( siehe Fakt 4 ) scheint zu einer noch kürzeren Lebensdauer von Containern zu führen, da das automatisierte Starten und Stoppen von Containern zu einer höheren Fluktuationsrate führt. In Organisationen, die einen Orchestrator betreiben, beträgt die typische Lebensdauer eines Containers etwa 12 Stunden. In Organisationen ohne Orchestrierung hat der Container eine durchschnittliche Lebensdauer von sechs Tagen.

_{Von < https://www.datadoghq.com/docker-adoption >} 

Stellen Sie sich vor, Sie als Betreiber müssten die Routing-Tabellen oder Lastausgleichspools alle sechs Tage aktualisieren, geschweige denn alle zwölf Stunden. Sie würden kaum etwas anderes tun. Das Potenzial für Fehlkonfigurationen wäre erheblich und würde wahrscheinlich umso größer werden, je länger Sie gezwungen wären, die Änderungen in einem Container-Cluster im manuellen Modus zu verwalten.

Ein Service-Register – wie Consul – wird zu einer kritischen Komponente Ihrer Containerbereitstellung. Service-Registries verfolgen Instanzen und Services und die ihnen zugehörigen IP-Adressen. In dieser Hinsicht können sie mit einem „DNS für Container und Dienste“ verglichen werden. 

Daher verfolgt das Service-Register die aktuellen Eigenschaften der Container im Cluster. Bei der Erkennung handelt es sich um den Vorgang, bei dem (über eine API oder durch Abonnieren einer Nachrichtenwarteschlange) eine Verbindung zum Dienstregister hergestellt wird, um Instanzen mit IP-Adressen abzugleichen.

Dies bedeutet, dass eine Infrastruktur, die Datenverkehr an einen bestimmten Dienst oder eine bestimmte Instanz innerhalb eines Containerclusters weiterleiten muss, in der Lage sein muss, eine IP-Adresse abzurufen. Denn auch wenn Container das Netzwerk vor der Anwendung verbergen, sind sie dennoch darauf angewiesen, um Daten von einem Ort zum anderen zu transportieren.

Die vierte Ebene: Orchestrierung

Dadurch wird eine neue Architekturebene in die Infrastruktur eingeführt, die mit Container-Orchestrierungsumgebungen interagiert. Diese Schicht – die Orchestrierungsschicht – integriert sich in die Containerumgebung und nutzt Funktionen wie die Diensterkennung, um die Erkennung von Diensten und Instanzen zu automatisieren. Das bedeutet, dass ein Load Balancer die Mitglieder eines Pools automatisch erkennen und ihn basierend auf Änderungen in der Umgebung kontinuierlich aktualisieren kann. Dadurch wird der Betriebsaufwand verringert, der durch die manuelle Aktualisierung von Lastausgleichspools entsteht – eine zunehmend mühsame Aufgabe, wenn die Lebensdauer der Container im Durchschnitt weniger als eine Woche beträgt.

Dieses Flugzeug ist nicht für die Interaktion mit Bedienern vorgesehen. Konfiguration, Überwachung und Betrieb erfolgen weiterhin über eine Verwaltungsebene. Der Speicherort eines Service-Registers würde über die Verwaltungsebene konfiguriert, aber von der Orchestrierungsebene verwendet, um eine Verbindung mit der Steuerungsebene herzustellen und Änderungen an diese zu kommunizieren.

Wir können die Orchestrierungsebene wie folgt definieren.

• Die Orchestrierungsebene ist eine der am wenigsten sichtbaren Ebenen in der Infrastrukturarchitektur. Die Interaktion damit erfolgt über die Verwaltungsebene, die in erster Linie dafür verantwortlich ist, die Orchestrierungsebene auf das entsprechende Dienstregister auszurichten. Seine Aufgabe besteht darin, dynamische Komponenten in der Steuerebene zu aktualisieren, um die ordnungsgemäße Weiterleitung und Verfügbarkeit der containerisierten Ressourcen sicherzustellen.

Es bleibt noch die Frage, ob diese Ebene zusammen mit den Steuer- und Datenebenen in das Gerät integriert werden sollte oder ob es sich lediglich um eine Verkleidung über der Verwaltungsebene handelt (was unser Diagramm leicht ändern würde, aber ansonsten die Interaktion zwischen Ebenen und Komponenten nicht beeinträchtigen würde). Viele herkömmliche Geräte unterstützen diese neue Ebene bereits, indem sie Erweiterungen bereitstellen, die sich in Containerumgebungen integrieren und Änderungen über die Verwaltungsebene vornehmen. Dies ist ein schönes Beispiel für die Umgestaltung traditioneller Architekturen, um die Funktionalität auf moderne Umgebungen auszuweiten. Aber letztlich ist es vielleicht nicht die ideale Lösung. 

Warum ist das wichtig?

Auf den ersten Blick mag es so aussehen, als spiele die Einführung einer vierten Ebene für die Infrastruktur keine Rolle. Schließlich besteht seine Funktion darin, den Bedienern einen Teil der Verantwortung für langwierige Aufgaben abzunehmen. Das kann nicht schlimm sein.

Das ist nicht schlimm, aber es ist wichtig zu verstehen, dass dieser Wechsel von der statischen zur dynamischen Konfiguration Konsequenzen für einige der wichtigsten Funktionen der Steuerebene hat. Die Bedeutung der Diensterkennung nimmt derart zu, dass ihre Verfügbarkeit und Sicherheit zwingend erforderlich sein sollten. Tatsächlich wird es zum einzigen Ausfallpunkt, auf dem Ihre gesamte Anwendungsinfrastruktur beruht.

Service-Registries basieren auf denselben Voraussetzungen wie die meisten modernen Anwendungen: Sie sind für die Bewältigung von Fehlern konzipiert. Es kann passieren, dass die gerade ermittelte IP-Adresse verschwindet, bevor Sie den Datenverkehr an ihre Instanz weiterleiten können. Die meisten Infrastrukturen sind zu diesem Zeitpunkt zur erneuten Übertragung in der Lage, der Vorgang braucht jedoch seine Zeit. In der digitalen Wirtschaft kommt es auf Mikrosekunden an, daher machen traditionelle Optionen wie Zeitüberschreitungen und Erkennungsintervalle in modernen Architekturen, die auf Erkennung basieren, einen Unterschied. Auch die Überwachung wird immer wichtiger, da die Fähigkeit, Zustand und Verfügbarkeit schnellstmöglich zu ermitteln, den Unterschied zwischen der Zufriedenheit eines Benutzers und seiner Abkehr ausmachen kann. Beides sind Belange auf Geschäftsebene, die jeder in einer modernen Organisation kennen und in seine eigenen Maßstäbe und Erwartungen einbeziehen sollte.

Die Implementierung der Orchestrierungsebene in Ihrer Infrastruktur sowie die Wahl des Service-Registers werden zu wichtigen Faktoren in Ihrem Entscheidungsprozess bezüglich der von Ihnen verwendeten Technologie. Überlegen Sie sich Ihre Auswahl sorgfältig, da sie sich sowohl auf die Verfügbarkeit als auch auf die Leistung von Anwendungen auswirkt, die über containerbasierte Architekturen bereitgestellt werden.