Edytuj

Udostępnij za pośrednictwem

Zaawansowana architektura mikrousług usługi Azure Kubernetes Service (AKS)

Azure Application Gateway
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Virtual Network

Ta architektura referencyjna zawiera szczegółowe informacje o kilku konfiguracjach, które należy wziąć pod uwagę podczas uruchamiania mikrousług w usługach Azure Kubernetes Services. Tematy obejmują konfigurowanie zasad sieciowych, autoskalowanie zasobników i rozproszone śledzenie w aplikacji opartej na mikrousługach.

Ta architektura opiera się na architekturze bazowej usługi AKS, zalecanym punktem wyjścia firmy Microsoft dla infrastruktury usługi Azure Kubernetes Service (AKS). Podstawowe funkcje planu bazowego usługi AKS, takie jak Tożsamość obciążeń Microsoft Entra, ograniczenia ruchu przychodzącego i ruchu wychodzącego, limity zasobów i inne bezpieczne konfiguracje infrastruktury usługi AKS. Te szczegóły infrastruktury nie zostały omówione w tym dokumencie. Zaleca się zapoznanie się z punktem odniesienia usługi AKS przed kontynuowaniem korzystania z zawartości mikrousług.

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

Architektura

Diagram sieciowy przedstawiający sieć piasty i szprych z dwiema równorzędnymi sieciami wirtualnymi i zasobami platformy Azure używanymi przez tę implementację.

Pobierz plik programu Visio z tą architekturą.

Jeśli wolisz zacząć od bardziej podstawowych przykładów mikrousług w usłudze AKS, zobacz Architektura mikrousług w usłudze AKS.

Przepływ pracy

Ten przepływ żądań implementuje wzorce projektowe wydawcy-subskrybenta, konkurencyjnych odbiorców i chmury routingu bramy. Przepływ obsługi komunikatów jest kontynuowany w następujący sposób:

  1. Żądanie HTTPS jest przesyłane w celu zaplanowana odbioru drona. Żądania są przekazywane przez usługę aplikacja systemu Azure Gateway do aplikacji internetowej pozyskiwania, która działa jako mikrousługa w klastrze w usłudze AKS.

  2. Aplikacja internetowa pozyskiwania generuje komunikat i wysyła go do kolejki komunikatów usługi Service Bus.

  3. System zaplecza przypisuje drona i powiadamia użytkownika. Przepływ 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 usługi Azure Cache for Redis.
    • Wysyła żądanie HTTPS do mikrousługi Drone Scheduler.
    • Wysyła żądanie HTTPS do mikrousługi Pakietu, która przekazuje dane do zewnętrznego magazynu danych bazy danych MongoDB.

  4. Żądanie HTTPS GET służy do zwracania stanu dostawy. To żądanie przechodzi przez usługę Application Gateway do mikrousługi dostarczania.

  5. Mikrousługa dostarczania odczytuje dane z usługi Azure Cache for Redis.

Składniki

Ta architektura korzysta z następujących składników platformy Azure:

Azure Kubernetes Service to oferta platformy Azure, która udostępnia zarządzany klaster Kubernetes. W przypadku korzystania z usługi AKS serwer interfejsu API Kubernetes jest zarządzany przez platformę Azure. Węzły lub pule węzłów platformy Kubernetes są dostępne i mogą być zarządzane przez operatora klastra.

Funkcje infrastruktury usługi AKS używane w tej architekturze obejmują:

Sieci wirtualne platformy Azure to izolowane i wysoce bezpieczne środowiska do uruchamiania maszyn wirtualnych i aplikacji. Ta architektura referencyjna używa topologii równorzędnej sieci wirtualnej piasty i szprych. Sieć wirtualna piasty przechowuje podsieci usługi Azure Firewall i Azure Bastion. Sieć wirtualna szprych zawiera podsieci puli węzłów użytkownika i systemu AKS oraz podsieci bramy aplikacja systemu Azure.

Usługa Azure Private Link przydziela określone prywatne adresy IP w celu uzyskania dostępu do usługi Azure Container Registry i Key Vault z prywatnych punktów końcowych w podsieci puli węzłów użytkownika i systemu AKS.

aplikacja systemu Azure Gateway Zapora aplikacji internetowej udostępnia trasy HTTP(S) do klastra usługi AKS i równoważy ruch internetowy do aplikacji internetowej. Ta architektura używa kontrolera ruchu przychodzącego bramy aplikacja systemu Azure (AGIC) jako kontrolera ruchu przychodzącego Kubernetes.

Usługa Azure Bastion zapewnia bezpieczny protokół RDP (Remote Desktop Protocol) i bezpieczny dostęp powłoki (SSH) do maszyn wirtualnych w sieciach wirtualnych przy użyciu protokołu SSL (Secure Socket Layer), bez konieczności uwidaczniania maszyn wirtualnych za pośrednictwem publicznych adresów IP.

Azure Firewall to usługa zabezpieczeń sieci, która chroni wszystkie zasoby usługi Azure Virtual Network. Zapora zezwala tylko na zatwierdzone usługi i w pełni kwalifikowane nazwy domen (FQDN) jako ruch wychodzący.

Magazyn zewnętrzny i inne składniki:

Usługa Azure Key Vault przechowuje klucze zabezpieczeń dla usług AKS i zarządza nimi.

Usługa Azure Container Registry przechowuje prywatne obrazy kontenerów, które można uruchomić w klastrze usługi AKS. Usługa AKS uwierzytelnia się w usłudze Container Registry przy użyciu tożsamości zarządzanej firmy Microsoft Entra. Możesz również użyć innych rejestrów kontenerów, takich jak Docker Hub.

Usługa Azure Cosmos DB przechowuje dane przy użyciu usługi Azure Cosmos DB typu open source dla bazy danych MongoDB. Mikrousługi są zwykle bezstanowe i zapisują swój stan w zewnętrznych magazynach danych. Azure Cosmos DB to baza danych NoSQL z interfejsami API typu open source dla baz danych MongoDB i Cassandra.

Usługa Azure Service Bus oferuje niezawodną obsługę komunikatów w chmurze jako usługę i prostą integrację hybrydową. Usługa Service Bus obsługuje asynchroniczne wzorce obsługi komunikatów, które są wspólne dla aplikacji mikrousług.

Usługa Azure Cache for Redis dodaje warstwę buforowania do architektury aplikacji, aby zwiększyć szybkość i wydajność dużych obciążeń.

Usługa Azure Monitor zbiera i przechowuje metryki i dzienniki, w tym dane telemetryczne aplikacji oraz metryki platformy Azure i usług. Te dane umożliwiają monitorowanie aplikacji, konfigurowanie alertów i pulpitów nawigacyjnych oraz przeprowadzanie analizy głównej przyczyny awarii.

Inne operacje obsługują składniki systemu operacyjnego:

Helm, menedżer pakietów dla platformy Kubernetes, który łączy obiekty Kubernetes w jedną jednostkę, którą można publikować, wdrażać, wersję i aktualizować.

Dostawca CSI magazynu kluczy tajnych usługi Azure Key Vault, pobiera wpisy tajne przechowywane w usłudze Azure Key Vault i używa interfejsu sterownika CSI magazynu wpisów tajnych, aby zainstalować je w zasobnikach Kubernetes.

Flux, otwarte i rozszerzalne rozwiązanie ciągłego dostarczania dla platformy Kubernetes, obsługiwane przez zestaw narzędzi GitOps Toolkit.

Szczegóły scenariusza

Przykładowa aplikacja wysyłkowa Fabrikam Drone Delivery Pokazana na powyższym diagramie implementuje składniki architektury i praktyki omówione w tym artykule. W tym przykładzie firma Fabrikam, Inc., fikcyjna firma zarządza flotą samolotów dronów. Firmy rejestrują się w usłudze, a użytkownicy mogą zamówić drona, który pobierze towary do dostarczenia. Gdy klient planuje odbiór, system zaplecza przypisuje drona i powiadamia użytkownika o szacowanym czasie dostawy. Podczas gdy dostarczanie jest w toku, klient może śledzić lokalizację drona przy użyciu stale aktualizowanego czasu ETA.

