Architektura mikrousług w usłudze Azure Kubernetes Service

Ta architektura referencyjna przedstawia aplikację mikrousług wdrożona w usłudze Azure Kubernetes Service (AKS). Opisuje podstawową konfigurację usługi AKS, której można użyć jako punktu początkowego dla większości wdrożeń. W tym artykule założono, że masz podstawową wiedzę na temat platformy Kubernetes. W tym artykule przedstawiono przede wszystkim aspekty infrastruktury i metodyki DevOps dotyczące zarządzania mikrousługami w usłudze AKS. Aby uzyskać więcej informacji na temat projektowania mikrousług, zobacz Projektowanie architektury mikrousług.

Implementacja referencyjna tej architektury jest dostępna w witrynie GitHub.

Architektura

Helm jest znakiem towarowym Cloud Native Computing Foundation (CNCF). Użycie tego znaku oznacza nie jest dorozumiane.

Pobierz plik programu Visio z tą architekturą.

Jeśli chcesz zobaczyć przykład bardziej zaawansowanej mikrousługi opartej na architekturze bazowej usługi AKS, zobacz zaawansowaną architekturę mikrousług usługi AKS.

Przepływ pracy

Ten przepływ żądań implementuje publisher-subscriber , konkurujących odbiorcówi routingu bramy wzorców projektowych chmury.

Poniższy przepływ danych odpowiada poprzedniemu diagramowi:

1. Aplikacja kliencka wysyła ładunek JSON za pośrednictwem protokołu HTTPS do publicznej w pełni kwalifikowanej nazwy domeny modułu równoważenia obciążenia (zarządzanego kontrolera ruchu przychodzącego), aby zaplanować odbiór drona.

   • Zarządzany kontroler ruchu przychodzącego kieruje żądanie do mikrousługi pozyskiwania.

   • Mikrousługa pozyskiwania przetwarza żądania i kolejkuje żądania dostarczania w kolejce usługi Azure Service Bus.

2. Mikrousługę przepływu pracy:

   • Używa informacji o komunikatach z kolejki komunikatów usługi Service Bus.

   • Wysyła żądanie HTTPS do mikrousługi dostarczania, która przekazuje dane do zewnętrznego magazynu danych w usłudze Azure Cache for Redis.

   • Wysyła żądanie HTTPS do mikrousługi harmonogramu dronów.

   • Wysyła żądanie HTTPS do mikrousługi pakietu, która przekazuje dane do zewnętrznego magazynu danych w bazie danych MongoDB.

3. Żądanie HTTPS GET zwraca stan dostawy. To żądanie przekazuje zarządzany kontroler ruchu przychodzącego do mikrousługi dostarczania. Następnie mikrousługa dostarczania odczytuje dane z usługi Azure Cache for Redis.

Aby uzyskać więcej informacji na temat przykładowej aplikacji mikrousług, zobacz przykład implementacji referencyjnej mikrousług.

Składniki

• AKS to zarządzany klaster Kubernetes hostowany w chmurze platformy Azure. Usługa AKS zmniejsza złożoność i nakłady operacyjne związane z zarządzaniem Kubernetes, odciążając dużą część tej odpowiedzialności na Azure.

• Serwer ruchu przychodzącego uwidacznia trasy HTTP do usług w klastrze. Implementacja referencyjna używa zarządzanego kontrolera ruchu przychodzącego NGINX za pomocą dodatku routingu aplikacji. Kontroler ruchu przychodzącego implementuje wzorzec bramy interfejsu API dla mikrousług.

• zewnętrzne magazyny danych, takie jak azure SQL Database lub Azure Cosmos DB, są używane przez mikrousługi bezstanowe do zapisywania danych i innych informacji o stanie. Implementacja referencyjna używa azure Cosmos DB, Azure Cache for Redis, Azure Cosmos DB for MongoDB i Service Bus jako magazyny danych lub miejsca do przechowywania stanu.

• identyfikator entra firmy Microsoft jest wymagany dla klastra usługi AKS. Udostępnia tożsamości zarządzanej używane do uzyskiwania dostępu do usługi Azure Container Registry oraz do uzyskiwania dostępu do zasobów platformy Azure, takich jak moduły równoważenia obciążenia i dyski zarządzane. Obciążenia wdrożone w klastrze usługi AKS również wymagają tożsamości w firmie Microsoft Entra w celu uzyskania dostępu do zasobów chronionych przez firmę Microsoft, takich jak Azure Key Vault i Microsoft Graph. W tej architekturze referencyjnej identyfikator obciążenia firmy Microsoft Entra integruje się z platformą Kubernetes i udostępnia obciążenia tożsamościom. Można również użyć tożsamości zarządzanych lub poświadczeń aplikacji dla każdego obciążenia.

• usługi Container Registry można używać do przechowywania prywatnych obrazów kontenerów, które są wdrażane w klastrze. Usługa AKS może uwierzytelniać się w usłudze Container Registry przy użyciu tożsamości firmy Microsoft Entra. W implementacji referencyjnej obrazy kontenerów mikrousług są kompilowane i wypychane do usługi Container Registry.

• usługa Azure Pipelines jest częścią pakietu Azure DevOps i uruchamia zautomatyzowane kompilacje, testy i wdrożenia. Podejście ciągłej integracji i ciągłego wdrażania (CI/CD) jest zdecydowanie zachęcane w środowiskach mikrousług. Różne zespoły mogą niezależnie tworzyć i wdrażać mikrousługi w usłudze AKS przy użyciu usługi Azure Pipelines.

• Helm to menedżer pakietów dla platformy Kubernetes, który udostępnia mechanizm tworzenia pakietów i standaryzacji obiektów Kubernetes w jedną jednostkę, która może zostać opublikowana, wdrożona, wersjonowana i zaktualizowana.

• usługa Azure Monitor zbiera i przechowuje metryki i dzienniki, dane telemetryczne aplikacji i metryki platformy dla usług platformy Azure. Usługa Azure Monitor integruje się z usługą AKS w celu zbierania metryk z kontrolerów, węzłów i kontenerów.

• application insights monitoruje mikrousługi i kontenery. Może służyć do zapewniania wglądu w mikrousługi, które obejmują przepływ ruchu, kompleksowe opóźnienie i procent błędów. Kondycja mikrousług i relacji między nimi może być wyświetlana na jednej mapie aplikacji.

Alternatywy

usługa Azure Container Apps zapewnia zarządzane środowisko platformy Kubernetes bezserwerowe. Jest to prostsza alternatywa dla usługi AKS do hostowania mikrousług, gdy nie potrzebujesz bezpośredniego dostępu do platformy Kubernetes ani jej interfejsów API i nie wymaga kontroli nad infrastrukturą klastra.

Zamiast zarządzanej bramy ruchu przychodzącego w usłudze AKS można użyć alternatyw, takich jak usługa Application Gateway for Containers, brama ruchu przychodzącego istio lub rozwiązania firmy innej niż Microsoft. Aby uzyskać więcej informacji, zobacz Ruchu przychodzącego w usłudze AKS.

Obrazy kontenerów można przechowywać w rejestrach kontenerów innych niż Microsoft, takich jak Docker Hub.

W przypadku mikrousług, które muszą obsługiwać informacje o stanie, języka Dapr zapewnia warstwę abstrakcji do zarządzania stanem mikrousługi.

Za pomocą funkcji GitHub Actions można tworzyć i wdrażać mikrousługi lub wybierać rozwiązania ciągłej integracji/ciągłego wdrażania firmy innej niż Microsoft, takie jak Jenkins.

Można zaobserwować mikrousługi za pomocą alternatywnych narzędzi, takich jak Kiali.

Szczegóły scenariusza

Przykład implementacji referencyjnej mikrousługi implementuje składniki architektury i praktyki opisane w tym artykule. W tym przykładzie fikcyjna firma o nazwie Fabrikam, Inc., zarządza flotą samolotów dronów. Firmy rejestrują się w usłudze, a użytkownicy mogą poprosić drona o odebranie towarów do dostawy. Gdy klient planuje odbiór, system zaplecza przypisuje drona i powiadamia użytkownika o szacowanym czasie dostawy. Gdy dostarczanie jest w toku, klient może śledzić lokalizację drona z stale aktualizowanym szacowanym czasem dostawy.

Scenariusz ma na celu zademonstrowanie architektury mikrousług i najlepszych rozwiązań dotyczących wdrażania w usłudze AKS.

Potencjalne przypadki użycia

Zastosuj następujące najlepsze rozwiązania ze scenariusza, aby utworzyć architekturę złożonych aplikacji opartych na mikrousługach w usłudze AKS:

• Złożone aplikacje internetowe
• Logika biznesowa opracowana przy użyciu zasad projektowania mikrousług

Kwestie wymagające rozważenia

Te zagadnienia implementują filary platformy Azure Well-Architected Framework, która jest zestawem wytycznych, których można użyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.

Projektowanie

Ta architektura referencyjna koncentruje się na mikrousługach, ale wiele zalecanych rozwiązań ma zastosowanie do innych obciążeń uruchamianych w usłudze AKS.

Mikrousługi

Mikrousługę jest luźno połączoną, niezależnie wdrażaną jednostką kodu. Mikrousługi zwykle komunikują się za pośrednictwem dobrze zdefiniowanych interfejsów API i są wykrywalne za pośrednictwem jakiejś formy odnajdywania usług. Obiekt usługi Kubernetes to typowy sposób modelowania mikrousług na platformie Kubernetes.

