Kubernetes frisst Infrastruktur

Kubernetes ist eine der wichtigsten Plattformumstellungen in der Geschichte der Datenverarbeitung. Kubernetes ist die Art und Weise, wie wir verteilte Cloud-native Anwendungen bereitstellen, planen und betreiben. Die Plattform wird schnell zur De-facto-Methode für moderne Anwendungen im Umgang mit Cloud-Infrastrukturen, einschließlich Rechen-, Speicher-, Netzwerk-, GPU- und DPU-Ressourcen. Ob in der öffentlichen Cloud, am Edge oder in privaten Umgebungen (private Rechenzentren oder Colocation-Zentren) - Kubernetes ist überall präsent. Im Gegensatz zu VMs abstrahiert und quantifiziert Kubernetes die Infrastrukturressourcen in einer freundlichen und intuitiven Weise, die für die Bereitstellung von Cloud-nativen Anwendungen entwickelt wurde. Es betrachtet die Infrastruktur aus einer praktischen, auf die Anwendungskomponenten ausgerichteten Sichtweise. Durch diese Abstraktion der Infrastruktur ermöglicht Kubernetes die Portabilität von Anwendungen über mehrere Clouds und Umgebungen hinweg, ob privat oder öffentlich. (Natürlich nur, solange keine direkten "harten" Abhängigkeiten von Plattformdiensten bestehen, die von den jeweiligen Clouds bereitgestellt werden).

Mit der zunehmenden Beliebtheit von Kubernetes wächst auch das Ökosystem der operativen Tools rasch. Wie Kubernetes sind auch diese Tools Cloud-nativ und können an jede Umgebung in jeder Cloud, ob privat oder öffentlich, angepasst werden, wobei sie dieselbe Infrastrukturabstraktion nutzen. Die Beobachtung, Bereitstellung und Fehlersuche über mehrere Clouds hinweg erfolgt auf standardmäßige, nicht maßgeschneiderte Weise unter Verwendung offener De-facto-Toolchains. Hunderttausende von Entwicklern, SREs und DevOps-Teams nutzen diese Tools täglich, ohne Angst haben zu müssen, in einer proprietären Sackgasse zu landen. Diese Tools werden organisations-, unternehmens- und cloudübergreifend genutzt, so dass das Wissen um diese Tools eine überall einsetzbare Fähigkeit darstellt.

Vernetzung sollte mehr in die Cloud gehen

Fast überall - nichts davon trifft auf moderne Netzwerke zu. Obwohl standardmäßige Cloud-native Ops-Tools für die Verwaltung und Überwachung von Cloud-Netzwerken gang und gäbe sind, können wir das Gleiche nicht über physische Netzwerke außerhalb der öffentlichen Cloud sagen. Physikalische Netzwerke in privaten Umgebungen befinden sich noch im Vor-Cloud-Zeitalter. Wir verlassen uns immer noch auf maßgeschneiderte, anbieterspezifische Tools, die in erster Linie den Interessen der Anbieter, nicht aber denen der Anwender dienen. Management-Tools werden für die großen Netzwerkinfrastruktur-Anbieter immer mehr zu einer Plattform. Sie nutzen diese Tools, die oft als Service in der Cloud gehostet werden, als Mittel, um Kunden an ihr breiteres Angebot zu binden. Eine der Hauptinspirationen für dieses Modell war die erfolgreiche Meraki-Plattform von Cisco. Meraki hat Unternehmens-/Campusnetzwerke rund um seine in der Cloud gehostete Verwaltungsplattform verbraucherorientiert gestaltet und damit den Netzwerkbetrieb erheblich vereinfacht. Allerdings auf Kosten einer geringeren Auswahl an Hardwaresystemen und -anbietern, die von der Plattform unterstützt werden. Ein ähnlicher Produktlinienwechsel findet bei den Plattformen für Rechenzentren statt - NEXUS Cloud von Cisco, Cloud Vision von Arista und, in geringerem Maße, Apstra von Juniper. Netzwerkmanagement-Tools sind jetzt ein Mechanismus, um die Konkurrenz auszusperren.