Potencjalne przypadki użycia

To rozwiązanie jest idealne dla przemysłu lotniczego, lotniczego i lotniczego.

Zalecenia

Zaimplementuj te zalecenia podczas wdrażania zaawansowanych architektur mikrousług usługi AKS.

Kontroler ruchu przychodzącego usługi Application Gateway (AGIC)

Routing bramy interfejsu API to ogólny wzorzec projektowania mikrousług. Brama interfejsu API działa jako zwrotny serwer proxy, który kieruje żądania od klientów do mikrousług. Zasób ruchu przychodzącego kubernetes i kontroler ruchu przychodzącego obsługują większość funkcji bramy interfejsu API przez:

Kierowanie żądań klientów do odpowiednich usług zaplecza zapewnia pojedynczy punkt końcowy dla klientów i pomoc w oddzieleniu klientów od usług.

  • Agregowanie wielu żądań do pojedynczego żądania w celu zmniejszenia rozmów między klientem a zapleczem.
  • Odciążanie funkcji, takich jak kończenie żądań SSL, uwierzytelnianie, ograniczenia adresów IP i ograniczanie szybkości klientów z usług zaplecza.

Stan klastra usługi AKS jest tłumaczony na konfigurację specyficzną dla usługi Application Gateway i stosowany za pośrednictwem usługi Azure Resource Manager.

Zewnętrzne kontrolery ruchu przychodzącego upraszczają pozyskiwanie ruchu do klastrów usługi AKS, zwiększają bezpieczeństwo i wydajność oraz oszczędzają zasoby. Ta architektura używa kontrolera ruchu przychodzącego bramy aplikacja systemu Azure (AGIC) do kontroli ruchu przychodzącego. Korzystanie z usługi Application Gateway do obsługi całego ruchu eliminuje konieczność dodatkowego modułu równoważenia obciążenia. Ze względu na to, że zasobniki ustanawiają bezpośrednie połączenia z usługą Application Gateway, liczba wymaganych przeskoków jest zmniejszona, co skutkuje lepszą wydajnością.

Usługa Application Gateway ma wbudowane funkcje skalowania automatycznego, w przeciwieństwie do kontrolerów ruchu przychodzącego w klastrze, które muszą być skalowane w poziomie, jeśli zużywają niepożądane ilości zasobów obliczeniowych. Usługa Application Gateway może wykonywać routing w warstwie 7 i kończenie żądań SSL i ma kompleksową usługę Transport Layer Security (TLS) zintegrowaną z wbudowaną zaporą aplikacji internetowej (WAF).

W przypadku opcji ruchu przychodzącego AGIC należy włączyć sieć CNI podczas konfigurowania klastra usługi AKS, ponieważ usługa Application Gateway jest wdrażana w podsieci sieci wirtualnej usługi AKS. Obciążenia wielodostępne lub pojedynczy klaster obsługujący środowiska programistyczne i testowe mogą wymagać większej liczby kontrolerów ruchu przychodzącego.

Zasady sieciowe o zerowym zaufaniu

Zasady sieciowe określają, w jaki sposób zasobniki usługi AKS mogą komunikować się ze sobą i z innymi punktami końcowymi sieci. Domyślnie cały ruch przychodzący i wychodzący jest dozwolony do i z zasobników. Podczas projektowania sposobu komunikowania się mikrousług ze sobą i z innymi punktami końcowymi należy rozważyć zastosowanie zasady zerowej zaufania, w której dostęp do dowolnej usługi, urządzenia, aplikacji lub repozytorium danych wymaga jawnej konfiguracji.