Magazyn danych

W architekturze mikrousług usługi nie powinny udostępniać rozwiązań magazynu danych. Każda usługa powinna zarządzać własnym zestawem danych, aby uniknąć ukrytych zależności między usługami. Separacja danych pomaga uniknąć przypadkowego sprzężenia między usługami. Ten proces może wystąpić, gdy usługi współdzielą te same schematy danych bazowych. Gdy usługi zarządzają własnymi magazynami danych, mogą używać odpowiedniego magazynu danych dla określonych wymagań. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące danych dotyczące mikrousług.

Unikaj przechowywania trwałych danych w magazynie klastra lokalnego, ponieważ ta metoda wiąże dane z węzłem. Zamiast tego użyj usługi zewnętrznej, takiej jak SQL Database lub Azure Cosmos DB. Inną opcją jest zainstalowanie trwałego woluminu danych w rozwiązaniu przy użyciu usługi Azure Disk Storage lub Azure Files. Aby uzyskać więcej informacji, zobacz Opcje magazynu dla aplikacji w usłudze AKS.

Brama interfejsu API

Bramy interfejsu API są ogólnym wzorcem projektowania mikrousług. Brama interfejsu API znajduje się między klientami zewnętrznymi a mikrousługami. Brama służy jako zwrotny serwer proxy i kieruje żądania od klientów do mikrousług. Brama interfejsu API może również wykonywać różne zadania krzyżowe, takie jak uwierzytelnianie, kończenie żądań protokołu SECURE Sockets Layer (SSL) i ograniczanie szybkości. Aby uzyskać więcej informacji, zobacz następujące zasoby:

• używanie bram interfejsu API w mikrousługach

• wybieranie technologii bramy interfejsu API

Na platformie Kubernetes kontroler ruchu przychodzącego obsługuje przede wszystkim funkcjonalność bramy interfejsu API. Kontroler ruchu przychodzącego i ruchu przychodzącego działa w połączeniu z:

• Kierowanie żądań klientów do poprawnych mikrousług zaplecza. Ten routing zapewnia pojedynczy punkt końcowy dla klientów i pomaga rozdzielić klientów z usług.

• Agregowanie wielu żądań w jednym żądaniu w celu zmniejszenia rozmów między klientem a zapleczem.

• Odciążanie funkcji z usług zaplecza, takich jak kończenie żądań SSL, uwierzytelnianie, ograniczenia adresów IP lub ograniczanie szybkości klienta (nazywane ograniczaniem przepustowości).

Istnieją kontrolery ruchu przychodzącego dla zwrotnych serwerów proxy, które obejmują NGINX, HAProxy, Traefik i Azure Application Gateway. Usługa AKS udostępnia wiele zarządzanych opcji ruchu przychodzącego. Możesz wybrać z zarządzanego kontrolera ruchu przychodzącego NGINX za pomocą dodatku routingu aplikacji application Gateway for Containers. Możesz też wybrać bramę ruchu przychodzącego Istio jako kontroler ruchu przychodzącego. Aby uzyskać więcej informacji, zobacz Ruchu przychodzącego w usłudze AKS.

Zasoby ruchu przychodzącego Kubernetes zostały zastąpione bardziej zaawansowanym i wszechstronnym interfejsem API bramy Kubernetes. Kontroler ruchu przychodzącego i interfejs API bramy to obiekty Kubernetes używane do routingu zarządzania ruchem i równoważenia obciążenia. Zaprojektowany jako ogólny, ekspresyjny, rozszerzalny i zorientowany na rolę, interfejs API bramy to nowoczesny zestaw interfejsów API do definiowania reguł routingu L4 i L7 na platformie Kubernetes.

Kontroler ruchu przychodzącego działa jako router brzegowy lub zwrotny serwer proxy. Zwrotny serwer proxy jest potencjalnym wąskim gardłem lub pojedynczym punktem awarii, dlatego zalecamy wdrożenie co najmniej dwóch replik w celu zapewnienia wysokiej dostępności.

Kiedy wybrać kontrolery ruchu przychodzącego lub interfejs API bramy

Zasoby ruchu przychodzącego są odpowiednie dla następujących przypadków użycia:

• Kontrolery ruchu przychodzącego są łatwe do skonfigurowania i nadają się do mniejszych i mniej złożonych wdrożeń platformy Kubernetes, które priorytetują łatwą konfigurację.

• Jeśli obecnie kontrolery ruchu przychodzącego są skonfigurowane w klastrze Kubernetes i spełniają twoje wymagania, może nie być konieczne natychmiastowe przejście do interfejsu API usługi Kubernetes Gateway.

