Zagadnienia dotyczące topologii sieci i łączności dla usługi AKS

Uwagi dotyczące projektowania

Usługa Azure Kubernetes Service (AKS) udostępnia trzy różne modele sieciowe dla sieci kontenerów: Kubenet, Nakładka CNI i CNI. Każdy z tych modeli ma swój unikatowy zestaw funkcji i zalet, oferując elastyczność i skalowalność dla sieci kontenerów w usłudze AKS.

Kubenet

Kubenet to podstawowe rozwiązanie sieciowe, które oszczędza przestrzeń adresów IP i oferuje prostą konfigurację. Jest idealnym rozwiązaniem w przypadku małych klastrów usługi AKS z mniej niż 400 węzłami, w których ręczne zarządzanie trasami zdefiniowanymi przez użytkownika i ich utrzymywanie jest akceptowalne. Jest ona odpowiednia w scenariuszach, w których wewnętrzne lub zewnętrzne moduły równoważenia obciążenia są wystarczające do dotarcia do zasobników spoza klastra.

Azure CNI

Azure CNI to model sieci zaprojektowany pod kątem zaawansowanych sieci. Zapewnia pełną łączność sieci wirtualnej dla zasobników, co pozwala na łączność zasobników z zasobnikami i zasobnikami na maszynę wirtualną. Jest to idealne rozwiązanie w scenariuszach, w których wymagane są zaawansowane funkcje usługi AKS, takie jak węzły wirtualne. Jest odpowiednia w scenariuszach, w których dostępna jest wystarczająca przestrzeń adresowa IP, a zasoby zewnętrzne muszą bezpośrednio dotrzeć do zasobników. Zasady sieciowe usługi AKS są również obsługiwane w usłudze Azure CNI.

Nakładka Azure CNI

Nakładka CNI platformy Azure została zaprojektowana pod kątem rozwiązywania problemów z niedoborami adresów IP i upraszczania konfiguracji sieci. Jest odpowiednia w scenariuszach, w których skalowanie do 1000 węzłów i 250 zasobników na węzeł jest wystarczające, a dodatkowy przeskok dla łączności zasobników jest akceptowalny. Wymagania dotyczące ruchu wychodzącego usługi AKS można również spełnić za pomocą nakładki usługi Azure CNI.

Podsumowanie zalecanych przypadków użycia dla modelu sieciowego można znaleźć w temacie Porównanie modeli sieciowych w usłudze AKS.

Ponadto podczas projektowania klastra usługi AKS ważne jest dokładne zaplanowanie adresowania IP i rozmiaru podsieci sieci wirtualnej w celu obsługi skalowania. Węzły wirtualne mogą służyć do szybkiego skalowania klastra, ale istnieją pewne znane ograniczenia.

Klastry usługi AKS obsługują jednostki SKU usługi Azure Load Balancer w warstwie Podstawowa i Standardowa, a usługi można uwidocznić za pomocą publicznych lub wewnętrznych modułów równoważenia obciążenia. Usługa AKS używa sieci CoreDNS do udostępniania rozpoznawania nazw zasobnikom uruchomionym w klastrze, a ruch sieciowy wychodzący (wychodzący) może być wysyłany za pośrednictwem usługi Azure Firewall lub klastra wirtualnego urządzenia sieciowego.

Domyślnie wszystkie zasobniki w klastrze usługi AKS mogą wysyłać i odbierać ruch bez ograniczeń. Jednak zasady sieciowe platformy Kubernetes mogą służyć do poprawy zabezpieczeń i filtrowania ruchu sieciowego między zasobnikami w klastrze usługi AKS. Dla usługi AKS są dostępne dwa modele zasad sieciowych: zasady sieci platformy Azure i Calico.

Na koniec usługa AKS konfiguruje sieciową grupę zabezpieczeń w podsieci, w której wdrożono klaster. Zaleca się, aby nie edytować ręcznie tej sieciowej grupy zabezpieczeń, ale usługi wdrożone w usłudze AKS mogą mieć na nią wpływ.

Ogólnie rzecz biorąc, wybranie odpowiedniego modelu sieciowego i dokładne planowanie zasobów sieciowych może pomóc w optymalizacji wydajności, zabezpieczeń i kosztów klastra usługi AKS.

Klastry prywatne

