Starsze interfejsy sieciowe kontenerów (CNI) w usłudze AKS

2025-05-03

Ważne

W dniu 31 marca 2028 r.zostanie wycofana sieć kubenet dla usługi Azure Kubernetes Service (AKS).

Aby uniknąć przerw w działaniu usługi, należyzaktualizować do nakładki Azure Container Networking Interface (CNI)przed tą datą, ponieważ obciążenia uruchomione na platformie kubenet dla AKS nie będą już obsługiwane.

W usłudze Azure Kubernetes Service (AKS), choć dla większości scenariuszy zalecane są Azure CNI Overlay i Azure CNI Pod Subnet, starsze modele sieciowe, takie jak Podsicie węzłów Azure CNI i kubenet, są nadal dostępne i obsługiwane. Te starsze modele oferują różne podejścia do zarządzania adresami IP podów i sieci, z których każde ma własny zestaw możliwości i zagadnień. Ten artykuł zawiera omówienie tych starszych opcji sieciowych, szczegółowo ich wymagań wstępnych, parametrów wdrożenia i kluczowych cech, aby ułatwić zrozumienie ich ról i sposobu ich efektywnego użycia w klastrach usługi AKS.

Wymagania wstępne

Dla podsieci węzła usługi Azure CNI wymagane są następujące wymagania wstępne:

Sieć wirtualna klastra usługi AKS musi zezwalać na wychodzącą łączność do Internetu.
Klastry AKS nie mogą używać 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 ani 192.0.2.0/24 dla zakresu adresów usługi Kubernetes, zakresu adresów podów lub zakresu adresów wirtualnej sieci klastra.
Tożsamość używana przez klaster AKS musi mieć co najmniej uprawnienia "Współtwórca sieci" w podsieci w sieci wirtualnej. Jeśli chcesz zdefiniować rolę niestandardową zamiast korzystać z wbudowanej roli Współautor sieci, wymagane są następujące uprawnienia:
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
- Microsoft.Authorization/roleAssignments/write
Podsieć przypisana do puli węzłów usługi AKS nie może być podsiecią delegowaną.

AKS nie stosuje grup zabezpieczeń sieciowych do swojej podsieci i nie modyfikuje żadnej grupy zabezpieczeń sieciowych skojarzonej z tą podsiecią. Jeśli podasz własną podsieć i dodasz grupy zabezpieczeń sieciowych skojarzone z tą podsiecią, upewnij się, że reguły zabezpieczeń w grupach zabezpieczeń sieciowych zezwalają na ruch w przedziale CIDR węzła. Aby uzyskać więcej informacji, zobacz Sieciowe grupy zabezpieczeń.

Podsieć węzła usługi Azure CNI

Za pomocą Interfejsu Sieci Kontenera Platformy Azure (CNI) każdy zasobnik pobiera adres IP z podsieci i może być dostępny bezpośrednio. Systemy znajdujące się w tej samej sieci wirtualnej co klaster usługi AKS widzą adres IP zasobnika jako adres źródłowy dla każdego ruchu z zasobnika. Systemy spoza sieci wirtualnej klastra AKS widzą adres IP węzła jako adres źródłowy dla dowolnego ruchu z podu. Te adresy IP muszą być unikatowe w przestrzeni sieciowej i muszą być planowane z wyprzedzeniem. Każdy węzeł ma parametr konfiguracji dla maksymalnej liczby podów, które może obsłużyć. Równoważna liczba adresów IP na węzeł jest następnie zarezerwowana z góry dla tego węzła. Takie podejście wymaga większego planowania i często prowadzi do wyczerpania adresów IP lub konieczności ponownego kompilowania klastrów w większej podsieci w miarę wzrostu zapotrzebowania aplikacji.

W przypadku Azure CNI Node Subnet każdy pod otrzymuje adres IP w podsieci IP i może komunikować się bezpośrednio z innymi podami i usługami. Klastry mogą być tak duże, jak zakres adresów IP, który określisz. Należy jednak z wyprzedzeniem zaplanować zakres adresów IP, a wszystkie adresy IP są wykorzystywane przez węzły AKS w zależności od maksymalnej liczby podów, które mogą obsłużyć. Zaawansowane funkcje sieci i scenariusze, takie jak węzły wirtualne lub zasady sieciowe (azure lub Calico) są obsługiwane w usłudze Azure CNI.

Parametry wdrożenia

Podczas tworzenia klastra usługi AKS można skonfigurować następujące parametry dla sieci usługi Azure CNI:

Sieć wirtualna: sieć wirtualna, w której chcesz wdrożyć klaster Kubernetes. Możesz utworzyć nową sieć wirtualną lub użyć istniejącej. Jeśli chcesz użyć istniejącej sieci wirtualnej, upewnij się, że znajduje się ona w tej samej lokalizacji i subskrypcji platformy Azure co klaster Kubernetes. Aby uzyskać informacje o limitach i limitach przydziałów dla sieci wirtualnej platformy Azure, zobacz Limity subskrypcji i usług platformy Azure, limity przydziału i ograniczenia.