Należy użyć interfejsu API bramy:

• W przypadku obsługi złożonych konfiguracji routingu, podziału ruchu i zaawansowanych strategii zarządzania ruchem. Elastyczność zapewniana przez zasoby tras interfejsu API bramy Kubernetes jest niezbędna.

• Jeśli wymagania dotyczące sieci wymagają niestandardowych rozwiązań lub integracji wtyczek firm innych niż Microsoft. Podejście interfejsu API bramy Kubernetes oparte na niestandardowych definicjach zasobów może zapewnić rozszerzoną rozszerzalność.

Niezawodność

Niezawodność zapewnia, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca niezawodności.

Partycjonowanie mikrousług

Użyj przestrzeni nazw, aby organizować usługi w klastrze. Każdy obiekt w klastrze Kubernetes należy do przestrzeni nazw. Dobrym rozwiązaniem jest organizowanie zasobów w klastrze przy użyciu przestrzeni nazw.

Przestrzenie nazw pomagają zapobiegać kolizjom nazewnictwa. Jeśli wiele zespołów wdraża mikrousługi w tym samym klastrze, z prawdopodobnie setkami mikrousług, trudno jest zarządzać, jeśli wszystkie przechodzą do tej samej przestrzeni nazw. Przestrzenie nazw umożliwiają również:

• Zastosuj ograniczenia zasobów do przestrzeni nazw, aby łączny zestaw zasobników przypisanych do tej przestrzeni nazw nie mógł przekroczyć limitu przydziału zasobów przestrzeni nazw.

• Stosowanie zasad na poziomie przestrzeni nazw, które obejmują kontrolę dostępu opartą na rolach (RBAC) i zasady zabezpieczeń.

Podczas tworzenia i wdrażania mikrousług przez wiele zespołów można użyć przestrzeni nazw jako wygodnego mechanizmu kontrolowania obszarów, w których każdy zespół może wdrażać. Na przykład zespół programistyczny A może mieć dostęp tylko do przestrzeni nazw A, a zespół programistyczny B może mieć dostęp tylko do przestrzeni nazw B za pośrednictwem platformy Kubernetes zasad RBAC.

W przypadku architektury mikrousług rozważ zorganizowanie mikrousług w ograniczonych kontekstach i utworzenie przestrzeni nazw dla każdego ograniczonego kontekstu. Na przykład wszystkie mikrousługi powiązane z powiązanym kontekstem "Order Fulfillment" mogą przechodzić do tej samej przestrzeni nazw. Alternatywnie utwórz przestrzeń nazw dla każdego zespołu deweloperów.

Umieść usługi narzędziowe we własnej oddzielnej przestrzeni nazw. Można na przykład wdrożyć narzędzia do monitorowania klastra, takie jak Elasticsearch i Prometheus, w przestrzeni nazw monitorowania.

Sondy kondycji

Platforma Kubernetes definiuje trzy typy sond kondycji, które mogą uwidocznić zasobnik:

• sonda gotowości: informuje platformę Kubernetes, czy zasobnik jest gotowy do akceptowania żądań.

• sonda liveness: informuje platformę Kubernetes, czy zasobnik powinien zostać usunięty i uruchomione nowe wystąpienie.

• Sonda uruchamiania: informuje platformę Kubernetes, czy zasobnik jest uruchomiony.

Podczas myślenia o sondach ważne jest, aby pamiętać, jak działa usługa na platformie Kubernetes. Usługa ma selektor etykiet, który pasuje do zestawu zera lub większej liczby zasobników. Obciążenie platformy Kubernetes równoważy ruch do zasobników pasujących do selektora. Tylko zasobniki, które są uruchamiane pomyślnie i są w dobrej kondycji odbierają ruch. Jeśli kontener ulegnie awarii, platforma Kubernetes zakończy działanie zasobnika i planuje zastąpienie.

Czasami zasobnik może nie być gotowy do odbierania ruchu, mimo że został uruchomiony pomyślnie. Na przykład w toku mogą być zadania inicjowania, takie jak gdy aplikacja uruchomiona w kontenerze ładuje dane do pamięci lub odczytuje pliki konfiguracji. Dla tych kontenerów wolno uruchamianych można użyć sondy uruchamiania. Takie podejście pomaga zapobiec zakończeniu działania platformy Kubernetes przed ich pełnym zainicjowaniem.

Sondy liveness są używane do sprawdzania, czy zasobnik jest uruchomiony, ale nie działa prawidłowo i musi zostać uruchomiony ponownie. Jeśli na przykład kontener obsługuje żądania HTTP, ale nagle przestaje odpowiadać bez awarii, sonda liveness wykrywa to zdarzenie i wyzwala ponowne uruchomienie zasobnika. Jeśli skonfigurujesz sondę aktualności, zauważysz, że kontener nie odpowiada i monituje platformę Kubernetes o ponowne uruchomienie zasobnika, jeśli kontener wielokrotnie kończy się niepowodzeniem sondy.