Widoczność adresu IP klastra usługi AKS może być publiczna lub prywatna. Klastry prywatne uwidaczniają interfejs API Kubernetes za pośrednictwem prywatnego adresu IP, ale nie za pośrednictwem publicznego. Ten prywatny adres IP jest reprezentowany w sieci wirtualnej usługi AKS za pośrednictwem prywatnego punktu końcowego. Interfejs API Kubernetes nie powinien być uzyskiwany za pośrednictwem adresu IP, ale zamiast tego za pośrednictwem w pełni kwalifikowanej nazwy domeny (FQDN). Rozpoznawanie nazwy FQDN interfejsu API Platformy Kubernetes do jej adresu IP zwykle odbywa się przez strefę usługi Azure Prywatna strefa DNS. Tę strefę DNS można utworzyć na platformie Azure w grupie zasobów węzła usługi AKS lub określić istniejącą strefę DNS.

Po sprawdzonych rozwiązaniach w skali przedsiębiorstwa rozpoznawanie nazw DNS dla obciążeń platformy Azure jest oferowane przez scentralizowane serwery DNS wdrożone w subskrypcji łączności, w sieci wirtualnej koncentratora lub w sieci wirtualnej usług udostępnionych połączonych z usługą Azure Virtual WAN. Te serwery będą warunkowo rozpoznawać nazwy specyficzne dla platformy Azure i publiczne przy użyciu usługi Azure DNS (adresu 168.63.129.16IP) i nazw prywatnych przy użyciu firmowych serwerów DNS. Jednak te scentralizowane serwery DNS nie będą mogły rozpoznać nazwy FQDN interfejsu API usługi AKS, dopóki nie zostaną połączone z strefą prywatną DNS utworzoną dla klastra usługi AKS. Każda usługa AKS ma unikatową strefę prywatną DNS, ponieważ losowy identyfikator GUID jest poprzedzany nazwą strefy. W związku z tym dla każdego nowego klastra usługi AKS odpowiednia prywatna strefa DNS powinna być połączona z siecią wirtualną, w której znajdują się centralne serwery DNS.

Wszystkie sieci wirtualne powinny być skonfigurowane do używania tych centralnych serwerów DNS do rozpoznawania nazw. Jeśli jednak sieć wirtualna usługi AKS jest skonfigurowana do używania centralnych serwerów DNS, a te serwery DNS nie są jeszcze połączone z prywatną strefą DNS, węzły usługi AKS nie będą mogły rozpoznać nazwy FQDN interfejsu API Kubernetes, a utworzenie klastra usługi AKS zakończy się niepowodzeniem. Sieć wirtualna usługi AKS powinna być skonfigurowana do używania centralnych serwerów DNS dopiero po utworzeniu klastra.

Po utworzeniu klastra połączenie jest tworzone między strefą prywatną DNS a siecią wirtualną, w której są wdrażane centralne serwery DNS. Sieć wirtualna usługi AKS została również skonfigurowana do używania centralnych serwerów DNS w subskrypcji łączności, a dostęp administratora do interfejsu API kubernetes usługi AKS będzie postępować zgodnie z tym przepływem:

Uwaga

Obrazy w tym artykule odzwierciedlają projekt przy użyciu tradycyjnego modelu łączności piasty i szprych. Strefy docelowe w skali przedsiębiorstwa mogą wybrać model łączności usługi Virtual WAN, w którym centralne serwery DNS będą znajdować się w sieci wirtualnej usług udostępnionych połączonych z koncentratorem usługi Virtual WAN.

1. Administrator rozpoznaje nazwę FQDN interfejsu API platformy Kubernetes. Lokalne serwery DNS przekazują żądanie do serwerów autorytatywnych: rozpoznawania nazw DNS na platformie Azure. Te serwery przekazują żądanie do serwera Usługi Azure DNS (168.63.129.16), który otrzyma adres IP ze strefy usługi Azure Prywatna strefa DNS.
2. Po rozwiązaniu adresu IP ruch do interfejsu API Kubernetes jest kierowany ze środowiska lokalnego do bramy sieci VPN lub usługi ExpressRoute na platformie Azure w zależności od modelu łączności.
3. Prywatny punkt końcowy wprowadzi /32 trasę w sieci wirtualnej koncentratora. Bramy sieci VPN i usługi ExpressRoute wysyłają ruch bezpośrednio do prywatnego punktu końcowego interfejsu API platformy Kubernetes wdrożonego w sieci wirtualnej usługi AKS.

Ruch z użytkowników aplikacji do klastra

Kontrolery przychodzące (przychodzące) mogą służyć do uwidaczniania aplikacji działających w klastrach usługi AKS.

