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)

Artykuł
08/25/2024

Ograniczenie dynamicznej alokacji adresów IP usługi Azure CNI to skalowalność rozmiaru podsieci zasobnika poza podsiecią /16. Nawet w przypadku dużej podsieci duże klastry mogą nadal być ograniczone do 65 tys. zasobników ze względu na limit mapowania adresów platformy 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 skalować limit klastra do 1 miliona zasobników z tradycyjnych zasobników 65K 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 wielu pulach węzłów klastra lub w wielu klastrach usługi AKS wdrożonych w tej samej sieci wirtualnej. Można również skonfigurować oddzielną podsieć zasobnika 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 zezwolenie na łączność z Internetem tylko dla zasobników, a nie dla węzłów, naprawianie źródłowego adresu IP zasobnika w puli węzłów przy użyciu bramy translatora adresów sieciowych platformy Azure oraz filtrowanie ruchu między pulami węzłów za pomocą sieciowych grup zabezpieczeń.
Zasady 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 rozszerzonej 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.
Zapoznaj się z parametrami wdrażania dotyczącymi konfigurowania podstawowej sieci usługi Azure CNI w usłudze AKS, co mają zastosowanie te same parametry.
Klastry AKS Engine i DIY nie są obsługiwane.
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 flagę 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

Dostępność w regionach

Ta funkcja nie jest dostępna w następujących regionach:

Południowe stany USA
Wschodnie stany USA 2
Zachodnie stany USA
Zachodnie stany USA 2

planowanie 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 puli klastrów/węzłów również otrzymują adresy IP z podsieci zasobnika, więc to zachowanie musi zostać uwzględnione.

W tym scenariuszu bloki CIDR /28 (16 IP) są przydzielane do węzłów na podstawie konfiguracji "--max-pod" dla puli węzłów, która definiuje maksymalną liczbę zasobnikó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 tagu ip wymagałyby maksymalnej wartości zasobników zgodnej 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, pozycja IP na węzeł = 31 - 30 = 1 [Niski poziom wastage — 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, wystanie 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 zasobników = (16 * 3) - 1 = 48 - 1 = 47, stan ip na węzeł = 47 - 32 = 15 [High Wastage - Not Recommended Case]

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 konfigurowania podstawowej sieci usługi Azure CNI w usłudze AKS są prawidłowe z dwoma wyjątkami:

Parametr identyfikatora podsieci sieci wirtualnej odwołuje się teraz do podsieci powiązanej z węzłami klastra.
Identyfikator podsieci parametru służy do określania 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 interfejsu wiersza polecenia platformy aks-preview Azure, potrzebujesz rozszerzenia. Zobacz Instalowanie rozszerzenia interfejsu wiersza polecenia platformy aks-preview 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.

Instalowanie rozszerzenia interfejsu wiersza polecenia platformy `aks-preview` Azure

aks-preview Zainstaluj rozszerzenie przy użyciu az extension add polecenia .
```
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
```

Rejestrowanie flagi `AzureVnetScalePreview` funkcji

Zarejestruj flagę AzureVnetScalePreview funkcji przy użyciu az feature register polecenia .
```
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 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 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-idpolecenia , podsieci i trybu alokacji przy użyciu --pod-subnet-id polecenia "--pod-ip-allocation-mode". Poniższy przykład tworzy dwie nowe podsieci, do których następnie odwołuje się utworzenie 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 można całkowicie przypisać podsieci z innej sieci wirtualnej?

Nie, podsieć zasobnika 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 sieci w usłudze AKS w następujących artykułach:

Udostępnij za pośrednictwem

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)

Wymagania wstępne

Ograniczenia

Dostępność w regionach

planowanie adresowania IP

Parametry wdrożenia

Zanim rozpoczniesz

Instalowanie rozszerzenia interfejsu wiersza polecenia platformy `aks-preview` Azure

Rejestrowanie flagi `AzureVnetScalePreview` funkcji

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

Dodawanie puli węzłów

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

Następne kroki

Dodatkowe zasoby

Udostępnij za pośrednictwem

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)

Wymagania wstępne

Ograniczenia

Dostępność w regionach

planowanie adresowania IP

Parametry wdrożenia

Zanim rozpoczniesz

Instalowanie rozszerzenia interfejsu wiersza polecenia platformy aks-preview Azure

Rejestrowanie flagi AzureVnetScalePreview funkcji

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

Dodawanie puli węzłów

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

Następne kroki

Dodatkowe zasoby

Instalowanie rozszerzenia interfejsu wiersza polecenia platformy `aks-preview` Azure

Rejestrowanie flagi `AzureVnetScalePreview` funkcji