Podczas projektowania sond dla mikrousług należy wziąć pod uwagę następujące kwestie.

• Jeśli kod ma długi czas uruchamiania, istnieje niebezpieczeństwo, że sonda liveness zgłasza błąd przed zakończeniem uruchamiania. Aby opóźnić rozpoczęcie sondy liveness, użyj sondy uruchamiania lub użyj ustawienia initialDelaySeconds z sondą liveness.

• Sonda aktualności pomaga tylko wtedy, gdy ponowne uruchomienie zasobnika może przywrócić go do stanu dobrej kondycji. Możesz użyć sondy aktualności, aby ograniczyć przecieki pamięci lub nieoczekiwane zakleszczenia, ale nie ma powodu, aby ponownie uruchomić zasobnik, który natychmiast się nie powiedzie.

• Czasami sondy gotowości są używane do sprawdzania usług zależnych. Jeśli na przykład zasobnik ma zależność od bazy danych, sonda może sprawdzić połączenie z bazą danych. Jednak takie podejście może powodować nieoczekiwane problemy. Usługa zewnętrzna może być tymczasowo niedostępna. Ta niedostępność powoduje niepowodzenie sondy gotowości dla wszystkich zasobników w usłudze, co powoduje usunięcie ich z równoważenia obciążenia. To usunięcie powoduje tworzenie kaskadowych niepowodzeń nadrzędnych.

  Lepszym rozwiązaniem jest zaimplementowanie obsługi ponawiania prób w usłudze, aby usługa mogła prawidłowo odzyskać sprawność po przejściowych awariach. Alternatywnie obsługa ponawiania prób, tolerancja błędów i wyłączniki można zaimplementować za pomocą siatki usługi Istio w celu utworzenia odpornej architektury, która może obsługiwać błędy mikrousług.

Ograniczenia zasobów

Rywalizacja o zasoby może mieć wpływ na dostępność usługi. Zdefiniuj ograniczenia zasobów dla kontenerów, aby pojedynczy kontener nie mógł przeciążyć zasobów klastra, takich jak pamięć i procesor CPU. W przypadku zasobów innych niż kontenery, takich jak wątki lub połączenia sieciowe, rozważ użycie wzorca bulkhead w celu odizolowania zasobów.

Użyj przydziałów zasobów, aby ograniczyć łączną ilość zasobów dozwoloną dla przestrzeni nazw. To ograniczenie gwarantuje, że fronton nie może głodować usług zaplecza dla zasobów ani odwrotnie. Przydziały zasobów mogą pomóc przydzielić zasoby w tym samym klastrze do wielu zespołów deweloperskich mikrousług.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nieprawidłowym użyciem cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotyczącazabezpieczeń.

Szyfrowanie TLS i SSL

W wielu implementacjach kontroler ruchu przychodzącego jest używany do kończenia żądań SSL. W ramach wdrażania kontrolera ruchu przychodzącego należy utworzyć lub zaimportować certyfikat protokołu Transport Layer Security (TLS). Używaj tylko certyfikatów z podpisem własnym do celów programistycznych i testowych. Aby uzyskać więcej informacji, zobacz Konfigurowanie niestandardowej nazwy domeny i certyfikatu SSL przy użyciu dodatku routingu aplikacji.

W przypadku obciążeń produkcyjnych uzyskaj podpisane certyfikaty od zaufanych urzędów certyfikacji.

Może być również konieczne obracanie certyfikatów w zależności od zasad organizacji. Za pomocą usługi Key Vault można wymieniać certyfikaty używane przez mikrousługi. Aby uzyskać więcej informacji, zobacz Konfigurowanie automatycznego obracania certyfikatów w usłudze Key Vault.

RBAC

Gdy wiele zespołów opracowuje i wdraża mikrousługi jednocześnie, mechanizmy kontroli RBAC usługi AKS mogą zapewnić szczegółową kontrolę i filtrowanie akcji użytkownika. Aby kontrolować dostęp do zasobów klastra, możesz użyć kontroli dostępu opartej na rolach platformy Kubernetes lub kontroli dostępu opartej na rolach platformy Azure z identyfikatorem Entra firmy Microsoft. Aby uzyskać więcej informacji, zobacz Access and identity options for AKS.

Uwierzytelnianie i autoryzacja

