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óra może być punktem wyjścia dla większości wdrożeń. W tym artykule założono podstawową wiedzę na temat platformy Kubernetes. Artykuł koncentruje się głównie na zagadnieniach dotyczących infrastruktury i metodyki DevOps dotyczących uruchamiania architektury mikrousług w usłudze AKS. Aby uzyskać wskazówki dotyczące projektowania mikrousług, zobacz Tworzenie mikrousług na platformie Azure.

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

Architektura

Pobierz plik programu Visio z tą architekturą.

Jeśli wolisz zobaczyć bardziej zaawansowany przykład mikrousług oparty na architekturze punktu odniesienia usługi AKS, zobacz Zaawansowana architektura mikrousług usługi Azure Kubernetes Service (AKS)

Przepływ pracy

Niniejsza architektura zawiera następujące składniki.

Azure Kubernetes Service (AKS). Usługa AKS to zarządzany klaster Kubernetes hostowany w chmurze platformy Azure. Platforma Azure zarządza usługą interfejsu API Kubernetes i musisz zarządzać tylko węzłami agenta.

Sieć wirtualna. Domyślnie usługa AKS tworzy sieć wirtualną, z którą są połączone węzły agenta. Sieć wirtualną można utworzyć najpierw w bardziej zaawansowanych scenariuszach, co pozwala kontrolować takie elementy jak konfiguracja podsieci, łączność lokalna i adresowanie IP. Aby uzyskać więcej informacji, zobacz Konfigurowanie zaawansowanej sieci w usłudze Azure Kubernetes Service (AKS).

Ruch przychodzący. Serwer ruchu przychodzącego uwidacznia trasy HTTP(S) do usług wewnątrz klastra. Aby uzyskać więcej informacji, zobacz sekcję API Gateway poniżej.

Azure Load Balancer. Po utworzeniu klastra usługi AKS klaster jest gotowy do korzystania z modułu równoważenia obciążenia. Następnie po wdrożeniu usługi NGINX moduł równoważenia obciążenia zostanie skonfigurowany przy użyciu nowego publicznego adresu IP, który będzie frontonem kontrolera ruchu przychodzącego. W ten sposób moduł równoważenia obciążenia kieruje ruch internetowy do ruchu przychodzącego.

Zewnętrzne magazyny danych. Mikrousługi są zwykle bezstanowe i zapisują stan w zewnętrznych magazynach danych, takich jak usługa Azure SQL Database lub Azure Cosmos DB.

Microsoft Entra ID. Usługa AKS używa tożsamości firmy Microsoft Entra do tworzenia innych zasobów platformy Azure, takich jak moduły równoważenia obciążenia platformy Azure i zarządzania nimi. Identyfikator Entra firmy Microsoft jest również zalecany do uwierzytelniania użytkowników w aplikacjach klienckich.

Azure Container Registry. Usługa Container Registry umożliwia przechowywanie prywatnych obrazów platformy Docker wdrożonych w klastrze. Usługa AKS może uwierzytelniać się w usłudze Container Registry przy użyciu tożsamości firmy Microsoft Entra. Usługa AKS nie wymaga usługi Azure Container Registry. Możesz użyć innych rejestrów kontenerów, takich jak Docker Hub. Upewnij się, że rejestr kontenerów jest zgodny lub przekracza umowę dotyczącą poziomu usług (SLA) dla obciążenia.

Azure Pipelines. Usługa Azure Pipelines jest częścią usług Azure DevOps Services i uruchamia zautomatyzowane kompilacje, testy i wdrożenia. Możesz również użyć rozwiązań ciągłej integracji/ciągłego wdrażania innych firm, takich jak Jenkins.

Helm. Helm to menedżer pakietów dla platformy Kubernetes, który umożliwia łączenie i uogólnianie obiektów Kubernetes w jedną jednostkę, którą można publikować, wdrażać, wersjonować i aktualizować.

Azure Monitor. Usługa Azure Monitor zbiera i przechowuje metryki i dzienniki, dane telemetryczne aplikacji i metryki platformy dla usług platformy Azure. Te dane służą do monitorowania aplikacji, konfigurowania alertów, pulpitów nawigacyjnych i przeprowadzania analizy głównej przyczyny awarii. Usługa Azure Monitor integruje się z usługą AKS w celu zbierania metryk z kontrolerów, węzłów i kontenerów.

Kwestie wymagające rozważenia

Projektowanie

Ta architektura referencyjna koncentruje się na architekturach mikrousług, chociaż wiele zalecanych rozwiązań ma zastosowanie do innych obciążeń działających 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. Usługa powinna być zawsze osiągalna nawet wtedy, gdy zasobniki się przemieszczają. Obiekt usługi Kubernetes Service to naturalny sposób modelowania mikrousług na platformie Kubernetes.

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. Działa jako zwrotny serwer proxy, rozsyłanie żądań od klientów do mikrousług. Może również wykonywać różne zadania krzyżowe, takie jak uwierzytelnianie, kończenie żądań SSL i ograniczanie szybkości. Aby uzyskać więcej informacji, zobacz:

• Korzystanie z bram interfejsu API w mikrousługach
• Wybieranie technologii bramy

Na platformie Kubernetes funkcjonalność bramy interfejsu API jest obsługiwana głównie przez kontroler ruchu przychodzącego. Zagadnienia zostały opisane w sekcji Ruch przychodzący .

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, które mogą wystąpić, gdy usługi współdzielą te same schematy danych bazowych. Ponadto gdy usługi zarządzają własnymi magazynami danych, mogą używać odpowiedniego magazynu danych dla swoich konkretnych wymagań.

Aby uzyskać więcej informacji, zobacz Projektowanie mikrousług: zagadnienia dotyczące danych.

Unikaj przechowywania trwałych danych w magazynie klastra lokalnego, ponieważ wiąże to dane z węzłem. Zamiast tego użyj usługi zewnętrznej, takiej jak Azure SQL Database lub Azure Cosmos DB. Inną opcją jest zainstalowanie trwałego woluminu danych w rozwiązaniu przy użyciu usługi Azure Disks lub Azure Files.

Aby uzyskać więcej informacji, zobacz Opcje magazynu dla aplikacji w usłudze Azure Kubernetes Service.

Przedmiot serwisu

Obiekt usługi Kubernetes Service udostępnia zestaw funkcji, które są zgodne z wymaganiami mikrousług dotyczącymi odnajdywania usługi:

• Adres IP. Obiekt usługi udostępnia statyczny wewnętrzny adres IP dla grupy zasobników (ReplicaSet). W miarę tworzenia lub przenoszenia zasobników usługa jest zawsze osiągalna pod tym wewnętrznym adresem IP.

• Równoważenie obciążenia. Ruch wysyłany do adresu IP usługi jest zrównoważony dla zasobników.

• Odnajdywanie usługi. Usługi są przypisywane wewnętrznych wpisów DNS przez usługę DNS Kubernetes. Oznacza to, że brama interfejsu API może wywołać usługę zaplecza przy użyciu nazwy DNS. Ten sam mechanizm może służyć do komunikacji między usługami. Wpisy DNS są zorganizowane według przestrzeni nazw, więc jeśli przestrzenie nazw odpowiadają powiązanym kontekstom, nazwa DNS usługi będzie mapowana naturalnie na domenę aplikacji.

Na poniższym diagramie przedstawiono koncepcyjną relację między usługami i zasobnikami. Rzeczywiste mapowanie adresów IP i portów punktu końcowego odbywa się za pomocą serwera proxy kube-proxy, serwera proxy sieci Kubernetes.

Ruch przychodzący

Na platformie Kubernetes kontroler ruchu przychodzącego może zaimplementować wzorzec bramy interfejsu API. W takim przypadku kontroler ruchu przychodzącego i ruchu przychodzącego działa w połączeniu, aby zapewnić następujące funkcje:

• Kierowanie żądań klientów do odpowiednich usł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 (ograniczanie przepustowości).

Ruch przychodzący abstrahuje ustawienia konfiguracji serwera proxy. Potrzebny jest również kontroler ruchu przychodzącego, który zapewnia podstawową implementację ruchu przychodzącego. Istnieją między innymi kontrolery ruchu przychodzącego dla serwerów Nginx, HAProxy, Traefik i aplikacja systemu Azure Gateway.

Zasób ruchu przychodzącego może być spełniony przez różne technologie. Aby współpracować, należy je wdrożyć jako kontroler ruchu przychodzącego w klastrze. Działa jako router brzegowy lub zwrotny serwer proxy. Zwrotny serwer proxy jest potencjalnym wąskim gardłem lub pojedynczym punktem awarii, więc zawsze wdrażaj co najmniej dwie repliki w celu zapewnienia wysokiej dostępności.

Często konfigurowanie serwera proxy wymaga złożonych plików, co może być trudne do dostosowania, jeśli nie jesteś ekspertem. Dlatego kontroler ruchu przychodzącego zapewnia miłą abstrakcję. Kontroler ruchu przychodzącego ma również dostęp do interfejsu API kubernetes, dzięki czemu może podejmować inteligentne decyzje dotyczące routingu i równoważenia obciążenia. Na przykład kontroler ruchu przychodzącego Nginx pomija serwer proxy sieci kube-proxy.

Z drugiej strony, jeśli potrzebujesz pełnej kontroli nad ustawieniami, możesz pominąć tę abstrakcję i ręcznie skonfigurować serwer proxy. Aby uzyskać więcej informacji, zobacz Deploying Nginx or HAProxy to Kubernetes (Wdrażanie serwera Nginx lub haProxy na platformie Kubernetes).

Aby uzyskać informacje na temat usług równoważenia obciążenia na platformie Azure, zobacz Omówienie opcji równoważenia obciążenia na platformie Azure.

Szyfrowanie TLS/SSL

W typowych implementacjach kontroler ruchu przychodzącego jest używany do kończenia żądań SSL. Dlatego w ramach wdrażania kontrolera ruchu przychodzącego należy utworzyć certyfikat TLS. Do celów tworzenia i testowania używaj tylko certyfikatów z podpisem własnym. Aby uzyskać więcej informacji, zobacz Tworzenie kontrolera ruchu przychodzącego HTTPS i używanie własnych certyfikatów TLS w usłudze Azure Kubernetes Service (AKS).

W przypadku obciążeń produkcyjnych uzyskaj podpisane certyfikaty od zaufanych urzędów certyfikacji. Aby uzyskać informacje na temat generowania i konfigurowania certyfikatów Let's Encrypt, zobacz Tworzenie kontrolera ruchu przychodzącego ze statycznym publicznym adresem IP w usłudze Azure Kubernetes Service (AKS).

Może być również konieczne obracanie certyfikatów zgodnie z zasadami organizacji. Aby uzyskać informacje, zobacz Rotacja certyfikatów w usłudze Azure Kubernetes Service (AKS).

Przestrzenie nazw

Użyj przestrzeni nazw, aby organizować usługi w klastrze. Każdy obiekt w klastrze Kubernetes należy do przestrzeni nazw. Domyślnie podczas tworzenia nowego obiektu przechodzi do default przestrzeni nazw. Dobrym rozwiązaniem jest jednak utworzenie przestrzeni nazw, które są bardziej opisowe, aby ułatwić organizowanie zasobów w klastrze.

Po pierwsze, 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. Ponadto przestrzenie nazw umożliwiają:

• 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, w tym kontroli dostępu opartej na rolach i zasad zabezpieczeń.

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ć usługę Elasticsearch lub Prometheus na potrzeby monitorowania klastra lub Tiller dla programu Helm.

Sondy kondycji

Platforma Kubernetes definiuje dwa typy sond kondycji, które może 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, a nowe wystąpienie zostało uruchomione.

Podczas myślenia o sondach warto przypomnieć sobie, jak działa usługa na platformie Kubernetes. Usługa ma selektor etykiet, który pasuje do zestawu (zero lub więcej) zasobników. Obciążenie platformy Kubernetes równoważy ruch do zasobników pasujących do selektora. Tylko zasobniki, które zostały uruchomione pomyślnie i są w dobrej kondycji odbierają ruch. Jeśli kontener ulegnie awarii, platforma Kubernetes zabije zasobnik i zaplanuje zastąpienie.

Czasami zasobnik może nie być gotowy do odbierania ruchu, mimo że zasobnik został uruchomiony pomyślnie. Na przykład mogą istnieć zadania inicjowania, w których aplikacja uruchomiona w kontenerze ładuje elementy do pamięci lub odczytuje dane konfiguracji. Aby wskazać, że zasobnik jest w dobrej kondycji, ale nie jest gotowy do odbierania ruchu, zdefiniuj sondę gotowości.

