Freigeben über

Containernetzwerkkonzepte in „Azure Kubernetes Service (AKS) auf Azure Stack HCI“

  • Artikel

Gilt für: AKS auf Azure Stack HCI 22H2, AKS unter Windows Server

Anwendungskomponenten müssen zusammenarbeiten, um ihre Aufgaben in einem containerbasierten Microservices-Ansatz zu verarbeiten. Kubernetes stellt Ressourcen zur Verfügung, die Anwendungskommunikation ermöglichen und Ihnen gestatten, intern und extern Verbindungen mit Anwendungen herstellen und diese ebenso verfügbar zu machen. Sie können einen Lastausgleich für Ihre Anwendungen vornehmen, um hochverfügbare Anwendungen zu erstellen.

Komplexere Anwendungen erfordern möglicherweise die Konfiguration des Eingehenden Datenverkehrs für die BEENDIGUNG von SSL/TLS oder das Routing mehrerer Komponenten. Möglicherweise müssen Sie auch den Netzwerkdatenverkehr in oder zwischen Pods und Knoten zur Sicherheit einschränken.

In diesem Artikel werden die Kernkonzepte vorgestellt, die Netzwerk für Ihre Anwendungen in AKS bereitstellen, die von Arc aktiviert sind:

  • Kubernetes-Dienste
  • Eingangscontroller
  • Netzwerkrichtlinien

Kubernetes-Dienste

Kubernetes verwendet Dienste, um die Netzwerkkonfiguration für Anwendungsworkloads zu vereinfachen. Dabei wird eine Reihe von Pods logisch gruppiert und Netzwerkkonnektivität bereitgestellt. Folgende Arten von Diensten sind verfügbar:

Cluster-IP: Erstellt eine interne IP-Adresse für die Verwendung innerhalb des Kubernetes-Clusters. Verwenden Sie Cluster IP für rein interne Anwendungen, die andere Workloads im Cluster unterstützen.

Diagramm, das den Cluster-IP-Datenverkehrsfluss in einem AKS-Cluster zeigt.

NodePort: erstellt eine Portzuordnung auf dem zugrunde liegenden Knoten, mit der die Anwendung direkt mit der Knoten-IP-Adresse und dem Port zugegriffen werden kann.

Diagramm mit NodePort-Datenverkehrsfluss in einem AKS-Cluster.

LoadBalancer: erstellt eine Azure-Lastenausgleichsressource, konfiguriert eine externe IP-Adresse und verbindet die angeforderten Pods mit dem Back-End-Pool des Lastenausgleichs. An den gewünschten Ports werden Regeln für den Lastenausgleich erstellt, damit der Datenverkehr der Kunden die Anwendung erreichen kann.

Diagramm, das den Datenverkehrsfluss des Lastenausgleichs in einem AKS-Cluster zeigt.

Für andere Steuerung und Weiterleitung des eingehenden Datenverkehrs können Sie einen Eingangscontroller verwenden.

Hinweis

Wenn Sie einen Zielcluster bereitstellen, der ein Netzwerk für einen anderen Zielcluster freigibt, besteht die Möglichkeit eines IP-Adresskonflikts für den Lastenausgleich. Dies kann passieren, wenn Sie zwei Arbeitsauslastungen, die unterschiedliche Anschlüsse in Zielclustern verwenden, die dasselbe AksHciClusterNetworkObjekt nutzen. Aufgrund der Art und Weise, wie die IP-Adressen und Anschlusszuordnungen innerhalb von HA Proxy zugewiesen werden, kann dies zu einer doppelten IP-Adresszuweisung führen. Wenn dies geschieht, kann eine oder beide Workloads zufällige Netzwerkkonnektivitätsprobleme auftreten, bis Sie Ihre Workloads erneut bereitstellen. Wenn Sie Ihre Workloads erneut bereitstellen, können Sie entweder denselben Port verwenden, der bewirkt, dass jede Workload eine separate Dienst-IP-Adresse empfängt, oder Sie können Ihre Workloads auf Zielclustern, die unterschiedliche AksHciClusterNetwork Objekte verwenden, erneut bereitstellen.

ExternalName: Erstellt einen bestimmten DNS-Eintrag für den einfacheren Anwendungszugriff. Die IP-Adressen für Lastenausgleichsmodule und Dienste können abhängig von der gesamten Einrichtung des Netzwerks interne oder externe Adressen sein und dynamisch zugewiesen werden. Alternativ können Sie eine vorhandene statische IP-Adresse zur Verwendung angeben. Eine vorhandene statische IP-Adresse ist häufig an einen DNS-Eintrag gebunden. Internen Lastenausgleichsmodulen wird nur eine private IP-Adresse zugeordnet, sodass nicht über das Internet darauf zugegriffen werden kann.

Kubernetes-Netzwerkgrundlagen in Azure Local

Um den Zugriff auf Ihre Anwendungen oder die gegenseitige Kommunikation von Anwendungskomponenten zu erlauben, stellt Kubernetes eine Abstraktionsschicht für virtuelle Netzwerke bereit. Kubernetes-Knoten sind mit dem virtuellen Netzwerk verbunden und können eingehende und ausgehende Konnektivität für Pods bereitstellen. Die auf jedem Knoten ausgeführte Komponente kube-proxy stellt diese Netzwerkfunktionen bereit.

In Kubernetes gruppieren Dienste die Pods logisch, um Folgendes zu ermöglichen:

  • Direkter Zugriff über eine einzelne IP-Adresse oder einen DNS-Namen und einen bestimmten Port.
  • Verteilen des Datenverkehrs mithilfe eines Lastenausgleichs zwischen mehreren Pods, die denselben Dienst oder dieselbe Anwendung hosten.

Die lokale Azure-Plattform trägt auch dazu bei, virtuelle Netzwerke für AKS auf lokalen Azure-Clustern zu vereinfachen, indem das "Unterschicht"-Netzwerk auf hochverfüzbarte Weise bereitgestellt wird. Wenn Sie einen AKS-Cluster erstellen, wird auch eine zugrunde liegende HAProxy-Lastenausgleichsressource erstellt und konfiguriert. Beim Bereitstellen von Anwendungen in einem Kubernetes-Cluster werden IP-Adressen für Ihre Pods und Kubernetes-Dienste in diesem Lastenausgleich als Endpunkte konfiguriert.

IP-Adressressourcen

Um die Netzwerkkonfiguration für Anwendungsworkloads zu vereinfachen, weist AKS Arc den folgenden Objekten in einer Bereitstellung IP-Adressen zu:

  • Kubernetes-Cluster-API-Server: Der API-Server ist eine Komponente der Kubernetes-Steuerelementebene, die die Kubernetes-API verfügbar macht. Der API-Server ist das Front-End für die Kubernetes-Steuerungsebene. API-Servern werden unabhängig vom zugrunde liegenden Netzwerkmodell immer statische IP-Adressen zugewiesen.
  • Kubernetes-Knoten (virtuelle Computer):Ein Kubernetes-Cluster besteht aus einer Reihe von Arbeitscomputern, die als Knoten bezeichnet werden, und die Knoten hosten containerisierte Anwendungen. Zusätzlich zu den Knoten der Steuerungsebene verfügt jeder Cluster über mindestens einen Workerknoten. Für einen AKS-Cluster werden Kubernetes-Knoten als virtuelle Computer konfiguriert. Diese virtuellen Computer werden als hoch verfügbare virtuelle Computer in Azure Local erstellt, weitere Informationen finden Sie unter Node-Netzwerkkonzepte.
  • Kubernetes-Dienste: In Kubernetes gruppieren Dienste logisch Pod-IP-Adressen, um direkten Zugriff über eine einzelne IP-Adresse oder einen DNS-Namen für einen bestimmten Port zu ermöglichen. Dienste können Datenverkehr auch über einen Lastenausgleich verteilen. Statische IP-Adressen werden unabhängig vom zugrunde liegenden Netzwerkmodell immer Kubernetes-Diensten zugewiesen.
  • HAProxy-Lastenausgleichsgeräte: HAProxy ist ein TCP/HTTP-Lastenausgleichsserver und Proxyserver, der eingehende Anforderungen über mehrere Endpunkte verteilt. Jeder Workloadcluster in einer AKS in einer lokalen Azure-Bereitstellung verfügt über einen HAProxy-Lastenausgleich, der als spezieller virtueller Computer bereitgestellt und konfiguriert ist.
  • Microsoft On-premises Cloud Service: Dies ist der lokale Azure-Cloudanbieter, der die Erstellung und Verwaltung der virtualisierten Umgebung ermöglicht, die Kubernetes auf einem lokalen Azure Local Cluster oder Windows Server-Cluster hostet. Das Netzwerkmodell gefolgt von Ihrem lokalen Azure- oder Windows Server-Cluster bestimmt die IP-Adresszuweisungsmethode, die vom lokalen Microsoft-Clouddienst verwendet wird. Weitere Informationen zu den vom lokalen Clouddienst von Microsoft implementierten Netzwerkkonzepten finden Sie unter Konzepte für Netzwerkknoten.

Kubernetes-Netzwerke

In AKS auf Azure Local können Sie einen Cluster bereitstellen, der eines der folgenden Netzwerkmodelle verwendet:

  • Flannel Overlay-Netzwerke: Die Netzwerkressourcen werden normalerweise bei der Bereitstellung des Clusters erstellt und konfiguriert.
  • Project Calico-Netzwerke: Dieses Modell bietet zusätzliche Netzwerkfeatures wie Netzwerkrichtlinien und Flusssteuerung.

Beide Netzwerkimplementierungen verwenden ein Überlagerungsnetzwerk-Konfigurationsmodell, das eine IP-Adresszuweisung bereitstellt, die vom restlichen Netzwerk des Rechenzentrums getrennt ist.

Weitere Informationen zu Überlagerungsnetzwerken finden Sie unter Introducing: Kubernetes Overlay Networking for Windows (Einführung: Kubernetes-Überlagerungsnetzwerke für Windows).

Weitere Informationen über das Calico-Netzwerk-Plug-In und Richtlinien finden Sie unter Getting Started with Calico Network Policy (Erste Schritte mit der Calico-Netzwerkrichtlinie).

Netzwerkmodelle im Vergleich

Flannel

Hinweis

Flannel CNI wurde im Dezember 2023 eingestellt.

Flannel ist eine speziell für Container entwickelte virtuelle Netzwerkschicht. Flannel erstellt ein flaches, das Hostnetzwerk überlagerndes Netzwerk. Allen Containern/Pods wird eine IP-Adresse in diesem Überlagerungsnetzwerk zugewiesen, und sie kommunizieren direkt miteinander, indem sie untereinander Verbindungen mit ihren IP-Adressen herstellen.

Calico

Bei Calico handelt es sich um eine Open-Source-Netzwerk- und Netzwerksicherheitslösung für Container, virtuelle Computer und native Workloads auf Hostbasis. Calico unterstützt mehrere Datenebenen, z. B. eine Linux-eBPF-Datenebene, eine Linux-Netzwerkdatenebene und eine Windows-HNS-Datenebene.

Capabilities

Funktion Flannel Calico
Netzwerkrichtlinien No Ja
IPv6 No Ja
Verwendete Schichten L2 (VxLAN) L2 (VxLAN)
Bereitstellen von Clustern in vorhandenen oder neuen virtuellen Netzwerken Ja Ja
Windows-Unterstützung Ja Ja
Pod-Pod-Verbindung Ja Ja
Pod-VM-Verbindung, VM im selben Netzwerk No Ja
Pod-VM-Verbindung, VM in einem anderen Netzwerk Ja Ja
Kubernetes-Dienste Ja Ja
Verfügbar machen über Lastenausgleich Ja Ja
Netzwerke Viele Netzwerke im selben Cluster mit Multi-Daemon Viele Netzwerke im selben Cluster
Bereitstellung Linux: DaemonSet Linux: DaemonSet
Windows: Dienst Windows: Dienst
Befehlszeile keine calicoctl

Wichtig

Die Standardauswahl besteht derzeit darin, Calico in einem Überlagerungsnetzwerkmodus zu verwenden. Verwenden Sie zum Aktivieren von Flannel den -primaryNetworkPlugin Parameter des New-AksHciCluster PowerShell-Befehls, und geben Sie flannel den Wert an. Dieser Wert kann nicht geändert werden, nachdem Sie den Cluster bereitgestellt haben, und er gilt sowohl für Windows- als auch für Linux-Clusterknoten.

Zum Beispiel:

New-AksHciCluster -name MyCluster -primaryNetworkPlugin 'flannel'

Nächste Schritte

In diesem Artikel werden Netzwerkkonzepte für Container in AKS-Knoten auf Azure Local behandelt. Weitere Informationen zu AKS für lokale Azure-Konzepte finden Sie in den folgenden Artikeln: