Clusterübergreifende Netzwerkanwendungsfälle für Azure Kubernetes Fleet Manager (Vorschau)

Clusterübergreifendes Netzwerk für Azure Kubernetes Fleet Manager (Fleet) ist ein verwaltetes Angebot, das auf Cilium Cluster Mesh basiert, mit dem Sie die direkte Pod-zu-Pod-Kommunikation über mehrere Azure Kubernetes Service (AKS) Cluster hinweg herstellen können. Durch das Erstellen eines clusterübergreifenden Netzwerks können Sie eine nahtlose Ost-West-Konnektivität ermöglichen, ohne dass Gateways erforderlich sind, und gleichzeitig mehr clusterübergreifende Observability und konsistente Sicherheitserzwingung erzielen.

Architektur und Funktionen

In einer clusterübergreifenden Netzwerkkonfiguration ermöglicht ein flaches virtuelles Netzwerk Pods in verschiedenen Clustern, Datenverkehr direkt über Clustergrenzen hinweg zu leiten. Jedem Cluster werden in der Regel zwei Subnetze zugewiesen: eines für Knoten und eines für Pods. Diese konsistente Architektur stellt sicher, dass das Pod-Netzwerk über das clusterübergreifende Netzwerk flach bleibt, ohne dass Überlagerungen oder Tunnel verwendet werden.

Diagramm mit Architektur von Azure Kubernetes Fleet Manager, der clusterübergreifende Ost-West-Konnektivität verwaltet. Pods in verschiedenen Clustern kommunizieren direkt über Cilium Agents über peered virtual networks.

Zu den wichtigsten Komponenten und Funktionen für dieses Szenario gehören:

  • Azure CNI mit Cilium-Datenebene: Beide AKS-Cluster müssen Azure CNI mit dem Azure CNI verwenden, das von Cilium-Datenebene unterstützt wird.
  • Advanced Container Networking Services (ACNS):ACNS muss für die Cluster aktiviert sein, um dieses Szenario zu unterstützen.
  • Azure Kubernetes Fleet Manager: Fleet verwaltet den Lebenszyklus und die Konfiguration des clusterübergreifenden Netzwerks über Ressourcen wie das ClusterMesh-Profil.
  • Systemeigene Leistung: Pod-IP-Routing erfolgt über Cluster mit systemeigener Leistung über direct-Routing, um die Notwendigkeit von Gateways oder Proxys zu umgehen.
  • Durchsetzung einheitlicher Netzwerkrichtlinien: Erweitert die Erzwingung von Cilium-Layer 3-7-Netzwerkrichtlinien auf alle Cluster im clusterübergreifenden Netzwerk und stellt einen konsistenten Sicherheitsansatz sicher.
  • Clusterübergreifende Beobachtbarkeit: Bietet durchgängige Transparenz über clusterübergreifende Datenverkehrsflüsse. Diese Sichtbarkeit hilft Ihnen, den Anwendungsstatus zu überwachen, Konnektivitätsprobleme zu beheben und Datenverkehrsmuster über das clusterübergreifende Netzwerk zu analysieren.

Anwendungsfälle

Clusterübergreifendes Netzwerk ermöglicht mehrere wichtige Multiclusterszenarien. In den folgenden Abschnitten werden die am häufigsten verwendeten Anwendungsfälle für clusterübergreifende Netzwerke mit Fleet beschrieben.

Anwendungsfall: Transparente Dienstermittlung und Lastenausgleich

Wenn Sie Standardmäßige Kubernetes-Dienste verwenden und diese als global kennzeichnen, ermittelt Cilium automatisch Endpunkte für diese Dienste in allen Clustern im clusterübergreifenden Netzwerk. Jeglicher Datenverkehr, der für das ClusterIP eines globalen Dienstes bestimmt ist, wird automatisch auf alle beteiligten Cluster lastverteilt, wodurch die clusterübergreifende Kommunikation vereinfacht wird.

Anwendungen können Unabhängig vom Cluster, in dem sie sich befinden, Dienste ermitteln und mit ihnen interagieren, ohne dass Änderungen auf Anwendungsebene oder externe Dienstregistrierungen erforderlich sind.