Sondy liveness obsługują przypadek, w którym zasobnik jest nadal uruchomiony, ale jest w złej kondycji i powinien zostać poddany recyklingu. Załóżmy na przykład, że kontener obsługuje żądania HTTP, ale zawiesza się z jakiegoś powodu. Kontener nie ulega awarii, ale przestał obsługiwać wszystkie żądania. Jeśli zdefiniujesz sondę liveness PROTOKOŁU HTTP, sonda przestanie odpowiadać i informuje platformę Kubernetes o ponownym uruchomieniu zasobnika.

Poniżej przedstawiono niektóre zagadnienia dotyczące projektowania sond:

• Jeśli kod ma długi czas uruchamiania, istnieje niebezpieczeństwo, że sonda liveness zgłosi błąd przed zakończeniem uruchamiania. Aby zapobiec awarii sondy, użyj initialDelaySeconds ustawienia, które opóźnia uruchamianie sondy.

• Sonda aktualności nie pomaga, chyba że ponowne uruchomienie zasobnika może przywrócić go do stanu dobrej kondycji. Można użyć sondy aktualności, aby zapobiec wyciekom pamięci lub nieoczekiwanym zakleszczeniom, ale nie ma sensu ponownego uruchamiania zasobnika, 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. Z jakiegoś powodu usługa zewnętrzna może być tymczasowo niedostępna. Spowoduje to niepowodzenie sondy gotowości dla wszystkich zasobników w usłudze, co spowoduje usunięcie wszystkich z nich z równoważenia obciążenia, a tym samym utworzenie kaskadowych błędów nadrzędnych. Lepszym rozwiązaniem jest zaimplementowanie obsługi ponawiania prób w usłudze, dzięki czemu usługa może prawidłowo odzyskać sprawność po przejściowych awariach.

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 (pamięci i procesora CPU). W przypadku zasobów innych niż kontenery, takich jak wątki lub połączenia sieciowe, rozważ użycie wzorca bulkhead do izolowania zasobów.

Użyj przydziałów zasobów, aby ograniczyć łączną ilość zasobów dozwoloną dla przestrzeni nazw. W ten sposób fronton nie może głodować usług zaplecza dla zasobów ani odwrotnie.

Zabezpieczenia

Kontrola dostępu oparta na rolach (RBAC)

Platforma Kubernetes i platforma Azure mają mechanizmy kontroli dostępu opartej na rolach (RBAC):

• Kontrola dostępu oparta na rolach platformy Azure kontroluje dostęp do zasobów na platformie Azure, w tym możliwość tworzenia nowych zasobów platformy Azure. Uprawnienia można przypisać do użytkowników, grup lub jednostek usługi. (Jednostka usługi to tożsamość zabezpieczeń używana przez aplikacje).

• Kontrola dostępu oparta na rolach platformy Kubernetes kontroluje uprawnienia do interfejsu API platformy Kubernetes. Na przykład tworzenie zasobników i wyświetlanie listy zasobników to akcje, które można autoryzować (lub odmówić) użytkownikowi za pośrednictwem kontroli dostępu opartej na rolach platformy Kubernetes. Aby przypisać uprawnienia platformy Kubernetes do użytkowników, należy utworzyć role i powiązania ról:

  • Rola to zestaw uprawnień, które mają zastosowanie w przestrzeni nazw. Uprawnienia są definiowane jako czasowniki (pobieranie, aktualizowanie, tworzenie, usuwanie) zasobów (zasobników, wdrożeń itd.).

  • Powiązanie ról przypisuje użytkowników lub grupy do roli.

  • Istnieje również obiekt ClusterRole, który jest jak rola, ale ma zastosowanie do całego klastra we wszystkich przestrzeniach nazw. Aby przypisać użytkowników lub grupy do elementu ClusterRole, utwórz klasterRoleBinding.

Usługa AKS integruje te dwa mechanizmy kontroli dostępu opartej na rolach. Podczas tworzenia klastra usługi AKS można skonfigurować go do używania identyfikatora Entra firmy Microsoft na potrzeby uwierzytelniania użytkownika. Aby uzyskać szczegółowe informacje na temat sposobu konfigurowania tego rozwiązania, zobacz Integrowanie identyfikatora entra firmy Microsoft z usługą Azure Kubernetes Service.

