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

Artykuł
08/16/2024

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

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

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 korzystasz z niestandardowej konfiguracji ip-masq-agent, w procesie uaktualniania powinien istnieć tylko azure-ip-masq-agent-config-reconciled obiekt ConfigMaps ConfigMaps usługi Azure ip-masq-agent.

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 używa już 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 pod CIDR pozostanie taki sam, jeśli parametr nie jest używany.

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:

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

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

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.

kubectl
YAML

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

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

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>

Uwidaczniaj wdrożenie serwera NGINX przy użyciu następującego manifestu YAML.

---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx
  name: nginx-ipv4
spec:
  externalTrafficPolicy: Cluster
  ports:
 - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx
  name: nginx-ipv6
spec:
  externalTrafficPolicy: Cluster
  ipFamilies:
 - IPv6
  ports:
 - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer

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

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"

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.

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

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

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

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"

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.

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

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

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 korzystać z usługi AKS z własną wtyczką interfejsu sieciowego kontenera (CNI), zobacz Wtyczka Bring your own Container Network Interface (CNI).

Udostępnij za pośrednictwem

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

Omówienie sieci nakładki

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

Planowanie adresów IP

Sieciowe grupy zabezpieczeń

Maksymalna liczba zasobników na węzeł

Wybieranie modelu sieciowego do użycia

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

Konfigurowanie klastrów nakładek

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

Uaktualnianie istniejącego klastra do nakładki CNI

Uaktualnianie klastra usługi Azure CNI

Uaktualnianie klastra Kubenet

Sieć z podwójnym stosem

Wymagania wstępne

Ograniczenia

Wdrażanie klastra usługi AKS z dwoma stosami

Tworzenie klastra usługi AKS z dwoma stosami

Tworzenie przykładowego obciążenia

Wdrażanie serwera internetowego NGINX

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

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

Wymagania wstępne

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

Rejestrowanie flagi funkcji "AzureOverlayDualStackPreview"

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

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

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

Rejestrowanie flagi funkcji "AzureOverlayDualStackPreview"

Konfigurowanie klastra nakładki

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

Następne kroki

Dodatkowe zasoby

Udostępnij za pośrednictwem

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

Omówienie sieci nakładki

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

Planowanie adresów IP

Sieciowe grupy zabezpieczeń

Maksymalna liczba zasobników na węzeł

Wybieranie modelu sieciowego do użycia

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

Konfigurowanie klastrów nakładek

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

Uaktualnianie istniejącego klastra do nakładki CNI

Uaktualnianie klastra usługi Azure CNI

Uaktualnianie klastra Kubenet

Sieć z podwójnym stosem

Wymagania wstępne

Ograniczenia

Wdrażanie klastra usługi AKS z dwoma stosami

Tworzenie klastra usługi AKS z dwoma stosami

Tworzenie przykładowego obciążenia

Wdrażanie serwera internetowego NGINX

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

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

Wymagania wstępne

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

Rejestrowanie flagi funkcji "AzureOverlayDualStackPreview"

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

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

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

Rejestrowanie flagi funkcji "AzureOverlayDualStackPreview"

Konfigurowanie klastra nakładki

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

Następne kroki

Dodatkowe zasoby

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