Mikrousługi mogą wymagać od użytkowników korzystających usług lub uwierzytelnienia i autoryzowania dostępu do mikrousługi przy użyciu certyfikatów, poświadczeń i mechanizmów kontroli dostępu opartej na rolach. Identyfikator Entra firmy Microsoft może służyć do implementowania tokenów protokołu OAuth 2.0 na potrzeby autoryzacji. Siatki usług, takie jak Istio również zapewniają mechanizmy autoryzacji i uwierzytelniania dla mikrousług, które obejmują weryfikację tokenu OAuth i routing oparty na tokenach. Implementacja referencyjna nie obejmuje scenariuszy uwierzytelniania mikrousług i autoryzacji.

Zarządzanie wpisami tajnymi i poświadczenia aplikacji

Aplikacje i usługi często wymagają poświadczeń, które umożliwiają im łączenie się z usługami zewnętrznymi, takimi jak Azure Storage lub SQL Database. Wyzwaniem jest zapewnienie bezpieczeństwa tych poświadczeń i nie wyciek ich.

W przypadku zasobów platformy Azure użyj tożsamości zarządzanych, jeśli to możliwe. Tożsamość zarządzana jest jak unikatowy identyfikator aplikacji lub usługi przechowywanej w identyfikatorze Entra firmy Microsoft. Używa tej tożsamości do uwierzytelniania za pomocą usługi platformy Azure. Aplikacja lub usługa ma utworzoną dla niej jednostkę usługi w identyfikatorze Entra firmy Microsoft i uwierzytelnia się przy użyciu tokenów OAuth 2.0. Kod uruchomiony w ramach procesu może w sposób niewidoczny uzyskać token. Takie podejście pomaga zagwarantować, że nie trzeba przechowywać żadnych haseł ani parametrów połączenia. Aby użyć tożsamości zarządzanych, możesz przypisać tożsamości firmy Microsoft entra do poszczególnych zasobników w usłudze AKS przy użyciu identyfikator obciążenia firmy Microsoft Entra.

Nawet jeśli używasz tożsamości zarządzanych, nadal może być konieczne przechowywanie niektórych poświadczeń lub innych wpisów tajnych aplikacji. Ten magazyn jest niezbędny w przypadku usług platformy Azure, które nie obsługują tożsamości zarządzanych, usług innych niż Microsoft ani kluczy interfejsu API. Aby bezpieczniej przechowywać wpisy tajne, możesz użyć następujących opcji:

• Key Vault: w usłudze AKS można zainstalować co najmniej jeden wpis tajny z usługi Key Vault jako wolumin. Wolumin odczytuje wpisy tajne z usługi Key Vault. Zasobnik może następnie odczytywać wpisy tajne, takie jak wolumin zwykły. Aby uzyskać więcej informacji, zobacz Use the Key Vault provider for Secrets Store CSI driver in an AKS cluster. Zasobnik uwierzytelnia się przy użyciu tożsamości obciążenia lub tożsamości zarządzanej przypisanej przez system lub użytkownika. Aby uzyskać więcej informacji, zobacz Connect your Azure identity provider to the Key Vault Secrets Store CSI Driver in Azure Kubernetes Service (AKS).

• HashiCorp Vault: tożsamości zarządzane firmy Microsoft Entra umożliwiają aplikacjom Kubernetes uwierzytelnianie za pomocą usługi HashiCorp Vault. Możesz wdrożyć magazyn na platformie Kubernetes. Rozważ uruchomienie go w oddzielnym dedykowanym klastrze z klastra aplikacji.

• wpisy tajne platformy Kubernetes: Inną opcją jest użycie wpisów tajnych platformy Kubernetes. Ta opcja jest najłatwiejsza do skonfigurowania, ale najmniej bezpieczna. Wpisy tajne są przechowywane w plikach itp., co jest rozproszonym magazynem par klucz-wartość. Usługa AKS szyfruje magazynowane dane itp. Firma Microsoft zarządza kluczami szyfrowania.

Korzystanie z rozwiązania takiego jak Usługa Key Vault zapewnia kilka zalet, takich jak:

• Scentralizowana kontrola nad wpisami tajnymi.
• Pomoc w zapewnieniu, że wszystkie wpisy tajne są szyfrowane w spoczynku.
• Scentralizowane zarządzanie kluczami.
• Kontrola dostępu do wpisów tajnych.
• Zarządzanie cyklem życia klucza.
• Inspekcja.

Implementacja referencyjna przechowuje parametry połączenia usługi Azure Cosmos DB i inne wpisy tajne w usłudze Key Vault. Implementacja referencyjna używa tożsamości zarządzanej dla mikrousług do uwierzytelniania w usłudze Key Vault i uzyskiwania dostępu do wpisów tajnych.

Zabezpieczenia kontenera i koordynatora

Poniższe zalecane rozwiązania mogą pomóc w zabezpieczeniu zasobników i kontenerów.

• Monitorowanie pod kątem zagrożeń. Monitorowanie zagrożeń przy użyciu usługi Microsoft Defender for Containers lub możliwości firmy innej niż Microsoft. Jeśli hostujesz kontenery na maszynie wirtualnej, użyj usługi Microsoft Defender for Servers lub możliwości firmy innej niż Microsoft. Ponadto można zintegrować dzienniki z rozwiązania do monitorowania kontenerów w usłudze Azure Monitor w celu usługi Microsoft Sentinel lub istniejącego rozwiązania do zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM).

• Monitorowanie luk w zabezpieczeniach. Stale monitoruj obrazy i uruchomione kontenery pod kątem znanych luk w zabezpieczeniach przy użyciu usługi Microsoft Defender for Cloud lub rozwiązania innego niż Microsoft.

• Automatyzowanie stosowania poprawek obrazów. Użyj zadań usługi Azure Container Registry, funkcji usługi Container Registry, aby zautomatyzować stosowanie poprawek obrazów. Obraz kontenera jest tworzony na podstawie warstw. Warstwy podstawowe obejmują obraz systemu operacyjnego i obrazy struktury aplikacji, takie jak ASP.NET Core lub Node.js. Obrazy podstawowe są zwykle tworzone nadrzędnie od deweloperów aplikacji, a inni osoby odpowiedzialne za projekt utrzymują je. Gdy te obrazy są poprawiane w górę, ważne jest, aby zaktualizować, przetestować i ponownie wdrożyć własne obrazy, aby nie pozostawić żadnych znanych luk w zabezpieczeniach. Zadania usługi Azure Container Registry mogą pomóc zautomatyzować ten proces.

• Przechowywanie obrazów w zaufanym rejestrze prywatnym. Do przechowywania obrazów użyj zaufanego rejestru prywatnego, takiego jak Container Registry lub Docker Trusted Registry. Użyj weryfikowania elementu webhook przyjęcia na platformie Kubernetes, aby upewnić się, że zasobniki mogą pobierać tylko obrazy z zaufanego rejestru.

• Zastosuj zasadę najniższych uprawnień. Nie uruchamiaj kontenerów w trybie uprzywilejowanym. Tryb uprzywilejowany zapewnia kontenerowi dostęp do wszystkich urządzeń na hoście. Jeśli to możliwe, unikaj uruchamiania procesów jako katalogu głównego wewnątrz kontenerów. Kontenery nie zapewniają pełnej izolacji z punktu widzenia zabezpieczeń, dlatego lepiej jest uruchomić proces kontenera jako użytkownik nieuprzywilejowany.

Zagadnienia dotyczące ciągłej integracji/ciągłego wdrażania

Rozważ następujące cele niezawodnego procesu ciągłej integracji/ciągłego wdrażania dla architektury mikrousług:

• Każdy zespół może tworzyć i wdrażać usługi, które są jej właścicielami niezależnie, bez wpływu na inne zespoły lub zakłócania ich działania.

• Zanim nowa wersja usługi zostanie wdrożona w środowisku produkcyjnym, zostanie wdrożona w środowiskach programowania, testowania i Q&A na potrzeby walidacji. Bramy jakości są wymuszane na każdym etapie.

• Nową wersję usługi można wdrożyć obok poprzedniej wersji.

• Obowiązują wystarczające zasady kontroli dostępu.

• W przypadku konteneryzowanych obciążeń można ufać obrazom kontenerów wdrożonym w środowisku produkcyjnym.

Aby dowiedzieć się więcej na temat wyzwań, zobacz Ciągła integracja/ciągłe wdrażanie dla architektur mikrousług.

Użycie siatki usług, takiej jak Istio, może pomóc w procesach ciągłej integracji/ciągłego wdrażania, takich jak wdrożenia kanary, testowanie A/B mikrousług i wdrażanie etapowe z podziałami ruchu opartego na procentach.

Aby uzyskać więcej informacji na temat konkretnych zaleceń i najlepszych rozwiązań, zobacz Tworzenie potoku ciągłej integracji/ciągłego wdrażania dla mikrousług na platformie Kubernetes przy użyciu usług Azure DevOps i Helm.

Optymalizacja kosztów

Optymalizacja kosztów koncentruje się na sposobach zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dlaoptymalizacji kosztów.

Koszty możesz szacować za pomocą kalkulatora cen platformy Azure. Inne zagadnienia opisano w sekcji Cost w witrynie Microsoft Azure Well-Architected Framework.

Rozważ następujące kwestie dla niektórych usług używanych w tej architekturze.

AKS

• W warstwie bezpłatnanie ma kosztów związanych z usługą AKS we wdrażaniu, zarządzaniu i operacjach klastra Kubernetes. Płacisz tylko za wystąpienia maszyn wirtualnych, magazyn i zasoby sieciowe używane przez klaster Kubernetes.

