Konfigurowanie sieci usługi Azure CNI pod kątem statycznej alokacji bloków CIDR i rozszerzonej obsługi podsieci w usłudze Azure Kubernetes Service (AKS) — (wersja zapoznawcza)

2025-04-08

Ograniczeniem dynamicznej alokacji adresów IP usługi Azure CNI jest skalowalność rozmiarów podsieci podów powyżej /16. Nawet przy posiadaniu dużej podsieci, duże skupiska serwerów mogą nadal być ograniczone do 65 tys. zasobników z powodu limitu mapowania adresów na platformie Azure. Nowa funkcja alokacji bloków statycznych w usłudze Azure CNI rozwiązuje ten problem, przypisując bloki CIDR do węzłów, a nie poszczególnych adresów IP.

Oferuje następujące korzyści:

Lepsza skalowalność adresów IP: bloki CIDR są statycznie przydzielane do węzłów klastra i są obecne przez cały okres istnienia węzła, w przeciwieństwie do tradycyjnej dynamicznej alokacji poszczególnych adresów IP z tradycyjnym interfejsem CNI. Umożliwia to routing oparty na blokach CIDR i pomaga zwiększyć limit klastra do 1 miliona podów z tradycyjnego limitu 65 000 podów na klaster. Sieć wirtualna platformy Azure musi być wystarczająco duża, aby obsłużyć skalę klastra.
Elastyczność: podsieci węzłów i zasobników można skalować niezależnie. Pojedyncza podsieć zasobnika może być współużytkowana w pulach węzłów klastra lub w wielu klastrach AKS wdrożonych w tej samej sieci VNet. Można również skonfigurować oddzielną podsieć poda dla puli węzłów.
Wysoka wydajność: ponieważ zasobniki mają przypisane adresy IP sieci wirtualnej, mają bezpośrednią łączność z innymi zasobnikami klastra i zasobami w sieci wirtualnej.
Oddzielne zasady sieci wirtualnej dla zasobników: ponieważ zasobniki mają oddzielną podsieć, można skonfigurować oddzielne zasady sieci wirtualnej dla nich, które różnią się od zasad węzłów. Umożliwia to wiele przydatnych scenariuszy, takich jak umożliwienie łączności z Internetem wyłącznie dla podów, a nie dla węzłów, ustalenie źródłowego adresu IP dla poda w puli węzłów przy użyciu bramy NAT w Azure, oraz filtrowanie ruchu między pulami węzłów za pomocą sieciowych grup zabezpieczeń (NSG).
Polityki sieciowe platformy Kubernetes: Cilium, Azure NPM i Calico współpracują z tym nowym rozwiązaniem.

W tym artykule pokazano, jak używać sieci CNI platformy Azure do statycznej alokacji CIDR i zwiększonej obsługi podsieci w usłudze AKS.

Wymagania wstępne

Uwaga

W przypadku korzystania z statycznej alokacji bloków CIDR uwidacznianie aplikacji jako usługi Private Link przy użyciu usługi Kubernetes Load Balancer nie jest obsługiwane.

Zapoznaj się z wymaganiami wstępnymi dotyczącymi konfigurowania podstawowej sieci usługi Azure CNI w usłudze AKS, ponieważ te same wymagania wstępne dotyczą tego artykułu.
Przejrzyj parametry wdrażania dla konfigurowania podstawowej sieci Azure CNI w AKS, ponieważ te same parametry mają zastosowanie.
Klastry AKS Engine oraz DIY nie są wspierane.
Wersja 2.37.0 interfejsu wiersza polecenia platformy Azure lub nowsza z rozszerzeniem aks-preview w wersji "2.0.0b2" lub nowszej
Jeśli masz istniejący klaster, musisz włączyć usługę Container Insights na potrzeby monitorowania użycia podsieci IP. Usługę az aks enable-addons Container Insights można włączyć przy użyciu polecenia , jak pokazano w poniższym przykładzie:
Zarejestruj znacznik funkcji na poziomie subskrypcji dla subskrypcji: "Microsoft.ContainerService/AzureVnetScalePreview"
```
az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>
```

Ograniczenia

Poniżej przedstawiono niektóre ograniczenia dotyczące używania alokacji bloków statycznych usługi Azure CNI:

Minimalna wymagana wersja platformy Kubernetes to 1.28
Obsługiwany maksymalny rozmiar podsieci to x.x.x.x/12 ~ 1 milion adresów IP
Na podsieć można używać tylko jednego trybu operacji. Jeśli podsieć używa trybu alokacji bloków statycznych, nie można użyć trybu dynamicznej alokacji adresów IP w innym klastrze lub puli węzłów z tą samą podsiecią i odwrotnie.
Obsługiwane tylko w nowych klastrach lub podczas dodawania pul węzłów z inną podsiecią do istniejących klastrów. Migrowanie lub aktualizowanie istniejących klastrów lub pul węzłów nie jest obsługiwane.
We wszystkich blokach CIDR przypisanych do węzła w puli węzłów zostanie wybrany jeden adres IP jako podstawowy adres IP węzła. W związku z tym w przypadku administratorów sieci wybierających --max-pods wartość spróbuj użyć poniższego obliczenia, aby najlepiej spełnić Twoje potrzeby i uzyskać optymalne użycie adresów IP w podsieci:
max_pods = (N * 16) - 1
gdzie N jest dowolną dodatnią liczbą całkowitą i N > 0

Plan adresowania IP

Planowanie adresowania IP jest bardziej elastyczne i szczegółowe. Ponieważ węzły i zasobniki są skalowane niezależnie, ich przestrzenie adresowe mogą być również planowane oddzielnie. Ponieważ podsieci zasobników można skonfigurować do stopnia szczegółowości puli węzłów, zawsze można dodać nową podsieć podczas dodawania puli węzłów. Zasobniki systemowe w klastrze/puli węzłów również otrzymują adresy IP z podsieci zasobnika, więc to zachowanie trzeba uwzględnić.

W tym scenariuszu bloki CIDR o rozmiarze /28 (16 IP) są przydzielane do węzłów na podstawie konfiguracji "--max-pod" dla puli węzłów, która określa maksymalną liczbę podów na węzeł. 1 adres IP jest zarezerwowany dla każdego węzła ze wszystkich dostępnych adresów IP w tym węźle do celów wewnętrznych.

W związku z tym podczas określania i planowania adresów IP niezbędne jest zdefiniowanie konfiguracji "--max-pods" i można je obliczyć najlepiej, jak pokazano poniżej: max_pods_per_node = (16 * N) - 1 gdzie N jest dowolną dodatnią liczbą całkowitą większą niż 0

Idealne wartości bez marnowania adresów IP wymagałyby, aby wartość maksymalna podów była zgodna z powyższym wyrażeniem.

Przykład 1: max_pods = 30, bloki CIDR przydzielone na węzeł = 2, łączna liczba adresów IP dostępnych dla zasobników = (16 * 2) - 1 = 32 - 1 = 31, marnotrawstwo IP na węzeł = 31 - 30 = 1 [Niski poziom marnotrawstwa — akceptowalny przypadek]
Przykład 2: max_pods = 31, bloki CIDR przydzielone na węzeł = 2, łączna liczba adresów IP dostępnych dla zasobników = (16 * 2) - 1 = 32 - 1 = 31, marnotrawstwo IP na węzeł = 31 - 31 = 0 [Idealny przypadek]
Przykład 3: max_pods = 32, bloki CIDR przydzielone na węzeł = 3, łączna liczba adresów IP dostępnych dla podów = (16 * 3) - 1 = 48 - 1 = 47, marnowane IP na węzeł = 47 - 32 = 15 [Duże marnotrawstwo - przypadek niezalecany]

Planowanie adresów IP dla usług Kubernetes pozostaje niezmienione.

Uwaga

Upewnij się, że sieć wirtualna ma wystarczająco dużą i ciągłą przestrzeń adresową do obsługi skali klastra.

Parametry wdrożenia

Parametry wdrażania do konfiguracji podstawowego sieciowania Azure CNI w usłudze AKS są prawidłowe z dwoma wyjątkami:

Parametr id podsieci sieci wirtualnej teraz odnosi się do podsieci związanej z węzłami klastra.
Parametr pod subnet id służy do określenia podsieci, której adresy IP będą statycznie lub dynamicznie przydzielane zasobnikom w puli węzłów.
Parametr trybu alokacji adresu IP zasobnika określa, czy należy używać dynamicznej alokacji pojedynczej lub statycznej alokacji bloków.

Zanim rozpoczniesz

Jeśli używasz Azure CLI, musisz mieć rozszerzenie aks-preview. Zobacz aks-preview interfejsu wiersza polecenia platformy Azure.
W przypadku korzystania z usługi ARM lub interfejsu API REST wersja interfejsu API usługi AKS musi być w wersji 2024-01-02-preview lub nowszej.

Zainstaluj rozszerzenie CLI platformy `aks-preview` Azure

Zainstaluj rozszerzenie aks-preview przy użyciu polecenia az extension add.
```
az extension add --name aks-preview
```
Przeprowadź aktualizację do najnowszej wersji rozszerzenia przy użyciu az extension update polecenia . Rozszerzenie powinno mieć wersję "2.0..0b2" lub nowszą
```
az extension update --name aks-preview
```

Zarejestruj flagę funkcji `AzureVnetScalePreview`

Zarejestruj flagę funkcji AzureVnetScalePreview używając polecenia az feature register.
```
az feature register --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"
```
Wyświetlenie stanu Zarejestrowane trwa kilka minut.

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

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

Gdy stan odzwierciedla Zarejestrowano, odśwież rejestrację dostawcy zasobów Microsoft.ContainerService za pomocą az provider register polecenia.
```
az provider register --namespace Microsoft.ContainerService
```

Konfigurowanie sieci przy użyciu statycznej alokacji bloków CIDR i rozszerzonej obsługi podsieci — interfejs wiersza polecenia platformy Azure

Użycie statycznej alokacji bloków CIDR w klastrze jest podobne do domyślnej metody konfigurowania klastra usługi Azure CNI na potrzeby dynamicznej alokacji adresów IP. W poniższym przykładzie przedstawiono tworzenie nowej sieci wirtualnej z podsiecią dla węzłów i podsieci dla zasobników oraz tworzenie klastra korzystającego z sieci CNI platformy Azure ze statyczną alokacją bloków CIDR. Pamiętaj, aby zastąpić zmienne, takie jak $subscription wartościami.

Utwórz sieć wirtualną z dwiema podsieciami.

resourceGroup="myResourceGroup"
vnet="myVirtualNetwork"
location="myRegion"

# Create the resource group
az group create --name $resourceGroup --location $location

# Create our two subnet network 
az network vnet create --resource-group $resourceGroup --location $location --name $vnet --address-prefixes 10.0.0.0/8 -o none 
az network vnet subnet create --resource-group $resourceGroup --vnet-name $vnet --name nodesubnet --address-prefixes 10.240.0.0/16 -o none 
az network vnet subnet create --resource-group $resourceGroup --vnet-name $vnet --name podsubnet --address-prefixes 10.40.0.0/13 -o none

Utwórz klaster, odwołując się do podsieci węzła przy użyciu --vnet-subnet-idpodsieci , przy użyciu --pod-subnet-idpolecenia , --pod-ip-allocation-mode w celu zdefiniowania trybu alokacji adresów IP i włączenia dodatku monitorowania.

clusterName="myAKSCluster"
subscription="aaaaaaa-aaaaa-aaaaaa-aaaa"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --max-pods 250 \
    --node-count 2 \
    --network-plugin azure \
    --pod-ip-allocation-mode StaticBlock \
    --vnet-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/nodesubnet \
    --pod-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/podsubnet \
    --enable-addons monitoring \
    --generate-ssh-keys

Dodawanie puli węzłów

Podczas dodawania puli węzłów należy odwołać się do podsieci węzłów przy użyciu --vnet-subnet-id, do podsieci podów przy użyciu --pod-subnet-id oraz trybu alokacji przy użyciu polecenia "--pod-ip-allocation-mode". Poniższy przykład tworzy dwie nowe podsieci, które są następnie wykorzystywane przy tworzeniu nowej puli węzłów.

az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name node2subnet --address-prefixes 10.242.0.0/16 -o none 
az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name pod2subnet --address-prefixes 10.243.0.0/16 -o none 

az aks nodepool add --cluster-name $clusterName -g $resourceGroup  -n newnodepool \
    --max-pods 250 \
    --node-count 2 \
    --vnet-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/node2subnet \
    --pod-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/pod2subnet \
    --pod-ip-allocation-mode StaticBlock \
    --no-wait

Statyczna alokacja bloków CIDR i rozszerzonej obsługi podsieci — często zadawane pytania

Czy mogę przypisać wiele podsieci do klastra?

Do klastra można przypisać wiele podsieci, ale do każdej puli węzłów można przypisać tylko jedną podsieć. Różne pule węzłów w tym samym/innym klastrze mogą współużytkować tę samą podsieć.
Czy mogę przypisać podsieci Pod z całkowicie innej sieci wirtualnej (VNet)?

Nie, podsieć podu powinna pochodzić z tej samej sieci wirtualnej co klaster.
Czy niektóre pule węzłów w klastrze mogą używać dynamicznej alokacji adresów IP, podczas gdy inne używają nowej alokacji bloków statycznych?

Tak, różne pule węzłów mogą używać różnych trybów alokacji. Jednak gdy podsieć jest używana w jednym trybie alokacji, może być używana tylko w tym samym trybie alokacji we wszystkich skojarzonych pulach węzłów.

Następne kroki

Dowiedz się więcej o sieciach komputerowych w AKS w następujących artykułach: