Sieć nakładka Azure Container Networking Interface (CNI)

Dzięki nakładce Azure CNI węzły klastra są wdrażane na podsieci usługi Azure Virtual Network (VNet). Zasobnikom przypisywane są adresy IP z prywatnego CIDR, który jest logicznie odmienny od sieci wirtualnej, w której znajdują się węzły. Ruch zasobników i węzłów w klastrze korzysta z sieci nakładkowej. 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 prywatnego CIDR w różnych klastrach AKS, co rozszerza zakres adresów IP dostępnych dla aplikacji kontenerowych w usłudze Azure Kubernetes Service (AKS).

Omówienie sieci nakładowej

W sieci nakładkowej tylko węzły klastra Kubernetes mają 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 wydzieloną z tego samego prefiksu CIDR. Dodatkowe węzły utworzone podczas skalowania klastra automatycznie otrzymują /24 przestrzenie adresowe z tego samego 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 pody, co tworzy sieć nakładkową umożliwiającą bezpośrednią komunikację między podami. 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.

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 zmienia źródłowy adres IP (adres IP nakładkowy poda) ruchu na podstawowy adres IP maszyny wirtualnej, co umożliwia stosowi sieciowemu platformy Azure przekierowanie ruchu do miejsca docelowego. Punkty końcowe spoza klastra nie mogą łączyć się bezpośrednio z podem. Musisz opublikować aplikację zasobnika jako usługę Kubernetes Load Balancer, aby była osiągalna w sieci wirtualnej.

Możesz zapewnić łączność wychodzącą z internetem dla zasobników nakładki przy użyciu Równoważnika Obciążenia Standard SKU lub zarządzanej bramy NAT. 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 application gateway for Containers, NGINX lub dodatek routingu aplikacji.

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

Poniższa tabela zawiera szczegółowe porównanie między rozwiązaniem kubenet i nakładką usługi Azure CNI:

Obszar	Nakładka Azure CNI	kubenet
Skalowanie klastra	5000 węzłów i 250 podów/węzeł	400 węzłów i 250 podów/węzeł
Konfiguracja sieci	Proste — konfiguracja sieci podów nie jest wymagana	Złożone — wymaga tabel tras i tras UDR (zdefiniowanych przez użytkownika) w podsieci klastra dla sieci podów
Wydajność połączeń sieciowych poda	Wydajność na równi z maszynami wirtualnymi w sieci wirtualnej	Dodatkowy przeskok dodaje niewielkie opóźnienie
Zasady sieciowe platformy Kubernetes	Zasady sieci platformy Azure, Calico, Cilium	Kreton
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ć /24 może mieścić się w maksymalnie 251 węzłach, ponieważ pierwsze trzy adresy IP są zarezerwowane do zadań zarządzania.

Pody

Rozwiązanie Nakładka sieciowa przypisuje przestrzeń adresową /24 dla zasobników w każdym węźle z prywatnego zakresu CIDR, określonego 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 IP dla zasobników należy wziąć pod uwagę następujące czynniki:

• Upewnij się, że prywatny CIDR jest wystarczająco duży, aby zapewnić /24 przestrzenie adresowe dla nowych węzłów, wspierając przyszłe rozszerzenie klastra.
• Ta sama przestrzeń CIDR dla zasobników może być używana w wielu niezależnych klastrach AKS w tym samym VNet.
• Przestrzeń CIDR poda nie może nakładać się na zakres podsieci klastra.
• Przestrzeń CIDR podów nie może nakładać się na bezpośrednio połączone sieci (takie jak komunikacja równorzędna VNet, usługa ExpressRoute lub sieć VPN). Jeśli ruch zewnętrzny ma adresy IP źródłowe w zakresie podCIDR, musi zostać przetłumaczony na nienakładające się adresy IP za pomocą SNAT, aby komunikować 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, który jest używany do odkrywania usług w klastrze. Nie używaj pierwszego adresu IP w zakresie adresów, ponieważ jest on używany dla adresu kubernetes.default.svc.cluster.local.

Sieciowe grupy zabezpieczeń

Ruch między podami za pomocą nakładki Azure CNI nie jest enkapsulowany, a reguły grupy zabezpieczeń sieci 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 CIDR węzła do CIDR podu na wszystkich portach i w ramach wszystkich protokołów (wymagany do routingu ruchu serwisowego)
• Ruch z CIDR zasobnika do CIDR zasobnika na wszystkich portach i protokołach (wymagany dla ruchu między zasobnikami i między zasobnikiem a usługą, 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 podów na węzeł

Można skonfigurować maksymalną liczbę podów na węzeł podczas tworzenia klastra lub dodawania nowej puli węzłów. Domyślna i maksymalna wartość nakładki usługi Azure CNI to 250, a minimalna wartość to 10. Maksymalna wartość zasobników na węzeł skonfigurowana podczas tworzenia grupy węzłów ma zastosowanie tylko do węzłów w tej grupie węzłów.

Wybieranie modelu sieciowego do użycia

Usługa Azure CNI oferuje dwie opcje adresowania IP dla zasobników: tradycyjną konfigurację, która przypisuje adresy IP sieci wirtualnej do zasobników, oraz sieć nakładkową. 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 podów, ale masz ograniczoną przestrzeń adresową IP w Twojej sieci wirtualnej.
• Większość komunikacji poda odbywa się wewnątrz klastra.
• 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 w podzie dotyczy zasobów poza klastrem.
• 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 usługi Azure CNI Overlay

Nakładka usługi Azure CNI ma następujące ograniczenia:

• Zestawy dostępności maszyn wirtualnych (VMAS) nie są obsługiwane.
• 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ć maksymalnie 63 znaki. Te nazwy będą używane jako etykiety w węzłach roboczych usługi AKS i podlegają regułom składni etykiet kubernetes.