.png)
Kubernetes-Cluster-I/O ist ein großes Chaos – aber Hilfe ist auf dem Weg
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 Ein- und Ausgänge (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 über die Ausbreitung und die Bemühungen sprechen, die unternommen werden, um die Landschaft zu vereinfachen.
Wie sind wir hierher gekommen? Eine kurze Geschichte der Kubernetes-Cluster-I/O
Zu Beginn gab es nur eine offizielle Upstream-Ingress-Kontrollressource für Kubernetes, die einfach als "Ingress" bekannt war. Es war einfach und hatte nur minimale Funktionen, die zur Erstellung und Bereitstellung mehrerer anderer Ingress-Controller-Ressourcen mit unterschiedlichen Funktionen und APIs für die Interaktion mit ihnen führten.
Die ursprüngliche Kubernetes-Eingangsressource wird derzeit zugunsten einer neueren Gateway-Ressource und -API veraltet, die in der Kubernetes SIG Network-Arbeitsgruppe speziell entwickelt wurden, um die Verbreitung ähnlicher, aber unterschiedlicher Implementierungen von Eingangsfunktionen zu bewältigen.
API-Gateways und Service-Meshes teilen sich die Eingangsfunktionalität
Mit der Migration von API-Management-Lösungen in die Cloud und Kubernetes-Lösungen in Form von API-Gateways wurde ein weiteres Control hinzugefügt, das funktional ein Ingress Controller ist. Zusätzlich zu den etwa einem Dutzend Kubernetes-Ingress-Controllern gibt es etwa ein Dutzend Kubernetes-API-Gateways, die Kubernetes-Benutzern eine weitere Dimension der Komplexität und Verwirrung hinzufügen.
Und dann gibt es noch die vielen verschiedenen Service-Mesh-Implementierungen und APIs, die effektiv eine weitere Eingangsschnittstelle (in das Mesh-Netzwerk, das von den verteilten Proxys implementiert wird) darstellen. Die gleichen funktionalen Anforderungen, die Ingress-Controller und API-Gateways umfassen, sind erforderlich, um den ein- und ausgehenden Datenverkehr von Mesh-Gateways zu steuern, bei denen Cluster-I/O in vielen Produktionsnetzwerken auftritt.
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
Es gibt zwei große Nachteile dieser Proliferation:
- Das rasante Wachstum von Schnittstellen und APIs hat zu einer vergrößerten Angriffsfläche geführt, wobei API-Schwachstellen immer häufiger auftreten.
- Die große Anzahl verfügbarer Lösungen für Ingress-Controller, API-Gateways und Service-Mesh-Funktionen führt zu Verwirrung und Komplikationen für Endbenutzer. Dies hat zu einer Umgebung geführt, in der Anbieter und Benutzer mehrere "Sprachen" sprechen müssen, um eine umfassende Kubernetes-Unterstützung für Sicherheitsrichtlinien zu bieten.
Da immer mehr Lösungen im Kubernetes-Ökosystem auftauchen, überschneiden sich die Funktionen aus den verschiedenen Ingress- und Egress-Kategorien zunehmend. Diese Überschneidung führt zu Verwirrung bei der Auswahl von Tools und erhöht die Komplexität einer ohnehin schon herausfordernden Landschaft.
Warum das komplexe Kubernetes-Ökosystem eine Standardisierung der Richtlinien erfordert
Das Container Network Interface (CNI) definiert die API zum Senden von clusterinternem Netzwerkverkehr zwischen Pods, und es gibt eine Reihe beliebter interoperabler Implementierungen, darunter OVN, Calico, Cilium usw. Obwohl es in den verschiedenen Produkten einige einzigartige Erweiterungen gibt, haben sie einen gemeinsamen Kern von Netzwerkrichtlinienfunktionen, die es Plattformbetreibern ermöglichen, festzulegen, welche netzwerkfähigen Entitäten wie kommunizieren können.
Netzwerkrichtlinien sind so optimiert, dass sie eine Standardverweigerungsumgebung bereitstellen, in der Zulassungsregeln Ausnahmen von diesem Verhalten darstellen, die auf der Identifizierung des Datenverkehrs basierend auf Bezeichnungen, Namespaces, Bereitstellungen und anderen Cloud-nativen Metadatenattributen basieren. Dies ist genau die Art von primitiven Funktionen, die eine gute Grundlage für die Filterung des ein- und ausgehenden Datenverkehrs von Kubernetes-Clustern wären. Der CNI verfügt jedoch nicht über einen Extra-Cluster-Bereich, und daher wurde dieser standardisierte Ansatz in der Welt der Ingress-Controller und API-Gateways nicht geteilt.
Die Service Meshes verfügen in der Regel über ähnliche Richtlinientools für die Filterung des Datenverkehrs, die im Vergleich zu den für CNIs definierten Netzwerkrichtlinien keinen standardisierten Ansatz haben. Service Mesh führt auch Layer-7-Filterung und Zulassungslisten ein, die nicht als in den Geltungsbereich von CNI-APIs fallend betrachtet wurden 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 für die Entwicklung einer einheitlichen API für die Verwaltung des ein- und ausgehenden Datenverkehrs in Kubernetes-Clustern verantwortlich. Das Hauptprojekt der Gruppe ist die Kubernetes Gateway-API , die eine flexiblere und ausdrucksstärkere API für die Konfiguration des ein- und ausgehenden Kubernetes-Datenverkehrs bereitstellensoll 6]]. Durch das Angebot einer standardisierten API zielt die Gateway Working Group darauf ab, den Prozess der Bereitstellung und Verwaltung von Kubernetes-Netzwerkkomponenten zu vereinfachen.
Durch das Angebot einer standardisierten API zielt die Gateway Working Group darauf ab, den Prozess der Bereitstellung und Verwaltung von Kubernetes-Netzwerkkomponenten zu 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 Netzwerkdatenverkehrs in Kubernetes-Umgebungen.
Um mehr über die wichtigsten Verbesserungen der Gruppe zu erfahren, greifen Sie auf diese Ressourcen zu:
GAMMA-Initiative
Die 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 Datenverkehr von Kubernetes verwendet werden, zu konsolidieren und zu standardisieren. Diese Initiative zielt darauf ab, Verwirrung und Komplexität für Endbenutzer zu reduzieren und die Bereitstellung und Verwaltung von Kubernetes-Netzwerkkomponenten zu vereinfachen.
Arbeitsgruppe Netzpolitik
Die Network Policy Working Group konzentriert sich auf die Definition und Implementierung von Netzwerkrichtlinien für Kubernetes, um die Sicherheit und Isolation zwischen Pods, Diensten und anderen Netzwerkeinheiten in einem Kubernetes-Cluster zu verbessern. Derzeit wird eine Vielzahl von Tools zum Angeben des Netzwerkdatenverkehrs unterstützt. Es wird häufig von beliebten CNIs implementiert und ist daher kein Tool, das auf ein- und ausgehenden Clusterdatenverkehr 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 Einschränkungen bei der aktuellen Implementierung von Netzwerkrichtlinien, indem neue Funktionen eingeführt und die vorhandene API erweitert werden, z. B. Unterstützung für die Filterung des ausgehenden Datenverkehrs, verbesserte Funktionen für den Richtlinienabgleich und verbesserte Richtliniendurchsetzung für eine bessere Sicherheit.
- NetworkPolicy++: Einführung erweiterter Netzwerkrichtlinienfunktionen durch Erweiterung der vorhandenen Netzwerkrichtlinien-API. Dies bietet eine detailliertere Kontrolle über das Traffic-Management, die Sicherheit und die Isolierung und ermöglicht es Benutzern, ausgefeilte Richtlinien zu erstellen, die auf ihre spezifischen Anforderungen zugeschnitten sind.
Die Einführung in der Community ersetzt Normungsorganisationen
Weiter oben in diesem Blog gibt es Verweise auf Bemühungen, Abstraktionen und APIs zu standardisieren, aber das ist nicht unbedingt eine Bestätigung dafür, dies über traditionelle Standardisierungsorganisationen wie IETF, ITU, IEEE usw. zu tun. Open-Source-Communities stimmen mit der Zeit ihrer Entwickler und ihrer Codebasis ab, so dass das Erreichen einer faktischen "Standardisierung" aufgrund des weit verbreiteten Community-Einsatzes der wichtigste Maßstab für den Erfolg ist.
Die Einführung der Kubernetes Gateway-API und die Abschaffung der Eingangsressource ist ein Beispiel dafür, wie eine Community, die sich der Verbesserung ihrer Infrastrukturplattform verschrieben hat, zusammenkommt, um weitreichende Änderungen vorzunehmen, ohne einen Wettbewerbsvorteil aus dieser Investition zu erzielen.
Zum Zeitpunkt der Veröffentlichung dieses Blogs gab es 19 Open-Source-Ingress-Controller- und Service-Mesh-Projekte in verschiedenen Stadien der Entwicklung ihrer Gateway-API-Implementierung, um ihre vorherige maßgeschneiderte Implementierung zu ersetzen. Die meisten davon befinden sich derzeit in der Beta-Version und einige sind allgemein verfügbar.
Eine schnelle, gemeinsame Implementierung ist der neue Weg, um Softwareschnittstellen mit der Geschwindigkeit der Community-Entwicklung zu standardisieren. Die Arbeit, die im Netzwerk SIG geleistet wird, ist keine akademische Arbeit; Die Community hat die Bereitschaft gezeigt, sich an den in den Arbeitsgruppen definierten gemeinsamen Schnittstellen und APIs zu beteiligen und diese anschließend zu übernehmen. Jeder kann teilnehmen und beitragen, wie er möchte.
Noch Luft nach oben?
Die Arbeit, die derzeit innerhalb der Netzwerk-SIG im Gange ist, wird einen Großteil des Proliferationschaos beseitigen, das derzeit in Bezug auf Cluster-I/O besteht. Es gibt jedoch auch andere Dimensionen der Verwirrung und Komplexität, die von der Community nicht ins Visier genommen wurden.
Die Arbeit der GAMMA-Initiative, Eingangsfunktionen und APIs mit der Arbeit der Gateway-API-Arbeitsgruppe zu teilen, trägt wesentlich dazu bei, zu erkennen, dass die funktionalen Anforderungen an das Service-Mesh denen eines CNI sehr ähnlich sein können, bei dem der traditionelle Eingang für Nicht-Service-Mesh erfolgt.
Trotz dieser Arbeit gibt es weiterhin funktionale Überschneidungen zwischen CNI und Service-Mesh, die nicht aufeinander abgestimmt werden. In den Anfängen implementierte das CNI Layer-Netzwerkrichtlinien, um den Datenverkehr auf den Schichten 3 und 4 zu filtern, und Service Mesh filterte ausschließlich eine Teilmenge dieses Datenverkehrs, indem es nur die Protokollelemente der Schicht 7 betrachtete.
Die Arbeitsgruppe für Netzwerkrichtlinien entwickelt und standardisiert die API, die von allen verschiedenen CNI-Anbietern übernommen wird, aber die meisten der beliebten Service-Mesh-Lösungen verfügen auch über eine nicht standardisierte Form der Layer-3- und -4-Filterrichtlinien-API. Keiner von ihnen hat vor, dies mit der Arbeit der Arbeitsgruppe für Netzpolitik in Einklang zu bringen.
Gleichzeitig gibt es keine gleichwertige Gruppe, die versucht, die APIs für die Layer-7-Filterung zu standardisieren, die von verschiedenen Service-Meshes unterschiedlich implementiert werden (obwohl die gemeinsame Verwendung des Open-Source-Envoy-Proxys für die Filterdurchsetzung zu einer großen Einheitlichkeit führt). Organisatorisch könnte es schwierig sein, Abstraktionen zwischen den verschiedenen Software-Artefakten (CNIs vs. Service Meshes) zu vereinheitlichen, da es kein Projekt gibt, das sich darum kümmert und es implementiert. Aus architektonischer Sicht ist dies sinnvoll, aber die Vereinheitlichung könnte eher eine CNCF-Führungsperspektive als eine projektzentrierte Perspektive einnehmen.
Wo wird das alles enden?
Wenn man akzeptiert, dass anhaltende funktionale Überschneidungen zwischen CNIs und Service-Meshes unvermeidlich sind, bedeutet dies, dass das Ziel der Netzwerk-SIG letztendlich darin bestehen sollte, eine gemeinsame API für die relevanten Sicherheits-, Datenverkehrsmanagement- und Routing-Funktionen zu definieren, unabhängig davon, ob sie in etwas implementiert sind, das als CNI, Service-Mesh oder auf eine andere Weise zur Bereitstellung einer virtuellen Netzwerkabstraktion implementiert ist.
Experten für Kubernetes-Infrastruktur 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 die Gefahr, taub zu sein und die Systembenutzer einer systementwicklerzentrierten Bottom-up-Schnittstelle auszusetzen, die die "Nerd-Knöpfe" freilegt.
Wenn es für Benutzer selbstverständlich ist, sowohl einen CNI-Anbieter als auch ein Service-Mesh als Implementierung ihres Netzwerk-Stacks und ihrer Funktionen zu betrachten, könnte dies die Attraktivität der Plattform verbessern, wenn sie mehr gemeinsame Abstraktionen und APIs nutzt. Die Netzwerkrichtlinie verfügt über eine Vielzahl von Filterprimitiven zum Auswählen des Datenverkehrs und zum Ausführen bedingter Aktionen. Es könnte erweitert und verbessert werden, um alle abstrahierten, Kubernetes-fähigen Match/Action-Regeln für Intra-Cluster-, Inter-Cluster- und Extra-Cluster-Netzwerke zu verarbeiten.
Teilen Sie uns mit, was Sie vom Wert allgemeiner Abstraktionen in allen Anwendungsfällen der Datenverkehrsverarbeitung halten. Wenn Sie sich für dieses Thema interessieren, behalten Sie diese Arbeit im Auge, die schnell voranschreitet und viele Kubernetes-Benutzer betreffen wird.
Erfahren Sie mehr über Illumio , indem Sie uns noch heute kontaktieren.
.webp)
