Udostępnij za pośrednictwem

Konfigurowanie sieci nakładki Azure CNI w usłudze Azure Kubernetes Service

  • Artykuł

Tradycyjny interfejs sieci kontenera platformy Azure (CNI) przypisuje adres IP sieci wirtualnej do każdego zasobnika. Przypisuje ten adres IP ze wstępnie zarezerwowanego zestawu adresów IP w każdym węźle lub oddzielnej podsieci zarezerwowanej dla zasobników. Takie podejście wymaga planowania adresów IP i może prowadzić do wyczerpania problemów, co powoduje trudności ze skalowaniem klastrów w miarę wzrostu zapotrzebowania aplikacji.

Dzięki nakładce usługi Azure CNI węzły klastra są wdrażane w podsieci usługi Azure Virtual Network (VNet). Zasobniki są przypisywane adresy IP z prywatnej trasy CIDR logicznie różni się od sieci wirtualnej obsługującej węzły. Ruch zasobników i węzłów w klastrze używa sieci nakładki. Translator adresów sieciowych używa adresu IP węzła do uzyskania dostępu do zasobów spoza klastra. To rozwiązanie pozwala zaoszczędzić znaczną ilość adresów IP sieci wirtualnej i umożliwić skalowanie klastra do dużych rozmiarów. Dodatkową zaletą jest możliwość ponownego użycia prywatnej trasy CIDR w różnych klastrach usługi AKS, która rozszerza przestrzeń IP dostępną dla konteneryzowanych aplikacji w usłudze Azure Kubernetes Service (AKS).

Omówienie sieci nakładki

W obszarze Sieć nakładki tylko węzły klastra Kubernetes są przypisane adresy IP z podsieci. Zasobniki odbierają adresy IP z prywatnej trasy CIDR udostępnionej podczas tworzenia klastra. Każdy węzeł ma przypisaną przestrzeń adresową /24 wyrzeźbioną z tej samej trasy CIDR. Dodatkowe węzły utworzone podczas skalowania klastra automatycznie odbierają /24 przestrzenie adresowe z tej samej trasy CIDR. Usługa Azure CNI przypisuje adresy IP do zasobników z tej /24 przestrzeni.

Oddzielna domena routingu jest tworzona w stosie sieci platformy Azure dla prywatnej przestrzeni CIDR zasobnika, która tworzy sieć nakładki na potrzeby bezpośredniej komunikacji między zasobnikami. Nie ma potrzeby aprowizowania tras niestandardowych w podsieci klastra ani używania metody hermetyzacji do tunelowania ruchu między zasobnikami, co zapewnia wydajność łączności między zasobnikami na równi z maszynami wirtualnymi w sieci wirtualnej. Obciążenia uruchomione w zasobnikach nie wiedzą nawet, że odbywa się manipulowanie adresami sieciowymi.

Diagram przedstawiający dwa węzły z trzema zasobnikami działającymi w sieci nakładki. Ruch zasobnika do punktów końcowych poza klastrem jest kierowany za pośrednictwem translatora adresów sieciowych.

Komunikacja z punktami końcowymi spoza klastra, takimi jak lokalne i równorzędne sieci wirtualne, odbywa się przy użyciu adresu IP węzła za pośrednictwem translatora adresów sieciowych. Usługa Azure CNI tłumaczy źródłowy adres IP (adres IP nakładki zasobnika) ruchu na podstawowy adres IP maszyny wirtualnej, co umożliwia stosowi sieci platformy Azure kierowanie ruchu do miejsca docelowego. Punkty końcowe spoza klastra nie mogą łączyć się bezpośrednio z zasobnikiem. Musisz opublikować aplikację zasobnika jako usługę Kubernetes Load Balancer, aby była osiągalna w sieci wirtualnej.

Możesz zapewnić łączność wychodzącą (wychodzącą) z Internetem dla zasobników nakładki przy użyciu modułu równoważenia obciążenia jednostki SKU w warstwie Standardowa lub zarządzanej bramy translatora adresów sieciowych. Możesz również kontrolować ruch wychodzący, kierując go do zapory przy użyciu tras zdefiniowanych przez użytkownika w podsieci klastra.

