Omówienie sieci CNI usługi Azure Kubernetes Service (AKS)
Platforma Kubernetes używa wtyczek interfejsu CNI (Container Networking Interface) do zarządzania siecią w klastrach Kubernetes. Elementy CNI są odpowiedzialne za przypisywanie adresów IP do zasobników, routing sieciowy między zasobnikami, routingiem usługi Kubernetes Service i nie tylko.
Usługa AKS udostępnia wiele wtyczek CNI, których można używać w klastrach w zależności od wymagań sieciowych.
Modele sieciowe w usłudze AKS
Wybór wtyczki CNI dla klastra usługi AKS zależy w dużej mierze od tego, który model sieci najlepiej odpowiada Twoim potrzebom. Każdy model ma własne zalety i wady, które należy wziąć pod uwagę podczas planowania klastra usługi AKS.
Usługa AKS używa dwóch głównych modeli sieci: nakładki sieci i sieci płaskiej.
Oba modele sieciowe mają wiele obsługiwanych opcji wtyczki CNI. Główne różnice między modelami to sposób przypisywanych adresów IP zasobników i sposób opuszczania klastra.
Nakładanie sieci
Sieć nakładek to najbardziej typowy model sieci używany w rozwiązaniu Kubernetes. W sieciach nakładek zasobniki otrzymują adres IP z prywatnej, logicznie oddzielnej trasy CIDR od podsieci sieci wirtualnej platformy Azure, w której są wdrażane węzły usługi AKS. Zapewnia to prostszą i często lepszą skalowalność niż model sieci płaskiej.
W sieciach nakładek zasobniki mogą komunikować się ze sobą bezpośrednio. Ruch opuszczający klaster to Przetłumaczony adres sieciowy źródła (SNAT) na adres IP węzła, a ruch przychodzący zasobnika jest kierowany przez niektóre usługi, takie jak moduł równoważenia obciążenia. Oznacza to, że adres IP zasobnika jest "ukryty" za adresem IP węzła. Takie podejście zmniejsza liczbę adresów IP sieci wirtualnej wymaganych dla klastrów.
Usługa Azure Kubernetes Service udostępnia następujące wtyczki CNI dla sieci nakładek:
- Nakładka CNI platformy Azure, zalecana wtyczka CNI dla większości scenariuszy.
- kubenet, starszy model nakładki CNI.
Sieci płaskie
W przeciwieństwie do sieci nakładki model sieci płaskiej w usłudze AKS przypisuje adresy IP do zasobników z podsieci z tej samej sieci wirtualnej platformy Azure co węzły usługi AKS. Oznacza to, że ruch opuszczający klastry nie jest adresem SNAT, a adres IP zasobnika jest bezpośrednio uwidoczniony w miejscu docelowym. Może to być przydatne w niektórych scenariuszach, takich jak w przypadku konieczności uwidocznienia adresów IP zasobników w usługach zewnętrznych.
Usługa Azure Kubernetes Service udostępnia dwie wtyczki CNI dla sieci płaskiej. Ten artykuł nie zawiera szczegółowych informacji dla każdej opcji wtyczki. Aby uzyskać więcej informacji, zobacz połączoną dokumentację:
- Podsieć usługi Azure CNI, zalecana wtyczka CNI dla scenariuszy z siecią płaską.
- Podsieć węzła usługi Azure CNI — starsza wersja modelu sieci płaskiej CNI zwykle zaleca użycie tylko wtedy, gdy potrzebujesz zarządzanej sieci wirtualnej dla klastra.
Wybieranie sieci CNI
Podczas wybierania sieci CNI należy wziąć pod uwagę kilka czynników. Każdy model sieci ma własne zalety i wady, a najlepszy wybór dla klastra będzie zależeć od konkretnych wymagań.
Wybieranie modelu sieci
Dwa główne modele sieciowe w usłudze AKS to nakładki i płaskie sieci.
Sieci nakładki:
- Oszczędzaj przestrzeń adresów IP sieci wirtualnej przy użyciu logicznie oddzielnych zakresów CIDR dla zasobników.
- Maksymalna obsługa skalowania klastra.
- Proste zarządzanie adresami IP.
Sieci płaskie:
- Zasobniki uzyskują pełną łączność z siecią wirtualną i mogą być dostępne bezpośrednio za pośrednictwem ich prywatnego adresu IP z połączonych sieci.
- Wymagaj dużej, niefragmentowanej przestrzeni adresowej IP sieci wirtualnej.
Porównanie przypadków użycia
Podczas wybierania modelu sieci należy wziąć pod uwagę przypadki użycia dla każdej wtyczki CNI i typu używanego modelu sieci:
Wtyczka CNI | Model sieci | Wyróżnianie przypadków użycia |
---|---|---|
Nakładka Azure CNI | Nakładka | - Najlepsze dla ochrony adresów IP sieci wirtualnej - Maksymalna liczba węzłów obsługiwanych przez serwer interfejsu API + 250 zasobników na węzeł - Prostsza konfiguracja -Brak bezpośredniego dostępu do zewnętrznego adresu IP zasobnika |
Podsieć usługi Azure CNI | Spłaszcz | - Bezpośredni dostęp do zasobników zewnętrznych - Tryby wydajnego użycia adresów IP sieci wirtualnej lub obsługi dużych klastrów (wersja zapoznawcza) |
Kubenet (starsza wersja) | Nakładka | - Określa priorytety ochrony adresów IP - Ograniczona skala - Ręczne zarządzanie trasami |
Podsieć węzła usługi Azure CNI (starsza wersja) | Spłaszcz | - Bezpośredni dostęp do zasobników zewnętrznych - Prostsza konfiguracja - Ograniczona skala - Nieefektywne użycie adresów IP sieci wirtualnej |
Porównanie funkcji
Warto również porównać funkcje każdej wtyczki CNI. Poniższa tabela zawiera ogólne porównanie funkcji obsługiwanych przez każdą wtyczkę CNI:
Funkcja | Nakładka Azure CNI | Podsieć usługi Azure CNI | Podsieć węzła usługi Azure CNI (starsza wersja) | Kubenet |
---|---|---|---|---|
Wdrażanie klastra w istniejącej lub nowej sieci wirtualnej | Obsługiwane | Obsługiwane | Obsługiwane | Obsługiwane — ręczne trasy zdefiniowane przez użytkownika |
Łączność zasobnika z maszyną wirtualną w tej samej lub równorzędnej sieci wirtualnej | Zainicjowano zasobnik | Oba sposoby | Oba sposoby | Zainicjowano zasobnik |
Dostęp lokalny za pośrednictwem sieci VPN/usługi Express Route | Zainicjowano zasobnik | Oba sposoby | Oba sposoby | Zainicjowano zasobnik |
Dostęp do punktów końcowych usługi | Obsługiwane | Obsługiwane | Obsługiwane | Obsługiwane |
Uwidacznianie usług przy użyciu modułu równoważenia obciążenia | Obsługiwane | Obsługiwane | Obsługiwane | Obsługiwane |
Uwidacznianie usług przy użyciu usługi App Gateway | Obecnie nieobsługiwane | Obsługiwane | Obsługiwane | Obsługiwane |
Uwidacznianie usług za pomocą kontrolera ruchu przychodzącego | Obsługiwane | Obsługiwane | Obsługiwane | Obsługiwane |
Pule węzłów systemu Windows | Obsługiwane | Obsługiwane | Obsługiwane | Nieobsługiwane |
Domyślne strefy DNS i prywatne platformy Azure | Obsługiwane | Obsługiwane | Obsługiwane | Obsługiwane |
Współużytkowanie podsieci sieci wirtualnej w wielu klastrach | Obsługiwane | Obsługiwane | Obsługiwane | Nieobsługiwane |
Zakres obsługi między modelami sieciowymi
W zależności od używanego interfejsu CNI zasoby sieci wirtualnej klastra można wdrożyć na jeden z następujących sposobów:
- Platforma Azure może automatycznie tworzyć i konfigurować zasoby sieci wirtualnej podczas tworzenia klastra usługi AKS. podobnie jak w przypadku nakładki CNI platformy Azure, podsieci węzłów usługi Azure CNI i rozwiązania Kubenet.
- Możesz ręcznie utworzyć i skonfigurować zasoby sieci wirtualnej oraz dołączyć je do tych zasobów podczas tworzenia klastra usługi AKS.
Mimo że obsługiwane są funkcje, takie jak punkty końcowe usługi lub trasy zdefiniowane przez użytkownika, zasady obsługi usługi AKS definiują, jakie zmiany można wprowadzić. Na przykład:
- Jeśli ręcznie utworzysz zasoby sieci wirtualnej dla klastra usługi AKS, będziesz obsługiwana podczas konfigurowania własnych tras zdefiniowanych przez użytkownika lub punktów końcowych usługi.
- Jeśli platforma Azure automatycznie tworzy zasoby sieci wirtualnej dla klastra usługi AKS, nie można ręcznie zmienić tych zasobów zarządzanych przez usługę AKS w celu skonfigurowania własnych tras zdefiniowanych przez użytkownika lub punktów końcowych usługi.
Wymagania wstępne
Podczas planowania konfiguracji sieci dla usługi AKS należy wziąć pod uwagę kilka wymagań i zagadnień:
- 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/16
zakresu172.31.0.0/16
172.30.0.0/16
192.0.2.0/24
adresów usługi Kubernetes, zakresu adresów zasobnika ani zakresu adresów sieci wirtualnej klastra. - W scenariuszach sieci wirtualnej BYO 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/action
Microsoft.Authorization/roleAssignments/write
Microsoft.Network/virtualNetworks/subnets/read
(wymagane tylko w przypadku definiowania własnych podsieci i ciDR)
- 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ą, musisz upewnić 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ń.
Następne kroki
Azure Kubernetes Service