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. Wtyczki CNI są odpowiedzialne za przypisywanie adresów IP do podów, trasowanie sieciowe między podami, trasowanie usług Kubernetes i nie tylko.

Usługa Azure Kubernetes Service (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 AKS.

Usługa AKS używa dwóch głównych modeli sieci:

• Sieć nakładki:

  • Oszczędza przestrzeń adresów IP dla sieci wirtualnych, używając logicznie oddzielnych zakresów Classless Inter-Domain Routing (CIDR) dla podów.
  • Zapewnia maksymalną obsługę skalowania klastra.
  • Zapewnia proste zarządzanie adresami IP.

• Sieć płaska:

  • Zapewnia pełną łączność sieci wirtualnej dla podów. Z podów można uzyskać bezpośredni dostęp przez ich prywatny adres IP z połączonych sieci.
  • Wymaga dużej, niefragmentowanej przestrzeni adresowej IP dla sieci wirtualnych.

Oba modele sieciowe mają wiele obsługiwanych opcji dla wtyczek CNI. Główne różnice między modelami to sposób przypisywania adresów IP podom oraz sposób, w jaki ruch opuszcza klaster.

Nakładanie sieci

Sieciowanie nakładowe to najczęściej spotykany model sieciowy używany w Kubernetes. W sieciach nakładek, zasobniki otrzymują adres IP z prywatnego, logicznie oddzielonego CIDR, które pochodzi z podsieci sieci wirtualnej Azure, w której wdrażane są węzły AKS. Ta konfiguracja umożliwia prostszą i często lepszą skalowalność niż model sieci płaskiej.

W sieciach nakładkowych zasobniki mogą komunikować się ze sobą bezpośrednio. Ruch opuszczający klaster ma źródłowy adres sieciowy przetłumaczony (SNAT) na adres IP węzła. Ruch IP przychodzący do poda jest kierowany przez usługę, taką jak równoważnik obciążenia. Adres IP poda jest następnie "ukryty" za adresem IP węzła. Takie podejście zmniejsza liczbę adresów IP wymaganych dla sieci wirtualnych w klastrach.

W przypadku sieci nakładek usługa AKS udostępnia wtyczkę Azure CNI Overlay. W większości scenariuszy zalecamy użycie tej wtyczki CNI.

Sieci płaskie

W usłudze AKS, w przeciwieństwie do sieci nakładki, model sieci płaskiej przypisuje adresy IP do podów z podsieci z tej samej sieci wirtualnej platformy Azure co węzły tej samej usługi AKS. Ruch, który opuszcza klastry, nie podlega SNAT, a adres IP poda jest bezpośrednio ujawniony do miejsca docelowego. Takie podejście może być przydatne w niektórych scenariuszach, na przykład gdy potrzebujesz ujawnić adresy IP zasobników dla usług zewnętrznych.

Usługa AKS udostępnia dwie wtyczki CNI dla sieci płaskiej:

• Podsieć usługi Azure CNI, zalecana wtyczka CNI dla scenariuszy z siecią płaską.
• Podsieć węzłów CNI platformy Azure, starsza wersja modelu CNI dla sieci prostych. Ogólnie rzecz biorąc, zalecamy użycie jej tylko wtedy, gdy potrzebujesz zarządzanej sieci wirtualnej dla klastra.

Wybieranie wtyczki CNI

Podczas wybierania wtyczki CNI należy wziąć pod uwagę kilka czynników. Każdy model sieci ma własne zalety i wady. Najlepszy wybór dla klastra zależy od konkretnych wymagań.

Porównanie przypadków użycia

Porównanie funkcji

Zakres wsparcia między modelami sieciowymi

W zależności od używanej wtyczki CNI można wdrożyć zasoby sieci wirtualnej dla klastra w jeden z następujących sposobów:

• Platforma Azure może automatycznie tworzyć i konfigurować zasoby sieci wirtualnej podczas tworzenia klastra usługi AKS, na przykład w nakładce usługi Azure CNI, podsieci węzłów usługi Azure CNI i platformie 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 wsparcia AKS definiują, jakie zmiany można wprowadzić. Przykład:

• Jeśli ręcznie utworzysz zasoby sieci wirtualnej dla klastra usługi AKS, będziesz mieć wsparcie podczas konfigurowania własnych tras zdefiniowanych przez użytkownika (UDR) lub punktów końcowych usługi.
• Jeśli platforma Azure automatycznie tworzy zasoby sieci wirtualnej dla klastra AKS, nie można ręcznie zmienić tych zasobów zarządzanych przez AKS, aby skonfigurować własne trasy UDR lub punkty końcowe usługi.

Prerequisites

Podczas planowania konfiguracji sieci dla usługi AKS należy pamiętać o następujących wymaganiach i zagadnieniach:

• Sieć wirtualna klastra usługi AKS musi zezwalać na wychodzące połączenia z Internetem.
• 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 jako zakresów adresów dla usługi Kubernetes, zasobników lub wirtualnych sieci klastra.
• W scenariuszach, w których używasz własnej sieci wirtualnej, 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 Omówienie sieciowych grup zabezpieczeń platformy Azure.

Treści powiązane

• Nakładka Azure CNI
• Podsieć Podów Azure CNI
• Starsze opcje CNI
• Planowanie adresów IP dla klastrów