Anwendungsfall: Hohe Verfügbarkeit und Fehlertoleranz

Hohe Verfügbarkeit ist der am häufigsten verwendete Anwendungsfall für clusterübergreifende Netzwerke. Dieser Anwendungsfall umfasst das Ausführen von Kubernetes-Clustern über mehrere Regionen oder Verfügbarkeitszonen hinweg und das Ausführen von Replikaten derselben Dienste in jedem Cluster. Bei Einem Fehler können Anforderungen an andere Cluster im clusterübergreifenden Netzwerk fehlschlagen.

Das in diesem Anwendungsfall behandelte Fehlerszenario ist nicht in erster Linie die vollständige Nichtverfügbarkeit einer gesamten Region oder Fehlerdomäne. Ein wahrscheinlicheres Szenario ist die temporäre Nichtverfügbarkeit von Ressourcen oder Fehlkonfigurationen in einem Cluster, was zu einer Unfähigkeit führt, bestimmte Dienste in diesem Cluster auszuführen oder zu skalieren. Bei clusterübergreifendem Netzwerk wird datenverkehr, der für den betroffenen Dienst bestimmt ist, automatisch an gesunde Endpunkte in anderen Clustern weitergeleitet, wobei Ihre Anwendung verfügbar bleibt.

Diagramm mit zwei AKS-Clustern über mehrere Regionen hinweg. Front-Ends in jedem Cluster leiten an einen lokalen Bestelldienst weiter, der von Orders-Pods unterstützt wird. Wenn Pods in Cluster B ungesund werden, schwenkt der Bestelldienst in Cluster B auf den Bestelldienst in Cluster A um.

Anwendungsfall: Gemeinsame Dienste

Der anfängliche Trend von Kubernetes-basierten Plattformen bestand darin, große, mehrinstanzenfähige Cluster zu erstellen, aber es wird immer häufiger, einzelne Cluster pro Mandant zu erstellen oder Cluster für verschiedene Kategorien von Diensten zu erstellen, z. B. unterschiedliche Sicherheitsempfindlichkeitsebenen.

Einige Dienste wie geheime Verwaltung, Protokollierung, Überwachung oder DNS werden jedoch häufig immer noch zwischen allen Clustern gemeinsam genutzt. Die Zentralisierung dieser Dienste in einem gemeinsamen „Service“-Cluster vermeidet den Betriebsaufwand, sie in jedem Mandantencluster zu betreiben.

Die primäre Motivation dieses Modells ist die Isolierung zwischen Mandantenclustern. Um dieses Ziel beizubehalten, sind Mandantencluster nur mit dem Cluster für gemeinsame Dienste verbunden und nicht mit anderen Mandantenclustern verbunden.

Diagramm mit zwei Mandanten-AKS-Clustern mit Anwendungen, die einen geheimen Client aufrufen. Beide Mandantencluster werden an einen Cluster für gemeinsame Dienste geleitet, der den geheimen Dienst hostet, der von Vault-1- und Vault-2-Pods unterstützt wird. Mandantencluster stellen nur eine Verbindung mit dem Cluster für gemeinsame Dienste her, nicht miteinander.

Anwendungsfall: Trennung von zustandsbehafteten und zustandslosen Komponenten

Sie können die betriebstechnische Komplexität von zustandsbehafteten Diensten wie Datenbanken und Speicher in dedizierten Clustern isolieren. Diese Trennung sorgt dafür, dass zustandslose Anwendungscluster agil und einfach migriert werden können. Außerdem verbessert sie die Sicherheit, vereinfacht die Lebenszyklusverwaltung des Clusters und ermöglicht es Ihnen, zustandslose Workloads unabhängig von zustandsbehafteten zu skalieren.

Diagramm, das zwei zustandslose AKS-Cluster zeigt, die jeweils über Ingress-Routing zu einem Frontend und einem Datenspeicherclient verfügen. Beide zustandslosen Cluster sind mit einem dedizierten zustandsbehafteten Cluster verbunden, der den Datenspeicherdienst beherbergt, der von den Pods data-1, data-2 und data-n bereitgestellt wird.

Anwendungsfall: Multiclustersicherheit und Richtlinienerzwingung

