Freigeben über

Konfigurieren von Azure CNI-Überlagerungsnetzwerken in Azure Kubernetes Service (AKS)

  • Artikel

Das herkömmliche Azure Container Networking Interface (CNI) weist jedem Pod eine VNET-IP-Adresse zu. Es weist diese IP-Adresse entweder aus einem vorreservierten Pool von IPs auf jedem Knoten oder einem separaten und für Pods reservierten Subnetz zu. Dieser Ansatz erfordert die Planung von IP-Adressen und kann dazu führen, dass es nicht genügend Adressen gibt wodurch Schwierigkeiten bei der Skalierung Ihrer Cluster auftreten, wenn die Anforderungen Ihrer Anwendungen zunehmen.

Mithilfe von Azure CNI Overlay werden die Clusterknoten in einem Azure Virtual Network-Subnetz (VNet) bereitgestellt. Pods werden IP-Adressen aus einem privaten CIDR zugewiesen, das sich logisch vom VNet-Hosting der Knoten unterscheidet. Pod- und Knotendatenverkehr innerhalb des Clusters verwendet ein Überlagerungsnetzwerk. Die Netzwerkadressübersetzung (Network Address Translation, NAT) verwendet die IP-Adresse des Knotens, um Ressourcen außerhalb des Clusters zu erreichen. Mit dieser Lösung wird eine erhebliche Menge an VNet-IP-Adressen eingespart, und Sie können Ihren Cluster auf große Größen skalieren. Ein zusätzlicher Vorteil besteht darin, dass das private CIDR in verschiedenen AKS-Clustern wiederverwendet werden kann, wodurch der für containerisierte Anwendungen in Azure Kubernetes Service (AKS) verfügbare IP-Adressraum erweitert wird.

Übersicht über das Überlagerungsnetzwerk

Im Überlagerungsnetzwerk werden nur den Kubernetes-Clusterknoten IPs aus Subnetzen zugewiesen. Pods erhalten IPs von einem privaten CIDR, das zum Zeitpunkt der Clustererstellung bereitgestellt wird. Jedem Knoten wird ein /24-Adressraum zugewiesen, der aus demselben CIDR stammt. Zusätzliche Knoten, die beim Aufskalieren eines Clusters erstellt werden, erhalten automatisch „/24“-Adressräume aus demselben CIDR. Azure CNI weist Pods IPs aus diesem /24-Raum zu.

Eine separate Routingdomäne wird im Azure-Netzwerkstapel für den privaten CIDR-Raum des Pods erstellt, der ein Überlagerungsnetzwerk für die direkte Kommunikation zwischen Pods erstellt. Es ist nicht erforderlich, benutzerdefinierte Routen im Clustersubnetz bereitzustellen oder eine Kapselungsmethode zum Tunneln des Datenverkehrs zwischen Pods zu verwenden, was eine Konnektivitätsleistung zwischen Pods auf dem Niveau von VMs in einem VNet ermöglicht. Workloads, die innerhalb der Pods ausgeführt werden, wissen nicht einmal, dass die Netzwerkadressen bearbeitet werden.

Ein Diagramm mit zwei Knoten mit drei Pods, die jeweils in einem Überlagerungsnetzwerk ausgeführt werden. Pod-Datenverkehr zu Endpunkten außerhalb des Clusters wird per NAT weitergeleitet.

Die Kommunikation mit Endpunkten außerhalb des Clusters, wie z. B. mit lokalen VNets und VNets mit Peering, erfolgt mithilfe der Knoten-IP über die Netzwerkadressenübersetzung (Network Adress Translation, NAT). Azure CNI übersetzt die Quell-IP (Überlagerungs-IP des Pods) des Datenverkehrs in die primäre IP-Adresse des virtuellen Computers, sodass der Azure-Netzwerkstapel den Datenverkehr an das Ziel weiterleiten kann. Endpunkte außerhalb des Clusters können keine direkte Verbindung mit einem Pod herstellen. Sie müssen die Anwendung des Pods als Kubernetes-Load Balancer-Dienst veröffentlichen, um sie im VNet erreichbar zu machen.

Sie können die ausgehende Konnektivität zum Internet für Überlagerungspods mithilfe eines Standard-SKU-Load Balancers oder eines verwalteten NAT Gateways bereitstellen. Sie können den ausgehenden Datenverkehr auch steuern, indem Sie ihn mithilfe von benutzerdefinierten Routen im Cluster-Subnetz an eine Firewall weiterleiten.

Sie können die eingehende Konnektivität zu dem Cluster mithilfe eines Eingangsdatencontrollers wie Nginx- oder per HTTP-Anwendungsrouting erreichen. Sie können die eingehende Konnektivität nicht mithilfe von Azure App Gateways konfigurieren. Ausführliche Informationen finden Sie unter Einschränkungen bei Azure CNI Overlay.

Unterschied zwischen Kubenet und Azure CNI Overlay

Wie Azure CNI Overlay weist Kubenet Pods IP-Adressen aus einem Adressraum zu, der sich logisch vom VNet unterscheidet, allerdings Skalierungs- und andere Einschränkungen hat. Die folgende Tabelle enthält einen detaillierten Vergleich zwischen Kubenet und Azure CNI Overlay. Wenn Sie Pods aufgrund einer Knappheit von IPs keine VNET-IP-Adressen zuweisen möchten, empfehlen wir die Verwendung von Azure CNI Overlay.

Bereich Azure CNI Overlay Kubenet
Clusterstaffelung 5000 Knoten und 250 Pods/Knoten 400 Knoten und 250 Pods/Knoten
Netzwerkkonfiguration Einfach – keine zusätzliche Konfiguration für Pod-Netzwerke erforderlich Komplex – erfordert Routingtabellen und UDRs im Cluster-Subnetz für Podnetzwerke
Pod-Konnektivitätsleistung Leistung wie bei VMs in einem VNet Zusätzlicher Hop fügt Latenz hinzu
Kubernetes-Netzwerkrichtlinien Azure-Netzwerkrichtlinien, Calico, Cilium Calico
Unterstützte Betriebssystemplattformen Linux und Windows Server 2022, 2019 Nur Linux

IP-Adressplanung

  • Clusterknoten: Stellen Sie beim Einrichten Ihres AKS-Clusters sicher, dass Ihre VNET-Subnetze über genügend Platz für die zukünftige Skalierung verfügt. Sie können jedem Knotenpool ein dediziertes Subnetz zuweisen. Beachten Sie, dass ein /24Subnetz bis zu 251 Knoten umfassen kann, da die ersten drei IP-Adressen für Verwaltungsaufgaben reserviert sind.
  • Pods: Die Überlagerungslösung weist jedem Knoten aus dem privaten CIDR, den Sie während der Clustererstellung angeben, einen /24-Adressraum für Pods zu. Die /24-Größe ist feststehend und kann nicht erhöht oder verringert werden. Sie können auf einem Knoten bis zu 250 Pods ausführen. Stellen Sie bei der Planung des Pod-Adressraums sicher, dass das private CIDR groß genug ist, um /24 Adressräume für neue Knoten bereitzustellen, um zukünftige Clustererweiterungen zu unterstützen.
    • Berücksichtigen Sie beim Planen des IP-Adressraums für Pods die folgenden Faktoren:
      • Derselbe Pod CIDR-Raum kann auf mehreren unabhängigen AKS-Clustern im gleichen VNet verwendet werden.
      • Pod CIDR-Speicherplatz darf sich nicht mit dem Cluster-Subnetzbereich überlappen.
      • Pod-CIDR-Speicherplatz darf sich nicht mit direkt verbundenen Netzwerken (z. B. VNET-Peering, ExpressRoute oder VPN) überschneiden. Wenn externer Datenverkehr Quell-IPs im podCIDR-Bereich aufweist, muss er über SNAT in eine nicht überlappende IP-Adresse übersetzt werden, um mit dem Cluster zu kommunizieren.
  • Kubernetes Dienstadressenbereich: Die Größe der Dienstadresse CIDR hängt von der Anzahl der Clusterdienste ab, die Sie erstellen möchten. Sie muss kleiner als /12 sein. Dieser Bereich sollte sich nicht mit dem Pod-CIDR-Bereich, dem Cluster-Subnetzbereich und dem IP-Bereich überlappen, der in VNets mit Peering und lokalen Netzwerken verwendet wird.
  • IP-Adresse des Kubernetes DNS-Diensts: Diese IP-Adresse befindet sich im Kubernetes-Dienstadressbereich, der von der Clusterdienstermittlung verwendet wird. Verwenden Sie nicht die erste IP-Adresse in Ihrem Adressbereich, da diese Adresse für die kubernetes.default.svc.cluster.local-Adresse verwendet wird.

Netzwerksicherheitsgruppen

Pod-zu-Pod-Datenverkehr mit Azure CNI Overlay ist nicht gekapselt, und Subnetzregeln für die Netzwerksicherheitsgruppe finden Anwendung. Wenn die Subnetz-NSG Ablehnungsregeln enthält, die sich auf den Pod-CIDR-Datenverkehr auswirken würden, stellen Sie sicher, dass die folgenden Regeln vorhanden sind, um die ordnungsgemäße Clusterfunktionalität sicherzustellen (zusätzlich zu allen AKS-Ausgangsanforderungen):

  • Datenverkehr vom Knoten-CIDR zum Knoten-CIDR an allen Ports und Protokollen
  • Datenverkehr vom Knoten-CIDR zum Pod-CIDR an allen Ports und Protokollen (erforderlich für das Routing von Dienstdatenverkehr)
  • Datenverkehr vom Pod-CIDR zum Pod-CIDR an allen Ports und Protokollen (erforderlich für den Pod-zu-Pod- und Pod-zu-Dienst-Datenverkehr, einschließlich DNS)

Der Datenverkehr von einem Pod zu einem beliebigen Ziel außerhalb des Pod-CIDR-Blocks verwendet SNAT, um die Quell-IP auf die IP-Adresse des Knotens festzulegen, auf dem der Pod ausgeführt wird.

Wenn Sie den Datenverkehr zwischen Workloads im Cluster einschränken möchten, empfehlen wir die Verwendung von Netzwerkrichtlinien.

Maximale Pods pro Knoten

Sie können die maximale Anzahl an Pods pro Knoten zum Zeitpunkt der Clustererstellung oder beim Hinzufügen eines neuen Knotenpools konfigurieren. Der Standardwert für eine Azure CNI-Überlagerung ist 250. Der Maximalwert, den Sie in Azure CNI Overlay angeben können, beträgt 250, und der Mindestwert liegt bei 10. Die maximale Anzahl an Pods pro Knotenwert, die während der Erstellung eines Knotenpools konfiguriert werden, gilt nur für die Knoten in diesem Knotenpool.

Auswählen eines zu verwendenden Netzwerkmodells

Azure CNI bietet zwei IP-Adressierungsoptionen für Pods: die herkömmliche Konfiguration, die VNet-IP-Adressen zu Pods zuweist, und das Überlagerungsnetzwerk. Die Wahl der für Ihren AKS-Cluster zu verwendenden Option ist ein Kompromiss zwischen Flexibilität und erweiterten Konfigurationsanforderungen. Die folgenden Überlegungen helfen bei der Entscheidung, welches Netzwerkmodell am besten geeignet ist.

Verwenden Sie Überlagerungsnetzwerke, wenn Folgendes zutrifft:

  • Sie möchten auf eine große Anzahl an Pods skalieren, aber verfügen in Ihrem VNet nur über einen begrenzten IP-Adressraum.
  • Die Podkommunikation findet überwiegend innerhalb des Clusters statt.
  • Erweiterte AKS-Features wie z. B. virtuelle Knoten sind nicht erforderlich.

