.png)
Kubernetes Cluster I/O ist ein großes Durcheinander — aber Hilfe ist unterwegs
Die Verbreitung von Schnittstellen, APIs und Abstraktionen für den Ein- und Ausgang von Kubernetes hat zu verschiedenen Herausforderungen in der Welt der Container-Orchestrierung geführt.
Anders lässt sich die enorme Verbreitung von Schnittstellen und Abstraktionen zur Steuerung des ein- und ausgehenden Netzwerkverkehrs, auch Inputs and Outputs (I/O) genannt, in Kubernetes-Clustern nicht beschreiben. Es ist ein großes Durcheinander.
Die gute Nachricht ist, dass sich die Community dessen bewusst ist und daran arbeitet, die Dinge zu verbessern.
In diesem Blog werden wir die Verbreitung und die Bemühungen zur Vereinfachung der Landschaft erörtern.
Wie sind wir hergekommen? Eine kurze Geschichte von Kubernetes-Cluster I/O
Am Anfang gab es nur eine offizielle Upstream-Ingress-Control-Ressource für Kubernetes, die einfach als „Ingress“ bekannt war. Es war einfach und hatte nur minimale Funktionen, was zur Erstellung und Bereitstellung mehrerer anderer Ingress-Controller-Ressourcen mit unterschiedlichen Funktionen und APIs für die Interaktion mit ihnen führte.
Die ursprüngliche Kubernetes-Ingress-Ressource wird derzeit zugunsten einer neueren Gateway-Ressource und API eingestellt, die in der Arbeitsgruppe des Kubernetes SIG-Netzwerks speziell entwickelt wurden, um der Verbreitung ähnlicher, aber unterschiedlicher Implementierungen von Ingress-Funktionen entgegenzuwirken.
API-Gateways und Service Meshes teilen sich die Ingress-Funktionalität
Im Zuge der Migration von API-Managementlösungen in die Cloud und Kubernetes-Lösungen in Form von API-Gateways wurde ein weiteres Steuerelement hinzugefügt, das funktionell ein Ingress-Controller ist. Zusätzlich zu den etwa einem Dutzend Kubernetes-Ingress-Controllern gibt es etwa ein Dutzend Kubernetes-API-Gateways, die den Kubernetes-Benutzern eine weitere Dimension der Komplexität und Verwirrung verleihen.
Und dann sind da noch die vielen verschiedenen Service-Mesh-Implementierungen und APIs, die quasi eine weitere Eingangsschnittstelle sind (in das Mesh-Netzwerk, das von den verteilten Proxys implementiert wird). Dieselben funktionalen Anforderungen, die Ingress-Controller und API-Gateways umfassen, sind erforderlich, um den ein- und ausgehenden Verkehr von Service-Mesh-Gateways zu kontrollieren, wo Cluster-I/O in vielen Produktionsnetzwerken stattfindet.
Zusammenfassend lässt sich sagen, dass der aktuelle Stand der Schnittstellen- und API-Verbreitung rund um Cluster-IO die Summe all dieser verschiedenen Implementierungen in den verschiedenen Lösungskategorien ist.
Die Schattenseiten der Proliferation
Diese Verbreitung hat zwei große Nachteile:
- Das schnelle Wachstum von Schnittstellen und APIs hat zu einer größeren Angriffsfläche mit API-Schwachstellen geführt wird immer häufiger.
- Die große Anzahl verfügbarer Lösungen für Ingress-Controller, API-Gateways und Service Mesh-Funktionen sorgt für Verwirrung und Komplikationen bei den Endbenutzern. Dies hat zu einer Umgebung geführt, in der Anbieter und Benutzer mehrere „Sprachen“ sprechen müssen, um umfassende Kubernetes-Unterstützung für Sicherheitsrichtlinien bieten zu können.
Da im Kubernetes-Ökosystem immer mehr Lösungen auftauchen, überschneiden sich die Funktionen der verschiedenen Eingangs- und Ausgangskategorien zunehmend. Diese Überschneidung führt zu Verwirrung bei der Auswahl der Tools und erhöht die Komplexität einer ohnehin schon herausfordernden Landschaft.
Warum das komplexe Kubernetes-Ökosystem eine Richtlinienstandardisierung benötigt
Das Container Network Interface (CNI) definiert die API für das Senden von Cluster-internem Netzwerkverkehr zwischen Pods, und es gibt eine Reihe beliebter interoperabler Implementierungen, darunter OVN, Calico, Cilium usw. Obwohl es einige einzigartige Erweiterungen in den verschiedenen Produkten gibt, teilen sie einen gemeinsamen Kern von Netzwerkrichtlinienfunktionen, mit denen Plattformbetreiber angeben können, welche netzwerkfähigen Entitäten wie kommunizieren können.
Netzwerkrichtlinien sind so optimiert, dass sie eine standardmäßige Verweigerungsumgebung bereitstellen, in der Zulassungsregeln Ausnahmen von diesem Verhalten sind, das auf der Identifizierung des Datenverkehrs anhand von Labels, Namespaces, Bereitstellungen und anderen Cloud-nativen Metadatenattributen basiert. Dies sind genau die primitiven Funktionen, die eine gute Grundlage für die Filterung des ein- und ausgehenden Datenverkehrs von Kubernetes-Clustern bilden würden. Das CNI hat jedoch keinen zusätzlichen Clusterbereich, weshalb dieser standardisierte Ansatz in der Welt der Ingress-Controller und API-Gateways nicht geteilt wurde.
Die Service Meshes verfügen in der Regel über ähnliche Tools zur Verkehrsfilterung, die im Vergleich zu den für CNIs definierten Netzwerkrichtlinien keinen standardisierten Ansatz verfolgen. Service Mesh führt auch Layer-7-Filterung und Zulassungslisten ein, die für CNI-APIs nicht in den Geltungsbereich fallen und bei der Einführung in der CNI-Arbeitsgruppe noch keine Fortschritte erzielt wurden.
Standardisierungsbemühungen der Kubernetes-Community
Um diese Probleme anzugehen, ergreifen Gruppen verschiedene Initiativen zur Standardisierung von Eingangs- und Ausgangsschnittstellen und APIs. Dazu gehören mehrere wichtige Bemühungen unter der Leitung der Kubernetes Network Special Interest Group (SIG), darunter die Network Policy Working Group, die Gateway Working Group und die GAMMA Initiative.
Gateway-Arbeitsgruppe
Die Gateway Working Group ist verantwortlich für die Entwicklung einer einheitlichen API für die Verwaltung des ein- und ausgehenden Datenverkehrs in Kubernetes-Clustern. Das Hauptprojekt der Gruppe ist Kubernetes Gateway-API welches entwickelt wurde, um eine flexiblere und ausdrucksstärkere API für die Konfiguration des eingehenden und ausgehenden Kubernetes-Datenverkehrs bereitzustellen6]]. Durch das Angebot einer standardisierten API will die Gateway Working Group den Prozess der Bereitstellung und Verwaltung von Kubernetes-Netzwerkkomponenten vereinfachen.
Durch das Angebot einer standardisierten API will die Gateway Working Group den Prozess der Bereitstellung und Verwaltung von Kubernetes-Netzwerkkomponenten vereinfachen.
Kubernetes Gateway-API V1.0
Die Kubernetes Gateway-API wurde entwickelt, um einige der Einschränkungen und Probleme zu beheben, die mit der ursprünglichen Eingangsressource verbunden sind. Diese Verbesserungen beheben die Einschränkungen der ursprünglichen Eingangsressource und bieten einen effizienteren und benutzerfreundlicheren Ansatz für die Verwaltung des Netzwerkverkehrs in Kubernetes-Umgebungen.
Um mehr über die wichtigsten Verbesserungen der Gruppe zu erfahren, greifen Sie auf diese Ressourcen zu:
Initiative GAMMA
Das GAMMA-Initiative (Gateway-API, Mesh und Middleware) ist eine Zusammenarbeit zwischen verschiedenen Kubernetes-SIGs und Interessenvertretern der Branche. Ziel ist es, die APIs und Schnittstellen, die für den ein- und ausgehenden Kubernetes-Verkehr verwendet werden, zu konsolidieren und zu standardisieren. Diese Initiative zielt darauf ab, Verwirrung und Komplexität für Endbenutzer zu verringern und die Bereitstellung und Verwaltung von Kubernetes-Netzwerkkomponenten zu vereinfachen.
Arbeitsgruppe Netzwerkpolitik
Die Network Policy Working Group konzentriert sich auf die Definition und Implementierung von Netzwerkrichtlinien für Kubernetes, um die Sicherheit und Isolierung zwischen Pods, Diensten und anderen Netzwerkeinheiten in einem Kubernetes-Cluster zu verbessern. Es unterstützt derzeit eine Vielzahl von Tools zur Spezifizierung des Netzwerkverkehrs. Es wird häufig von gängigen CNIs implementiert und ist daher kein Tool, das auf eingehenden/ausgehenden Cluster-Verkehr angewendet wird.
Die Gruppe arbeitet derzeit an mehreren Projekten:
- Administrative Netzwerkrichtlinie: Bietet Clusteradministratoren mehr Kontrolle über Netzwerkrichtlinien, indem eine höhere Abstraktionsebene eingeführt wird. Auf diese Weise können Administratoren globale, clusterweite Richtlinien definieren, die konsistent auf alle Namespaces angewendet werden können.
- Netzwerkrichtlinie V2: Behebt die Einschränkungen bei der aktuellen Implementierung von Netzwerkrichtlinien, indem neue Funktionen eingeführt und die bestehende API erweitert werden, z. B. Unterstützung für die Filterung des ausgehenden Datenverkehrs, erweiterte Funktionen zum Abgleich von Richtlinien und eine verbesserte Durchsetzung von Richtlinien für mehr Sicherheit.
- NetworkPolicy++: Einführung erweiterter Netzwerkrichtlinien-Funktionen durch Erweiterung der bestehenden Network Policy API. Dies bietet eine detailliertere Kontrolle über Verkehrsmanagement, Sicherheit und Isolierung und ermöglicht es Benutzern, ausgefeilte Richtlinien zu erstellen, die auf ihre spezifischen Bedürfnisse zugeschnitten sind.
Die Übernahme durch die Gemeinschaft ersetzt Normungsorganisationen
Weiter oben in diesem Blog gibt es Hinweise auf Bemühungen zur Standardisierung von Abstraktionen und APIs, aber das ist nicht unbedingt eine Bestätigung dafür, dass dies über traditionelle Standardisierungsorganisationen wie IETF, ITU, IEEE usw. geschieht. Open-Source-Communities stimmen mit der Zeit ihrer Entwickler und ihrer Codebasis ab, daher ist die faktische „Standardisierung“ aufgrund der flächendeckenden Bereitstellung in der Community der wichtigste Erfolgsmaßstab.
Die Einführung der Kubernetes Gateway-API und die Abschaffung der Ingress-Ressource sind ein Beispiel dafür, wie eine Community, die sich der Verbesserung ihrer Infrastrukturplattform verschrieben hat, zusammenkommt, um weitreichende Änderungen vorzunehmen, ohne aus dieser Investition einen Wettbewerbsvorteil zu ziehen.
Zum Zeitpunkt der Veröffentlichung dieses Blogs gab es 19 Open-Source-Ingress-Controller- und Service-Mesh-Projekte in verschiedenen Phasen der Entwicklung ihrer Gateway-API-Implementierung, um ihre vorherige maßgeschneiderte Implementierung zu ersetzen. Die meisten davon befinden sich derzeit in der Betaversion und mehrere sind allgemein verfügbar (GA).
Schnelle, gemeinsame Implementierung ist die neue Methode, Softwareschnittstellen mit der Geschwindigkeit der Community-Entwicklung zu standardisieren. Die Arbeit, die in der Network SIG geleistet wird, ist keine akademische Arbeit. Die Community hat ihre Bereitschaft gezeigt, zu den in den Arbeitsgruppen definierten gemeinsamen Schnittstellen und APIs beizutragen und sie anschließend zu übernehmen. Jeder kann nach Belieben teilnehmen und Beiträge leisten.
Immer noch Verbesserungspotenzial?
Die Arbeiten, die derzeit innerhalb der Network SIG laufen, werden viel von dem Chaos beseitigen, das derzeit in Bezug auf Cluster-I/O herrscht. Es gibt jedoch noch andere Dimensionen der Verwirrung und Komplexität, die von der Community nicht berücksichtigt wurden.
Die Arbeit der GAMMA-Initiative zur gemeinsamen Nutzung von Ingress-Funktionen und APIs mit der Arbeit der Gateway-API-Arbeitsgruppe trägt wesentlich zur Erkenntnis bei, dass die funktionalen Anforderungen an Service Mesh denen eines CNI sehr ähnlich sein können, wo herkömmlicher Ingress für Nicht-Service-Mesh erfolgt.
Trotz dieser Arbeit gibt es weiterhin funktionale Überschneidungen zwischen CNI und Service-Mesh, die nicht aufeinander abgestimmt sind. In der Anfangszeit implementierte das CNI Layer-Netzwerkrichtlinien, um den Datenverkehr auf den Ebenen 3 und 4 zu filtern, und Service Mesh filterte ausschließlich einen Teil dieses Datenverkehrs heraus, indem es nur die Protokollelemente der Schicht 7 betrachtete.
Die Arbeitsgruppe für Netzwerkpolitik entwickelt und standardisiert die API, die von allen verschiedenen CNI-Anbietern übernommen wird. Die meisten beliebten Service Mesh-Lösungen verfügen jedoch auch über eine nicht standardisierte Form der Layer-3- und 4-Filterrichtlinien-API. Keiner plant, dies mit der Arbeit der Network Policy Working Group in Einklang zu bringen.
Gleichzeitig gibt es keine vergleichbare Gruppe, die versucht, die APIs für die Layer-7-Filterung zu standardisieren, die von verschiedenen Service Meshes unterschiedlich implementiert werden (obwohl ihre gemeinsame Verwendung des Open-Source-Envoy-Proxy zur Durchsetzung von Filtern zu einer großen Einheitlichkeit führt). Organisatorisch könnte es schwierig sein, die Abstraktionen zwischen den verschiedenen Software-Artefakten (CNIs im Vergleich zu Service Meshes) zu vereinheitlichen, da es kein Projekt gibt, das sich darum kümmert und es implementiert. Aus architektonischer Sicht ist das sinnvoll, aber die Vereinheitlichung könnte eher eine CNCF-Führungsperspektive als eine projektzentrierte Perspektive einnehmen.
Wo wird das alles enden?
Wenn akzeptiert wird, dass eine kontinuierliche funktionale Überschneidung zwischen CNIs und Service Meshes unvermeidlich ist, bedeutet das, dass das Ziel der Network SIG letztlich darin bestehen sollte, eine gemeinsame API für die relevanten Sicherheits-, Verkehrsmanagement- und Routing-Funktionen zu definieren, unabhängig davon, ob sie in etwas implementiert sind, das als CNI, Service Mesh oder eine andere Art der Bereitstellung einer virtuellen Netzwerkabstraktion verpackt ist.
Experten für Kubernetes-Infrastrukturen werden einige gute Einwände erheben, die auf den Architekturprinzipien basieren, die ein CNI von einem Service Mesh unterscheiden und eine logische Trennung von Funktionen und Standards vorschreiben. Aus UX-Sicht besteht jedoch das Risiko, taub zu sein und die Systembenutzer einer auf Systementwickler ausgerichteten, von unten nach oben gerichteten Oberfläche auszusetzen, die die „Nerd-Knöpfe“ zum Vorschein bringt.
Wenn es für Benutzer selbstverständlich ist, sowohl an einen CNI-Anbieter als auch an ein Service Mesh zu denken, die ihren Netzwerk-Stack und ihre Funktionen implementieren, könnte dies die Attraktivität der Plattform erhöhen, wenn sie mehr gemeinsame Abstraktionen und APIs gemeinsam nutzen. Die Netzwerkrichtlinie verfügt über eine Vielzahl von Filterfunktionen für die Auswahl des Datenverkehrs und die Durchführung bedingter Aktionen. Es könnte erweitert und verbessert werden, um alle abstrahierten, Kubernetes-fähigen Match-/Action-Regeln für clusterinterne, clusterübergreifende und clusterübergreifende Netzwerke zu handhaben.
Teilen Sie uns mit, was Sie vom Wert gemeinsamer Abstraktionen in allen Anwendungsfällen der Verkehrsverarbeitung halten. Wenn Sie sich für dieses Thema interessieren, behalten Sie diese Arbeit im Auge, die schnell voranschreitet und viele Kubernetes-Benutzer betreffen wird.
Erfahre mehr über Illumio von kontaktiere uns noch heute.
.webp)