Po skonfigurowaniu tego ustawienia użytkownik, który chce uzyskać dostęp do interfejsu API Kubernetes (na przykład za pomocą narzędzia kubectl), musi zalogować się przy użyciu poświadczeń usługi Microsoft Entra.

Domyślnie użytkownik firmy Microsoft Entra nie ma dostępu do klastra. Aby udzielić dostępu, administrator klastra tworzy roleBindings odwołujące się do użytkowników lub grup firmy Microsoft Entra. Jeśli użytkownik nie ma uprawnień do określonej operacji, zakończy się niepowodzeniem.

Jeśli użytkownicy domyślnie nie mają dostępu, jak administrator klastra ma uprawnienia do tworzenia powiązań ról w pierwszej kolejności? Klaster usługi AKS ma dwa typy poświadczeń do wywoływania serwera interfejsu API Kubernetes: użytkownika klastra i administratora klastra. Poświadczenia administratora klastra zapewniają pełny dostęp do klastra. Polecenie az aks get-credentials --admin interfejsu wiersza polecenia platformy Azure pobiera poświadczenia administratora klastra i zapisuje je w pliku kubeconfig. Administrator klastra może użyć tego narzędzia kubeconfig do tworzenia ról i powiązań ról.

Zamiast zarządzać obiektami Role i RoleBinding klastra Kubernetes natywnie w usłudze Kubernetes, preferowane jest użycie kontroli dostępu opartej na rolach platformy Azure na potrzeby autoryzacji kubernetes. Umożliwia to ujednolicone zarządzanie i kontrolę dostępu między zasobami platformy Azure, usługą AKS i zasobami kubernetes. Te przypisania ról RBAC platformy Azure mogą być przeznaczone dla klastra lub przestrzeni nazw w klastrze w celu uzyskania bardziej szczegółowej kontroli dostępu. Kontrola dostępu oparta na rolach platformy Azure obsługuje ograniczony zestaw uprawnień domyślnych i można połączyć ją z natywnym mechanizmem Kubernetes zarządzania rolami i funkcjami RoleBinding w celu obsługi zaawansowanych lub bardziej szczegółowych wzorców dostępu. Po włączeniu tej opcji podmioty zabezpieczeń firmy Microsoft będą weryfikowane wyłącznie przez kontrolę dostępu opartą na rolach platformy Azure, podczas gdy regularni użytkownicy i konta usługi Kubernetes są wyłącznie weryfikowane przez kontrolę dostępu opartą na rolach platformy Kubernetes.

Ponieważ poświadczenia administratora klastra są tak zaawansowane, użyj kontroli dostępu opartej na rolach platformy Azure, aby ograniczyć do nich dostęp:

• Uprawnienie "Rola administratora klastra usługi Azure Kubernetes Service" ma uprawnienia do pobierania poświadczeń administratora klastra. Do tej roli należy przypisać tylko administratorów klastra.

• Rola użytkownika klastra usługi Azure Kubernetes Service ma uprawnienia do pobierania poświadczeń użytkownika klastra. Do tej roli można przypisać użytkowników niebędących administratorami. Ta rola nie daje żadnych konkretnych uprawnień do zasobów Kubernetes wewnątrz klastra — umożliwia użytkownikowi łączenie się z serwerem interfejsu API.

Podczas definiowania zasad RBAC (zarówno kubernetes, jak i platformy Azure) należy zastanowić się nad rolami w organizacji:

• Kto może utworzyć lub usunąć klaster usługi AKS i pobrać poświadczenia administratora?
• Kto może administrować klastrem?
• Kto może tworzyć lub aktualizować zasoby w przestrzeni nazw?

Dobrym rozwiązaniem jest określenie zakresu uprawnień RBAC platformy Kubernetes według przestrzeni nazw, przy użyciu ról i elementów RoleBindings, a nie klasterRoleBindings.