Łączność ruchu przychodzącego z klastrem można skonfigurować przy użyciu kontrolera ruchu przychodzącego, takiego jak routing aplikacji Nginx lub HTTP. Nie można skonfigurować łączności ruchu przychodzącego przy użyciu bramy aplikacja systemu Azure. Aby uzyskać szczegółowe informacje, zobacz Ograniczenia dotyczące nakładki usługi Azure CNI.

Różnice między nakładką kubenet i azure CNI

Podobnie jak w przypadku nakładki usługi Azure CNI, platforma Kubenet przypisuje adresy IP do zasobników z przestrzeni adresowej logicznie różni się od sieci wirtualnej, ale ma skalowanie i inne ograniczenia. Poniższa tabela zawiera szczegółowe porównanie platformy Kubenet i nakładki CNI platformy Azure. Jeśli nie chcesz przypisywać adresów IP sieci wirtualnej do zasobników z powodu niedoboru adresów IP, zalecamy użycie nakładki usługi Azure CNI.

Obszar Nakładka Azure CNI Kubenet
Skalowanie klastra 5000 węzłów i 250 zasobników/węzłów 400 węzłów i 250 zasobników/węzłów
Konfiguracja sieci Proste — brak dodatkowych konfiguracji wymaganych do obsługi sieci zasobników Złożone — wymaga tabel tras i tras zdefiniowanych przez użytkownika w podsieci klastra dla sieci zasobników
Wydajność łączności zasobnika Wydajność na równi z maszynami wirtualnymi w sieci wirtualnej Dodatkowy przeskok dodaje opóźnienie
Zasady sieciowe platformy Kubernetes Zasady sieci platformy Azure, Calico, Cilium Perkal
Obsługiwane platformy systemu operacyjnego Linux i Windows Server 2022, 2019 Tylko Linux

Planowanie adresów IP

  • Węzły klastra: podczas konfigurowania klastra usługi AKS upewnij się, że podsieci sieci wirtualnej mają wystarczającą ilość miejsca na zwiększenie skali w przyszłości. Każdą pulę węzłów można przypisać do dedykowanej podsieci. Podsieć /24może mieścić się w maksymalnie 251 węzłach, ponieważ pierwsze trzy adresy IP są zarezerwowane do zadań zarządzania.
  • Zasobniki: rozwiązanie nakładki przypisuje przestrzeń adresową /24 zasobników w każdym węźle z prywatnej trasy CIDR określonej podczas tworzenia klastra. Rozmiar /24 jest stały i nie można go zwiększyć ani zmniejszyć. W węźle można uruchomić maksymalnie 250 zasobników. Podczas planowania przestrzeni adresowej zasobnika upewnij się, że prywatna usługa CIDR jest wystarczająco duża, aby zapewnić /24 przestrzenie adresowe dla nowych węzłów do obsługi przyszłego rozszerzenia klastra.
    • Podczas planowania przestrzeni adresowej IP dla zasobników należy wziąć pod uwagę następujące czynniki:
      • To samo miejsce CIDR zasobnika może być używane w wielu niezależnych klastrach usługi AKS w tej samej sieci wirtualnej.
      • Miejsce CIDR zasobnika nie może nakładać się na zakres podsieci klastra.
      • Miejsce CIDR zasobnika nie może nakładać się na bezpośrednie połączone sieci (takie jak komunikacja równorzędna sieci wirtualnych, usługa ExpressRoute lub sieć VPN). Jeśli ruch zewnętrzny ma źródłowe adresy IP w zakresie podCIDR, wymaga tłumaczenia na nienakładające się adresy IP za pośrednictwem protokołu SNAT w celu komunikowania się z klastrem.
  • Zakres adresów usługi Kubernetes: rozmiar adresu usługi CIDR zależy od liczby usług klastra, które chcesz utworzyć. Musi być mniejszy niż /12. Ten zakres nie powinien pokrywać się z zakresem CIDR zasobnika, zakresem podsieci klastra i zakresem adresów IP używanymi w równorzędnych sieciach wirtualnych i sieciach lokalnych.
  • Adres IP usługi DNS platformy Kubernetes: ten adres IP znajduje się w zakresie adresów usługi Kubernetes używanym przez odnajdywanie usługi klastra. Nie używaj pierwszego adresu IP w zakresie adresów, ponieważ ten adres jest używany dla kubernetes.default.svc.cluster.local tego adresu.