Jedną ze strategii wdrażania zasad zerowego zaufania jest utworzenie zasad sieci, które odrzucają cały ruch przychodzący i wychodzący do wszystkich zasobników w docelowej przestrzeni nazw. W poniższym przykładzie przedstawiono "odmów wszystkich zasad", które będą stosowane do wszystkich zasobników znajdujących się w przestrzeni nazw dev zaplecza.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Po wprowadzeniu restrykcyjnych zasad należy zdefiniować określone reguły sieci, aby zezwolić na ruch do i z każdego zasobnika w mikrousłudze. W poniższym przykładzie zasady sieci są stosowane do dowolnego zasobnika w przestrzeni nazw dev zaplecza z etykietą zgodną app.kubernetes.io/component: backendz . Zasady odrzucają ruch, chyba że pochodzi z zasobnika z etykietą zgodną app.kubernetes.io/part-of: dronedeliveryz etykietą .

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/part-of: dronedelivery
    ports:
    - port: 80
      protocol: TCP

Aby uzyskać więcej informacji na temat zasad sieci platformy Kubernetes i dodatkowych przykładów potencjalnych zasad domyślnych, zobacz Zasady sieciowe w dokumentacji platformy Kubernetes.

Limity przydziałów zasobów

Przydziały zasobów to sposób, w jaki administratorzy mogą rezerwować i ograniczać zasoby w zespole deweloperów lub projekcie. Limity przydziału zasobów można ustawić w przestrzeni nazw i użyć ich do ustawienia limitów:

  • Zasoby obliczeniowe, takie jak procesor CPU i pamięć, lub procesory GPU.
  • Zasoby magazynu, w tym liczba woluminów lub ilość miejsca na dysku dla danej klasy magazynu.
  • Liczba obiektów, takich jak maksymalna liczba wpisów tajnych, usług lub zadań, które można utworzyć.

Gdy łączna suma żądań lub limitów zasobów przejdzie przypisany limit przydziału, żadne dalsze wdrożenia nie zostaną pomyślnie wykonane.

Przydziały zasobów zapewniają, że łączny zestaw zasobników przypisanych do przestrzeni nazw nie może przekroczyć limitu przydziału zasobów przestrzeni nazw. Fronton nie może głodować usług zaplecza dla zasobów ani odwrotnie.

Podczas definiowania przydziałów zasobów wszystkie zasobniki utworzone w przestrzeni nazw muszą zapewniać limity lub żądania w specyfikacji zasobnika. Jeśli te wartości nie zostaną podane, wdrożenie zostanie odrzucone.

W poniższym przykładzie przedstawiono specyfikację zasobnika, która ustawia żądania przydziału zasobów i limity:

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

Aby uzyskać więcej informacji na temat przydziałów zasobów, zobacz:

Skalowanie automatyczne

Platforma Kubernetes obsługuje skalowanie automatyczne w celu zwiększenia liczby zasobników przydzielonych do wdrożenia lub zwiększenia liczby węzłów w klastrze w celu zwiększenia całkowitej liczby dostępnych zasobów obliczeniowych. Autoskalowanie jest autonomicznym systemem opinii. Mimo że zasobniki i węzły można skalować ręcznie, skalowanie automatyczne minimalizuje prawdopodobieństwo, że usługi stają się zagęszczone zasobami przy dużych obciążeniach. Strategia skalowania automatycznego musi uwzględniać zarówno zasobniki, jak i węzły.

Skalowanie automatyczne klastra

Funkcja skalowania automatycznego klastra (CA) skaluje liczbę węzłów. Załóżmy, że zasobniki nie mogą być zaplanowane z powodu ograniczeń zasobów; funkcja automatycznego skalowania klastra aprowizuje więcej węzłów. Należy zdefiniować minimalną liczbę węzłów, aby klaster usługi AKS i obciążenia działały oraz maksymalną liczbę węzłów dla dużego ruchu. Urząd certyfikacji sprawdza co kilka sekund pod kątem oczekujących zasobników lub pustych węzłów i odpowiednio skaluje klaster usługi AKS.

W poniższym przykładzie przedstawiono konfigurację urzędu certyfikacji z szablonu usługi ARM:

"autoScalerProfile": {
    "scan-interval": "10s",
    "scale-down-delay-after-add": "10m",
    "scale-down-delay-after-delete": "20s",
    "scale-down-delay-after-failure": "3m",
    "scale-down-unneeded-time": "10m",
    "scale-down-unready-time": "20m",
    "scale-down-utilization-threshold": "0.5",
    "max-graceful-termination-sec": "600",
    "balance-similar-node-groups": "false",
    "expander": "random",
    "skip-nodes-with-local-storage": "true",
    "skip-nodes-with-system-pods": "true",
    "max-empty-bulk-delete": "10",
    "max-total-unready-percentage": "45",
    "ok-total-unready-count": "3"
},

Następujące wiersze w szablonie usługi ARM ustawiają przykładowe minimalne i maksymalne węzły dla urzędu certyfikacji:

"minCount": 2,
"maxCount": 5,

Autoskalowanie zasobników

Narzędzie Horizontal Pod Autoscaler (HPA) skaluje zasobniki na podstawie obserwowanego procesora CPU, pamięci lub metryk niestandardowych. Aby skonfigurować skalowanie zasobników w poziomie, należy określić metryki docelowe oraz minimalną i maksymalną liczbę replik w specyfikacji zasobnika wdrożenia Platformy Kubernetes. Przetestuj obciążenie usług, aby określić te liczby.

Urząd certyfikacji i hpa współpracują ze sobą, dlatego włącz obie opcje skalowania automatycznego w klastrze usługi AKS. Usługa HPA skaluje aplikację, a urząd certyfikacji skaluje infrastrukturę.

Poniższy przykład ustawia metryki zasobów dla hpa:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 60

Narzędzie HPA analizuje rzeczywiste zasoby używane lub inne metryki z uruchomionych zasobników, ale urząd certyfikacji aprowizuje węzły dla zasobników, które nie są jeszcze zaplanowane. W związku z tym urząd certyfikacji analizuje żądane zasoby, jak określono w specyfikacji zasobnika. Użyj testowania obciążenia, aby dostosować te wartości.

Sondy kondycji

Obciążenie platformy Kubernetes równoważy ruch do zasobników pasujących do selektora etykiet dla usługi. Tylko zasobniki, które zostały uruchomione pomyślnie i są w dobrej kondycji odbierają ruch. Jeśli kontener ulegnie awarii, platforma Kubernetes usunie zasobnik i zaplanuje zastąpienie.

Na platformie Kubernetes zasobnik może uwidocznić dwa typy sondy kondycji:

  • Sonda liveness informuje platformę Kubernetes, czy zasobnik został uruchomiony pomyślnie i jest w dobrej kondycji.
  • Sonda gotowości informuje platformę Kubernetes, czy zasobnik jest gotowy do akceptowania żądań.

Sondy utrzymania obsługują zasobniki, które są nadal uruchomione, ale są w złej kondycji i powinny być poddawane recyklingu. Jeśli na przykład kontener obsługujący żądania HTTP zawiesza się, kontener nie ulega awarii, ale zatrzymuje obsługę żądań. Sonda aktualności HTTP przestaje odpowiadać, co informuje platformę Kubernetes o ponownym uruchomieniu zasobnika.

Czasami zasobnik może nie być gotowy do odbierania ruchu, mimo że zasobnik został uruchomiony pomyślnie. Na przykład aplikacja uruchomiona w kontenerze może wykonywać zadania inicjowania. Sonda gotowości wskazuje, czy zasobnik jest gotowy do odbierania ruchu.

Mikrousługi powinny uwidaczniać punkty końcowe w kodzie, które ułatwiają sondy kondycji, z opóźnieniem i limitem czasu dostosowanym specjalnie do testów, które wykonują. Klucze formuł HPA prawie wyłącznie poza fazą Gotowe na zasobniku, dlatego ważne jest, aby sondy kondycji istniały i były dokładne.

Monitorowanie

