Przypadki użycia sieci między klastrami dla usługi Azure Kubernetes Fleet Manager (wersja zapoznawcza)

Komunikacja między klastrami dla usługi Azure Kubernetes Fleet Manager (Fleet) to usługa zarządzana oparta na Cilium Cluster Mesh, która umożliwia bezpośrednią komunikację między zasobnikami w wielu klastrach usługi Azure Kubernetes Service (AKS). Tworząc sieć między klastrami, można włączyć bezproblemową łączność wschodnio-zachodnią bez konieczności używania bram, jednocześnie uzyskując wgląd w wiele klastrów i spójne wymuszanie zabezpieczeń.

Architektura i możliwości

W konfiguracji sieci między klastrami płaska sieć wirtualna umożliwia podom w różnych klastrach bezpośrednie przesyłanie ruchu ponad granicami klastrów. Każdemu klastrowi zazwyczaj przypisuje się dwie podsieci: jedną dla węzłów i jedną dla podów. Ta spójna architektura zapewnia, że sieć podów pozostaje płaska w całej sieci międzyklastrowej, bez użycia sieci nakładkowych ani tuneli.

Diagram ilustrujący architekturę usługi Azure Kubernetes Fleet Manager zarządzającej łącznością między klastrami typu east-west. Zasobniki w różnych klastrach komunikują się bezpośrednio za pośrednictwem agentów Cilium w sparowanych sieciach wirtualnych.

Kluczowe składniki i możliwości tego scenariusza obejmują:

  • Azure CNI z płaszczyzną danych Cilium: Oba klastry usługi AKS muszą korzystać z usługi Azure CNI z płaszczyzną danych Azure CNI opartą na rozwiązaniu Cilium.
  • Advanced Container Networking Services (ACNS): usługi ACNS muszą być włączone w klastrach, aby obsługiwać ten scenariusz.
  • Azure Kubernetes Fleet Manager: Fleet zarządza cyklem życia i konfiguracją sieci między klastrami za pośrednictwem zasobów, takich jak profil ClusterMesh.
  • Natywna wydajność: Trasowanie ruchu do adresów IP podów odbywa się między klastrami z natywną wydajnością dzięki routingowi bezpośredniemu, eliminując potrzebę stosowania jakichkolwiek bram ani serwerów proxy.
  • Ujednolicone egzekwowanie zasad sieciowych: rozszerza egzekwowanie zasad sieciowych Cilium dla warstw 3–7 na wszystkie klastry w sieci międzyklastrowej, zapewniając spójne podejście do bezpieczeństwa.
  • Możliwość obserwacji wielu klastrów: zapewnia pełny wgląd w przepływy ruchu między klastrami. Ta widoczność pomaga monitorować kondycję aplikacji, rozwiązywać problemy z łącznością i analizować wzorce ruchu w sieci między klastrami.

Przypadki użycia

Sieć między klastrami umożliwia korzystanie z kilku kluczowych scenariuszy obejmujących wiele klastrów. W poniższych sekcjach opisano najczęstsze przypadki użycia sieci między klastrami w usłudze Fleet.

Przypadek użycia: przezroczyste wykrywanie usług i równoważenie obciążenia

Jeśli używasz standardowych usług Kubernetes i oznaczysz je jako globalne, Cilium automatycznie odnajduje punkty końcowe dla tych usług we wszystkich klastrach w sieci między klastrami. Każdy ruch kierowany do elementu ClusterIP globalnej usługi jest automatycznie równoważony obciążeniem pomiędzy wszystkie uczestniczące klastry, co upraszcza komunikację między klastrami.

Aplikacje mogą odnajdywać usługi i korzystać z nich niezależnie od klastra, w którym się znajdują, bez konieczności wprowadzania zmian na poziomie aplikacji ani rejestrów usług zewnętrznych.

Przypadek użycia: wysoka dostępność i odporność na uszkodzenia

Wysoka dostępność jest najczęstszym przypadkiem użycia sieci między klastrami. Ten przypadek użycia obejmuje obsługę klastrów Kubernetes w wielu regionach lub strefach dostępności oraz uruchamianie replik tych samych usług w każdym klastrze. W przypadku awarii żądania mogą zostać przełączone awaryjnie do innych klastrów w sieci międzyklastrowej.

Scenariusz awarii opisany w tym przypadku użycia nie jest przede wszystkim pełną niedostępnością całego regionu lub domeny awarii. Bardziej prawdopodobnym scenariuszem jest tymczasowa niedostępność zasobów lub błędna konfiguracja w jednym klastrze, co prowadzi do braku możliwości uruchamiania lub skalowania określonych usług w tym klastrze. W przypadku sieci między klastrami ruch przeznaczony dla usługi, którego dotyczy problem, jest automatycznie kierowany do punktów końcowych w dobrej kondycji w innych klastrach, dzięki czemu aplikacja jest dostępna.

Diagram przedstawiający dwa klastry AKS w różnych regionach. Frontendy w każdym klastrze kierują ruch do lokalnej usługi zamówień obsługiwanej przez pody zamówień. Gdy pody w klastrze B staną się niezdrowe, usługa zamówień w klastrze B przełącza się awaryjnie na usługę zamówień w klastrze A.

Przypadek użycia: Usługi udostępnione

Chociaż początkowym trendem w przypadku platform opartych na Kubernetesie było tworzenie dużych, wielodzierżawczych klastrów, coraz powszechniejsze staje się tworzenie osobnych klastrów dla poszczególnych dzierżawców lub klastrów dla różnych kategorii usług, takich jak różne poziomy wymagań bezpieczeństwa.

Jednak niektóre usługi, takie jak zarządzanie wpisami tajnymi, rejestrowanie, monitorowanie lub system DNS, są często udostępniane między wszystkimi klastrami. Scentralizowanie tych usług w udostępnionym klastrze "usługi" pozwala uniknąć nakładu pracy związanego z konserwowaniem ich w każdym klastrze dzierżawy.

Podstawową motywacją tego modelu jest izolacja między klastrami dzierżaw. Aby zachować ten cel, klastry dzierżaw są połączone tylko z klastrem usług udostępnionych i nie są połączone z innymi klastrami dzierżaw.

Diagram przedstawiający dwa klastry AKS dzierżawców z aplikacjami wywołującymi klienta usługi wpisów tajnych. Oba klastry dzierżawców kierują ruch do współdzielonego klastra usług, który hostuje usługę wpisów tajnych obsługiwaną przez pody vault-1 i vault-2. Klastry dzierżawców łączą się wyłącznie z klastrem usług współdzielonych, a nie ze sobą.

Przypadek użycia: separacja stanowa i bezstanowa

Można odizolować złożoność operacyjną usług stanowych, takich jak bazy danych i magazyn, w dedykowanych klastrach. Ten podział sprawia, że klastry aplikacji bezstanowych pozostają elastyczne i łatwe do migracji. Zwiększa również bezpieczeństwo, upraszcza zarządzanie cyklem życia klastra i umożliwia skalowanie bezstanowych obciążeń niezależnie od tych stanowych.

Diagram przedstawiający dwa bezstanowe klastry AKS, każdy z trasowaniem ruchu przychodzącego do frontendu i klienta magazynu danych. Oba bezstanowe klastry łączą się z dedykowanym klastrem stanowym hostującym usługę magazynu danych opartą na zasobnikach data-1, data-2 i data-n.

Przypadek użycia: wymuszanie zabezpieczeń i zasad w wielu klastrach

Komunikacja międzyklastrowa rozszerza egzekwowanie zasad sieciowych warstw 3–7 przez Cilium na wszystkie klastry w sieci międzyklastrowej. To ujednolicone wymuszanie zapewnia spójny stan zabezpieczeń i upraszcza zarządzanie zasadami, unikając konieczności ręcznego replikowania zasad w każdym środowisku. Zasady stosowane w jednym klastrze są respektowane we wszystkich pozostałych klastrach, zapewniając ujednolicone zabezpieczenia uwzględniające tożsamość w całej flocie.

Przypadek użycia: możliwość obserwacji wielu klastrów

Sieć między klastrami zapewnia kompleksową widoczność ruchu przepływającego między usługami w klastrach. Agregując dane przepływu z każdego klastra w sieci między klastrami, można wizualizować ruch we wschodniej części zachodu, monitorować kondycję aplikacji w różnych regionach, rozwiązywać problemy z łącznością między klastrami i analizować wzorce ruchu na potrzeby planowania pojemności.

Dzięki dziennikom sieciowym kontenerów operatorzy uzyskują ujednolicony widok komunikacji między zasobnikami niezależnie od tego, w którym klastrze znajduje się źródło lub cel, bez konieczności instrumentowania aplikacji.

Usługi globalne

Aby umożliwić przepływ ruchu między klastrami, należy skonfigurować usługi Kubernetes jako usługi globalne. W sieci obejmującej wiele klastrów usługa globalna jest standardową usługą Kubernetes udostępnioną w wielu klastrach. Gdy oznaczysz usługę jako globalną, Cilium automatycznie odnajduje punkty końcowe dla tej usługi we wszystkich klastrach w sieci między klastrami i wykonuje w nich równoważenie obciążenia.

Po oznaczeniu usługi jako globalnej wszystkie zasady stosowane w jednym klastrze są honorowane w innych klastrach w sieci między klastrami, zapewniając spójny stan zabezpieczeń. Ta konfiguracja umożliwia:

  • Transparent Service Discovery: aplikacje mogą odnajdywać usługi i korzystać z nich niezależnie od klastra, w którym się znajdują.
  • Wysoka dostępność: Jeśli usługa w jednym klastrze stanie się niedostępna, ruch zostanie automatycznie przekierowany do sprawnej instancji w innym klastrze.

Cilium zarządza tym wykrywaniem, monitorując usługi z adnotacją io.cilium/global-service: "true". W przypadku tych usług wszystkie punkty końcowe o tej samej nazwie i przestrzeni nazw w klastrach są scalane w jedną usługę globalną. Każdy ruch kierowany do ClusterIP tej usługi jest następnie równoważony między wszystkie uczestniczące klastry.

Ograniczenia

  • Klaster członkowski może uczestniczyć tylko w jednej sieci między klastrami jednocześnie.
  • Jedna sieć między klastrami obsługuje maksymalnie 255 klastrów członkowskich.
  • Konfiguracje wieloklastrowe Cilium zarządzane samodzielnie nie są obsługiwane razem z siecią międzyklastrową zarządzaną przez Fleet.
  • Polecenia CLI Cilium, które modyfikują siatkę, takie jak cilium clustermesh connect lub cilium upgrade, nie są obsługiwane, ponieważ tymi operacjami zarządza Fleet.
  • Sieć między klastrami jest ograniczona do klastrów w tej samej dostępnej domenie routingu płaskiego. Nie obsługuje łączności siatkowej między sieciami wirtualnymi niepołączonymi relacją komunikacji równorzędnej.

Następne kroki

  • Last updated on