Sieciowe grupy zabezpieczeń

Zasobnik do ruchu zasobnika z nakładką usługi Azure CNI nie jest hermetyzowany, a reguły sieciowej grupy zabezpieczeń podsieci są stosowane. Jeśli sieciowa grupa zabezpieczeń podsieci zawiera reguły odmowy, które miałyby wpływ na ruch CIDR zasobnika, upewnij się, że obowiązują następujące reguły w celu zapewnienia prawidłowej funkcjonalności klastra (oprócz wszystkich wymagań dotyczących ruchu wychodzącego usługi AKS):

  • Ruch z węzła CIDR do węzła CIDR we wszystkich portach i protokołach
  • Ruch z węzła CIDR do trasy CIDR zasobnika we wszystkich portach i protokołach (wymagany do routingu ruchu usługi)
  • Ruch z zasobnika CIDR do trasy CIDR zasobnika we wszystkich portach i protokołach (wymagany dla zasobnika do zasobnika i zasobnika do ruchu usługi, w tym DNS)

Ruch z zasobnika do dowolnego miejsca docelowego poza blokiem CIDR zasobnika korzysta z protokołu SNAT, aby ustawić źródłowy adres IP na adres IP węzła, w którym działa zasobnik.

Jeśli chcesz ograniczyć ruch między obciążeniami w klastrze, zalecamy użycie zasad sieciowych.

Maksymalna liczba zasobników na węzeł

Maksymalną liczbę zasobników na węzeł można skonfigurować podczas tworzenia klastra lub podczas dodawania nowej puli węzłów. Domyślną wartością nakładki usługi Azure CNI jest 250. Maksymalna wartość, którą można określić w nakładce CNI platformy Azure, wynosi 250, a minimalna wartość to 10. Maksymalna wartość zasobników na węzeł skonfigurowana podczas tworzenia puli węzłów ma zastosowanie tylko do węzłów w tej puli węzłów.

Wybieranie modelu sieciowego do użycia

Usługa Azure CNI oferuje dwie opcje adresowania IP dla zasobników: tradycyjna konfiguracja, która przypisuje adresy IP sieci wirtualnej do zasobników i sieci nakładki. Wybór opcji, która ma być używana dla klastra usługi AKS, to równowaga między elastycznością a zaawansowanymi potrzebami konfiguracji. Poniższe zagadnienia pomagają określić, kiedy każdy model sieciowy może być najbardziej odpowiedni.

Użyj sieci nakładki, gdy:

  • Chcesz skalować do dużej liczby zasobników, ale masz ograniczoną przestrzeń adresową IP w sieci wirtualnej.
  • Większość komunikacji zasobnika znajduje się w klastrze.
  • Nie potrzebujesz zaawansowanych funkcji usługi AKS, takich jak węzły wirtualne.

Użyj tradycyjnej opcji sieci wirtualnej, gdy:

  • Masz dostępną przestrzeń adresową IP.
  • Większość komunikacji zasobnika dotyczy zasobów spoza klastra.
  • Zasoby spoza klastra muszą bezpośrednio uzyskać dostęp do zasobników.
  • Potrzebujesz zaawansowanych funkcji usługi AKS, takich jak węzły wirtualne.

Ograniczenia dotyczące nakładki usługi Azure CNI

Nakładka usługi Azure CNI ma następujące ograniczenia:

  • Nie można użyć usługi Application Gateway jako kontrolera ruchu przychodzącego (AGIC) dla klastra nakładki.
  • Nie można użyć usługi Application Gateway dla kontenerów dla klastra nakładki.
  • Zestawy dostępności maszyn wirtualnych (VMAS) nie są obsługiwane w przypadku nakładki.
  • Maszyn wirtualnych serii DCsv2 nie można używać w pulach węzłów. Aby spełnić wymagania dotyczące przetwarzania poufnego, rozważ użycie maszyn wirtualnych z serii DCasv5 lub DCadsv5.
  • Jeśli używasz własnej podsieci do wdrożenia klastra, nazwy podsieci, sieci wirtualnej i grupy zasobów zawierającej sieć wirtualną muszą mieć co najmniej 63 znaki. Wynika to z faktu, że te nazwy będą używane jako etykiety w węzłach roboczych usługi AKS i dlatego podlegają regułom składni etykiet Kubernetes.

Konfigurowanie klastrów nakładek

Uwaga

Aby użyć argumentu, musisz mieć interfejs wiersza polecenia w wersji 2.48.0 lub nowszej --network-plugin-mode . W przypadku systemu Windows musisz mieć zainstalowane rozszerzenie interfejsu wiersza polecenia platformy Azure w wersji zapoznawczej aks-preview i wykonać poniższe instrukcje.

Utwórz klaster za pomocą nakładki az aks create usługi Azure CNI przy użyciu polecenia . Pamiętaj, aby użyć argumentu --network-plugin-mode , aby określić klaster nakładki. Jeśli nie określono trasy CIDR zasobnika, usługa AKS przypisuje domyślne miejsce: 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

Dodawanie nowej puli węzłów do dedykowanej podsieci

Po utworzeniu klastra za pomocą nakładki usługi Azure CNI można utworzyć kolejną pulę węzłów i przypisać węzły do nowej podsieci tej samej sieci wirtualnej. Takie podejście może być przydatne, jeśli chcesz kontrolować adresy IP ruchu przychodzącego lub wychodzącego hosta z/do obiektów docelowych w tej samej sieci wirtualnej lub równorzędnych sieciach wirtualnych.

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

Sieć z podwójnym stosem

Klastry usługi AKS można wdrożyć w trybie podwójnego stosu podczas korzystania z sieci nakładki i sieci wirtualnej platformy Azure z podwójnym stosem. W tej konfiguracji węzły otrzymują zarówno adres IPv4, jak i IPv6 z podsieci sieci wirtualnej platformy Azure. Zasobniki odbierają zarówno adres IPv4, jak i IPv6 z logicznie innej przestrzeni adresowej do podsieci sieci wirtualnej platformy Azure węzłów. Dzięki skonfigurowaniu translatora adresów sieciowych (NAT) zasobniki mogą uzyskać dostęp do zasobów w sieci wirtualnej platformy Azure. Źródłowy adres IP ruchu to TRANSLATOR adresów sieciowych do podstawowego adresu IP węzła tej samej rodziny (IPv4 do IPv4 i IPv6 do IPv6).

Wymagania wstępne

  • Musisz mieć zainstalowany interfejs wiersza polecenia platformy Azure w wersji 2.48.0 lub nowszej.
  • Kubernetes w wersji 1.26.3 lub nowszej.

Ograniczenia

Następujące funkcje nie są obsługiwane w przypadku sieci z podwójnym stosem:

  • Zasady sieci platformy Azure
  • Zasady sieci Calico
  • Brama translatora adresów sieciowych
  • Dodatek węzłów wirtualnych

Wdrażanie klastra usługi AKS z dwoma stosami

Dostępne są następujące atrybuty do obsługi klastrów z dwoma stosami:

  • --ip-families: Pobiera rozdzielaną przecinkami listę rodzin adresów IP, które mają być włączone w klastrze.
    • Obsługiwane są tylko lub ipv4 ipv4,ipv6 obsługiwane.
  • --pod-cidrs: Pobiera rozdzielaną przecinkami listę zakresów adresów IP notacji CIDR w celu przypisania adresów IP zasobników.
    • Liczba i kolejność zakresów na tej liście musi być zgodna z wartością podaną w pliku --ip-families.
    • Jeśli nie podano żadnych wartości, zostanie użyta wartość 10.244.0.0/16,fd12:3456:789a::/64 domyślna.
  • --service-cidrs: Pobiera rozdzielaną przecinkami listę zakresów adresów IP notacji CIDR w celu przypisania adresów IP usługi.
    • Liczba i kolejność zakresów na tej liście musi być zgodna z wartością podaną w pliku --ip-families.
    • Jeśli nie podano żadnych wartości, zostanie użyta wartość 10.0.0.0/16,fd12:3456:789a:1::/108 domyślna.
    • Podsieć IPv6 przypisana do --service-cidrs nie może być większa niż /108.

