Starsze interfejsy sieciowe kontenerów usługi AKS (CNI)
W usłudze Azure Kubernetes Service (AKS), natomiast nakładka usługi Azure CNI i podsieć usługi Azure CNI są zalecane w większości scenariuszy, starsze modele sieciowe, takie jak podsieć 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 i sieci zasobnika, z których każdy 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
W przypadku podsieci węzłów azure CNI i kubenet wymagane są następujące wymagania wstępne:
Sieć wirtualna klastra usługi AKS musi zezwalać na wychodzącą łączność z Internetem.
Klastry usługi AKS nie mogą używać
169.254.0.0/16zakresu172.31.0.0/16172.30.0.0/16192.0.2.0/24adresów usługi Kubernetes, zakresu adresów zasobnika ani zakresu adresów sieci wirtualnej klastra.Tożsamość klastra używana przez klaster usługi AKS musi mieć co najmniej uprawnienia Współautor 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/actionMicrosoft.Network/virtualNetworks/subnets/readMicrosoft.Authorization/roleAssignments/write
Podsieć przypisana do puli węzłów usługi AKS nie może być podsiecią delegowana.
- Usługa AKS nie stosuje sieciowych grup zabezpieczeń do podsieci i nie modyfikuje żadnej sieciowej grupy zabezpieczeń skojarzonej z tą podsiecią. Jeśli podasz własną podsieć i dodasz sieciowe grupy zabezpieczeń skojarzone z tą podsiecią, upewnij się, że reguły zabezpieczeń w sieciowych grupach zabezpieczeń zezwalają na ruch w zakresie CIDR węzła. Aby uzyskać więcej informacji, zobacz Sieciowe grupy zabezpieczeń.
Uwaga
Platforma Kubenet nie jest dostępna dla kontenerów systemu Windows Server. Aby użyć pul węzłów systemu Windows Server, należy użyć usługi Azure CNI.
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 usługi AKS widzą adres IP węzła jako adres źródłowy dla dowolnego ruchu z zasobnika. 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 zasobników, które obsługuje. 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 podsieci węzła usługi Azure CNI każdy zasobnik otrzymuje adres IP w podsieci IP i może komunikować się bezpośrednio z innymi zasobnikami i usługami. Klastry mogą być tak duże, jak określony zakres adresów IP. Należy jednak zaplanować zakres adresów IP z wyprzedzeniem, a wszystkie adresy IP są używane przez węzły usługi AKS na podstawie maksymalnej liczby zasobników, które mogą obsługiwać. 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 klastra wirtualne sieci równorzędne.
- 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/16lub192.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 adresu kubernetes.default.svc.cluster.local .
Kubenet
Klastry usługi AKS używają rozwiązania kubenet i domyślnie tworzą sieć wirtualną i podsieć platformy Azure. W przypadku sieci kubenet węzły uzyskują adresy IP z podsieci sieci wirtualnej platformy Azure. Zasobniki uzyskują adresy IP z przestrzeni adresowej, która jest logicznie różna od podsieci sieci wirtualnej platformy Azure, używanej przez węzły. Translator adresów sieciowych (NAT) jest następnie skonfigurowany, aby zasobniki mogły uzyskiwać dostęp do zasobów w sieci wirtualnej platformy Azure. Źródłowy adres IP ruchu to translator adresów sieciowych do podstawowego adresu IP węzła. Takie podejście znacznie zmniejsza liczbę adresów IP, które należy zarezerwować w przestrzeni sieciowej, aby zasobniki były używane.
Maksymalną liczbę zasobników można skonfigurować w węźle w czasie tworzenia klastra lub podczas tworzenia nowych pul węzłów. Jeśli nie określisz maxPods podczas tworzenia nowych pul węzłów, otrzymasz wartość domyślną 110 dla rozwiązania kubenet.
Omówienie sieci kubenet z własną podsiecią
W wielu środowiskach zdefiniowano sieci wirtualne i podsieci z przydzielonymi zakresami adresów IP i używasz tych zasobów do obsługi wielu usług i aplikacji. Aby zapewnić łączność sieciową, klastry usługi AKS mogą używać rozwiązania kubenet (sieci podstawowej) lub usługi Azure CNI (sieć zaawansowana).
W przypadku rozwiązania kubenet tylko węzły otrzymują adres IP w podsieci sieci wirtualnej. Zasobniki nie mogą komunikować się bezpośrednio ze sobą. Zamiast tego routing zdefiniowany przez użytkownika (UDR) i przekazywanie ip obsługują łączność między zasobnikami między węzłami. Konfiguracja tras zdefiniowanych przez użytkownika i przekierowywanie adresów IP jest tworzona i domyślnie utrzymywana przez usługę AKS, ale jeśli chcesz, możesz przenieść własną tabelę tras na potrzeby niestandardowego zarządzania trasami. Można również wdrożyć zasobniki za usługą, która odbiera przypisany adres IP i równoważy ruch dla aplikacji. Na poniższym diagramie pokazano, jak węzły usługi AKS odbierają adres IP w podsieci sieci wirtualnej, ale nie zasobniki:
pomoc techniczna platformy Azure maksymalnie 400 tras w trasach zdefiniowanych przez użytkownika, więc nie można mieć klastra usługi AKS większego niż 400 węzłów. Węzły wirtualne usługi AKS i zasady sieci platformy Azure nie są obsługiwane w usłudze kubenet. Zasady sieci Calico są obsługiwane.
Ograniczenia i zagadnienia dotyczące rozwiązania kubenet
- Dodatkowy przeskok jest wymagany w projekcie rozwiązania kubenet, co dodaje niewielkie opóźnienie do komunikacji zasobnika.
- Tabele tras i trasy zdefiniowane przez użytkownika są wymagane do korzystania z rozwiązania kubenet, co zwiększa złożoność operacji.
- Bezpośrednie adresowanie zasobników nie jest obsługiwane w przypadku rozwiązania kubenet ze względu na projekt kubenet.
- W przeciwieństwie do klastrów usługi Azure CNI wiele klastrów kubenet nie może współużytkować podsieci.
- Usługa AKS nie stosuje sieciowych grup zabezpieczeń do podsieci i nie modyfikuje żadnej sieciowej grupy zabezpieczeń skojarzonej z tą podsiecią. Jeśli podasz własną podsieć i dodasz sieciowe grupy zabezpieczeń skojarzone z tą podsiecią, musisz upewnić się, że reguły zabezpieczeń w sieciowych grupach zabezpieczeń zezwalają na ruch między węzłem a trasą CIDR zasobnika. Aby uzyskać więcej informacji, zobacz Sieciowe grupy zabezpieczeń.
- Funkcje nieobsługiwane w rozwiązaniu kubenet obejmują:
Uwaga
Niektóre zasobniki systemowe, takie jak konnectivity w klastrze, używają adresu IP węzła hosta, a nie adresu IP z przestrzeni adresowej nakładki. Zasobniki systemowe będą używać tylko adresu IP węzła, a nie adresu IP z sieci wirtualnej.
Dostępność i wyczerpanie adresów IP
Typowym problemem z usługą Azure CNI jest to, że przypisany zakres adresów IP jest zbyt mały, aby dodać więcej węzłów podczas skalowania lub uaktualniania klastra. Zespół ds. sieci może również nie być w stanie wydać wystarczająco dużego zakresu adresów IP, aby obsługiwać oczekiwane wymagania aplikacji. W ramach naruszenia zabezpieczeń można utworzyć klaster usługi AKS, który używa rozwiązania kubenet i łączyć się z istniejącą podsiecią sieci wirtualnej. Takie podejście umożliwia węzłom odbieranie zdefiniowanych adresów IP bez konieczności wcześniejszego zarezerwowania dużej liczby adresów IP dla potencjalnych zasobników, które mogą być uruchamiane w klastrze.
Dzięki rozwiązaniu kubenet można użyć znacznie mniejszego zakresu adresów IP i obsługiwać duże klastry i wymagania aplikacji. Na przykład z zakresem adresów IP /27 w podsieci można uruchomić klaster 20–25 węzłów z wystarczającą ilością miejsca do skalowania lub uaktualniania. Ten rozmiar klastra może obsługiwać maksymalnie 2200–2750 zasobników (domyślnie maksymalnie 110 zasobników na węzeł). Maksymalna liczba zasobników na węzeł, które można skonfigurować za pomocą usługi kubenet w usłudze AKS, wynosi 250.
Następujące podstawowe obliczenia porównują różnicę w modelach sieciowych:
- kubenet: prosty zakres adresów IP /24 może obsługiwać maksymalnie 251 węzłów w klastrze. Każda podsieć sieci wirtualnej platformy Azure rezerwuje pierwsze trzy adresy IP dla operacji zarządzania. Ta liczba węzłów może obsługiwać maksymalnie 27 610 zasobników z domyślnym maksymalnie 110 zasobnikami na węzeł.
- 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ć maksymalnie 240 zasobników z domyślnym maksymalnie 30 zasobnikami 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.
Komunikacja równorzędna sieci wirtualnych i połączenia usługi ExpressRoute
Aby zapewnić łączność lokalną, możesz użyć komunikacji równorzędnej sieci wirtualnych platformy Azure lub połączeń usługi ExpressRoute z usługami Azure CNI i kubenet . 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 anonsowanego 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ć usługi 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 systemy zewnętrzne dla ruchu pochodzącego z zasobnika z obsługą sieci 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 usługi AKS widzą adres IP węzła jako adres źródłowy dla dowolnego ruchu z zasobnika. 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ż sieć CNI platformy Azure na potrzeby dynamicznej alokacji adresów IP implementuje infrastrukturę sieci kontenerów platformy Microsoft Azure, która zapewnia kompleksowe środowisko pracy. 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ć zasady sieci dla 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żna wdrożyć w węźle konfigurowalnym?
Domyślnie klastry usługi AKS używają rozwiązania kubenet i tworzą sieć wirtualną i podsieć. Dzięki rozwiązaniu kubenet węzły uzyskują adres IP z podsieci sieci wirtualnej. Translacja adresów sieciowych (NAT) jest następnie konfigurowana w węzłach, a zasobniki otrzymują adres IP "ukryty" za adresem IP węzła. Takie podejście zmniejsza liczbę adresów IP, które należy zarezerwować w przestrzeni sieciowej, aby zasobniki były używane.
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 usługi AKS widzą adres IP węzła jako adres źródłowy dla dowolnego ruchu z zasobnika. 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 zasobników, które obsługuje. 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 na potrzeby dynamicznej alokacji adresów IP nie można wdrożyć maszyn wirtualnych w podsieci zasobnika.
Jaki źródłowy adres IP widzi systemy zewnętrzne dla ruchu pochodzącego z zasobnika z obsługą sieci 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 usługi AKS widzą adres IP węzła jako adres źródłowy dla dowolnego ruchu z zasobnika.
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ż sieć CNI platformy Azure na potrzeby dynamicznej alokacji adresów IP implementuje infrastrukturę sieci kontenerów platformy Microsoft Azure, która zapewnia kompleksowe środowisko pracy. 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ę.
Azure Kubernetes Service