• Kontrolery ruchu przychodzącego zapewniają routing na poziomie aplikacji kosztem niewielkiego wzrostu złożoności.
• Kontrolery ruchu przychodzącego mogą uwzględniać funkcje zapory aplikacji internetowej (WAF).
• Kontrolery ruchu przychodzącego mogą uruchamiać poza klastrem i klastrem:
  • Kontroler ruchu przychodzącego poza klastrem odciąża obliczenia (takie jak routing ruchu HTTP lub kończenie żądań PROTOKOŁU TLS) do innej usługi spoza usługi AKS, takiej jak dodatek kontroler ruchu przychodzącego bramy aplikacja systemu Azure (AGIC).
  • Rozwiązanie w klastrze korzysta z zasobów klastra usługi AKS na potrzeby obliczeń (takich jak routing ruchu HTTP lub kończenie żądań PROTOKOŁU TLS). Kontrolery ruchu przychodzącego w klastrze mogą oferować niższe koszty, ale wymagają starannego planowania i konserwacji zasobów.
• Podstawowy dodatek routingu aplikacji HTTP jest łatwy w użyciu, ale ma pewne ograniczenia opisane w artykule Routing aplikacji HTTP.

Kontrolery ruchu przychodzącego mogą uwidaczniać aplikacje i interfejsy API z publicznym lub prywatnym adresem IP.

• Konfiguracja powinna być zgodna z projektem filtrowania ruchu wychodzącego, aby uniknąć routingu asymetrycznego. Trasy zdefiniowane przez użytkownika mogą powodować routing asymetryczny (potencjalnie), ale niekoniecznie. Usługa Application Gateway może kierować SNAT na ruch, co oznacza, że ruch powrotny wraca do węzła usługi Application Gateway, a nie do trasy zdefiniowanej przez użytkownika, jeśli trasa zdefiniowana przez użytkownika jest skonfigurowana tylko dla ruchu internetowego.
• Jeśli wymagane jest zakończenie protokołu TLS, należy rozważyć zarządzanie certyfikatami TLS.

Ruch aplikacji może pochodzić ze środowiska lokalnego lub publicznego Internetu. Na poniższej ilustracji opisano przykład, w którym brama aplikacja systemu Azure jest skonfigurowana do zwrotnego połączenia serwera proxy z klastrami zarówno ze środowiska lokalnego, jak i z publicznego Internetu.

Ruch ze środowiska lokalnego jest zgodny z przepływem numerowanych niebieskich objaśnień na poprzednim diagramie.

1. Klient rozpoznaje nazwę FQDN przypisaną do aplikacji przy użyciu serwerów DNS wdrożonych w subskrypcji łączności lub lokalnych serwerów DNS.
2. Po rozpoznaniu nazwy FQDN aplikacji na adres IP (prywatny adres IP bramy aplikacji) ruch jest kierowany przez sieć VPN lub bramę usługi ExpressRoute.
3. Routing w podsieci bramy jest skonfigurowany do wysyłania żądania do zapory aplikacji internetowej.
4. Zapora aplikacji internetowej wysyła prawidłowe żądania do obciążenia uruchomionego w klastrze usługi AKS.

Brama aplikacja systemu Azure w tym przykładzie można wdrożyć w tej samej subskrypcji co klaster usługi AKS, ponieważ jej konfiguracja jest ściśle powiązana z obciążeniami wdrożonym w usłudze AKS i dlatego jest zarządzana przez ten sam zespół aplikacji. Dostęp z Internetu jest zgodny z przepływem numerowanych zielonych objaśnień na poprzednim diagramie.

1. Klienci z publicznego Internetu rozpoznają nazwę DNS aplikacji przy użyciu usługi Azure Traffic Manager. Alternatywnie można użyć innych globalnych technologii równoważenia obciążenia, takich jak usługa Azure Front Door .
2. Publiczna nazwa FQDN aplikacji zostanie rozpoznana przez usługę Traffic Manager na publiczny adres IP bramy aplikacji, do której klienci uzyskują dostęp za pośrednictwem publicznego Internetu.
3. Brama aplikacji uzyskuje dostęp do obciążenia wdrożonego w usłudze AKS.

Uwaga

Te przepływy są prawidłowe tylko w przypadku aplikacji internetowych. Aplikacje inne niż internetowe znajdują się poza zakresem tego artykułu i można je uwidocznić za pośrednictwem usługi Azure Firewall w sieci wirtualnej koncentratora lub bezpiecznego koncentratora wirtualnego, jeśli korzystasz z modelu łączności usługi Virtual WAN.