W aplikacji mikrousług monitorowanie zarządzania wydajnością aplikacji (APM) ma kluczowe znaczenie dla wykrywania anomalii, diagnozowania problemów i szybkiego zrozumienia zależności między usługami. Usługa Application Insights, która jest częścią usługi Azure Monitor, zapewnia monitorowanie aplikacji na żywo napisanych w programie .NET Core, Node.js, Java i wielu innych językach aplikacji.

Application Insights:

  • Rejestruje żądania HTTP, w tym opóźnienie i kod wyniku.
  • Domyślnie włącza śledzenie rozproszone.
  • Zawiera identyfikator operacji w śladach, dzięki czemu można dopasować wszystkie ślady dla określonej operacji.
  • Często zawiera dodatkowe informacje kontekstowe w śladach.

Aby kontekstować dane telemetryczne usług za pomocą środowiska Kubernetes, zintegruj dane telemetryczne usługi Azure Monitor z usługą AKS w celu zbierania metryk z kontrolerów, węzłów i kontenerów, a także dzienników kontenerów i węzłów. Jeśli używasz platformy .NET, biblioteka Application Insights dla platformy Kubernetes wzbogaca dane telemetryczne usługi Application Insights za pomocą obrazów, kontenerów, węzłów, zasobników, etykiet i zestawu replik.

Na poniższym diagramie przedstawiono przykład mapy zależności aplikacji generowanej przez usługę Application Insights dla śledzenia telemetrii mikrousług usługi AKS:

Przykład mapy zależności usługi Application Insights dla aplikacji mikrousług usługi AKS.

Aby uzyskać więcej informacji na temat opcji instrumentacji wspólnych języków integracji usługi Application Insights, zobacz Monitorowanie aplikacji dla platformy Kubernetes.

Kwestie wymagające rozważenia

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

Skalowalność

Podczas planowania skalowalności należy wziąć pod uwagę następujące kwestie.

  • Nie łącz skalowania automatycznego i imperatywnego ani deklaratywnego zarządzania liczbą replik. Użytkownicy i autoskalator próbujący zmodyfikować liczbę replik mogą spowodować nieoczekiwane zachowanie. Po włączeniu funkcji HPA zmniejsz liczbę replik do minimalnej liczby, którą chcesz wdrożyć.

  • Efektem ubocznym autoskalowania zasobników jest to, że zasobniki mogą być tworzone lub eksmitowane często, gdy występują zdarzenia skalowania w poziomie i skalowania w poziomie. Aby ograniczyć te efekty:

    • Użyj sond gotowości, aby poinformować platformę Kubernetes, gdy nowy zasobnik jest gotowy do akceptowania ruchu.
    • Użyj budżetów zakłóceń zasobników, aby ograniczyć liczbę zasobników, które można eksmitować z usługi naraz.

  • Nie można zmienić rozmiaru maszyny wirtualnej po utworzeniu klastra, dlatego należy zaplanować początkową pojemność, aby wybrać odpowiedni rozmiar maszyny wirtualnej dla węzłów agenta podczas tworzenia klastra.

  • Wielodostępne lub inne zaawansowane obciążenia mogą mieć wymagania dotyczące izolacji puli węzłów, które wymagają większej i prawdopodobnie mniejszej podsieci. Aby uzyskać więcej informacji na temat tworzenia pul węzłów z unikatowymi podsieciami, zobacz Dodawanie puli węzłów z unikatową podsiecią. Organizacje mają różne standardy implementacji piasty i szprych. Pamiętaj, aby postępować zgodnie z wytycznymi organizacji.

Możliwości zarządzania

Podczas planowania możliwości zarządzania należy wziąć pod uwagę następujące kwestie.

  • Zarządzanie infrastrukturą klastra AKS za pośrednictwem zautomatyzowanego potoku wdrażania. Implementacja referencyjna dla tej architektury udostępnia przepływ pracy funkcji GitHub Actions, który można odwołać podczas tworzenia potoku.

  • Plik przepływu pracy wdraża tylko infrastrukturę, a nie obciążenie, w istniejącej sieci wirtualnej i konfiguracji firmy Microsoft Entra. Wdrożenie infrastruktury i obciążenia oddzielnie umożliwia rozwiązanie różnych problemów związanych z cyklem życia i operacjami.

  • Jeśli wystąpi awaria regionalna, należy wziąć pod uwagę przepływ pracy jako mechanizm wdrażania w innym regionie. Skompiluj potok, aby można było wdrożyć nowy klaster w nowym regionie przy użyciu zmian parametrów i danych wejściowych.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Omówienie filaru zabezpieczeń.

Podczas planowania zabezpieczeń należy wziąć pod uwagę następujące kwestie.

  • Zasobnik usługi AKS uwierzytelnia się przy użyciu tożsamości obciążenia przechowywanej w identyfikatorze Entra firmy Microsoft. Użycie tożsamości obciążenia jest preferowane, ponieważ nie wymaga wpisu tajnego klienta.

  • Dzięki tożsamościom zarządzanym proces wykonywania może szybko uzyskać tokeny OAuth 2.0 usługi Azure Resource Manager; nie ma potrzeby wprowadzania haseł ani parametry połączenia. W usłudze AKS można przypisywać tożsamości do poszczególnych zasobników przy użyciu Tożsamość obciążeń Microsoft Entra.

  • Każda usługa w aplikacji mikrousług powinna mieć przypisaną unikatową tożsamość obciążenia w celu ułatwienia przypisań kontroli dostępu opartej na rolach o najniższych uprawnieniach. Tożsamości należy przypisywać tylko do usług, które ich wymagają.

  • W przypadkach, gdy składnik aplikacji wymaga dostępu do interfejsu API platformy Kubernetes, upewnij się, że zasobniki aplikacji są skonfigurowane do używania konta usługi z odpowiednio określonym zakresem dostępu do interfejsu API. Aby uzyskać więcej informacji na temat konfigurowania konta usługi Kubernetes i zarządzania nim, zobacz Zarządzanie kontami usługi Kubernetes.

  • Nie wszystkie usługi platformy Azure obsługują uwierzytelnianie płaszczyzny danych przy użyciu identyfikatora Entra firmy Microsoft. Aby przechowywać poświadczenia lub wpisy tajne aplikacji dla tych usług, w przypadku usług innych firm lub kluczy interfejsu API, użyj usługi Azure Key Vault. Usługa Azure Key Vault zapewnia scentralizowane zarządzanie, kontrolę dostępu, szyfrowanie magazynowane i inspekcję wszystkich kluczy i wpisów tajnych.

  • W usłudze AKS można zainstalować co najmniej jeden wpis tajny z usługi Key Vault jako wolumin. Zasobnik może następnie odczytywać wpisy tajne usługi Key Vault tak samo jak zwykły wolumin. Aby uzyskać więcej informacji, zobacz projekt secrets-store-csi-driver-provider-azure w witrynie GitHub.

Optymalizacja kosztów

Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Omówienie filaru optymalizacji kosztów.

  • Sekcja Koszt w witrynie Microsoft Azure Well-Architected Framework opisuje zagadnienia dotyczące kosztów. Skorzystaj z kalkulatora cen platformy Azure, aby oszacować koszty dla konkretnego scenariusza.

  • Usługa AKS nie ma kosztów związanych z wdrażaniem, zarządzaniem i operacjami klastra Kubernetes. Płacisz tylko za wystąpienia maszyn wirtualnych, magazyn i zasoby sieciowe używane przez klaster. Skalowanie automatyczne klastra może znacznie obniżyć koszt klastra, usuwając puste lub nieużywane węzły.

  • Aby oszacować koszt wymaganych zasobów, zobacz kalkulator usług kontenerów.

  • Rozważ włączenie analizy kosztów usługi AKS na potrzeby szczegółowej alokacji kosztów infrastruktury klastra według określonych konstrukcji platformy Kubernetes.

Następne kroki