Verwenden Sie die herkömmliche VNet-Option, wenn Folgendes zutrifft:

  • Sie haben genügend verfügbaren IP-Adressraum.
  • Podkommunikation findet überwiegend mit außerhalb des Clusters befindlichen Ressourcen statt.
  • Ressourcen außerhalb des Clusters müssen Pods direkt erreichen.
  • Sie benötigen erweiterte AKS-Features wie z. B. virtuelle Knoten.

Einschränkungen bei Azure CNI Overlay

Die Azure CNI-Überlagerung weist die folgenden Einschränkungen auf:

  • Sie können Application Gateway nicht als Eingangscontroller (AGIC) für einen Überlagerungscluster verwenden.
  • Virtual Machine Availability Sets (VMAS) werden für die Überlagerung nicht unterstützt.
  • Sie können keine virtuellen Computer der DCsv2-Serie in Knotenpools verwenden. Um die Anforderungen des vertraulichen Computings zu erfüllen, sollten Sie stattdessen vertrauliche VMs der DCasv5- oder DCadsv5-Serie verwenden.
  • Falls Sie ihr eigenes Subnetz zum Bereitstellen des Clusters verwenden, müssen die Namen der Subnetz-, VNET- und Ressourcengruppe, die das VNET enthält, maximal 63 Zeichen lang sein. Dies kommt aus der Tatsache, dass diese Namen als Bezeichnungen in AKS-Workerknoten verwendet werden und daher Kubernetes-Bezeichnungssyntaxregeln unterliegen.

Einrichten von Überlagerungsclustern

Hinweis

Sie benötigen CLI-Version 2.48.0 oder höher, um das Argument --network-plugin-mode verwenden zu können. Für Windows muss die neueste aks-preview Azure CLI-Erweiterung installiert sein, und die folgenden Anweisungen müssen befolgt werden können.

Erstellen Sie mit Azure CNI Overlay mithilfe des Befehls „az aks create“ einen Cluster. Vergewissern Sie sich, dass Sie das Argument „--network-plugin-mode“ verwenden, um einen Überlagerungscluster anzugeben. Wenn das Pod CIDR nicht angegeben wird, weist AKS einen Standardraum zu: viz. 10.244.0.0/16.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --pod-cidr 192.168.0.0/16 \
    --generate-ssh-keys

Hinzufügen eines neuen Knotenpools zu einem dedizierten Subnetz

Nachdem Sie ein Cluster mit Azure CNI Overlay erstellt haben, können Sie einen anderen Knotenpool erstellen und den Knoten einem neuen Subnetz desselben VNet zuweisen. Dieser Ansatz kann nützlich sein, wenn Sie die Eingangs- oder Ausgangs-IPs des Hosts von/zu Zielen im gleichen VNET oder VNets mit Peering steuern möchten.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"
nodepoolName="newpool1"
subscriptionId=$(az account show --query id -o tsv)
vnetName="yourVnetName"
subnetName="yourNewSubnetName"
subnetResourceId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnetName/subnets/$subnetName"
az aks nodepool add --resource-group $resourceGroup --cluster-name $clusterName \
  --name $nodepoolName --node-count 1 \
  --mode system --vnet-subnet-id $subnetResourceId

Upgrade eines vorhandenen Clusters auf CNI Overlay

Hinweis

Sie können einen vorhandenen Azure CNI-Cluster auf Overlay aktualisieren, wenn der Cluster die folgenden Kriterien erfüllt:

  • Der Cluster basiert auf Kubernetes, Version 1.22 oder höher.
  • Er verwendet nicht das Feature „Dynamische Zuweisung der Pod-IP“.
  • Für den Cluster sind keine Netzwerkrichtlinien aktiviert. Das Netzwerkrichtlinienmodul kann vor dem Upgrade deinstalliert werden. Weitere Informationen finden Sie unter Deinstallieren von des Azure-Netzwerkrichtlinien-Manager oder Calico.
  • Er darf keine Windows-Knotenpools mit Docker als Containerruntime verwenden.

Hinweis

Da die Routingdomäne für ARM noch nicht unterstützt wird, wird das CNI Overlay auf ARM-basierten Prozessorknoten (ARM64) noch nicht unterstützt.

Hinweis

Das Upgrade eines vorhandenen Clusters auf CNI Overlay kann nicht rückgängig gemacht werden.

Warnung

Vor dem Windows-Betriebssystembuild 20348.1668 gab es eine Einschränkung im Bereich der Windows-Überlagerungspods, die fälschlicherweise eine Quellnetzwerkadressübersetzung (SNATing) von Paketen von Hostnetzwerkpods durchführten, was sich nachteilig auf Cluster auswirkte, die auf die Overlay aktualisiert wurden. Um dieses Problem zu vermeiden, verwenden Sie Windows-Betriebssystembuild größer als oder gleich 20348.1668.

Warnung

Wenn Sie eine benutzerdefinierte Konfiguration für „azure-ip-masq-agent“ verwenden, um zusätzliche IP-Adressbereiche einzuschließen, die keine Pakete aus Pods per SNAT weiterleiten sollen, kann ein Upgrade auf Azure CNI Overlay die Konnektivität zu diesen Bereichen unterbrechen. Pod-IPs aus dem Überlagerungsbereich sind von außerhalb der Clusterknoten nicht zu erreichen. Darüber hinaus kann für genügend alte Cluster eine ConfigMap aus einer früheren Version von „azure-ip-masq-agent“ übrig bleiben. Wenn diese ConfigMap mit dem Namen azure-ip-masq-agent-config vorhanden ist und nicht absichtlich an Ort und Stelle ist, muss sie vor dem Ausführen des Aktualisierungsbefehls gelöscht werden. Wenn keine benutzerdefinierte Konfiguration für „ip-masq-agent“ verwendet wird, sollte nur die ConfigMap azure-ip-masq-agent-config-reconciled in Bezug auf Azure-ConfigMaps vom Typ „ip-masq-agent“ vorhanden sein, und diese wird während des Upgradevorgangs automatisch aktualisiert.

Durch den Upgradeprozess wird gleichzeitig für jeden Knotenpool das Durchführen eines Reimagings ausgelöst. Ein separates Upgrade jedes Knotenpools auf Overlay wird nicht unterstützt. Alle Unterbrechungen des Clusternetzwerks ähneln einem Knotenimageupgrade oder einem Kubernetes-Versionsupgrade, bei dem für jeden Knoten in einem Knotenpool ein Reimaging durchgeführt wird.

Azure CNI-Clusterupgrade

Aktualisieren Sie einen vorhandenen Azure CNI-Cluster, um Overlay mithilfe des Befehls „az aks update“ zu verwenden.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin-mode overlay \
--pod-cidr 192.168.0.0/16

Der Parameter „--pod-cidr“ ist beim Upgrade von Legacy-CNI erforderlich, da die Pods IP-Adressen aus einem neuen Überlagerungsbereich abrufen müssen, der sich nicht mit dem vorhandenen Knotensubnetz überschneidet. Das Pod-CIDR darf auch nicht mit VNET-Adressen der Knotenpools überlappen. Wenn Ihre VNet-Adresse beispielsweise 10.0.0.0/8 lautet und sich Ihre Knoten im Subnetz 10.240.0.0/16 befinden, darf sich der --pod-cidr nicht mit 10.0.0.0/8 oder dem vorhandenen Dienst-CIDR im Cluster überschneiden.

Kubenet-Clusterupgrade

Aktualisieren Sie einen vorhandenen Kubenet-Cluster, um Azure CNI Overlay mithilfe des Befehls az aks update zu verwenden.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin azure \
--network-plugin-mode overlay

Da das Cluster bereits einen privaten CIDR für Pods verwendet, der nicht mit dem IP-Raum des VNet überlappt, müssen Sie den Parameter --pod-cidr nicht angeben, und der Pod-CIDR bleibt gleich.

Hinweis

Beim Upgrade von Kubenet auf CNI Overlay ist die Routingtabelle für das Podrouting nicht mehr erforderlich. Wenn der Cluster eine vom Kunden bereitgestellte Routingtabelle verwendet, werden die Routen, die zum Weiterleiten des Poddatenverkehrs an den richtigen Knoten verwendet wurden, während des Migrationsvorgangs automatisch gelöscht. Wenn der Cluster eine verwaltete Routingtabelle verwendet (die Routingtabelle wurde von AKS erstellt und befindet sich in der Knotenressourcengruppe), wird diese Routingtabelle im Rahmen der Migration gelöscht.

Dual-Stack-Netzwerk

Sie können AKS-Cluster Ihre in einem Modus mit dualem Stapel (Dual Stack) bereitstellen, wenn Sie ein Überlagerungsnetzwerk und ein virtuelles Azure-Netzwerk mit dualem Stapel verwenden. In dieser Konfiguration erhalten Knoten sowohl eine IPv4- als auch eine IPv6-Adresse aus dem Subnetz des virtuellen Azure-Netzwerks. Pods erhalten sowohl eine IPv4- als auch eine IPv6-Adresse aus einem logisch unterschiedlichen Adressraum für das Subnetz des virtuellen Azure-Netzwerks der Knoten. Die Netzwerkadressübersetzung (NAT, Network Address Translation) wird dann so konfiguriert, dass die Pods Ressourcen im virtuellen Azure-Netzwerk erreichen können. Die Quell-IP-Adresse des Datenverkehrs wird mittels NAT in die primäre IP-Adresse des Knotens innerhalb der gleichen IP-Adressfamilie übersetzt (also IPv4 in IPv4 und IPv6 in IPv6).

Voraussetzungen

  • Sie müssen Azure CLI 2.48.0 oder höher installieren.
  • Kubernetes ab Version 1.26.3.

Begrenzungen

Die folgenden Features werden bei Netzwerken mit dualem Stapel nicht unterstützt:

  • Windows-Knotenpools
  • Azure-Netzwerkrichtlinien
  • Calico-Netzwerkrichtlinien
  • NAT Gateway
  • Add-On für virtuelle Knoten

Bereitstellen eines AKS-Clusters mit dualem Stapel

Zur Unterstützung von Clustern mit dualem Stapel werden die folgenden Attribute bereitgestellt:

  • --ip-families: Akzeptiert eine durch Kommas getrennte Liste mit IP-Adressfamilien, die im Cluster aktiviert werden sollen.
    • Nur ipv4 oder ipv4,ipv6 werden unterstützt.
  • --pod-cidrs: Akzeptiert eine durch Kommas getrennte Liste mit IP-Bereichen (in CIDR-Notation), aus denen Pod-IP-Adressen zugewiesen werden sollen.
    • Anzahl und Reihenfolge der Bereiche in dieser Liste müssen dem für --ip-families angegebenen Wert entsprechen.
    • Wenn keine Werte angegeben sind, wird der Standardwert „10.244.0.0/16,fd12:3456:789a::/64“ verwendet.
  • --service-cidrs: Akzeptiert eine durch Kommas getrennte Liste mit IP-Bereichen (in CIDR-Notation), aus denen Dienst-IP-Adressen zugewiesen werden sollen.
    • Anzahl und Reihenfolge der Bereiche in dieser Liste müssen dem für --ip-families angegebenen Wert entsprechen.
    • Wenn keine Werte angegeben sind, wird der Standardwert „10.0.0.0/16,fd12:3456:789a:1::/108“ verwendet.
    • Das IPv6-Subnetz, das --service-cidrs zugewiesen ist, darf nicht größer als /108 sein.

Erstellen eines AKS-Clusters mit dualem Stapel

  1. Erstellen Sie mit dem Befehl [az group create][az-group-create] eine Azure-Ressourcengruppe für den Cluster.

    az group create --location <region> --name <resourceGroupName>

  2. Erstellen Sie einen AKS-Cluster mit dualem Stapel mit dem Befehl „az aks create“, wobei der --ip-families-Parameter auf „ipv4,ipv6“ festgelegt sein sollte.

    az aks create \
    --location <region> \
    --resource-group <resourceGroupName> \
    --name <clusterName> \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --ip-families ipv4,ipv6 \
    --generate-ssh-keys

Erstellen einer Beispielworkload

Nachdem der Cluster erstellt wurde, können Sie Ihre Workloads bereitstellen. Dieser Artikel führt Sie durch eine beispielhafte Workloadbereitstellung eines NGINX-Webservers.

Installieren eines NGINX-Webservers

Das Add-on für Anwendungsrouting ist die empfohlene Methode für den Eingang in ein AKS-Cluster. Weitere Informationen zum Add-on für Anwendungsrouting und wie Sie eine Anwendung mit dem Add-on bereitstellen, finden Sie unter Verwalteter NGINX-Eingang mit dem Anwendungsrouting-Add-On.

Verfügbarmachen der Workload über einen Dienst vom Typ „LoadBalancer“

Wichtig

Für IPv6-Dienste in AKS gelten derzeit zwei Einschränkungen.

  • Von Azure Load Balancer werden über eine verbindungslokale Adresse Integritätstests an IPv6-Ziele gesendet. In Azure Linux-Knotenpools kann dieser Datenverkehr nicht an einen Pod weitergeleitet werden kann, deshalb wird Datenverkehr, der zu mit externalTrafficPolicy: Cluster bereitgestellten IPv6-Diensten fließt, fehlschlagen. IPv6-Dienste müssen mit externalTrafficPolicy: Local bereitgestellt werden, was dazu führt, dass kube-proxy auf den Test auf dem Knoten reagiert.
  • Da bei Kubernetes-Versionen vor 1.27 für den Lastenausgleich nur die erste IP-Adresse für einen Dienst bereitgestellt wird, erhält ein Dienst mit dualem Stapel nur eine öffentliche IP-Adresse für die erste aufgeführte IP-Adressfamilie. Wenn Sie für eine einzelne Bereitstellung einen Dienst mit dualem Stapel bereitstellen möchten, müssen zwei auf den gleichen Selektor ausgerichtete Dienste erstellt werden: einer für IPv4 und einer für IPv6. Diese Einschränkung besteht in Kubernetes 1.27 oder höher nicht mehr.

  1. Machen Sie die NGINX-Bereitstellung mit dem Befehl „kubectl expose deployment nginx“ verfügbar.

    kubectl expose deployment nginx --name=nginx-ipv4 --port=80 --type=LoadBalancer'
kubectl expose deployment nginx --name=nginx-ipv6 --port=80 --type=LoadBalancer --overrides='{"spec":{"ipFamilies": ["IPv6"]}}'

    Ihnen wir eine Ausgabe angezeigt, die besagt, dass die Dienste verfügbar gemacht wurden.

    service/nginx-ipv4 exposed
service/nginx-ipv6 exposed

  2. Nachdem die Bereitstellung verfügbar gemacht wurde und die LoadBalancer-Dienste vollständig bereitgestellt wurden, rufen Sie die IP-Adressen der Dienste mithilfe des Befehls „kubectl get services“ ab.

    kubectl get services

    NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s

  3. Überprüfen Sie die Funktionalität über eine Befehlszeilenwebanforderung von einem IPv6-fähigen Host. Azure Cloud Shell ist nicht IPv6-fähig.

    SERVICE_IP=$(kubectl get services nginx-ipv6 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
curl -s "http://[${SERVICE_IP}]" | head -n5

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>

Nächste Schritte

Informationen zur Verwendung von AKS mit Ihrem eigenen CNI-Plug-In (Container Network Interface, Containerschnittstelle) finden Sie unter Eigenes CNI-Plug-In (Container Network Interface).