Tworzenie klastra usługi AKS z dwoma stosami

  1. Utwórz grupę zasobów platformy Azure dla klastra przy użyciu polecenia [az group create][az-group-create].

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

  2. Utwórz klaster usługi AKS z podwójnym stosem az aks create przy użyciu polecenia z parametrem ustawionym --ip-families na ipv4,ipv6.

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

Tworzenie przykładowego obciążenia

Po utworzeniu klastra możesz wdrożyć obciążenia. W tym artykule przedstawiono przykładowe wdrożenie obciążenia serwera internetowego NGINX.

Wdrażanie serwera internetowego NGINX

Dodatek routingu aplikacji jest zalecanym sposobem na ruch przychodzący w klastrze usługi AKS. Aby uzyskać więcej informacji na temat dodatku routingu aplikacji i przykład sposobu wdrażania aplikacji z dodatkiem, zobacz Managed NGINX ingress with the application routing add-on (Zarządzana ruch przychodzący NGINX z dodatkiem routingu aplikacji).

Uwidacznianie obciążenia za pośrednictwem LoadBalancer usługi typu

Ważne

Obecnie istnieją dwa ograniczenia dotyczące usług IPv6 w usłudze AKS.

  • Usługa Azure Load Balancer wysyła sondy kondycji do miejsc docelowych IPv6 z adresu lokalnego linku. W pulach węzłów systemu Linux platformy Azure ten ruch nie może być kierowany do zasobnika, więc ruch przepływający do usług IPv6 wdrożonych z externalTrafficPolicy: Cluster powodu niepowodzenia. Usługi IPv6 należy wdrożyć za pomocą externalTrafficPolicy: Localpolecenia , co powoduje kube-proxy reagowanie na sondę w węźle.
  • Przed rozwiązaniem Kubernetes w wersji 1.27 tylko pierwszy adres IP usługi zostanie aprowizowany do modułu równoważenia obciążenia, więc usługa dwustosowa otrzymuje publiczny adres IP tylko dla swojej rodziny adresów IP z pierwszej listy. Aby zapewnić usługę podwójnego stosu dla pojedynczego wdrożenia, utwórz dwie usługi przeznaczone dla tego samego selektora, jedną dla protokołu IPv4 i jedną dla protokołu IPv6. Nie jest to już ograniczenie dotyczące platformy Kubernetes w wersji 1.27 lub nowszej.

  1. Uwidaczniaj wdrożenie serwera NGINX przy użyciu kubectl expose deployment nginx polecenia .

    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"]}}'

    Otrzymasz dane wyjściowe, które pokazują, że usługi zostały ujawnione.

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

  2. Po ujawnieniu wdrożenia i LoadBalancer pełnym aprowizowanym usługach uzyskaj adresy IP usług przy użyciu kubectl get services polecenia .

    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. Sprawdź funkcjonalność za pośrednictwem żądania internetowego wiersza polecenia z hosta obsługującego protokół IPv6. Usługa Azure Cloud Shell nie obsługuje protokołu IPv6.

    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>

Sieć dwustosowa za pomocą usługi Azure CNI obsługiwanej przez cilium — (wersja zapoznawcza)

Klastry AKS z podwójnym stosem można wdrożyć za pomocą usługi Azure CNI obsługiwanej przez cilium. Pozwala to również kontrolować ruch IPv6 za pomocą aparatu zasad sieciowych Cilium.

Ważne

Funkcje usługi AKS w wersji zapoznawczej są dostępne na zasadzie samoobsługi. Wersje zapoznawcze są udostępniane w wersji "as is" i "jako dostępne" i są wykluczone z umów dotyczących poziomu usług i ograniczonej gwarancji. Wersje zapoznawcze usługi AKS są częściowo objęte pomocą techniczną dla klientów. W związku z tym te funkcje nie są przeznaczone do użytku produkcyjnego. Aby uzyskać więcej informacji, zobacz następujące artykuły pomocy technicznej:

Wymagania wstępne

  • Musisz mieć najnowszą wersję rozszerzenia usługi AKS w wersji zapoznawczej.
  • Musisz mieć platformę Kubernetes w wersji 1.29 lub nowszej.

