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 vorab reservierten Pool von IP-Adressen 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.
  • Sie können kein Anwendungsgateway für Container für einen Overlaycluster 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

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:

  • 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>

Dual-Stack-Netzwerk mit Azure CNI Powered by Cilium (Vorschau)

Sie können Ihre AKS-Dual-Stack-Cluster mit Azure CNI Powered by Cilium bereitstellen. Auf diese Weise können Sie Ihren IPv6-Datenverkehr auch mit der Netzwerkrichtlinien-Engine von Cilium steuern.

Wichtig

AKS-Previewfunktionen stehen gemäß dem Self-Service- und Aktivierungsprinzip zur Verfügung. Vorschauversionen werden „wie besehen“ und „wie verfügbar“ bereitgestellt und sind von Service Level Agreements und der Herstellergarantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:

Voraussetzungen

  • Sie müssen über die neueste Version der AKS-Vorschauerweiterung verfügen.
  • Sie müssen über Kubernetes Version 1.29 oder höher verfügen.

Installieren der Azure CLI-Erweiterung „aks-preview“

  • Installieren Sie die Erweiterung „aks-preview“ mithilfe des Befehls az extension add.

    az extension add --name aks-preview

  • Führen Sie mit dem Befehl az extension update ein Update auf die neueste veröffentlichte Version der Erweiterung durch.

    az extension update --name aks-preview

Registrieren des Featureflags „AzureOverlayDualStackPreview“

  1. Registrieren Sie das Featureflag AzureOverlayDualStackPreview mithilfe des Befehls az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"

    Es dauert einige Minuten, bis der Status Registered (Registriert) angezeigt wird.

  2. Überprüfen Sie den Registrierungsstatus mit dem Befehl az feature show:

    az feature show --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"

  3. Wenn der Zustand Registered (Registriert) lautet, aktualisieren Sie die Registrierung des Ressourcenanbieters Microsoft.ContainerService mithilfe des Befehls az provider register.

    az provider register --namespace Microsoft.ContainerService

Einrichten von Überlagerungsclustern mit Azure CNI Powered by Cilium

Erstellen Sie mit Azure CNI Overlay mithilfe des Befehls „az aks create“ einen Cluster. Achten Sie darauf, für die Angabe der Cilium-Datenebene das --network-dataplane cilium-Argument zu verwenden.

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

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --ip-families ipv4,ipv6 \
    --generate-ssh-keys\

Weitere Informationen zu Azure CNI Powered by Cilium finden Sie unter Azure CNI Powered by Cilium.

Dual-Stack-Netzwerk mit Windows-Knotenpools (Vorschau)

Sie können Ihre AKS-Dual-Stack-Cluster mit Windows-Knotenpools bereitstellen.

Wichtig

AKS-Previewfunktionen stehen gemäß dem Self-Service- und Aktivierungsprinzip zur Verfügung. Vorschauversionen werden „wie besehen“ und „wie verfügbar“ bereitgestellt und sind von Service Level Agreements und der Herstellergarantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:

Installieren der Azure CLI-Erweiterung „aks-preview“

  • Installieren Sie die Erweiterung „aks-preview“ mithilfe des Befehls az extension add.

    az extension add --name aks-preview

  • Führen Sie mit dem Befehl az extension update ein Update auf die neueste veröffentlichte Version der Erweiterung durch.

    az extension update --name aks-preview

Registrieren des Featureflags „AzureOverlayDualStackPreview“

  1. Registrieren Sie das Featureflag AzureOverlayDualStackPreview mithilfe des Befehls az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"

    Es dauert einige Minuten, bis der Status Registered (Registriert) angezeigt wird.

  2. Überprüfen Sie den Registrierungsstatus mit dem Befehl az feature show:

    az feature show --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"

  3. Wenn der Zustand Registered (Registriert) lautet, aktualisieren Sie die Registrierung des Ressourcenanbieters Microsoft.ContainerService mithilfe des Befehls az provider register.

    az provider register --namespace Microsoft.ContainerService

Einrichten eines Überlagerungsclusters

Erstellen Sie mit Azure CNI Overlay mithilfe des Befehls „az aks create“ einen Cluster.

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

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --ip-families ipv4,ipv6 \
    --generate-ssh-keys\

Hinzufügen eines Windows-Knotenpools zum Cluster

Fügen Sie dem Cluster mithilfe des Befehls [az aks nodepool add][az-aks-nodepool-add] einen Windows-Knotenpool hinzu.

az aks nodepool add \
    --resource-group $resourceGroup \
    --cluster-name $clusterName \
    --os-type Windows \
    --name winpool1 \
    --node-count 2

Nächste Schritte

Informationen zum Upgrade vorhandener Cluster auf die Azure CNI-Überlagerung finden Sie unter Upgrade von AZURE Kubernetes Service (AKS) IPAM-Modi und Dataplane Technology.

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).