Podsieć: podsieć w sieci wirtualnej, w której chcesz wdrożyć klaster. Podczas procesu tworzenia klastra można dodawać nowe podsieci do sieci wirtualnej. W przypadku łączności hybrydowej zakres adresów nie powinien pokrywać się z innymi sieciami wirtualnymi w danym środowisku.

Wtyczka sieci platformy Azure: jeśli jest używana wtyczka sieci platformy Azure, wewnętrzna usługa LoadBalancer z parametrem "externalTrafficPolicy=Local" nie może być dostępna z maszyn wirtualnych z adresem IP w klastrze CLUSTERCIDR, który nie należy do klastra usługi AKS.

Zakres adresów usługi Kubernetes: ten parametr jest zestawem wirtualnych adresów IP przypisywanych przez platformę Kubernetes do usług wewnętrznych w klastrze. Nie można zaktualizować tego zakresu po utworzeniu klastra. Możesz użyć dowolnego zakresu prywatnych adresów, który spełnia następujące wymagania:

Nie może należeć do zakresu adresów IP sieci wirtualnej klastra.
Nie może nakładać się na inne sieci wirtualne, z którymi sieć wirtualna klastra się łączy.
Nie może nakładać się na żadne lokalne adresy IP.
Nie może znajdować się w zakresach 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16lub 192.0.2.0/24.

Chociaż istnieje możliwość określenia zakresu adresów usługi w tej samej sieci wirtualnej co klaster, nie zalecamy jej. Nakładające się zakresy adresów IP mogą powodować nieprzewidywalne zachowanie. Aby uzyskać więcej informacji, zobacz często zadawane pytania. Aby uzyskać więcej informacji na temat usług Kubernetes, zobacz Usługi w dokumentacji platformy Kubernetes.

Adres IP usługi DNS Kubernetes: Adres IP usługi DNS klastra. Ten adres musi znajdować się w zakresie adresów usługi Kubernetes. Nie używaj pierwszego adresu IP w zakresie adresów. Pierwszy adres w zakresie podsieci jest używany dla kubernetes.default.svc.cluster.local.

Azure CNI: Ten sam podstawowy zakres podsieci /24 może obsługiwać tylko maksymalnie 8 węzłów w klastrze. Ta liczba węzłów może obsługiwać co najwyżej 240 zasobników, z domyślnym limitem 30 zasobników na węzeł.

Uwaga

Te wartości maksymalne nie uwzględniają operacji uaktualniania ani skalowania. W praktyce nie można uruchomić maksymalnej liczby węzłów, które obsługuje zakres adresów IP podsieci. Należy pozostawić niektóre adresy IP dostępne do skalowania lub uaktualniania operacji.

Peering sieci wirtualnych i połączenia ExpressRoute

Aby zapewnić łączność z lokalną infrastrukturą, możesz użyć peeringu sieci wirtualnych platformy Azure lub połączeń usługi ExpressRoute za pomocą Azure CNI. Pamiętaj, aby dokładnie zaplanować adresy IP, aby zapobiec nakładaniu się i niepoprawnemu routingowi ruchu. Na przykład wiele sieci lokalnych używa zakresu adresów 10.0.0.0/8 reklamowanego za pośrednictwem połączenia usługi ExpressRoute. Zalecamy utworzenie klastrów usługi AKS w podsieciach sieci wirtualnej platformy Azure poza tym zakresem adresów, takich jak 172.16.0.0/16.

Aby uzyskać więcej informacji, zobacz Porównanie modeli sieciowych i ich zakresów pomocy technicznej.

Podsieć podów Azure CNI — często zadawane pytania

Czy mogę wdrożyć maszyny wirtualne w podsieci klastra?

Tak w przypadku podsieci węzła usługi Azure CNI maszyny wirtualne można wdrożyć w tej samej podsieci co klaster usługi AKS.
Jaki źródłowy adres IP widzi system zewnętrzny dla ruchu pochodzącego z poda CNI platformy Azure?

Systemy znajdujące się w tej samej sieci wirtualnej co klaster usługi AKS widzą adres IP zasobnika jako adres źródłowy dla każdego ruchu z zasobnika. Systemy spoza sieci wirtualnej klastra AKS widzą adres IP węzła jako adres źródłowy dla dowolnego ruchu z podu. Jednak w przypadku dynamicznej alokacji adresów IP usługi Azure CNI, niezależnie od tego, czy połączenie znajduje się w tej samej sieci wirtualnej, czy między sieciami wirtualnymi, adres IP zasobnika jest zawsze adresem źródłowym dla dowolnego ruchu z zasobnika. Dzieje się tak, ponieważ Azure CNI do dynamicznej alokacji adresów IP implementuje infrastrukturę Microsoft Azure Container Networking, która zapewnia kompleksowe doświadczenie użytkownika typu end-to-end. W związku z tym eliminuje użycie usługi ip-masq-agent, która jest nadal używana przez tradycyjną usługę Azure CNI.
Czy mogę skonfigurować polityki sieciowe dla każdego zasobnika?

Tak, zasady sieciowe platformy Kubernetes są dostępne w usłudze AKS. Aby rozpocząć, zobacz Zabezpieczanie ruchu między zasobnikami przy użyciu zasad sieciowych w usłudze AKS.
Czy maksymalna liczba zasobników możliwych do wdrożenia na węzeł jest konfigurowalna?

Za pomocą Interfejsu Sieci Kontenera Platformy Azure (CNI) każdy zasobnik pobiera adres IP z podsieci i może być dostępny bezpośrednio. Systemy znajdujące się w tej samej sieci wirtualnej co klaster usługi AKS widzą adres IP zasobnika jako adres źródłowy dla każdego ruchu z zasobnika. Systemy spoza sieci wirtualnej klastra AKS widzą adres IP węzła jako adres źródłowy dla dowolnego ruchu z podu. Te adresy IP muszą być unikatowe w przestrzeni sieciowej i muszą być planowane z wyprzedzeniem. Każdy węzeł ma parametr konfiguracji dla maksymalnej liczby podów, które może obsłużyć. Równoważna liczba adresów IP na węzeł jest następnie zarezerwowana z góry dla tego węzła. Takie podejście wymaga większego planowania i często prowadzi do wyczerpania adresów IP lub konieczności ponownego kompilowania klastrów w większej podsieci w miarę wzrostu zapotrzebowania aplikacji.
Czy mogę wdrożyć maszyny wirtualne w podsieci klastra?

Tak. Jednak w przypadku sieci CNI platformy Azure do dynamicznej alokacji adresów IP nie można wdrożyć maszyn wirtualnych w podsieci podów.
Jaki źródłowy adres IP widzi system zewnętrzny dla ruchu pochodzącego z poda CNI platformy Azure?

Systemy znajdujące się w tej samej sieci wirtualnej co klaster usługi AKS widzą adres IP zasobnika jako adres źródłowy dla każdego ruchu z zasobnika. Systemy spoza sieci wirtualnej klastra AKS widzą adres IP węzła jako adres źródłowy dla dowolnego ruchu z podu.

Jednak w przypadku dynamicznej alokacji adresów IP w usłudze Azure CNI, niezależnie od tego, czy połączenie znajduje się w tej samej sieci wirtualnej, czy między sieciami wirtualnymi, adres IP zasobnika jest zawsze adresem źródłowym dla dowolnego ruchu z zasobnika. Dzieje się tak, ponieważ Azure CNI do dynamicznej alokacji adresów IP implementuje infrastrukturę Microsoft Azure Container Networking, która zapewnia kompleksowe doświadczenie użytkownika typu end-to-end. W związku z tym eliminuje użycie usługi ip-masq-agent, która jest nadal używana przez tradycyjną usługę Azure CNI.
Czy mogę użyć innej podsieci w sieci wirtualnej klastra dla zakresu adresów usługi Kubernetes?

Nie jest to zalecane, ale ta konfiguracja jest możliwa. Zakres adresów usługi to zestaw wirtualnych adresów IP (VIP), który platforma Kubernetes przypisuje do usług wewnętrznych w klastrze. Usługa Azure Networking nie ma wglądu w zakres adresów IP usługi klastra Kubernetes. Brak wglądu w zakres adresów usługi klastra może prowadzić do problemów. Później można utworzyć nową podsieć w sieci wirtualnej klastra, która nakłada się na zakres adresów usługi. Jeśli wystąpi takie nakładanie, platforma Kubernetes może przypisać usłudze adres IP, który jest już używany przez inny zasób w podsieci, powodując nieprzewidywalne zachowanie lub błędy. Zapewniając użycie zakresu adresów poza siecią wirtualną klastra, można uniknąć tego ryzyka nakładania się. Tak, podczas wdrażania klastra przy użyciu interfejsu wiersza polecenia platformy Azure lub szablonu usługi Resource Manager. Zobacz Maksymalna liczba zasobników na węzeł.
Czy mogę użyć innej podsieci w sieci wirtualnej klastra dla zakresu adresów usługi Kubernetes?

Nie jest to zalecane, ale ta konfiguracja jest możliwa. Zakres adresów usługi to zestaw wirtualnych adresów IP (VIP), który platforma Kubernetes przypisuje do usług wewnętrznych w klastrze. Usługa Azure Networking nie ma wglądu w zakres adresów IP usługi klastra Kubernetes. Brak wglądu w zakres adresów usługi klastra może prowadzić do problemów. Później można utworzyć nową podsieć w sieci wirtualnej klastra, która nakłada się na zakres adresów usługi. Jeśli wystąpi takie nakładanie, platforma Kubernetes może przypisać usłudze adres IP, który jest już używany przez inny zasób w podsieci, powodując nieprzewidywalne zachowanie lub błędy. Zapewniając użycie zakresu adresów poza siecią wirtualną klastra, można uniknąć tego ryzyka nakładania się.