Instalowanie rozszerzenia interfejsu wiersza polecenia platformy Azure w wersji zapoznawczej usługi aks

  • Zainstaluj rozszerzenie aks-preview przy użyciu az extension add polecenia .

    az extension add --name aks-preview

  • Zaktualizuj do najnowszej wersji rozszerzenia wydanego az extension update za pomocą polecenia .

    az extension update --name aks-preview

Rejestrowanie flagi funkcji "AzureOverlayDualStackPreview"

  1. Zarejestruj flagę AzureOverlayDualStackPreview funkcji przy użyciu az feature register polecenia .

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

    Wyświetlenie stanu Zarejestrowane trwa kilka minut.

  2. Sprawdź stan rejestracji przy użyciu az feature show polecenia :

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

  3. Gdy stan będzie odzwierciedlał wartość Zarejestrowano, odśwież rejestrację dostawcy zasobów Microsoft.ContainerService przy użyciu az provider register polecenia .

    az provider register --namespace Microsoft.ContainerService

Konfigurowanie klastrów nakładek za pomocą usługi Azure CNI obsługiwanej przez cilium

Utwórz klaster za pomocą nakładki az aks create usługi Azure CNI przy użyciu polecenia . Pamiętaj, aby użyć argumentu --network-dataplane cilium , aby określić płaszczyznę danych Cilium.

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\

Aby uzyskać więcej informacji na temat interfejsu CNI platformy Azure obsługiwanego przez cilium, zobacz Azure CNI Powered by Cilium(Azure CNI Powered by Cilium).

Pule węzłów systemu Windows z obsługą dwóch stosów — (wersja zapoznawcza)

Klastry AKS z podwójnym stosem można wdrożyć za pomocą puli węzłów systemu Windows.

Ważne

Funkcje usługi AKS w wersji zapoznawczej są dostępne na zasadzie samoobsługi. Wersje zapoznawcze są udostępniane w wersji "as is" i "jako dostępne" i są wykluczone z umów dotyczących poziomu usług i ograniczonej gwarancji. Wersje zapoznawcze usługi AKS są częściowo objęte pomocą techniczną dla klientów. W związku z tym te funkcje nie są przeznaczone do użytku produkcyjnego. Aby uzyskać więcej informacji, zobacz następujące artykuły pomocy technicznej:

Instalowanie rozszerzenia interfejsu wiersza polecenia platformy Azure w wersji zapoznawczej usługi aks

  • Zainstaluj rozszerzenie aks-preview przy użyciu az extension add polecenia .

    az extension add --name aks-preview

  • Zaktualizuj do najnowszej wersji rozszerzenia wydanego az extension update za pomocą polecenia .

    az extension update --name aks-preview

Rejestrowanie flagi funkcji "AzureOverlayDualStackPreview"

  1. Zarejestruj flagę AzureOverlayDualStackPreview funkcji przy użyciu az feature register polecenia .

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

    Wyświetlenie stanu Zarejestrowane trwa kilka minut.

  2. Sprawdź stan rejestracji przy użyciu az feature show polecenia :

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

  3. Gdy stan będzie odzwierciedlał wartość Zarejestrowano, odśwież rejestrację dostawcy zasobów Microsoft.ContainerService przy użyciu az provider register polecenia .

    az provider register --namespace Microsoft.ContainerService

Konfigurowanie klastra nakładki

Utwórz klaster za pomocą nakładki az aks create usługi Azure CNI przy użyciu polecenia .

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\

Dodawanie puli węzłów systemu Windows do klastra

Dodaj pulę węzłów systemu Windows do klastra przy użyciu polecenia [az aks nodepool add][az-aks-nodepool-add].

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

Następne kroki

Aby dowiedzieć się, jak uaktualnić istniejące klastry do nakładki usługi Azure CNI, zobacz Uaktualnianie trybów ipAM usługi Azure Kubernetes Service (AKS) i technologia dataplane.

Aby dowiedzieć się, jak korzystać z usługi AKS z własną wtyczką interfejsu sieciowego kontenera (CNI), zobacz Wtyczka Bring your own Container Network Interface (CNI).