Die clusterübergreifende Vernetzung erweitert die Durchsetzung von Ciliums Layer-3-7-Netzwerkrichtlinien auf alle Cluster im clusterübergreifenden Netzwerk. Diese einheitliche Durchsetzung gewährleistet einen konsistenten Sicherheitsstatus und vereinfacht die Richtlinienverwaltung, indem die Notwendigkeit vermieden wird, Richtlinien in jeder Umgebung manuell zu replizieren. Richtlinien, die auf einem Cluster angewendet werden, werden in den anderen Clustern berücksichtigt und bieten einheitliche, identitätsbewusste Sicherheit in Ihrer Flotte.

Anwendungsfall: Clusterübergreifende Beobachtbarkeit

Clusterübergreifendes Netzwerk bietet End-to-End-Sichtbarkeit des Datenverkehrs, der zwischen Diensten über Cluster hinweg fließt. Durch das Aggregieren von Flussdaten aus jedem Cluster im clusterübergreifenden Netzwerk können Sie den Ost-West-Datenverkehr visualisieren, den Anwendungsstatus in allen Regionen überwachen, Clusterverbindungsprobleme beheben und Datenverkehrsmuster für die Kapazitätsplanung analysieren.

Mit Containernetzwerkprotokollen erhalten Operatoren eine einheitliche Ansicht der Pod-zu-Pod-Kommunikation, unabhängig davon, in welchem Cluster sich die Quelle oder das Ziel befindet, ohne Anwendungen zu instrumentieren.

Globale Dienste

Um den Datenverkehrsfluss zwischen Clustern zu aktivieren, müssen Sie Ihre Kubernetes-Dienste als globale Dienste konfigurieren. In einem clusterübergreifenden Netzwerk ist ein globaler Dienst ein Standard-Kubernetes-Dienst, der über mehrere Cluster hinweg freigegeben wird. Wenn Sie einen Dienst als global markieren, ermittelt Cilium automatisch Endpunkte für diesen Dienst in allen Clustern innerhalb des clusterübergreifenden Netzwerks und führt einen Lastenausgleich für diesen Dienst aus.

Sobald ein Dienst als global gekennzeichnet ist, werden alle auf einem Cluster angewendeten Richtlinien in den anderen Clustern im clusterübergreifenden Netzwerk berücksichtigt und bieten einen konsistenten Sicherheitsstatus. Diese Konfiguration ermöglicht Folgendes:

  • Transparente Dienstermittlung: Anwendungen können Unabhängig vom Cluster, in dem sie sich befinden, Dienste ermitteln und mit ihnen interagieren.
  • Hohe Verfügbarkeit: Wenn ein Dienst in einem Cluster nicht verfügbar ist, wird der Datenverkehr automatisch auf eine fehlerfreie Instanz in einem anderen Cluster verschoben.

Cilium verwaltet diese Erkennung, indem es Dienste mit der Annotation io.cilium/global-service: "true" überwacht. Für diese Dienste werden alle Endpunkte mit demselben Namen und Namespace über Cluster hinweg mit einem einzigen globalen Dienst zusammengeführt. Jeder Datenverkehr, der für den ClusterIP dieses Dienstes bestimmt ist, wird dann per Lastenausgleich auf alle beteiligten Cluster verteilt.

Einschränkungen

  • Ein Mitgliedscluster kann jeweils nur an einem clusterübergreifenden Netzwerk teilnehmen.
  • Ein einzelnes clusterübergreifendes Netzwerk unterstützt bis zu 255 Mitgliedscluster.
  • Selbstverwaltete Cilium-Multi-Cluster-Konfigurationen werden in Verbindung mit von Fleet verwaltetem clusterübergreifendem Networking nicht unterstützt.
  • Cilium-CLI-Befehle, die das Mesh ändern, wie z. B. cilium clustermesh connect oder cilium upgrade, werden nicht unterstützt, da Fleet diese Vorgänge verwaltet.
  • Clusterübergreifende Netzwerke sind auf Cluster innerhalb derselben erreichbaren Flachroutingdomäne beschränkt. Sie unterstützt keine Meshkonnektivität über virtuelle Netzwerke ohne Peering.

Nächste Schritte

  • Last updated on