Architektura mikrousług w Azure Kubernetes Service

Azure Active Directory
Container Registry
Kubernetes Service
Load Balancer
Pipelines

Ta architektura referencyjna przedstawia aplikację mikrousług wdrożonych w usłudze Azure Kubernetes Service (AKS). Opisano w nim podstawową konfigurację usługi AKS, która może być punktem wyjścia dla większości wdrożeń. W tym artykule przyjęto założenie, że podstawowa wiedza na temat platformy Kubernetes. Ten artykuł koncentruje się głównie na zagadnieniach dotyczących infrastruktury i metodyki DevOps związanych z uruchamianiem architektury mikrousług w usłudze AKS. Aby uzyskać wskazówki dotyczące projektowania mikrousług, zobacz Tworzenie mikrousług na platformie Azure.

Logo usługi GitHub Implementacja referencyjna tej architektury jest dostępna w usłudze GitHub.

Architektura

Diagram przedstawiający architekturę referencyjną usługi AKS.

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 Architektura mikrousług advanced 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 wystarczy zarządzać węzłami agenta.

Sieć wirtualna. Domyślnie usługa AKS tworzy sieć wirtualną, z którą są połączone węzły agenta. Możesz najpierw utworzyć sieć wirtualną dla bardziej zaawansowanych scenariuszy, 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 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 frontonu 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 Azure SQL Database lub Azure Cosmos DB.

Azure Active Directory. Usługa AKS używa tożsamości usługi Azure Active Directory (Azure AD) do tworzenia innych zasobów platformy Azure, takich jak moduły równoważenia obciążenia platformy Azure i zarządzania nimi. Azure AD zaleca się również uwierzytelnianie użytkowników w aplikacjach klienckich.

Azure Container Registry. Usługa Container Registry służy do przechowywania prywatnych obrazów platformy Docker, 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 Azure AD. Usługa AKS nie wymaga 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ą 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 błędów. Usługa Azure Monitor integruje się z usługą AKS w celu zbierania metryk z kontrolerów, węzłów i kontenerów.

Zagadnienia do rozważenia

Projekt

Ta architektura referencyjna koncentruje się na architekturach mikrousług, chociaż wiele zalecanych rozwiązań ma zastosowanie do innych obciążeń uruchomionych 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, routing żą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:

W usłudze 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 podstawowe schematy danych. 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 należy użyć 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 Azure Kubernetes Service.

Obiekt usługi

Obiekt usługi Kubernetes Service udostępnia zestaw funkcji, które spełniają wymagania mikrousług dotyczące możliwości odnajdywania usług:

  • Adres IP. Obiekt Usługi udostępnia statyczny wewnętrzny adres IP dla grupy zasobników (ReplicaSet). Gdy zasobniki są tworzone lub przenoszone, usługa jest zawsze dostępna pod tym wewnętrznym adresem IP.

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

  • Odnajdywanie usług. 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ę przez serwer proxy kube-proxy — serwer proxy sieci Kubernetes.

Diagram przedstawiający usługi i zasobniki.

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ń do jednego żądania w celu zmniejszenia liczby 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 stanowi abstrakcję ustawień 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 Nginx, HAProxy, Traefik i Azure Application Gateway.

Zasób ruchu przychodzącego może być spełniony przez różne technologie. Aby współpracować, należy wdrożyć je 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, dlatego 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 ładną 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 w usłudze Kubernetes).