In der Vergangenheit hat der Formfaktor der Auslieferung als Hardware-Appliance alles definiert - es ist einfach eine "Box". Die Art und Weise, wie wir Netzwerke verwalten, ist genau so - als ein Haufen von Kisten - eine Kiste nach der anderen. Die Vernetzung war die ursprüngliche verteilte Anwendung. Mit dem Aufkommen von Software-Netzwerkfunktionen wird der verteilte Anwendungscharakter von Netzwerken noch deutlicher. Neue Netzwerkanwendungen oder -dienste können überall ausgeführt werden - auf Switches, smartNICs, regulären Servern oder speziellen Serviceknoten (also regulären Servern, die jedoch speziell für die Netzwerkverwaltung vorgesehen sind). Die Netzwerkverwaltung wird immer mehr zur Software, und der Netzwerkbetrieb wandelt sich zu einem Softwarebetrieb.

Die Vernetzung verwandelt sich in eine Wolke.

Dieser "Box-Ansatz" funktioniert nicht für Software - es gibt einen besseren Weg. In operativer Hinsicht müssen wir die Vernetzung näher an die Computer- und Anwendungsplattformen heranführen. Wir müssen die gleiche Erfahrung bieten, die heute so viele in der Cloud machen, wo NetOps einfach ein Teil des normalen DevOps-Prozesses ist. Da so viele jüngere Infrastrukturspezialisten in der Cloud aufwachsen, müssen wir dafür sorgen, dass sich physische Netzwerke so anfühlen, verhalten und funktionieren, wie es diesen neuen Infrastrukturexperten vertraut ist.

Die Vernetzung sollte mehr Kubernetes werden

Entgegen der Meinung der großen Netzwerkausrüster sind die Netzwerkmanagement-Tools nicht die Plattform. Das physische Netzwerk ist nur ein kleiner, aber wesentlicher Teil des Infrastrukturbildes. Es ist für die Verbindung von Anwendungen untereinander, mit dem Internet und anderen Clouds und Umgebungen verantwortlich. In jeder Umgebung ist das physische Netzwerk ein integraler Bestandteil der Anwendung. Aber es ist der einzige Teil, der auf eine spezielle, maßgeschneiderte Weise verwaltet wird, die oft nicht mit den Abläufen der restlichen Infrastruktur und des Anwendungsstapels kompatibel ist. Und dieser Teil des Stacks wird vollständig von Kubernetes beherrscht, genau wie in der öffentlichen Cloud. Kubernetes ist eine sich schnell entwickelnde De-facto-Plattform für die Nutzung der Infrastruktur und eine hervorragende Möglichkeit zur Verwaltung moderner verteilter Anwendungen - genau das, was Netzwerke brauchen. Kubernetes lässt sich gut in eine breite Palette von De-facto-Betriebstools integrieren und funktioniert gut mit modernen Betriebsansätzen wie GitOps, Infrastruktur als Code/Daten, kontinuierliche Bereitstellung usw. Durch den Einsatz von Kubernetes wird das physische Netzwerk zu einer weiteren Komponente des standardmäßigen offenen Infrastruktur-Stacks.

Wie kommen wir dahin?

Ein Netzwerk-Betriebssystem

Zunächst benötigen wir ein offenes Netzwerkbetriebssystem (NOS), um die Vernetzung als moderne verteilte Anwendung bereitzustellen. Das NOS sollte modularisiert und containerisiert sein. Wir sollten in der Lage sein, jede seiner Komponenten oder Dienste wie eine Anwendung zu behandeln. Mit ein wenig (naja, vielleicht auch viel) Aufräumarbeit, SONiC kann diese Eigenschaften erfüllen. SONiC hat bereits eine große Fangemeinde und wird von den meisten White-Box- und Markensystemanbietern unterstützt. Es ist jedoch noch einiges an Arbeit erforderlich. Eine ganze Reihe von Initialisierungs- und Verwaltungsskripten muss entkoppelt, entwirrt und modularisiert werden. Ziel ist es, dass jeder Dienst unabhängig verwaltet und aktualisiert werden kann, ohne dass ein umfassenderer Neustart erforderlich ist, der andere Dienste beeinträchtigt. Eine Container-Laufzeitumgebung muss möglicherweise von Docker auf containerd migriert werden, um eine reibungslosere Interoperabilität mit Kubernetes und anderen modernen Cloud-nativen Tools zu gewährleisten. 