Na koniec istnieje pytanie, jakie uprawnienia musi mieć klaster usługi AKS do tworzenia zasobów platformy Azure i zarządzania nimi, takich jak moduły równoważenia obciążenia, sieć lub magazyn. Aby uwierzytelnić się za pomocą interfejsów API platformy Azure, klaster używa jednostki usługi Microsoft Entra. Jeśli nie określisz jednostki usługi podczas tworzenia klastra, zostanie ona utworzona automatycznie. Jednak dobrym rozwiązaniem jest utworzenie jednostki usługi i przypisanie do niej minimalnych uprawnień RBAC. Aby uzyskać więcej informacji, zobacz Service principals with Azure Kubernetes Service (Jednostki usługi w usłudze Azure Kubernetes Service).

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 jedną z opcji jest użycie tożsamości zarządzanych. Ideą tożsamości zarządzanej jest to, że aplikacja lub usługa ma tożsamość przechowywaną w identyfikatorze Entra firmy Microsoft i używa tej tożsamości do uwierzytelniania za pomocą usługi platformy Azure. Aplikacja lub usługa ma utworzoną jednostkę usługi w identyfikatorze Entra firmy Microsoft i uwierzytelnia się przy użyciu tokenów OAuth 2.0. Kod wykonujący proces może w sposób niewidoczny uzyskać token do użycia. W ten sposób nie trzeba przechowywać żadnych haseł ani parametry połączenia. Tożsamości zarządzane w usłudze AKS można używać, przypisując tożsamości firmy Microsoft entra do poszczególnych zasobników przy użyciu Tożsamość obciążeń Microsoft Entra (wersja zapoznawcza).

Obecnie nie wszystkie usługi platformy Azure obsługują uwierzytelnianie przy użyciu tożsamości zarządzanych. Aby uzyskać listę, zobacz Usługi platformy Azure, które obsługują uwierzytelnianie firmy Microsoft Entra.

Nawet w przypadku tożsamości zarządzanych prawdopodobnie trzeba będzie przechowywać niektóre poświadczenia lub inne wpisy tajne aplikacji, niezależnie od tego, czy w przypadku usług platformy Azure, które nie obsługują tożsamości zarządzanych, usług innych firm, kluczy interfejsu API itd. Poniżej przedstawiono kilka opcji bezpiecznego przechowywania wpisów tajnych:

• Azure 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 tak jak zwykły wolumin. Aby uzyskać więcej informacji, zobacz Use the Azure Key Vault Provider for Secrets Store CSI Driver in an AKS cluster (Używanie dostawcy usługi Azure Key Vault dla sterownika CSI magazynu wpisów tajnych w klastrze usługi AKS).

  Zasobnik uwierzytelnia się przy użyciu tożsamości obciążenia lub przy użyciu tożsamości zarządzanej przypisanej przez użytkownika lub system. Aby uzyskać więcej informacji, zobacz Zapewnianie tożsamości w celu uzyskania dostępu do dostawcy usługi Azure Key Vault dla sterownika CSI magazynu wpisów tajnych.

• HashiCorp Vault. Aplikacje Kubernetes mogą uwierzytelniać się za pomocą usługi HashiCorp Vault przy użyciu tożsamości zarządzanych firmy Microsoft Entra. Zobacz HashiCorp Vault mówi o identyfikatorze Entra firmy Microsoft. Magazyn można wdrożyć na platformie Kubernetes. Rozważ uruchomienie go w osobnym dedykowanym klastrze z klastra aplikacji.

• Wpisy tajne platformy Kubernetes. Inną opcją jest po prostu użycie wpisów tajnych platformy Kubernetes. Ta opcja jest najłatwiejsza do skonfigurowania, ale ma pewne wyzwania. 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 systemu takiego jak HashiCorp Vault lub Azure Key Vault zapewnia kilka zalet, takich jak:

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

Zabezpieczenia kontenera i programu Orchestrator

Są to zalecane rozwiązania dotyczące zabezpieczania zasobników i kontenerów:

• Monitorowanie zagrożeń: monitorowanie zagrożeń przy użyciu usługi Microsoft Defender for Containers (lub możliwości innych firm). Jeśli hostujesz kontenery na maszynie wirtualnej, użyj usługi Microsoft Defender dla serwerów lub możliwości innych firm. Ponadto można zintegrować dzienniki z rozwiązania do monitorowania kontenerów w usłudze Azure Monitor do usługi Microsoft Sentinel lub istniejącego rozwiązania SIEM.

• Monitorowanie luk w zabezpieczeniach: ciągłe monitorowanie obrazów i uruchamianie kontenerów pod kątem znanych luk w zabezpieczeniach przy użyciu Microsoft Defender dla Chmury lub rozwiązania innej firmy dostępnego w witrynie Azure Marketplace.