W przypadku usługi AKS można również użyć Azure Application Gateway, używając kontrolera ruchu przychodzącego Application Gateway (AGIC). Azure Application Gateway może wykonywać routing warstwy 7 i kończenie żądań SSL. Ma również wbudowaną obsługę zapory aplikacji internetowej (WAF). Jeśli klaster usługi AKS korzysta z sieci CNI, Application Gateway można wdrożyć w podsieci sieci wirtualnej klastra lub można je wdrożyć w innej sieci wirtualnej z sieci wirtualnej usługi AKS, jednak dwie sieci wirtualne muszą być połączone za pomocą komunikacji równorzędnej. Program AGIC obsługuje również wtyczkę sieci Kubenet. W przypadku korzystania z trybu Kubenet kontroler ruchu przychodzącego musi zarządzać tabelą tras w podsieci Application Gateway w celu kierowania ruchu do adresów IP zasobników. Aby uzyskać więcej informacji, zobacz How to setup networking between Application Gateway and AKS (Jak skonfigurować sieć między Application Gateway i usługą AKS).

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 Create an HTTPS ingress controller and use your own TLS certificates on Azure Kubernetes Service (AKS) (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 Create an ingress controller with a static public IP address in Azure Kubernetes Service (AKS) (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 Obracanie certyfikatów w 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 on 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.

Najpierw przestrzenie nazw pomagają zapobiegać kolizjom nazewnictwa. Gdy wiele zespołów wdraża mikrousługi w tym samym klastrze, z prawdopodobnie setkami mikrousług, trudno 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, biorąc pod uwagę organizowanie mikrousług w ograniczonych kontekstach i tworzenie przestrzeni nazw dla każdego ograniczonego kontekstu. Na przykład wszystkie mikrousługi powiązane z powiązanym kontekstem "Order Fulfillment" mogą przejść 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 sondy 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 o tym, czy zasobnik powinien zostać usunięty, a nowe wystąpienie zostało uruchomione.

Podczas myślenia o sondach warto przypomnieć, jak działa usługa na platformie Kubernetes. Usługa ma selektor etykiet zgodny z zestawem (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 HTTP, sonda przestanie odpowiadać i informuje platformę Kubernetes o ponownym uruchomieniu zasobnika.

Oto kilka zagadnień związanych z projektowaniem sond:

  • Jeśli kod ma długi czas uruchamiania, istnieje zagrożenie, że sonda liveness zgłosi niepowodzenie przed ukończeniem uruchamiania. Aby zapobiec awarii tej sondy, użyj initialDelaySeconds ustawienia, które opóźnia uruchamianie sondy.

  • Sonda liveness nie pomaga, chyba że ponowne uruchomienie zasobnika może przywrócić go do stanu dobrej kondycji. Możesz użyć sondy liveness, aby zminimalizować wycieki pamięci lub nieoczekiwane zakleszczenia, ale nie ma sensu ponownego uruchamiania zasobnika, który natychmiast nie powiedzie się.

  • 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 awarii 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 limitów 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 RBAC platformy Kubernetes kontroluje uprawnienia do interfejsu API Kubernetes. Na przykład tworzenie zasobników i zasobników listy to akcje, które mogą być autoryzowane (lub blokowane) dla użytkownika za pośrednictwem kontroli dostępu opartej na rolach platformy Kubernetes. Aby przypisać uprawnienia platformy Kubernetes użytkownikom, 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ń itp.).

    • Element RoleBinding 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 klastraRole, 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 Azure AD na potrzeby uwierzytelniania użytkowników. Aby uzyskać szczegółowe informacje na temat sposobu konfigurowania tej funkcji, zobacz Integrowanie usługi Azure Active Directory z 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ń Azure AD.

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

Jeśli użytkownicy nie mają dostępu domyślnie, w jaki sposób 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żytkownik klastra i administrator klastra. Poświadczenia administratora klastra zapewniają pełny dostęp do klastra. Polecenie interfejsu wiersza polecenia az aks get-credentials --admin platformy Azure pobiera poświadczenia administratora klastra i zapisuje je w pliku kubeconfig. Administrator klastra może użyć tej konfiguracji kubeconfig do tworzenia ról i powiązań ról.

Zamiast zarządzać rolami klastra Kuernetes i obiektami RoleBinding natywnie w usłudze Kubernetes, preferowane jest użycie kontroli RBAC 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 Platformy 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 ją połączyć z natywnym mechanizmem Kubernetes zarządzania rolami i funkcjami RoleBindings w celu obsługi zaawansowanych lub bardziej szczegółowych wzorców dostępu. Po włączeniu Azure AD podmioty zabezpieczeń będą weryfikowane wyłącznie przez kontrolę dostępu na podstawie ról platformy Azure, podczas gdy regularne konta i użytkownicy platformy Kubernetes są wyłącznie weryfikowane przez kontrolę dostępu na podstawie ról 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 "Azure Kubernetes Service Cluster Administracja Role" ma uprawnienia do pobierania poświadczeń administratora klastra. Do tej roli należy przypisać tylko administratorów klastra.

  • Uprawnienie "Azure Kubernetes Service Rola użytkownika klastra" ma uprawnienia do pobierania poświadczeń użytkownika klastra. Użytkownicy niebędący administratorami mogą być przypisani do tej roli. Ta rola nie daje żadnych konkretnych uprawnień do zasobów Platformy 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) zastanów 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 o to, 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ę przy użyciu interfejsów API platformy Azure, klaster używa jednostki usługi Azure AD. Jeśli podczas tworzenia klastra nie określisz jednostki usługi, 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 Jednostki usługi z 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 Azure AD i używa tej tożsamości do uwierzytelniania w usłudze platformy Azure. Aplikacja lub usługa ma utworzoną dla niej jednostkę usługi w Azure AD i uwierzytelnia się przy użyciu tokenów OAuth 2.0. Kod procesu wykonywania może w sposób niewidoczny uzyskać token do użycia. W ten sposób nie trzeba przechowywać żadnych haseł ani parametrów połączenia. Tożsamości zarządzane w usłudze AKS można używać, przypisując tożsamości Azure AD do poszczególnych zasobników przy użyciu tożsamości obciążeń Azure AD (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 Azure AD.

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:

Korzystanie z systemu takiego jak HashiCorp Vault lub Azure Key Vault zapewnia kilka zalet, takich jak:

  • Scentralizowana kontrola wpisów tajnych.
  • 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 Microsoft Defender dla kontenerów (lub możliwości innych firm). Jeśli hostujesz kontenery na maszynie wirtualnej, użyj 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ługiMicrosoft 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 za pośrednictwem Azure Marketplace.

  • Automatyzowanie stosowania poprawek obrazów przy użyciu usługi ACR Tasks— funkcji 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 zaktualizowanie, przetestowanie i ponowne wdrożenie własnych obrazów, dzięki czemu nie pozostawisz żadnych znanych luk w zabezpieczeniach. Zadania usługi ACR mogą pomóc zautomatyzować ten proces.

  • Przechowuj obrazy w zaufanym rejestrze prywatnym, takim jak Azure Container Registry lub Zaufany rejestr platformy Docker. Użyj sprawdzania poprawności elementu webhook wstępu na platformie Kubernetes, aby upewnić się, że zasobniki mogą ściągać 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.

DevOps

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

Rozważ zastosowanie kryteriów izolacji obciążenia do struktury szablonu usługi ARM, obciążenie jest zwykle definiowane jako dowolna jednostka funkcjonalności; Można na przykład mieć oddzielny szablon dla klastra, a następnie inny dla usług zależnych. Izolacja obciążeń 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)

Oto 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ą posiadane 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 programie 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, zobacz kalkulator 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. W przypadku skonfigurowania reguł nie są naliczane opłaty godzinowe za usługa Load Balancer w warstwie Standardowa.

Aby uzyskać więcej informacji, zobacz Azure Load Balancer Cennik.

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 dla 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 Azure DevOps Services Cennik.

Azure Monitor

W przypadku usługi Log Analytics w usłudze Azure Monitor 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