Architektura sieci aplikacji platformy Azure Kubernetes (wersja zapoznawcza)

Architektura sieci aplikacji platformy Azure Kubernetes jest podzielona na trzy warstwy: płaszczyznę zarządzania, płaszczyznę sterowania i płaszczyznędanych. Każda warstwa ma odrębne obowiązki, które razem zapewniają w pełni zarządzane, oparte na Ambient rozwiązanie sieciowe dla usługi Azure Kubernetes Service (AKS). Ta architektura umożliwia bezpieczną komunikację opartą na zasadach między usługami bez konieczności stosowania przyczepek ani zmian w aplikacjach.

Ten artykuł zawiera omówienie warstw architektury usługi Azure Kubernetes Application Network, sposobu ich interakcji oraz modelu odnajdywania usługi z wieloma klastrami, który umożliwia skalowalną komunikację między klastrami. Aby uzyskać więcej informacji na temat usługi Azure Kubernetes Application Network, zobacz Omówienie usługi Azure Kubernetes Application Network for AKS.

Omówienie warstw architektury sieci aplikacji

Warstwy architektury zarządzają następującymi obowiązkami:

• Płaszczyzna zarządzania: obsługuje operacje zasobów platformy Azure, takie jak tworzenie, aktualizowanie i usuwanie zasobów usługi Application Network oraz zarządzanie członkostwem w klastrze.
• Płaszczyzna sterowania: zarządza konfiguracją siatki, cyklem życia certyfikatu i odnajdywaniem usług dla każdego klastra członkowskiego.
• Płaszczyzna danych: zabezpiecza ruch między usługami bezpośrednio w klastrze członkowskim przy użyciu trybu ambient, który nie wymaga żadnych sidecarów ani zmian w aplikacjach.

W przypadku wdrożeń obejmujących wiele klastrów Application Network synchronizuje informacje o odnajdowaniu usług między klastrami, dzięki czemu usługi mogą komunikować się przez granice klastrów.

Na poniższym diagramie przedstawiono warstwy architektury usługi Azure Kubernetes Application Network oraz sposób interakcji ze sobą i z klastrami usługi AKS:

Warstwa zarządzania

Płaszczyzna zarządzania to dostawca zasobów platformy Azure, który obsługuje wszystkie operacje zasobów usługi Application Network. Podczas tworzenia zasobu usługi Application Network lub dołączania do klastra członkowskiego płaszczyzna zarządzania potwierdza ważność żądania, aprowizuje zasoby pomocnicze platformy Azure, takie jak usługa Azure Key Vault dla magazynu certyfikatów, i koordynuje tworzenie regionalnej płaszczyzny sterowania dla członka.

Możesz korzystać z warstwy zarządzania za pośrednictwem interfejsu wiersza polecenia Azure (az appnet) lub interfejsu API ARM. Płaszczyzna zarządzania koordynuje całą aprowizację podrzędną, aby składniki płaszczyzny sterowania i płaszczyzny danych zostały wdrożone bez ręcznej interwencji.

Płaszczyzna sterowania

Płaszczyzna sterowania jest w pełni zarządzaną infrastrukturą działającą poza klastrem usługi AKS. Gdy klaster członkowski dołącza do sieci aplikacji, dedykowana płaszczyzna sterowania jest aprowizowana w tym samym regionie świadczenia usługi Azure co klaster członkowski, co zapewnia małe opóźnienie między składnikami sterowania i płaszczyzny danych.

Płaszczyzna sterowania zawiera następujące komponenty:

• Istiod: łączy się z serwerem interfejsu API Kubernetes klastra członkowskiego, aby odnajdywać usługi i obserwować zmiany konfiguracji. Wypycha konfigurację xDS do serwerów proxy ztunnel i waypoint w warstwie danych. W przypadku wdrożeń obejmujących wiele klastrów program Istiod łączy się również z serwerami interfejsu API Kubernetes innych klastrów członkowskich w celu uzyskania informacji o odnajdowaniu usługi, umożliwiając odnajdywanie usług między klastrami.
• Zarządzanie certyfikatami: zarządza i wymienia certyfikaty CA wspierane przez usługę Azure Key Vault. Główny urząd certyfikacji ustanawia wspólną granicę zaufania we wszystkich klastrach członkowskich, a każdy członek otrzymuje pośredni urząd certyfikacji, który wystawia certyfikaty obciążeń krótkotrwałych. Aby uzyskać więcej informacji, zobacz Omówienie zabezpieczeń usługi Azure Kubernetes Application Network.
• Zarządzanie cyklem życia: wdrażanie i aktualizowanie wszystkich składników płaszczyzny danych w klastrze członkowskim, w tym ztunnel, Istio CNI, serwery proxy waypoint oraz niestandardowe definicje zasobów (CRD). Aby uzyskać więcej informacji, zobacz Konfigurowanie uaktualnień dla członków usługi Azure Kubernetes Application Network.

Płaszczyzna danych

Płaszczyzna danych składa się ze składników wdrożonych w przestrzeni nazw klastra członkowskiego applink-system. Sieć aplikacji korzysta z trybu ambient Istio, więc do Twoich obciążeń nie są wstrzykiwane żadne sidecary.