Przepływy ruchu dla aplikacji internetowych można również wykonywać w celu przechodzenia zarówno przez usługę Azure Firewall w subskrypcji łączności, jak i zapory aplikacji internetowej w sieci wirtualnej usługi AKS. Takie podejście ma zaletę oferowania większej ochrony, takiej jak używanie filtrowania opartego na analizie usługi Azure Firewall w celu usuwania ruchu ze znanych złośliwych adresów IP w Internecie. Jednak ma też pewne wady. Na przykład utrata oryginalnego adresu IP klienta oraz dodatkowa koordynacja wymagana między zaporą a zespołami aplikacji podczas uwidaczniania aplikacji. Dzieje się tak, ponieważ w usłudze Azure Firewall będą potrzebne reguły tłumaczenia adresów sieciowych (DNAT).

Ruch z zasobników usługi AKS do usług zaplecza

Zasobniki działające wewnątrz klastra usługi AKS mogą wymagać dostępu do usług zaplecza, takich jak Azure Storage, Bazy danych Azure SQL Database lub Bazy danych NoSQL usługi Azure Cosmos DB. Punkty końcowe usługi sieci wirtualnej i usługa Private Link mogą służyć do zabezpieczania łączności z tymi usługami zarządzanymi platformy Azure.

Jeśli używasz prywatnych punktów końcowych platformy Azure na potrzeby ruchu zaplecza, rozpoznawanie nazw DNS dla usług platformy Azure można wykonać przy użyciu stref usługi Azure Prywatna strefa DNS. Ponieważ narzędzia rozpoznawania nazw DNS dla całego środowiska znajdują się w sieci wirtualnej piasty (lub w sieci wirtualnej usług udostępnionych, jeśli korzystasz z modelu łączności usługi Virtual WAN), te strefy prywatne powinny zostać utworzone w subskrypcji łączności. Aby utworzyć rekord A wymagany do rozpoznania nazwy FQDN usługi prywatnej, można skojarzyć prywatną strefę DNS (w subskrypcji łączności) z prywatnym punktem końcowym (w subskrypcji aplikacji). Ta operacja wymaga pewnych uprawnień w tych subskrypcjach.

Istnieje możliwość ręcznego utworzenia rekordów A, ale skojarzenie prywatnej strefy DNS z prywatnym punktem końcowym powoduje, że konfiguracja jest mniej podatna na błędną konfigurację.

Łączność zaplecza z zasobników usługi AKS z usługami PaaS platformy Azure uwidoczniona za pośrednictwem prywatnych punktów końcowych jest następująca sekwencja:

1. Zasobniki usługi AKS rozpoznają nazwę FQDN platformy Azure jako usługi (PaaS) przy użyciu centralnych serwerów DNS w subskrypcji łączności, które są zdefiniowane jako niestandardowe serwery DNS w sieci wirtualnej usługi AKS.
2. Rozpoznany adres IP to prywatny adres IP prywatnych punktów końcowych, do których uzyskuje się dostęp bezpośrednio z zasobników usługi AKS.

Ruch między zasobnikami usługi AKS a prywatnymi punktami końcowymi na wartość domyślną nie będzie przechodził przez usługę Azure Firewall w sieci wirtualnej koncentratora (lub bezpiecznego koncentratora wirtualnego, jeśli używasz wirtualnej sieci WAN), nawet jeśli klaster usługi AKS jest skonfigurowany do filtrowania ruchu wychodzącego za pomocą usługi Azure Firewall. Przyczyną /32 jest to, że prywatny punkt końcowy tworzy trasę w podsieciach sieci wirtualnej aplikacji, w której wdrożono usługę AKS.

Zalecenia dotyczące projektowania

• Jeśli zasady zabezpieczeń wymagają posiadania interfejsu API Kubernetes z prywatnym adresem IP (zamiast publicznego adresu IP), wdróż prywatny klaster usługi AKS.
  • Użyj niestandardowych prywatnych stref DNS podczas tworzenia klastra prywatnego, a nie zezwalania procesowi tworzenia na używanie prywatnej strefy DNS systemu.
• Użyj interfejsu sieci kontenera platformy Azure (CNI) jako modelu sieciowego, chyba że masz ograniczony zakres adresów IP, które można przypisać do klastra usługi AKS.
  • Postępuj zgodnie z dokumentacją dotyczącą planowania adresów IP w usłudze CNI.
  • Aby użyć pul węzłów systemu Windows Server i węzłów wirtualnych w celu zweryfikowania ograniczeń ostatecznej, zapoznaj się z często zadawanymi pytaniami pomocy technicznej usługi Windows AKS.