• Rozważ użycie narzędzia do automatycznego skalowania zasobników w poziomie w celu automatycznego skalowania mikrousług w poziomie lub skalowania ich w poziomie w zależności od obciążenia.

• Skonfiguruj narzędzie do automatycznego skalowania klastra , aby skalować węzły w poziomie lub skalować je w poziomie w zależności od obciążenia.

• Rozważ użycie węzłów typu typu spot do hostowania niekrytycznych mikrousług.

• Zapoznaj się z najlepszymi rozwiązaniami dotyczącymi optymalizacji kosztów dla usługi AKS.

• Aby oszacować koszt wymaganych zasobów, użyj kalkulatora usługi AKS .

Równoważnik obciążenia Azure

Opłaty są naliczane tylko za liczbę skonfigurowanych reguł równoważenia obciążenia i ruchu wychodzącego. Reguły tłumaczenia adresów sieciowych dla ruchu przychodzącego są bezpłatne. Nie są naliczane opłaty godzinowe za usługa Load Balancer w warstwie Standardowa, gdy nie skonfigurowano żadnych reguł. Aby uzyskać więcej informacji, zobacz cennik usługi Azure Load Balancer.

Azure Pipelines

Ta architektura referencyjna używa tylko usługi Azure Pipelines. Platforma Azure udostępnia potok jako pojedynczą usługę. Dozwolone jest bezpłatne zadanie hostowane przez firmę Microsoft z 1800 minutami dla każdego miesiąca dla ciągłej integracji/ciągłego wdrażania i jedno zadanie hostowane samodzielnie z nieograniczoną liczbą minut dla każdego miesiąca. Dodatkowe zadania generują więcej kosztów. Aby uzyskać więcej informacji, zobacz cennik usług Azure DevOps Services.

Azure Monitor

W przypadku usługi Azure Monitor Log Analytics opłaty są naliczane za pozyskiwanie i przechowywanie danych. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure Monitor.

Doskonałość operacyjna

Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca doskonałości operacyjnej.

Ta architektura referencyjna obejmuje pliki Bicep na potrzeby aprowizowania zasobów w chmurze i ich zależności. Za pomocą usługi Azure Pipelines można wdrożyć te pliki Bicep i szybko skonfigurować różne środowiska, takie jak replikowanie scenariuszy produkcyjnych. Takie podejście pomaga zaoszczędzić koszty, aprowizowanie środowisk testowania obciążenia tylko wtedy, gdy jest to konieczne.

Rozważ zastosowanie kryteriów izolacji obciążenia w celu struktury pliku Bicep. Obciążenie jest zwykle definiowane jako dowolna jednostka funkcjonalności. Na przykład możesz mieć oddzielny plik Bicep dla klastra, a następnie inny plik dla usług zależnych. Usługi Azure DevOps można używać do przeprowadzania ciągłej integracji/ciągłego wdrażania z izolacją obciążenia, ponieważ każde obciążenie jest skojarzone i zarządzane przez własny zespół.

Wdrażanie tego scenariusza

Aby wdrożyć implementację referencyjną dla tej architektury, wykonaj kroki opisane w repozytorium GitHub. Aby uzyskać więcej informacji, zobacz implementację referencyjną mikrousług usługi AKS.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

• Francis SimyGotowaćh | Starszy specjalista techniczny

Inni współautorzy:

• Paolo Salvatori | Główny inżynier klienta
• Alessandro Vossa | Starszy specjalista techniczny

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

• Używanie jednostki usługi z usługą AKS
• ochrona kontenera w usłudze Defender for Cloud
• Planowanie wdrożenia usługi Defender dla serwerów
• rozwiązanie do monitorowania kontenerów w usłudze Azure Monitor
• usługi Microsoft Sentinel lub istniejącego rozwiązania SIEM
• Defender for Cloud lub rozwiązanie innej firmy niż Microsoft dostępne za pośrednictwem witryny Azure Marketplace
• Automate container image builds and maintenance with Azure Container Registry tasks (Automatyzowanie kompilacji i konserwacji obrazu kontenera za pomocą zadań usługi Azure Container Registry)

Powiązane zasoby

• Aby pracować z bardziej zaawansowanym przykładem mikrousług, zobacz Advanced AKS microservices architecture.
• Aby dowiedzieć się, jak mierzymy wydajność tej aplikacji, zobacz Scenariusz dostrajania wydajności: Transakcje biznesowe rozproszone.
• Ciągła integracja/ciągłe wdrażanie dla architektur mikrousług
• Ciągła integracja/ciągłe wdrażanie dla mikrousług na platformie Kubernetes