• Automatyzowanie stosowania poprawek obrazów przy użyciu usługi ACR Tasks— funkcji usługi Azure Container Registry. 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 i są obsługiwane przez innych opiekunów projektów. 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. Usługa ACR Tasks może pomóc zautomatyzować ten proces.

• Przechowuj obrazy w zaufanym rejestrze prywatnym, takim jak Usługa Azure Container Registry lub Zaufany rejestr platformy Docker. Użyj weryfikowania elementu webhook przyjęcia na platformie Kubernetes, aby upewnić się, że zasobniki mogą ściągać obrazy tylko z zaufanego rejestru.

• Stosowanie zasady 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 niebędący uprzywilejowanym.

DevOps

Ta architektura referencyjna udostępnia szablon usługi Azure Resource Manager do aprowizowania zasobów w chmurze i jego zależności. Korzystając z [szablonów usługi Azure Resource Manager][arm-template], możesz użyć usługi Azure DevOps Services do aprowizowania różnych środowisk w ciągu kilku minut, na przykład w celu replikowania scenariuszy produkcyjnych. Dzięki temu można zaoszczędzić koszty i aprowizować środowisko testowania obciążenia tylko wtedy, gdy jest to konieczne.

Rozważ zastosowanie kryteriów izolacji obciążenia w celu struktury szablonu usługi ARM, obciążenie jest zwykle definiowane jako dowolna jednostka funkcjonalności; Możesz na przykład mieć oddzielny szablon dla klastra, a następnie inny dla usług zależnych. Izolacja obciążenia umożliwia metodyce DevOps wykonywanie ciągłej integracji i ciągłego dostarczania (CI/CD), ponieważ każde obciążenie jest skojarzone i zarządzane przez odpowiedni zespół DevOps.

Zagadnienia dotyczące wdrażania (CI/CD)

Poniżej przedstawiono kilka celów 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 tworzenia i testowania/kontroli jakości 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.

Aby uzyskać szczegółowe zalecenia i najlepsze rozwiązania, zobacz Ciągła integracja/ciągłe wdrażanie dla mikrousług na platformie Kubernetes.

Optymalizacja kosztów

Koszty możesz szacować za pomocą kalkulatora cen platformy Azure. Inne zagadnienia zostały opisane w sekcji Koszt w witrynie Microsoft Azure Well-Architected Framework.

Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę w przypadku niektórych usług używanych w tej architekturze.

Azure Kubernetes Service (AKS)

Usługa AKS nie wiąże się z kosztami wdrażania, zarządzania i operacji klastra Kubernetes. Płacisz tylko za wystąpienia maszyn wirtualnych, magazyn i zasoby sieciowe używane przez klaster Kubernetes.

Aby oszacować koszt wymaganych zasobów, użyj kalkulatora usług kontenerów.

Azure Load Balancer

Opłaty są naliczane tylko za liczbę skonfigurowanych reguł równoważenia obciążenia i ruchu wychodzącego. Reguły NAT 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 oferuje usługę Azure Pipeline jako pojedynczą usługę. Dozwolone jest bezpłatne zadanie hostowane przez firmę Microsoft z 1800 minut miesięcznie w przypadku ciągłej integracji/ciągłego wdrażania i jedno zadanie hostowane samodzielnie z nieograniczonymi minutami miesięcznie, dodatkowe zadania mają opłaty. 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.

Wdrażanie tego scenariusza

Aby wdrożyć implementację referencyjną dla tej architektury, wykonaj kroki opisane w repozytorium GitHub.

Następne kroki

• Jednostki usługi w usłudze Azure Kubernetes Service
• Usługa Microsoft Defender dla kontenerów
• Usługa Microsoft Defender dla serwerów
• Rozwiązanie do monitorowania kontenerów w usłudze Azure Monitor
• Microsoft Sentinel lub istniejące rozwiązanie SIEM.
• Microsoft Defender dla Chmury lub rozwiązanie innej firmy dostępne za pośrednictwem witryny Azure Marketplace.
• Zadania usługi ACR

Powiązane zasoby

• Aby pracować z bardziej zaawansowanym przykładem mikrousług, zobacz Zaawansowana architektura mikrousług usługi Azure Kubernetes Service (AKS)
• 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