Kubernetes-Kontrollebene

Kubernetes ist ein hervorragendes Tool für die Bereitstellung von Software und die Verteilung von Konfigurationen. Es ist hochgradig modular und erweiterbar (über CRDs, Controller und Operatoren), was es zu einer idealen Grundlage für Infrastruktur-Controller macht. Wenn wir ein Netzwerk aus Switches, smartNICs und Serviceknoten in einen Kubernetes-Cluster umwandeln, können wir das Netzwerk als eine Reihe von verteilten Anwendungen behandeln. Dabei kann es sich um Routing-Protokolle, Utility-Funktionen, Beobachtungssonden, Proxies, API-Gateways, Policy Enforcer, Log Collection Agents oder Debug-Bots handeln. Die heutige Hardware ist unglaublich; was wir jetzt brauchen, ist bessere Software: kommerzielle, quelloffene oder selbstentwickelte Experimente.

Cloud-Native Ops und Beobachtbarkeit

Auf der operativen Seite wird Kubernetes die Integration mit häufig verwendeten Cloud-nativen Tools vereinfachen. Dies ermöglicht den nativen Einsatz von Observability-/Telemetrie-Tools wie ELK-Stack, Prometheus, Jaeger und Grafana. Automatisierungstools wie Terraform und ArgoCD ermöglichen standardmäßige DevOps-Praktiken wie GitOps und Infrastructure As Code. Die Integration mit diesen Tools bringt die gleichen operativen Ansätze, die DevOps- und SRE-Teams in der Public Cloud nutzen.

Abstraktion von Stoffen

Wir müssen die Netzwerkinfrastruktur für Menschen öffnen, die mit der Cloud aufgewachsen sind. Jeder, der sich mit Cloud-Netzwerken beschäftigt, ist mit dem Konzept einer VPC bestens vertraut. VPC ist eine grundlegende Einheit für die Netzwerknutzung und -isolierung in AWS. Sie ermöglicht es Ihnen, Ihr eigenes "Stück" des Cloud-Netzwerks zu haben, in dem Sie Ihre Anwendungen ausführen können. Das Konzept ist sehr abstrakt und gibt die zugrunde liegende Implementierung des Netzwerks nicht preis. Für den Benutzer spielt es keine Rolle, wie das Netzwerk unter der Haube implementiert ist. Der Benutzer hat keine direkte Kontrolle über die zugrunde liegenden Netzwerkkonzepte und -protokolle. Der einzige Weg, wie der Benutzer mit dem Netzwerk interagieren kann, ist die Abstraktion.

Ein ähnliches Verfahren sollte auch für das physische Netz außerhalb der Cloud angewandt werden. Die Abstraktion sollte dem Benutzer keine Instrumentierungs- oder Protokolldetails verraten und muss über entsprechende Instrumentierungsrichtlinien an mehrere Netzwerktechnologien angepasst werden können. Beispielsweise kann die Isolierung auf der Grundlage der Org, des Benutzers oder der Eigenschaften des VPC-Objekts entweder als VLANs oder BGP eVPNs. Instrumentierungsrichtlinien sind Eigentum des Netzwerkarchitekturteams und können vom Benutzer, der eine VPC zuweist, nicht geändert werden.

Die Zukunft wird weitaus futuristischer sein als ursprünglich angenommen.

Wir wollen das neue offene physische Netzwerk für die breite Masse zugänglich machen, die physische Infrastruktur vereinfachen, indem wir sie cloudfähiger machen, und das physische Netzwerk endlich aus dem Weg räumen. Daran arbeiten wir hart, Wirst du dich unserer Revolution anschließen?