Der neue OSI-Netzwerk-Stack: Container und Halbschichten
Im Jahr 1983, als ich noch lernte, wie ich einen Blick auf die Hardware meines Apple ][e werfen und sie untersuchen konnte, kam eine Gruppe gleichgesinnter Leute aus der Computer- und Telekommunikationsbranche zusammen, um eine detaillierte Spezifikation zu erstellen, die sie Open Systems Interconnection (OSI) nannten. Was als Versuch begann, tatsächliche Schnittstellen auszuarbeiten, entwickelte sich schließlich zu einem gemeinsamen Referenzmodell, das wiederum von anderen – wie etwa der IETF – zur Entwicklung von Schnittstellen verwendet werden konnte. Diese Schnittstellen könnten sich irgendwann zu Standards entwickeln – und das ist auch der Fall: IP, TCP, HTTP usw.
Dieses Referenzmodell wurde den meisten von uns beigebracht, als wir uns durch die Informatikkurse an der Universität quälten. Wir lernten die „sieben Schichten von OSI“ kennen, mussten jedoch in der Praxis feststellen, dass sich tatsächliche Implementierungen nur selten sauber auf das OSI-Netzwerkmodell abbilden lassen.
Die Abbildungsqualität ist jedoch ausreichend gut, so dass wir es weiterhin als das Referenzmodell verwenden, das es sein soll. Die meisten von uns verstehen, dass sich Schicht 4 auf TCP, Schicht 7 auf HTTP und Schicht 2/3 auf IP und Ethernet bezieht. Sie sind nahezu austauschbar.
Vor einigen Jahren kam es sogar zu Debatten darüber, wohin genau die mit SDN und virtuellen Netzwerken verbundenen Overlay-Protokolle gehören. Sie gehörten nicht wirklich zur Schicht 2, aber auch nicht genau zur Schicht 3. Sie lagen irgendwie dazwischen.
Wir konnten das größtenteils ignorieren und haben die beiden Schichten nur vage abgetan und es lediglich als „Overlay-Networking“ bezeichnet. Jeder verstand, was wir meinten, und wir hatten andere Dinge, über die wir streiten konnten – etwa über die Definition der Cloud und darüber, ob DevOps für das Unternehmen geeignet war oder nicht.
Geben Sie Container ein – oder genauer gesagt: Container-Netzwerke. Die äußerst volatile und automatisierte Welt der Container Orchestration Environments (COE) hat die Notwendigkeit weiterer Schichten im Netzwerk-Stack entstehen lassen.
Wie beim Overlay-Networking sind wir nicht geneigt, neue Schichten im OSI-Modell zu erstellen, da es sich mittlerweile um eine Standardreferenz handelt und das Ändern von Standards lange dauern kann. Entlang. Lang. Zeit. Aber wie beim Overlay-Networking existieren diese Schichten weiterhin als existentielle Schnittstellen im Netzwerkstapel. Und wie beim Overlay-Networking bin ich geneigt, ihnen „halbe“ Schichten zu geben, weil sie für die Zukunft des Networkings im COE so wichtig sind.
SCHICHT 4.5: SERVICE-NETZ
Der erste „Halbton“ liegt zwischen den Schichten 4 und 5. Hier kommen die Ausführung und Automatisierung des Service Mesh ins Spiel. Kurz gesagt besteht ein Service-Mesh aus Side-Car-Proxys, die jede Anfrage abfangen. Dadurch können sie domänenspezifisches Routing für Dienste in der gesamten Containerumgebung ausführen. Es geht davon aus, dass Protokolle niedrigerer Ordnung vorhanden sind, und erweitert diese effektiv. Dies ist erforderlich, da alle darunter liegenden Netzwerkschichten davon ausgehen, dass Konnektivität und Routing ausschließlich auf der IP-Adresse basieren. Und obwohl Pakete in einer Containerumgebung letztlich auf diese Weise verschoben werden, basiert die Entscheidung, an welche IP-Adresse und an welchen Port eine bestimmte Anforderung gesendet wird, nicht auf diesen Informationen. Es basiert auf einer Vielzahl von Variablen im Zusammenhang mit dem Service- und Anwendungsstatus sowie dem Standort. Im Wesentlichen sehen wir uns die Metainformationen zu einer Anfrage an und verwenden diese, um zu bestimmen, wie sie weitergeleitet werden soll. Diese Metainformationen sind für die Erstellung des „Netzes“ von entscheidender Bedeutung, das wiederum die Verfügbarkeit und Skalierbarkeit jedes Dienstes sicherstellt.
SCHICHT 7.5: SERVICE-TAGS
Der zweite „Halbton“ befindet sich fast oben, über Ebene 7. Abgesehen von allen Witzen über die „menschliche Ebene (Ebene 8)“ platziert COE tatsächlich eine Ebene mit Metadaten über der Anwendung, die den „Klebstoff“ bereitstellt, der die Skalierung in Containerumgebungen ermöglicht. Hierbei handelt es sich um die Anwendungs- oder Service-Tags, die zur Identifizierung einzelner Services verwendet werden, für die das COE eine automatisierte Skalierung anbietet. Ohne die Tags ist es fast unmöglich, eine App von einer anderen zu unterscheiden. Dies liegt daran, dass alle Schichten des OSI-Stapels anhand bestimmter Konstrukte wie IP-Adresse und Port identifizierbar sind. Obwohl wir seit langem Verständnis für Architekturimplementierungen haben, die auf der gemeinsamen Nutzung dieser Konstrukte außerhalb der Umgebung (virtuelle Server und hostbasierte Netzwerke) basieren, haben Container innerhalb der Umgebung dieselben Probleme verursacht. Die gemeinsame Nutzung von Ports und IP-Adressen erschwert die Unterscheidung zwischen Diensten bei den erforderlichen Geschwindigkeiten.
Das Hinzufügen von „Tags“ auf Ebene 7.5 in containerisierten Umgebungen bietet diesen Netzwerkdiensten (wie Lastausgleich und Routing) die Möglichkeit, Ressourcen eindeutig zu identifizieren und gleichzeitig Skalierbarkeit und Verfügbarkeit sicherzustellen.
Die neuen „Containerebenen“ ermöglichen es der Umgebung, sich von Netzwerkkonstrukten abzukoppeln und gewährleisten dabei eine höhere Portabilität als frühere Technologien, die eng mit anderen Ebenen im Netzwerkstapel verbunden blieben. Durch den Betrieb auf „Halbebenen“ und die Annahme der Existenz traditioneller Ebenen werden containerisierte Umgebungen von jedem spezifischen Netzwerkschema oder jeder spezifischen Architektur unabhängig und können mit der gleichen Leichtigkeit zwischen Entwicklung und Test, Test und Produktion sowie vor Ort und in der Cloud wechseln.