• Użyj usługi Azure DDoS Protection, aby chronić sieć wirtualną używaną dla klastra usługi AKS, chyba że używasz usługi Azure Firewall lub zapory aplikacji internetowej w scentralizowanej subskrypcji.
• Użyj konfiguracji DNS połączonej z ogólną konfiguracją sieci z usługą Azure Virtual WAN lub architekturą piasty i szprych, strefami Azure DNS i własną infrastrukturą DNS.
• Użyj usługi Private Link, aby zabezpieczyć połączenia sieciowe i korzystać z prywatnej łączności opartej na protokole IP z innymi zarządzanymi usługami platformy Azure, które obsługują usługę Private Link, taką jak Azure Storage, Azure Container Registry, Azure SQL Database i Azure Key Vault.
• Użyj kontrolera ruchu przychodzącego do zapewnienia zaawansowanego routingu i zabezpieczeń PROTOKOŁU HTTP oraz do zaoferowania pojedynczego punktu końcowego dla aplikacji.
• Wszystkie aplikacje internetowe skonfigurowane do korzystania z ruchu przychodzącego powinny używać szyfrowania TLS i nie zezwalać na dostęp za pośrednictwem niezaszyfrowanego protokołu HTTP. Te zasady są już wymuszane, jeśli subskrypcja zawiera zalecane zasady w zasadach uwzględnionych w implementacjach referencyjnych stref docelowych w skali przedsiębiorstwa.
• Opcjonalnie, aby zaoszczędzić zasoby obliczeniowe i magazynowe klastra usługi AKS, użyj kontrolera ruchu przychodzącego poza klastrem.
  • Użyj dodatku kontrolera ruchu przychodzącego bramy aplikacja systemu Azure (AGIC), który jest usługą platformy Azure zarządzaną przez pierwszą firmę.
  • W usłudze AGIC wdróż dedykowaną bramę aplikacja systemu Azure dla każdego klastra usługi AKS i nie współużytkuj tej samej usługi Application Gateway w wielu klastrach usługi AKS.
  • Jeśli nie ma żadnych ograniczeń zasobów lub operacyjnych lub AGIC nie udostępnia wymaganych funkcji, użyj rozwiązania kontrolera ruchu przychodzącego w klastrze, takiego jak NGINX, Traefik lub inne rozwiązanie obsługiwane przez platformę Kubernetes.
• W przypadku aplikacji internetowych i aplikacji internetowych o krytycznym znaczeniu dla zabezpieczeń i zabezpieczeń należy użyć zapory aplikacji internetowej z kontrolerem ruchu przychodzącego.
  • aplikacja systemu Azure Gateway i Azure Front Door integrują usługę Zapora aplikacji internetowej platformy Azure w celu ochrony aplikacji internetowych.
• Jeśli zasady zabezpieczeń wymagają inspekcji całego wychodzącego ruchu internetowego wygenerowanego w klastrze usługi AKS, bezpieczny ruch sieciowy wychodzący przy użyciu usługi Azure Firewall lub wirtualnego urządzenia sieciowego innej firmy wdrożonego w sieci wirtualnej koncentratora zarządzanego. Aby uzyskać więcej informacji, zobacz Ograniczanie ruchu wychodzącego. Trasa zdefiniowana przez użytkownika typu ruchu wychodzącego usługi AKS wymaga skojarzenia tabeli tras z podsiecią węzłów usługi AKS, więc nie można jej używać obecnie z dynamicznym wstrzyknięciem trasy obsługiwanym przez usługę Azure Virtual WAN lub Azure Route Server.
• W przypadku klastrów innych niż prywatne użyj autoryzowanych zakresów adresów IP.
• Użyj warstwy Standardowa, a nie warstwy Podstawowa usługi Azure Load Balancer.
• Podczas projektowania klastra Kubernetes na platformie Azure jednym z kluczowych zagadnień jest wybranie odpowiedniego modelu sieciowego dla określonych wymagań. Usługa Azure Kubernetes Service (AKS) oferuje trzy różne modele sieciowe: Kubenet, Azure CNI i Azure CNI Overlay. Aby podjąć świadomą decyzję, należy zrozumieć możliwości i cechy poszczególnych modeli.

Porównanie funkcji między trzema modelami sieciowymi w usłudze AKS; Rozwiązania Kubenet, Azure CNI i Azure CNI Overlay można znaleźć w temacie Porównanie modeli sieciowych w usłudze AKS.