Udostępnij za pośrednictwem

Podsieć zasobnika interfejsu azure Container Networking Interface (CNI)

  • Artykuł

Podsieć zasobnika usługi Azure CNI przypisuje adresy IP do zasobników z oddzielnej podsieci z węzłów klastra. Ta funkcja jest dostępna w dwóch trybach: dynamiczna alokacja adresów IP i alokacja bloków statycznych (wersja zapoznawcza).

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 oraz wersja 2.0.0b2 rozszerzenia lub nowszaaks-preview.

  • Zarejestruj flagę funkcji na poziomie subskrypcji dla subskrypcji: "Microsoft.ContainerService/AzureVnetScalePreview".

  • Jeśli masz istniejący klaster, musisz włączyć dodatek Container Insights do 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:

    az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>

Tryb dynamicznej alokacji adresów IP

Dynamiczna alokacja adresów IP pomaga rozwiązać problemy z wyczerpaniem adresów IP zasobnika, przydzielając adresy IP zasobników z podsieci, która jest oddzielona od podsieci hostowania klastra usługi AKS.

Tryb dynamicznej alokacji adresów IP oferuje następujące korzyści:

  • Lepsze wykorzystanie adresów IP: adresy IP są dynamicznie przydzielane do zasobników klastra z podsieci Zasobnika. Prowadzi to do lepszego wykorzystania adresów IP w klastrze w porównaniu z tradycyjnym rozwiązaniem CNI, które wykonuje statyczną alokację adresów IP dla każdego węzła.
  • Skalowalne i elastyczne: 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 są przypisane do adresów IP sieci wirtualnej, mają bezpośrednią łączność z innymi zasobnikami klastra i zasobami w sieci wirtualnej. Rozwiązanie obsługuje bardzo duże klastry bez spadku wydajności.
  • 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 oraz filtrowanie ruchu między pulami węzłów przy użyciu sieciowych grup zabezpieczeń.
  • Zasady sieciowe platformy Kubernetes: zarówno zasady sieci platformy Azure, jak i Calico współpracują z tym trybem.

planowanie adresowania IP

Dzięki dynamicznej alokacji adresów IP węzły i zasobniki są skalowane niezależnie, dzięki czemu można planować ich przestrzenie adresowe 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.

Adresy IP są przydzielane do węzłów w partiach 16. Alokacja adresów IP podsieci podsieci powinna być planowana z co najmniej 16 adresami IP na węzeł w klastrze, ponieważ węzły żądają 16 adresów IP podczas uruchamiania i żądają kolejnej partii 16 w dowolnym momencie, gdy istnieje <8 adresów IP bez przydziału.

Planowanie adresów IP dla usług Kubernetes i Platformy Docker Bridge pozostaje niezmienione.

Tryb alokacji bloków statycznych (wersja zapoznawcza)

Alokacja bloków statycznych pomaga ograniczyć potencjalne ograniczenia rozmiaru podsieci podsieci i mapowania adresów platformy Azure przez przypisanie bloków CIDR do węzłów, a nie poszczególnych adresów IP.

Tryb alokacji bloków statycznych 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 rozwiązaniem.

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

Dzięki alokacji bloków statycznych węzły i zasobniki są skalowane niezależnie, dzięki czemu można planować ich przestrzenie adresowe 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.

Bloki CIDR /28 (16 IP) są przydzielane do węzłów na --max-pods podstawie konfiguracji 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.

Podczas planowania adresów IP należy zdefiniować --max-pods konfigurację przy użyciu następującego obliczenia: max_pods_per_node = (16 * N) - 1, gdzie N każda dodatnia liczba całkowita jest większa niż 0.

Idealne wartości bez tagu ip wymagałyby maksymalnej wartości zasobników zgodnej z powyższym wyrażeniem.

Zobacz następujące przykładowe przypadki:

Przykładowy przypadek max_pods Bloki CIDR przydzielone na węzeł Łączna liczba adresów IP dostępnych dla zasobników Element wastage ip dla węzła
Niski poziom opóźnienia (akceptowalny) 30 2 (16 * 2) - 1 = 32 - 1 = 31 31 – 30 = 1
Idealny przypadek 31 2 (16 * 2) - 1 = 32 - 1 = 31 31 – 31 = 0
Wysoki poziom wastage (niezalecane) 32 3 (16 * 3) - 1 = 48 - 1 = 47 47 - 32 = 15

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.