Freigeben über

Containernetzwerkkonzepte

Gilt für: 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 könnten die Konfiguration des eingehenden Datenverkehrs für die Aufhebung von SSL/TLS oder das Routing mehrerer Komponenten erfordern. 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 Netzwerkfunktionen für Ihre Anwendungen in AKS unter Windows Server bereitstellen:

  • 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 Datenfluss des Load Balancers 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 mit einem anderen Zielcluster ein Netzwerk teilt, besteht die Möglichkeit eines IP-Adresskonflikts beim Lastenausgleich. Dies kann passieren, wenn Sie zwei Workloads bereitstellen, die in Zielclustern unterschiedliche Ports verwenden und dasselbe AksHciClusterNetwork-Objekt 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, können eine oder beide Workloads zufällige Netzwerkkonnektivitätsprobleme aufweisen, 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.

Grundlegendes zu Kubernetes-Netzwerken

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.

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 in diesem Lastenausgleichsdienst IP-Adressen für Ihre Pods und Kubernetes-Dienste 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 Maschinen werden als hochverfügbare virtuelle Maschinen 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 unter Windows Server-Bereitstellung verfügt über einen HAProxy-Lastenausgleich, der als spezialisierter virtueller Computer bereitgestellt und konfiguriert ist.
  • Microsoft On-premises Cloud Service: Dies ist der Cloudanbieter, der die Erstellung und Verwaltung der virtualisierten Umgebung ermöglicht, die Kubernetes auf einem lokalen Windows Server-Cluster hostet. Das Netzwerkmodell gefolgt von Ihrem 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 unter Windows Server 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 in diesem Überlagerungsnetzwerk eine IP-Adresse zugewiesen, und sie kommunizieren direkt, indem sie die IP-Adressen der anderen nutzen.

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.

Fähigkeiten

Fähigkeit Flannel Calico
Netzwerkrichtlinien Nein Ja
IPv6 Nein 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 Nein 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 legen Sie flannel als Wert fest. 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 Windows Server behandelt. Weitere Informationen zu AKS für Windows Server-Konzepte finden Sie in den folgenden Artikeln: