Udostępnij za pośrednictwem


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.

Diagram przedstawiający dwa węzły z trzema zasobnikami działającymi w sieci nakładki. Ruch zasobnika do punktów końcowych poza klastrem jest kierowany za pośrednictwem translatora adresów sieciowych.

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.

Diagram przedstawiający dwa węzły z trzema zasobnikami działającymi w modelu sieci płaskiej.

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 (wersja zapoznawcza) 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
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/16zakresu 172.31.0.0/16172.30.0.0/16192.0.2.0/24 adresów usługi Kubernetes, zakresu adresów zasobnika ani zakresu adresów sieci wirtualnej klastra.
  • W scenariuszach byO CNI 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.Network/virtualNetworks/subnets/read
    • Microsoft.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ą, 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