Płaszczyzna danych zawiera następujące składniki:

• Ztunnel: serwer proxy L4 na poziomie węzła wdrożony jako DaemonSet. Usługa Ztunnel przechwytuje ruch typu service-to-service w węźle, ustanawia połączenia mTLS transparentnie i wymusza zasady autoryzacji L4.
• Serwery proxy programu Waypoint: opcjonalne serwery proxy L7 dla przestrzeni nazw, które zapewniają routing HTTP, przesunięcie ruchu, wstrzyknięcie błędów i autoryzację L7. Serwery proxy programu Waypoint są wdrażane tylko wtedy, gdy zasady L7 są skonfigurowane dla przestrzeni nazw.
• Brama wschodnio-zachodnia: obsługuje ruch między klastrami we wdrożeniach obejmujących wiele klastrów. Odpowiadasz za zapewnienie łączności sieciowej między bramami east-west w każdym klastrze członkowskim. Aby uzyskać więcej informacji, zobacz Odnajdywanie usług wieloklastrowych.
• Istio CNI: DaemonSet, który konfiguruje sieć podów do przechwytywania ruchu siatki środowiskowej.
• CrDs: niestandardowe definicje zasobów platformy Kubernetes służące do konfigurowania zasad zarządzania ruchem i zabezpieczeń.

Po wysłaniu żądania między usługami, ztunnel przechwytuje ruch, ustanawia połączenie mTLS z ztunnelem miejsca docelowego i przekazuje żądanie do docelowego serwisu. Jeśli zasady L7 są skonfigurowane, ruch jest kierowany przez serwer proxy punktu drogi przed dotarciem do miejsca docelowego. W przypadku ruchu sieciowego między klastrami, ztunnel kieruje się przez bramę wschodnio-zachodnią, aby uzyskać dostęp do obciążeń roboczych w zdalnych klastrach członkowskich.

Odkrywanie usług między klastrami

Usługa Application Network obsługuje łączenie wielu klastrów usługi AKS w ujednoliconą sieć usług. Usługi w jednym klastrze członkowskim mogą komunikować się z usługami w innych klastrach członkowskich, przy czym mTLS jest egzekwowany na całej długości granic klastrów.

W przypadku wdrożeń wieloklastrowych Istio typu open-source płaszczyzny kontrolne zwykle łączą się z serwerami API Kubernetes pozostałych klastrów w celu odkrywania usług i zmian konfiguracji. Usługa Application Network jest zgodna z podobnym modelem odnajdywania usług, w którym płaszczyzny sterowania uzyskują informacje o usłudze z klastrów członkowskich, dzięki czemu usługi mogą być odnajdywane przez granice klastra. Takie podejście umożliwia obciążeń w jednym klastrze członkowskim rozpoznawanie i komunikowanie się z usługami działającymi w innych klastrach bez konieczności wprowadzania zmian w aplikacjach. Dodanie nowego klastra członkowskiego rozszerza członkostwo siatki, aby usługi w nowym klastrze mogły zostać wykryte przez innych członków.

Ruch między klastrami przepływa przez bramy wschodnio-zachodnie wdrożone w każdym klastrze członkowskim. Jesteś odpowiedzialny za zapewnienie możliwości połączenia sieciowego między bramami east-west w klastrach członkowskich — na przykład za pośrednictwem peeringu sieci VNet, VPN lub innych rozwiązań do tworzenia połączeń. Cały ruch między klastrami jest szyfrowany za pomocą biblioteki mTLS.

Jak składniki współdziałają

Warstwa sterowania łączy się z serwerem API Kubernetes klastra podrzędnego, śledzi zmiany w usługach i konfiguracji oraz wysyła aktualizacje xDS do serwerów proxy ztunnel i waypoint. Gdy istnieje wiele elementów członkowskich, każda płaszczyzna sterowania wymienia również informacje o usłudze za pośrednictwem komunikatów zarządzanych, dzięki czemu każdy element członkowski ma spójny widok wszystkich usług w całej siatce.

Zarządzanie certyfikatami instaluje główny urząd certyfikacji przy tworzeniu zasobu sieci aplikacyjnej i wystawia pośrednie urzędy certyfikacji dla każdego członkowskiego klastra. Certyfikaty obciążenia są wystawiane z okresem ważności 24-godzinnym i obracane automatycznie co 12 godzin. Cały cykl życia certyfikatu, od korzeniowego urzędu certyfikacji poprzez certyfikaty pośrednie i certyfikaty obciążeń roboczych, jest zarządzany bez ręcznej interwencji.

Aby uzyskać pełną hierarchię certyfikatów i harmonogram rotacji, zobacz Omówienie zabezpieczeń usługi Azure Kubernetes Application Network.

Treści powiązane

Aby uzyskać więcej informacji na temat usługi Azure Kubernetes Application Network, zobacz następujące artykuły:

• Omówienie usługi Azure Kubernetes Application Network for AKS
• Obsługiwane wersje usługi Azure Kubernetes Application Network