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 z 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 Calico
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.
  • 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 -n $clusterName -g $resourceGroup \
  --location $location \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16

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  -g $resourceGroup --cluster-name $clusterName \
  --name $nodepoolName --node-count 1 \
  --mode system --vnet-subnet-id $subnetResourceId

Uaktualnianie istniejącego klastra do nakładki CNI

Uwaga

Istniejący klaster usługi Azure CNI można zaktualizować do nakładki, jeśli klaster spełnia następujące kryteria:

  • Klaster znajduje się na platformie Kubernetes w wersji 1.22 lub nowszej.
  • Nie używa funkcji dynamicznej alokacji adresów IP zasobnika.
  • Nie ma włączonych zasad sieciowych. Aparat zasad sieciowych można odinstalować przed uaktualnieniem, zobacz Odinstalowywanie menedżera zasad sieciowych platformy Azure lub Calico
  • Nie używa żadnych pul węzłów systemu Windows z platformą Docker jako środowiska uruchomieniowego kontenera.

Uwaga

Ponieważ domena routingu nie jest jeszcze obsługiwana dla usługi ARM, nakładka CNI nie jest jeszcze obsługiwana w węzłach procesora opartych na usłudze ARM (ARM64).

Uwaga

Uaktualnianie istniejącego klastra do nakładki CNI jest procesem niewzględnialnym.

Ostrzeżenie

Przed kompilacją systemu operacyjnego Windows 20348.1668 wystąpiło ograniczenie dotyczące zasobników nakładki systemu Windows nieprawidłowo SNATing pakietów z zasobników sieci hosta, co miało bardziej szkodliwy wpływ na klastry uaktualniania do nakładki. Aby uniknąć tego problemu, użyj kompilacji systemu operacyjnego Windows większej lub równej 20348.1668.

Ostrzeżenie

Jeśli używasz niestandardowej konfiguracji azure-ip-masq-agent w celu uwzględnienia dodatkowych zakresów adresów IP, które nie powinny zawierać pakietów SNAT z zasobników, uaktualnienie do nakładki azure CNI może przerwać łączność z tymi zakresami. Adresy IP zasobników z miejsca nakładki nie będą osiągalne przez wszystkie elementy spoza węzłów klastra. Ponadto w przypadku wystarczająco starych klastrów może istnieć obiekt ConfigMap pozostawiony z poprzedniej wersji agenta azure-ip-masq-agent. Jeśli ten obiekt ConfigMap o nazwie azure-ip-masq-agent-config, istnieje i nie został celowo usunięty przed uruchomieniem polecenia aktualizacji. Jeśli nie używasz niestandardowej konfiguracji ip-masq-agent, w procesie uaktualniania powinien istnieć tylko azure-ip-masq-agent-config-reconciled obiekt ConfigMap w odniesieniu do konfiguracji usługi Azure ip-masq-agent Mapy a zostanie on automatycznie zaktualizowany.

Proces uaktualniania wyzwala ponowne obrazy każdej puli węzłów jednocześnie. Uaktualnienie każdej puli węzłów oddzielnie do nakładki nie jest obsługiwane. Wszelkie zakłócenia w sieci klastra są podobne do uaktualnienia obrazu węzła lub uaktualnienia wersji platformy Kubernetes, w których każdy węzeł w puli węzłów jest ponownie obrazowany.

Uaktualnianie klastra usługi Azure CNI

Zaktualizuj istniejący klaster usługi Azure CNI, aby użyć nakładki az aks update przy użyciu polecenia .

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

Parametr jest wymagany podczas uaktualniania --pod-cidr ze starszej wersji sieci CNI, ponieważ zasobniki muszą pobierać adresy IP z nowego miejsca nakładki, co nie nakłada się na istniejącą podsieć węzła. CiDR zasobnika nie może również nakładać się na żaden adres sieci wirtualnej pul węzłów. Jeśli na przykład adres sieci wirtualnej to 10.0.0.0/8, a węzły znajdują się w podsieci 10.240.0.0/16, --pod-cidr nie można nakładać się na 10.0.0.0/8 lub istniejącą trasę CIDR usługi w klastrze.

Uaktualnianie klastra Kubenet

Zaktualizuj istniejący klaster Kubenet, aby używać nakładki usługi Azure CNI przy użyciu az aks update polecenia .

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

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

Ponieważ klaster korzysta już z prywatnej trasy CIDR dla zasobników, które nie nakładają się na obszar IP sieci wirtualnej, nie musisz określać parametru --pod-cidr , a ciDR zasobnika pozostanie taka sama.

Uwaga

Podczas uaktualniania z platformy Kubenet do nakładki CNI tabela tras nie będzie już wymagana do routingu zasobników. Jeśli klaster korzysta z tabeli tras dostarczonej przez klienta, trasy, które były używane do kierowania ruchu zasobników do odpowiedniego węzła, zostaną automatycznie usunięte podczas operacji migracji. Jeśli klaster korzysta z zarządzanej tabeli tras (tabela tras została utworzona przez usługę AKS i znajduje się w grupie zasobów węzła), ta tabela tras zostanie usunięta w ramach migracji.

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:

  • Pule węzłów systemu Windows
  • 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 ipv4ipv4,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 -l <region> -n <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 -l <region> -g <resourceGroupName> -n <clusterName> \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --ip-families ipv4,ipv6

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>

Następne kroki

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