Architektura bazowa dla klastra usługi Azure Kubernetes Service (AKS)

Ta architektura referencyjna udostępnia zalecaną architekturę infrastruktury bazowej do wdrażania klastra usługi Azure Kubernetes Service (AKS) na platformie Azure. Wykorzystuje ona nasze zasady projektowania i opiera się na naszych najlepszych rozwiązaniach dotyczących architektury z platformy Azure Well-Architected Framework w celu kierowania międzydyscyplinarnego lub wielu różnych zespołów, takich jak sieć, zabezpieczenia i tożsamość, dzięki wdrożeniu tej infrastruktury ogólnego przeznaczenia.

Ta architektura nie koncentruje się na obciążeniu, a raczej koncentruje się na samym klastrze usługi AKS. Poniżej przedstawiono minimalną zalecaną linię bazową dla większości klastrów usługi AKS. Integruje się z usługami platformy Azure, które zapewniają wgląd, topologię sieci, która obsługuje rozwój wielu regionów i zabezpiecza ruch w klastrze.

Architektura docelowa ma wpływ na wymagania biznesowe, a w rezultacie może się różnić w zależności od różnych kontekstów aplikacji. Należy je traktować jako punkt wyjścia dla etapów przedprodukcyjnego i produkcyjnego.

Implementacja tej architektury jest również dostępna w witrynie GitHub: Implementacja referencyjna punktu odniesienia usługi Azure Kubernetes Service (AKS). Można go użyć jako alternatywnego punktu wyjścia i skonfigurować go na podstawie Twoich potrzeb.

Konfiguracja sieci

Topologia sieci
Planowanie adresów IP
Wdrażanie zasobów ruchu przychodzącego

Obliczenia klastra

Obliczenia dla klastra podstawowego
Dokumentacja obrazu kontenera
Zarządzanie zasadami

Zarządzanie tożsamościami

Integrowanie identyfikatora Entra firmy Microsoft dla klastra
Integrowanie identyfikatora Entra firmy Microsoft dla obciążenia

Bezpieczny przepływ danych

Zabezpieczanie przepływu sieci
Dodawanie zarządzania wpisami tajnymi

Ciągłość działalności biznesowej

Skalowalność
Dostępność klastra i węzła
Dostępność i obsługa wielu regionów

Operacje

Potoki ciągłej integracji/ciągłego wdrażania klastra i obciążenia
Kondycja i metryki klastra
Zarządzanie kosztami i raportowanie

Topologia sieci

Ta architektura korzysta z topologii sieci piasty i szprych. Piasty i szprychy są wdrażane w oddzielnych sieciach wirtualnych połączonych za pośrednictwem komunikacji równorzędnej. Niektóre zalety tej topologii to:

• Zarządzanie segregowane. Umożliwia stosowanie ładu i przestrzeganie zasady najniższych uprawnień. Obsługuje również koncepcję strefy docelowej platformy Azure z rozdzieleniem obowiązków.

• Minimalizuje bezpośrednie narażenie zasobów platformy Azure na publiczny Internet.

• Organizacje często działają z regionalnymi topologiami piasty i szprych. Topologie sieci piasty i szprych można rozszerzyć w przyszłości i zapewnić izolację obciążenia.

• Wszystkie aplikacje internetowe powinny wymagać usługi zapory aplikacji internetowej (WAF), aby ułatwić zarządzanie przepływem ruchu HTTP.

• Naturalny wybór dla obciążeń obejmujących wiele subskrypcji.

• Sprawia to, że architektura jest rozszerzalna. Aby obsłużyć nowe funkcje lub obciążenia, można dodać nowe szprychy zamiast przeprojektować topologię sieci.

• Niektóre zasoby, takie jak zapora i dns, mogą być współużytkowane przez sieci.

• Jest zgodny ze strefami docelowymi w skali przedsiębiorstwa platformy Azure.

Pobierz plik programu Visio z tą architekturą.

Aby uzyskać więcej informacji, zobacz Topologia sieci piasty i szprych na platformie Azure.

Aby przejrzeć zmiany projektu sieci zawarte w kontenerach systemu Windows w architekturze referencyjnej punktu odniesienia usługi AKS, zobacz artykuł towarzyszący.

Piasta

Sieć wirtualna piasty jest centralnym punktem łączności i możliwości obserwacji. Centrum zawsze zawiera usługę Azure Firewall z globalnymi zasadami zapory zdefiniowanymi przez centralne zespoły IT, aby wymusić zasady zapory dla całej organizacji, usługę Azure Bastion, podsieć bramy na potrzeby łączności vpn i usługę Azure Monitor w celu obserwowania sieci.

W sieci są wdrażane trzy podsieci.

Podsieć do hostowania usługi Azure Firewall

Usługa Azure Firewall to zapora jako usługa. Wystąpienie zapory zabezpiecza wychodzący ruch sieciowy. Bez tej warstwy zabezpieczeń ten ruch może komunikować się ze złośliwą usługą innej firmy, która może eksfiltrować poufne dane firmy. Usługa Azure Firewall Manager umożliwia centralne wdrażanie i konfigurowanie wielu wystąpień usługi Azure Firewall oraz zarządzanie zasadami usługi Azure Firewall dla tego typu architektury sieci wirtualnej piasty.

Podsieć do hostowania bramy

Ta podsieć jest symbolem zastępczym bramy sieci VPN lub usługi ExpressRoute. Brama zapewnia łączność między routerami w sieci lokalnej i sieci wirtualnej.

Podsieć do hostowania usługi Azure Bastion

Ta podsieć jest symbolem zastępczym usługi Azure Bastion. Za pomocą usługi Bastion można bezpiecznie uzyskiwać dostęp do zasobów platformy Azure bez uwidaczniania zasobów w Internecie. Ta podsieć jest używana tylko do zarządzania i operacji.

Mówił

Sieć wirtualna szprychy zawiera klaster usługi AKS i inne powiązane zasoby. Szprycha ma cztery podsieci:

Podsieć do hostowania bramy aplikacja systemu Azure

Usługa Azure Application Gateway to internetowy moduł równoważenia obciążenia ruchu działający w warstwie 7. Implementacja referencyjna używa jednostki SKU usługi Application Gateway w wersji 2, która umożliwia zaporę aplikacji internetowej (WAF). Zapora aplikacji internetowej zabezpiecza ruch przychodzący z typowych ataków na ruch internetowy, w tym botów. Wystąpienie ma publiczną konfigurację adresu IP frontonu, która odbiera żądania użytkowników. Zgodnie z projektem usługa Application Gateway wymaga dedykowanej podsieci.

Podsieć do hostowania zasobów ruchu przychodzącego

Aby kierować i dystrybuować ruch, Traefik jest kontrolerem ruchu przychodzącego, który będzie wypełniać zasoby ruchu przychodzącego Kubernetes. Wewnętrzne moduły równoważenia obciążenia platformy Azure istnieją w tej podsieci. Aby uzyskać więcej informacji, zobacz Używanie wewnętrznego modułu równoważenia obciążenia z usługą Azure Kubernetes Service (AKS).

Podsieć do hostowania węzłów klastra

Usługa AKS obsługuje dwie oddzielne grupy węzłów (lub pul węzłów). Pula węzłów systemowych hostuje zasobniki, które uruchamiają podstawowe usługi klastra. Pula węzłów użytkownika uruchamia obciążenie i kontroler ruchu przychodzącego, aby umożliwić komunikację przychodzącą z obciążeniem.

Podsieć do hostowania punktów końcowych usługi Private Link

Połączenia usługi Azure Private Link są tworzone dla usług Azure Container Registry i Azure Key Vault, więc dostęp do tych usług można uzyskać przy użyciu prywatnego punktu końcowego w sieci wirtualnej będącej szprychą. Prywatne punkty końcowe nie wymagają dedykowanej podsieci i można je również umieścić w sieci wirtualnej koncentratora. W implementacji punktu odniesienia są one wdrażane w dedykowanej podsieci w sieci wirtualnej będącej szprychą. Takie podejście zmniejsza ruch przekazujący równorzędne połączenie sieciowe, utrzymuje zasoby należące do klastra w tej samej sieci wirtualnej i umożliwia stosowanie szczegółowych reguł zabezpieczeń na poziomie podsieci przy użyciu sieciowych grup zabezpieczeń.

Aby uzyskać więcej informacji, zobacz Opcje wdrażania usługi Private Link.

Planowanie adresów IP

Pobierz plik programu Visio z tą architekturą.

Przestrzeń adresowa sieci wirtualnej powinna być wystarczająco duża, aby przechowywać wszystkie podsieci. Uwzględnij wszystkie jednostki, które będą odbierać ruch. Adresy IP dla tych jednostek zostaną przydzielone z przestrzeni adresowej podsieci. Weź pod uwagę te kwestie.

• Uaktualnienie

  Usługa AKS regularnie aktualizuje węzły, aby upewnić się, że podstawowe maszyny wirtualne są aktualne na temat funkcji zabezpieczeń i innych poprawek systemowych. Podczas procesu uaktualniania usługa AKS tworzy węzeł, który tymczasowo hostuje zasobniki, podczas gdy węzeł uaktualniania jest cordoned i opróżniany. Ten tymczasowy węzeł ma przypisany adres IP z podsieci klastra.

  W przypadku zasobników może być konieczne dodatkowe adresy w zależności od strategii. W przypadku aktualizacji stopniowych potrzebne są adresy dla zasobników tymczasowych, które uruchamiają obciążenie podczas aktualizowania rzeczywistych zasobników. Jeśli używasz strategii zastępowania, zasobniki zostaną usunięte, a nowe zostaną utworzone. Dlatego adresy skojarzone ze starymi zasobnikami są ponownie używane.

• Skalowalność

  Należy wziąć pod uwagę liczbę węzłów wszystkich węzłów systemu i użytkowników oraz ich maksymalny limit skalowalności. Załóżmy, że chcesz skalować w poziomie o 400%. Będziesz potrzebować cztery razy więcej adresów dla wszystkich węzłów skalowanych w poziomie.

  W tej architekturze każdy zasobnik można skontaktować się bezpośrednio. Dlatego każdy zasobnik potrzebuje indywidualnego adresu. Skalowalność zasobnika będzie mieć wpływ na obliczenie adresu. Ta decyzja będzie zależeć od wybranej liczby zasobników, które chcesz zwiększyć.

• Adresy usługi Azure Private Link

  Uwzględnij adresy wymagane do komunikacji z innymi usługami platformy Azure za pośrednictwem usługi Private Link. W tej architekturze mamy dwa adresy przypisane do linków do usługi Azure Container Registry i Key Vault.

• Niektóre adresy są zarezerwowane do użytku przez platformę Azure. Nie można ich przypisać.

Poprzednia lista nie jest wyczerpująca. Jeśli projekt ma inne zasoby, które będą mieć wpływ na liczbę dostępnych adresów IP, uwzględnij te adresy.

Ta architektura jest przeznaczona dla pojedynczego obciążenia. W przypadku wielu obciążeń można odizolować pule węzłów użytkownika od siebie i z puli węzłów systemowych. Ten wybór powoduje zwiększenie liczby podsieci o mniejszym rozmiarze. Ponadto zasób ruchu przychodzącego może być bardziej złożony, a w rezultacie może być konieczne użycie wielu kontrolerów ruchu przychodzącego, które wymagają dodatkowych adresów IP.

Aby zapoznać się z pełnym zestawem zagadnień dotyczących tej architektury, zobacz Topologia sieci punktu odniesienia usługi AKS.

Aby uzyskać informacje dotyczące planowania adresu IP klastra usługi AKS, zobacz Planowanie adresowania IP klastra.

Aby zapoznać się z zagadnieniami dotyczącymi planowania adresów IP uwzględnionych w kontenerach systemu Windows w architekturze referencyjnej punktu odniesienia usługi AKS, zobacz artykuł towarzyszący.

Dodatki i funkcje w wersji zapoznawczej

Platforma Kubernetes i usługa AKS stale ewoluują produkty z szybszymi cyklami wydawania niż oprogramowanie w środowiskach lokalnych. Ta architektura linii bazowej zależy od wybranych funkcji usługi AKS w wersji zapoznawczej i dodatków usługi AKS. Różnica między nimi jest następująca:

• Zespół usługi AKS opisuje funkcje w wersji zapoznawczej dostarczane i ulepszane. Przyczyną tego jest to, że wiele funkcji w wersji zapoznawczej pozostaje w tym stanie tylko przez kilka miesięcy przed przejściem do fazy ogólnie dostępnej.
• Dodatki i rozszerzenia usługi AKS zapewniają dodatkowe, obsługiwane funkcje. Ich instalacja, konfiguracja i cykl życia są zarządzane przez usługę AKS.

Ta architektura punktu odniesienia nie obejmuje każdej funkcji w wersji zapoznawczej ani dodatku, a zamiast tego uwzględniane są tylko te, które dodają znaczącą wartość do klastra ogólnego przeznaczenia. W miarę jak te funkcje są w wersji zapoznawczej, ta architektura punktu odniesienia zostanie odpowiednio zmieniona. Istnieją pewne dodatkowe funkcje w wersji zapoznawczej lub dodatki usługi AKS, które warto ocenić w klastrach przedprodukcyjnych, które zwiększają bezpieczeństwo, możliwości zarządzania lub inne wymagania. W przypadku dodatków innych firm należy je zainstalować i obsługiwać, w tym śledzić dostępne wersje i instalować aktualizacje po uaktualnieniu wersji rozwiązania Kubernetes klastra.

Dokumentacja obrazu kontenera

Oprócz obciążenia klaster może zawierać kilka innych obrazów, takich jak kontroler ruchu przychodzącego. Niektóre z tych obrazów mogą znajdować się w rejestrach publicznych. Podczas ściągania ich do klastra należy wziąć pod uwagę te punkty.

• Klaster jest uwierzytelniany w celu ściągnięcia obrazu.

• Jeśli używasz obrazu publicznego, rozważ zaimportowanie go do rejestru kontenerów, który jest zgodny z celami slo. W przeciwnym razie obraz może podlegać nieoczekiwanym problemom z dostępnością. Te problemy mogą powodować problemy operacyjne, jeśli obraz nie jest dostępny, gdy jest on potrzebny. Poniżej przedstawiono niektóre korzyści wynikające z używania rejestru kontenerów zamiast rejestru publicznego:

  • Możesz zablokować nieautoryzowany dostęp do obrazów.
  • Nie będziesz mieć publicznych zależności.
  • Możesz uzyskać dostęp do dzienników ściągania obrazów w celu monitorowania działań i klasyfikacji problemów z łącznością.
  • Korzystaj ze zintegrowanego skanowania kontenerów i zgodności obrazów.

  Opcja to Azure Container Registry (ACR).

• Ściąganie obrazów z autoryzowanych rejestrów. To ograniczenie można wymusić za pomocą usługi Azure Policy. W tej implementacji referencyjnej klaster ściąga tylko obrazy z usługi ACR wdrożonej w ramach architektury.

Konfigurowanie zasobów obliczeniowych dla klastra podstawowego

W usłudze AKS każda pula węzłów jest mapowania na zestaw skalowania maszyn wirtualnych. Węzły to maszyny wirtualne w każdej puli węzłów. Rozważ użycie mniejszego rozmiaru maszyny wirtualnej dla puli węzłów systemowych, aby zminimalizować koszty. Ta implementacja referencyjna wdraża pulę węzłów systemowych z trzema węzłami DS2_v2. Ten rozmiar jest wystarczający do spełnienia oczekiwanego obciążenia zasobników systemowych. Dysk systemu operacyjnego to 512 GB.

W przypadku puli węzłów użytkownika poniżej przedstawiono kilka zagadnień:

• Wybierz większe rozmiary węzłów, aby spakować maksymalną liczbę zasobników ustawionych w węźle. Zminimalizuje ślad usług uruchamianych we wszystkich węzłach, takich jak monitorowanie i rejestrowanie.

• Wdróż co najmniej dwa węzły. W ten sposób obciążenie będzie mieć wzorzec wysokiej dostępności z dwiema replikami. Usługa AKS umożliwia zmianę liczby węzłów bez ponownego tworzenia klastra.

• Rzeczywiste rozmiary węzłów dla obciążenia będą zależeć od wymagań określonych przez zespół projektowy. Na podstawie wymagań biznesowych wybraliśmy DS4_v2 dla obciążenia produkcyjnego. Aby obniżyć koszty, można zmniejszyć rozmiar do DS3_v2, co jest zaleceniem minimalnym.

• Podczas planowania pojemności klastra załóżmy, że obciążenie może zużywać do 80% każdego węzła; pozostałe 20% jest zarezerwowane dla usług AKS.

• Ustaw maksymalne zasobniki na węzeł na podstawie planowania pojemności. Jeśli próbujesz ustanowić plan bazowy pojemności, zacznij od wartości 30. Dostosuj wartość na podstawie wymagań obciążenia, rozmiaru węzła i ograniczeń adresu IP.

Integrowanie identyfikatora Entra firmy Microsoft dla klastra

Zabezpieczanie dostępu do i z klastra ma kluczowe znaczenie. Pomyśl z perspektywy klastra, kiedy dokonujesz wyborów zabezpieczeń:

• Dostęp wewnętrzny. Dostęp usługi AKS do składników platformy Azure, takich jak infrastruktura sieciowa, usługa Azure Container Registry i usługa Azure Key Vault. Autoryzuj tylko te zasoby, do których klaster ma dozwolony dostęp.
• Dostęp zewnętrzny. Zapewnianie tożsamościom dostępu do klastra Kubernetes. Autoryzuj tylko te jednostki zewnętrzne, które mogą uzyskiwać dostęp do serwera interfejsu API Kubernetes i usługi Azure Resource Manager.

Dostęp usługi AKS do platformy Azure

Istnieją dwa sposoby zarządzania usługą AKS do platformy Azure za pośrednictwem identyfikatora Entra firmy Microsoft: jednostki usługi lub tożsamości zarządzane dla zasobów platformy Azure.

Zaleca się użycie dwóch sposobów tożsamości zarządzanych. W przypadku jednostek usługi odpowiadasz za zarządzanie i rotację wpisów tajnych, ręcznie lub programowo. Dzięki tożsamościom zarządzanym identyfikator Entra firmy Microsoft zarządza uwierzytelnianiem i terminowym rotacją wpisów tajnych.

Zaleca się włączenie tożsamości zarządzanych, aby klaster mógł wchodzić w interakcje z zewnętrznymi zasobami platformy Azure za pomocą identyfikatora Entra firmy Microsoft. To ustawienie można włączyć tylko podczas tworzenia klastra. Nawet jeśli identyfikator Entra firmy Microsoft nie jest używany natychmiast, możesz dołączyć go później.

Domyślnie istnieją dwie podstawowe tożsamości używane przez klaster, tożsamość klastra i tożsamość kubeletu. Tożsamość klastra jest używana przez składniki płaszczyzny sterowania usługi AKS do zarządzania zasobami klastra, w tym modułami równoważenia obciążenia ruchu przychodzącego, publicznymi adresami IP zarządzanymi przez usługę AKS itp. Tożsamość kubelet służy do uwierzytelniania za pomocą usługi Azure Container Registry (ACR). Niektóre dodatki obsługują również uwierzytelnianie przy użyciu tożsamości zarządzanej.

Jako przykład dla wewnętrznego przypadku przeanalizujmy użycie tożsamości zarządzanych, gdy klaster musi ściągnąć obrazy z rejestru kontenerów. Ta akcja wymaga, aby klaster pobierał poświadczenia rejestru. Jednym ze sposobów jest przechowywanie tych informacji w postaci obiektu Wpisy tajne Kubernetes i używanie imagePullSecrets ich do pobierania wpisu tajnego. Takie podejście nie jest zalecane ze względu na złożoność zabezpieczeń. Nie tylko potrzebujesz wcześniejszej wiedzy o wpisie tajnym, ale także ujawnieniu tego wpisu tajnego za pośrednictwem potoku DevOps. Innym powodem jest obciążenie operacyjne związane z zarządzaniem rotacją wpisu tajnego. Zamiast tego przyznaj acrPull dostęp do tożsamości zarządzanej kubelet klastra w rejestrze. Takie podejście rozwiązuje te problemy.

W tej architekturze klaster uzyskuje dostęp do zasobów platformy Azure zabezpieczonych za pomocą identyfikatora Entra firmy Microsoft i wykonuje operacje obsługujące tożsamości zarządzane. Przypisz kontrolę dostępu opartą na rolach (RBAC) platformy Azure i uprawnienia do tożsamości zarządzanych klastra, w zależności od operacji, które zamierza wykonać klaster. Klaster uwierzytelnia się w identyfikatorze Entra firmy Microsoft, a następnie jest dozwolony lub blokowany dostęp na podstawie przypisanych ról. Poniżej przedstawiono kilka przykładów z tej implementacji referencyjnej, w której wbudowane role platformy Azure zostały przypisane do klastra:

• Współautor sieci. Możliwość kontrolowania sieci wirtualnej będącej szprychą przez klaster. To przypisanie roli umożliwia przypisaną tożsamość systemu klastra usługi AKS do pracy z dedykowaną podsiecią dla usług Wewnętrznego kontrolera ruchu przychodzącego.
• Wydawca metryk monitorowania. Możliwość wysyłania metryk do usługi Azure Monitor przez klaster.
• AcrPull. Możliwość ściągania obrazów z określonych rejestrów kontenerów platformy Azure przez klaster.

Dostęp do klastra

Integracja z firmą Microsoft Entra upraszcza również zabezpieczenia dostępu zewnętrznego. Załóżmy, że użytkownik chce użyć narzędzia kubectl. W ramach początkowego kroku uruchamiają az aks get-credentials polecenie , aby uzyskać poświadczenia klastra. Identyfikator entra firmy Microsoft uwierzytelni tożsamość użytkownika względem ról platformy Azure, które mogą uzyskiwać poświadczenia klastra. Aby uzyskać więcej informacji, zobacz Dostępne uprawnienia ról klastra.

Usługa AKS umożliwia dostęp do platformy Kubernetes przy użyciu identyfikatora Entra firmy Microsoft na dwa sposoby. Pierwszy polega na używaniu identyfikatora Entra firmy Microsoft jako dostawcy tożsamości zintegrowanego z natywnym systemem kontroli dostępu opartej na rolach Kubernetes. Druga używa natywnej kontroli dostępu opartej na rolach platformy Azure w celu kontrolowania dostępu do klastra. Oba te elementy zostały szczegółowo opisane poniżej.

Kojarzenie kontroli dostępu opartej na rolach platformy Kubernetes z identyfikatorem entra firmy Microsoft

Platforma Kubernetes obsługuje kontrolę dostępu opartą na rolach (RBAC) za pośrednictwem:

• Zestaw uprawnień. Zdefiniowane przez Role obiekt lub ClusterRole dla uprawnień dla całego klastra.

• Powiązania, które przypisują użytkowników i grupy, które mogą wykonywać akcje. Zdefiniowane przez RoleBinding obiekt lub ClusterRoleBinding .

Platforma Kubernetes ma wbudowane role, takie jak cluster-admin, edit, view itd. Powiąż te role z użytkownikami i grupami firmy Microsoft, aby zarządzać dostępem za pomocą katalogu przedsiębiorstwa. Aby uzyskać więcej informacji, zobacz Use Kubernetes RBAC with Microsoft Entra integration (Używanie kontroli dostępu opartej na rolach platformy Kubernetes z integracją z firmą Microsoft Entra).

Upewnij się, że grupy entra firmy Microsoft używane na potrzeby dostępu do klastra i przestrzeni nazw znajdują się w przeglądach dostępu firmy Microsoft Entra.

Używanie kontroli dostępu opartej na rolach platformy Azure na potrzeby autoryzacji na platformie Kubernetes

Zamiast używać natywnej kontroli dostępu opartej na rolach platformy Kubernetes (ClusterRoleBindings i RoleBindings) do autoryzacji ze zintegrowanym uwierzytelnianiem firmy Microsoft Entra, inną zalecaną opcją jest użycie kontroli ról platformy Azure i przypisań ról platformy Azure w celu wymuszania kontroli autoryzacji w klastrze. Te przypisania ról można nawet dodać w zakresach subskrypcji lub grupy zasobów, aby wszystkie klastry w zakresie dziedziczyły spójny zestaw przypisań ról w odniesieniu do osób mających uprawnienia dostępu do obiektów w klastrze Kubernetes.

Aby uzyskać więcej informacji, zobacz Azure RBAC for Kubernetes Authorization (Kontrola dostępu na podstawie ról platformy Azure dla autoryzacji na platformie Kubernetes).

Konta lokalne

Usługa AKS obsługuje natywne uwierzytelnianie użytkowników platformy Kubernetes. Nie jest sugerowany dostęp użytkownika do klastrów przy użyciu tej metody. Jest on oparty na certyfikatach i jest wykonywany poza podstawowym dostawcą tożsamości; utrudnianie scentralizowanej kontroli dostępu użytkowników i zapewniania ładu. Zawsze zarządzaj dostępem do klastra przy użyciu identyfikatora Entra firmy Microsoft i skonfiguruj klaster, aby jawnie wyłączyć dostęp do konta lokalnego.

W tej implementacji referencyjnej dostęp za pośrednictwem kont klastra lokalnego jest jawnie wyłączony po wdrożeniu klastra.

Integrowanie identyfikatora Entra firmy Microsoft dla obciążenia

Podobnie jak w przypadku tożsamości zarządzanej przypisanej przez system platformy Azure dla całego klastra, można przypisać tożsamości zarządzane na poziomie zasobnika. Tożsamość obciążenia umożliwia hostowanym obciążeniu dostęp do zasobów za pośrednictwem identyfikatora Entra firmy Microsoft. Na przykład obciążenie przechowuje pliki w usłudze Azure Storage. Gdy będzie on musiał uzyskać dostęp do tych plików, zasobnik będzie uwierzytelniany względem zasobu jako tożsamości zarządzanej platformy Azure.

W tej implementacji referencyjnej tożsamości zarządzane dla zasobników są udostępniane za pośrednictwem Tożsamość obciążeń Microsoft Entra w usłudze AKS. Integruje się to z natywnymi możliwościami platformy Kubernetes w celu federacji z zewnętrznymi dostawcami tożsamości. Aby uzyskać więcej informacji na temat federacji Tożsamość obciążeń Microsoft Entra, zobacz następujące omówienie.

Wdrażanie zasobów ruchu przychodzącego

Zasoby ruchu przychodzącego kubernetes kierują i dystrybuują ruch przychodzący do klastra. Istnieją dwie części zasobów ruchu przychodzącego:

• Wewnętrzne równoważenie obciążenia. Zarządzane przez usługę AKS. Ten moduł równoważenia obciążenia uwidacznia kontroler ruchu przychodzącego za pośrednictwem prywatnego statycznego adresu IP. Służy jako pojedynczy punkt kontaktu, który odbiera przepływy przychodzące.

  W tej architekturze jest używana usługa Azure Load Balancer. Znajduje się poza klastrem w podsieci dedykowanej dla zasobów przychodzących. Odbiera ruch z bramy aplikacja systemu Azure i że komunikacja odbywa się za pośrednictwem protokołu TLS. Aby uzyskać informacje na temat szyfrowania TLS dla ruchu przychodzącego, zobacz Przepływ ruchu przychodzącego.

• Kontroler ruchu przychodzącego. Wybraliśmy Traefik. Jest on uruchamiany w puli węzłów użytkownika w klastrze. Odbiera ruch z wewnętrznego modułu równoważenia obciążenia, przerywa protokół TLS i przekazuje go do zasobników obciążeń za pośrednictwem protokołu HTTP.

Kontroler ruchu przychodzącego jest krytycznym składnikiem klastra. Podczas konfigurowania tego składnika należy wziąć pod uwagę te punkty.

• W ramach decyzji projektowych wybierz zakres, w którym będzie dozwolony kontroler ruchu przychodzącego. Na przykład można zezwolić kontrolerowi na interakcję tylko z zasobnikami, które uruchamiają określone obciążenie.

• Unikaj umieszczania replik w tym samym węźle, aby rozłożyć obciążenie i zapewnić ciągłość działania, jeśli węzeł nie działa. Użyj podAntiAffinity go do tego celu.

• Zasobniki ograniczeń, które mają być zaplanowane tylko w puli węzłów użytkownika przy użyciu polecenia nodeSelectors. To ustawienie spowoduje izolowanie zasobników obciążeń i zasobników systemowych.

• Otwórz porty i protokoły, które umożliwiają określonym podmiotom wysyłanie ruchu do kontrolera ruchu przychodzącego. W tej architekturze Traefik odbiera tylko ruch z aplikacja systemu Azure Gateway.

• Kontroler ruchu przychodzącego powinien wysyłać sygnały wskazujące kondycję zasobników. Skonfiguruj readinessProbe i livenessProbe ustawienia, które będą monitorować kondycję zasobników w określonym interwale.

• Rozważ ograniczenie dostępu kontrolera ruchu przychodzącego do określonych zasobów i możliwość wykonywania określonych akcji. To ograniczenie można zaimplementować za pomocą uprawnień RBAC platformy Kubernetes. Na przykład w tej architekturze Traefik otrzymał uprawnienia do oglądania, pobierania i wyświetlania listy usług i punktów końcowych przy użyciu reguł w obiekcie Kubernetes ClusterRole .

Aby przejrzeć projekt ruchu przychodzącego używany w kontenerach systemu Windows w architekturze referencyjnej punktu odniesienia usługi AKS, zobacz artykuł towarzyszący.

Ustawienia routera

Kontroler ruchu przychodzącego używa tras, aby określić, gdzie wysyłać ruch. Trasy określają port źródłowy, na którym jest odbierany ruch, oraz informacje o portach docelowych i protokołach.

Oto przykład z tej architektury:

Traefik używa dostawcy Kubernetes do konfigurowania tras. Element annotations, tlsi entrypoints wskazuje, że trasy będą obsługiwane za pośrednictwem protokołu HTTPS. Określamiddlewares, że dozwolony jest tylko ruch z podsieci bramy aplikacja systemu Azure. Odpowiedzi będą używać kodowania gzip, jeśli klient akceptuje. Ponieważ Traefik kończy pracę z protokołem TLS, komunikacja z usługami zaplecza odbywa się za pośrednictwem protokołu HTTP.

apiVersion:networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port: 
              number: 80

Zabezpieczanie przepływu sieci

W tym kontekście przepływ sieci można podzielić na następujące kategorie:

• Ruch przychodzący. Od klienta do obciążenia uruchomionego w klastrze.

• Ruch wychodzący. Z zasobnika lub węzła w klastrze do usługi zewnętrznej.

• Ruch zasobnik-zasobnik. Komunikacja między zasobnikami. Ten ruch obejmuje komunikację między kontrolerem ruchu przychodzącego a obciążeniem. Ponadto jeśli obciążenie składa się z wielu aplikacji wdrożonych w klastrze, komunikacja między tymi aplikacjami będzie należeć do tej kategorii.

• Ruch zarządzania. Ruch między klientem a serwerem interfejsu API Kubernetes.

Pobierz plik programu Visio z tą architekturą.

Ta architektura ma kilka warstw zabezpieczeń, aby zabezpieczyć wszystkie typy ruchu.

Przepływ ruchu przychodzącego

Architektura akceptuje tylko zaszyfrowane żądania TLS od klienta. Protokół TLS w wersji 1.2 jest minimalną dozwoloną wersją z ograniczonym zestawem cyprherów. Włączono ścisłe wskazanie nazwy serwera (SNI). Kompleksowe protokoły TLS są konfigurowane za pośrednictwem usługi Application Gateway przy użyciu dwóch różnych certyfikatów TLS, jak pokazano na tej ilustracji.

Pobierz plik programu Visio z tą architekturą.

1. Klient wysyła żądanie HTTPS do nazwy domeny: bicycle.contoso.com. Ta nazwa jest skojarzona z rekordem DNS A z publicznym adresem IP aplikacja systemu Azure Gateway. Ten ruch jest szyfrowany, aby upewnić się, że nie można sprawdzić ani zmienić ruchu między przeglądarką klienta i bramą.

2. Usługa Application Gateway ma zintegrowaną zaporę aplikacji internetowej (WAF) i negocjuje uzgadnianie protokołu TLS dla bicycle.contoso.com, umożliwiając tylko bezpieczne szyfry. Usługa Application Gateway jest punktem zakończenia protokołu TLS, ponieważ jest wymagana do przetwarzania reguł inspekcji zapory aplikacji internetowej i wykonywania reguł routingu przekazujących ruch do skonfigurowanego zaplecza. Certyfikat TLS jest przechowywany w usłudze Azure Key Vault. Dostęp do niego jest uzyskiwany przy użyciu tożsamości zarządzanej przypisanej przez użytkownika zintegrowanej z usługą Application Gateway. Aby uzyskać informacje o tej funkcji, zobacz Kończenie szyfrowania TLS przy użyciu certyfikatów usługi Key Vault.

3. W miarę jak ruch przechodzi z usługi Application Gateway do zaplecza, jest on ponownie szyfrowany przy użyciu innego certyfikatu TLS (symbol wieloznaczny *.aks-ingress.contoso.com), ponieważ jest przekazywany do wewnętrznego modułu równoważenia obciążenia. To ponowne szyfrowanie zapewnia, że ruch, który nie jest bezpieczny, nie przepływa do podsieci klastra.

4. Kontroler ruchu przychodzącego odbiera zaszyfrowany ruch za pośrednictwem modułu równoważenia obciążenia. Kontroler jest kolejnym punktem zakończenia protokołu TLS dla *.aks-ingress.contoso.com i przekazuje ruch do zasobników obciążenia za pośrednictwem protokołu HTTP. Certyfikaty są przechowywane w usłudze Azure Key Vault i instalowane w klastrze przy użyciu sterownika interfejsu magazynu kontenerów (CSI). Aby uzyskać więcej informacji, zobacz Dodawanie zarządzania wpisami tajnymi.

Cały ruch TLS na każdym przeskoku można zaimplementować na każdym przeskoku do zasobnika obciążenia. Pamiętaj, aby zmierzyć wydajność, opóźnienie i wpływ operacyjny podczas podejmowania decyzji o zabezpieczeniu ruchu między zasobnikami. W przypadku większości klastrów z jedną dzierżawą, z odpowiednią kontrolą kontroli RBAC i dojrzałymi praktykami cyklu życia tworzenia oprogramowania, wystarczy zaszyfrować protokół TLS do kontrolera ruchu przychodzącego i chronić go za pomocą zapory aplikacji internetowej (WAF). Pozwoli to zminimalizować obciążenie związane z zarządzaniem obciążeniami i wpływem na wydajność sieci. Wymagania dotyczące obciążenia i zgodności będą decydować o tym, gdzie wykonasz zakończenie szyfrowania TLS.

Przepływ ruchu wychodzącego

W tej architekturze zalecamy, aby cały ruch wychodzący z klastra komunikował się za pośrednictwem usługi Azure Firewall lub własnego podobnego wirtualnego urządzenia sieciowego, za pośrednictwem innych opcji, takich jak brama translatora adresów sieciowych lub serwer proxy HTTP. W przypadku kontroli zerowej zaufania i możliwości inspekcji ruchu cały ruch wychodzący z klastra przechodzi przez usługę Azure Firewall. Możesz zaimplementować ten wybór przy użyciu tras zdefiniowanych przez użytkownika (UDR). Następny przeskok trasy to prywatny adres IP usługi Azure Firewall. W tym miejscu usługa Azure Firewall decyduje, czy blokować lub zezwalać na ruch wychodzący. Ta decyzja jest oparta na określonych regułach zdefiniowanych w usłudze Azure Firewall lub wbudowanych regułach analizy zagrożeń.

Alternatywą dla korzystania z usługi Azure Firewall jest użycie funkcji serwera proxy HTTP usługi AKS. Cały ruch wychodzący klastra jest ustawiany jako pierwszy na adres IP serwera proxy HTTP, który decyduje się na przekazanie ruchu lub usunięcie go.

W przypadku każdej metody przejrzyj wymagane reguły sieci ruchu wychodzącego dla usługi AKS.

Wyjątkiem od kontroli zerowej zaufania jest to, że klaster musi komunikować się z innymi zasobami platformy Azure. Na przykład klaster musi ściągnąć zaktualizowany obraz z rejestru kontenerów lub wpisy tajne z usługi Azure Key Vault. Zalecaną metodą jest użycie usługi Azure Private Link. Zaletą jest to, że określone podsieci docierają bezpośrednio do usługi zamiast ruchu między klastrem a usługami przechodzącymi przez Internet. Wadą jest to, że usługa Private Link wymaga dodatkowej konfiguracji zamiast używania usługi docelowej za pośrednictwem publicznego punktu końcowego. Ponadto nie wszystkie usługi platformy Azure lub jednostki SKU obsługują usługę Private Link. W takich przypadkach rozważ włączenie punktu końcowego usługi sieci wirtualnej w podsieci w celu uzyskania dostępu do usługi.

Jeśli usługa Private Link lub punkty końcowe usługi nie są opcją, możesz uzyskać dostęp do innych usług za pośrednictwem ich publicznych punktów końcowych i kontrolować dostęp za pośrednictwem reguł usługi Azure Firewall i zapory wbudowanej w usługę docelową. Ponieważ ten ruch będzie przechodzić przez statyczne adresy IP zapory, te adresy można dodać do listy dozwolonych adresów IP usługi. Jedną z wad jest to, że usługa Azure Firewall musi mieć dodatkowe reguły, aby upewnić się, że dozwolony jest tylko ruch z określonej podsieci. Należy uwzględnić te adresy, gdy planujesz wiele adresów IP dla ruchu wychodzącego za pomocą usługi Azure Firewall, w przeciwnym razie możesz uzyskać dostęp do wyczerpania portów. Aby uzyskać więcej informacji na temat planowania wielu adresów IP, zobacz Ograniczanie i kontrolowanie ruchu wychodzącego.

Aby zapoznać się z zagadnieniami dotyczącymi ruchu wychodzącego specyficznymi dla systemu Windows używanymi w kontenerach systemu Windows w architekturze referencyjnej punktu odniesienia usługi AKS, zobacz artykuł towarzyszący.

Ruch zasobnik-zasobnik

Domyślnie zasobnik może akceptować ruch z dowolnego innego zasobnika w klastrze. Platforma Kubernetes NetworkPolicy służy do ograniczania ruchu sieciowego między zasobnikami. Zastosuj zasady w rozsądny sposób. W przeciwnym razie może wystąpić sytuacja, w której krytyczny przepływ sieci jest blokowany. Zezwalaj tylko na określone ścieżki komunikacyjne, w razie potrzeby, na przykład ruch między kontrolerem ruchu przychodzącego a obciążeniem. Aby uzyskać więcej informacji, zobacz Zasady sieciowe.

Włącz zasady sieciowe po aprowizacji klastra, ponieważ nie można go dodać później. Istnieje kilka opcji dotyczących technologii implementujących NetworkPolicyprogram . Zalecana jest usługa Azure Network Policy, która wymaga interfejsu azure Container Networking Interface (CNI), zobacz poniższą uwagę. Inne opcje obejmują zasady sieci Calico, dobrze znaną opcję typu open source. Rozważ rozwiązanie Calico, jeśli musisz zarządzać zasadami sieciowymi obejmującymi cały klaster. Calico nie jest objęte standardowymi pomoc techniczna platformy Azure.

Aby uzyskać więcej informacji, zobacz Różnice między zasadami sieci platformy Azure i zasadami calico oraz ich możliwościami.

Ruch zarządzania

W ramach uruchamiania klastra serwer interfejsu API Kubernetes odbiera ruch z zasobów, które chcą wykonywać operacje zarządzania w klastrze, takie jak żądania tworzenia zasobów lub skalowania klastra. Przykłady tych zasobów obejmują pulę agentów kompilacji w potoku DevOps, podsieć bastionu i same pule węzłów. Zamiast akceptować ten ruch zarządzania ze wszystkich adresów IP, użyj funkcji Autoryzowanych zakresów adresów IP usługi AKS, aby zezwolić tylko na ruch z autoryzowanych zakresów adresów IP do serwera interfejsu API.

Aby uzyskać więcej informacji, zobacz Definiowanie autoryzowanych zakresów adresów IP serwera interfejsu API.

W przypadku dodatkowej warstwy kontroli kosztem dodatkowej złożoności można aprowizować prywatny klaster usługi AKS. Korzystając z klastra prywatnego, można zapewnić, że ruch sieciowy między serwerem interfejsu API i pulami węzłów pozostaje tylko w sieci prywatnej, ale nie jest dostępny w Internecie. Aby uzyskać więcej informacji, zobacz AKS Private Clusters (Klastry prywatne usługi AKS).

Dodawanie funkcji zarządzania wpisami tajnymi

Przechowywanie wpisów tajnych w zarządzanym magazynie kluczy, takim jak usługa Azure Key Vault. Zaletą jest to, że magazyn zarządzany obsługuje rotację wpisów tajnych, oferuje silne szyfrowanie, zapewnia dziennik inspekcji dostępu i przechowuje podstawowe wpisy tajne z potoku wdrażania. W tej architekturze zapora usługi Azure Key Vault jest włączona i skonfigurowana przy użyciu połączeń łącza prywatnego z zasobami na platformie Azure, które muszą uzyskiwać dostęp do wpisów tajnych i certyfikatów.

Usługa Azure Key Vault jest dobrze zintegrowana z innymi usługami platformy Azure. Użyj wbudowanej funkcji tych usług, aby uzyskać dostęp do wpisów tajnych. Aby zapoznać się z przykładem sposobu uzyskiwania dostępu do certyfikatów TLS przez bramę aplikacja systemu Azure dla przepływu ruchu przychodzącego, zobacz sekcję Przepływ ruchu przychodzącego.

Model uprawnień RBAC platformy Azure dla usługi Key Vault umożliwia przypisanie tożsamości obciążeń do przypisania roli Użytkownik wpisów tajnych usługi Key Vault lub Czytelnik usługi Key Vault oraz uzyskiwanie dostępu do wpisów tajnych. Aby uzyskać więcej informacji, zobacz Uzyskiwanie dostępu do usługi Azure Key Vault przy użyciu kontroli dostępu opartej na rolach.

Uzyskiwanie dostępu do wpisów tajnych klastra

Aby umożliwić zasobnikowi dostęp do wpisów tajnych z określonego magazynu, należy użyć tożsamości obciążeń. Aby ułatwić proces pobierania, należy użyć sterownika CSI magazynu wpisów tajnych. Gdy zasobnik wymaga wpisu tajnego, sterownik łączy się z określonym magazynem, pobiera wpis tajny na woluminie i instaluje ten wolumin w klastrze. Zasobnik może następnie pobrać wpis tajny z systemu plików woluminów.

Sterownik CSI ma wielu dostawców do obsługi różnych magazynów zarządzanych. W tej implementacji wybraliśmy usługę Azure Key Vault ze sterownikiem CSI magazynu wpisów tajnych przy użyciu dodatku w celu pobrania certyfikatu TLS z usługi Azure Key Vault i załadowania go w zasobniku z uruchomionym kontrolerem ruchu przychodzącego. Odbywa się to podczas tworzenia zasobnika, a woluminy są przechowywane zarówno jako publiczne, jak i prywatne.

Magazyn obciążeń

Obciążenie używane w tej architekturze jest bezstanowe. Jeśli musisz przechowywać stan, zalecane jest utrwalanie go poza klastrem. Wskazówki dotyczące stanu obciążenia wykraczają poza zakres tego artykułu.

Aby dowiedzieć się więcej na temat opcji magazynu, zobacz Opcje magazynu dla aplikacji w usłudze Azure Kubernetes Service (AKS).

Zarządzanie zasadami

Skutecznym sposobem zarządzania klastrem usługi AKS jest wymuszanie ładu za pomocą zasad. Platforma Kubernetes implementuje zasady za pośrednictwem usługi OPA Gatekeeper. W przypadku usługi AKS zasady są dostarczane za pośrednictwem usługi Azure Policy. Każda zasada jest stosowana do wszystkich klastrów w swoim zakresie. Wymuszanie usługi Azure Policy jest ostatecznie obsługiwane przez usługę OPA Gatekeeper w klastrze, a wszystkie kontrole zasad są rejestrowane. Zmiany zasad nie zostaną natychmiast odzwierciedlone w klastrze. Spodziewaj się pewnych opóźnień.

Istnieją dwa różne scenariusze zapewniane przez usługę Azure Policy do zarządzania klastrami usługi AKS:

• Zapobieganie lub ograniczanie wdrażania klastrów usługi AKS w grupie zasobów lub subskrypcji przez ocenę standardów organizacji. Na przykład postępuj zgodnie z konwencją nazewnictwa, określ tag itp.
• Zabezpiecz klaster usługi AKS za pomocą usługi Azure Policy dla platformy Kubernetes.

Podczas ustawiania zasad zastosuj je na podstawie wymagań obciążenia. Rozważ następujące czynniki:

• Czy chcesz ustawić kolekcję zasad (nazywanych inicjatywami) lub wybrać poszczególne zasady? Usługa Azure Policy udostępnia dwie wbudowane inicjatywy: podstawową i ograniczoną. Każda inicjatywa to kolekcja wbudowanych zasad mających zastosowanie do klastra usługi AKS. Zaleca się wybranie inicjatywy i wybranie dodatkowych zasad dla klastra i zasobów (ACR, Application Gateway, Key Vault i innych), które współdziałają z klastrem zgodnie z wymaganiami organizacji.

• Czy chcesz przeprowadzić inspekcję lub odmówić akcji? W trybie inspekcji akcja jest dozwolona, ale jest oznaczona jako niezgodna. Mieć procesy sprawdzania niezgodnych stanów w regularnym tempie i podejmij niezbędne działania. W trybie odmowy akcja jest blokowana, ponieważ narusza zasady. Należy zachować ostrożność podczas wybierania tego trybu, ponieważ może to być zbyt restrykcyjne, aby obciążenie działało.

• Czy masz obszary w obciążeniu, które nie powinny być zgodne z projektem? Usługa Azure Policy ma możliwość określania przestrzeni nazw Kubernetes, które są wykluczone z wymuszania zasad. Zaleca się stosowanie zasad w trybie inspekcji , aby pamiętać o tych wystąpieniach.

• Czy masz wymagania, które nie są objęte wbudowanymi zasadami? Możesz utworzyć niestandardową definicję usługi Azure Policy, która stosuje niestandardowe zasady usługi OPA Gatekeeper. Nie stosuj zasad niestandardowych bezpośrednio do klastra. Aby dowiedzieć się więcej na temat tworzenia zasad niestandardowych, zobacz Tworzenie i przypisywanie niestandardowych definicji zasad.

• Czy masz wymagania dotyczące całej organizacji? Jeśli tak, dodaj te zasady na poziomie grupy zarządzania. Klaster powinien również przypisywać własne zasady specyficzne dla obciążenia, nawet jeśli organizacja ma ogólne zasady.

• Zasady platformy Azure są przypisywane do określonych zakresów. Upewnij się, że zasady produkcji są również weryfikowane względem środowiska przedprodukcyjnego. W przeciwnym razie podczas wdrażania w środowisku produkcyjnym mogą wystąpić nieoczekiwane dodatkowe ograniczenia, które nie zostały uwzględnione w środowisku przedprodukcyjnym.

W tej implementacji referencyjnej usługa Azure Policy jest włączona po utworzeniu klastra usługi AKS i przypisuje restrykcyjną inicjatywę w trybie inspekcji, aby uzyskać wgląd w niezgodność.

Implementacja określa również dodatkowe zasady, które nie są częścią żadnych wbudowanych inicjatyw. Te zasady są ustawiane w trybie odmowy . Istnieją na przykład zasady umożliwiające upewnienie się, że obrazy są pobierane tylko z wdrożonego usługi ACR. Rozważ utworzenie własnych inicjatyw niestandardowych. Połącz zasady, które mają zastosowanie do obciążenia w ramach pojedynczego przypisania.

Aby zobaczyć, jak usługa Azure Policy działa z poziomu klastra, możesz uzyskać dostęp do dzienników zasobników dla wszystkich zasobników w gatekeeper-system przestrzeni nazw, a także dzienników dla azure-policy zasobników i azure-policy-webhook w kube-system przestrzeni nazw.

Aby zapoznać się z zagadnieniami dotyczącymi usługi Azure Policy specyficznymi dla systemu Windows zawartymi w kontenerach systemu Windows w architekturze referencyjnej punktu odniesienia usługi AKS, zobacz artykuł towarzyszący.

Skalowalność węzłów i zasobników

Dzięki rosnącemu zapotrzebowaniu platforma Kubernetes może skalować w poziomie, dodając więcej zasobników do istniejących węzłów przez skalowanie automatyczne zasobników poziomych (HPA). Jeśli nie można już zaplanować dodatkowych zasobników, należy zwiększyć liczbę węzłów za pomocą skalowania automatycznego klastra usługi AKS. Kompletne rozwiązanie skalowania musi mieć sposoby skalowania zarówno replik zasobników, jak i liczby węzłów w klastrze.

Istnieją dwa podejścia: skalowanie automatyczne lub skalowanie ręczne.

Ręczny lub programowy sposób wymaga monitorowania i ustawiania alertów dotyczących użycia procesora CPU lub metryk niestandardowych. W przypadku skalowania zasobników operator aplikacji może zwiększyć lub zmniejszyć liczbę replik zasobników, dostosowując ReplicaSet interfejsy API platformy Kubernetes. W przypadku skalowania klastra jednym ze sposobów jest otrzymywanie powiadomień, gdy harmonogram Kubernetes kończy się niepowodzeniem. Innym sposobem jest obserwowanie oczekujących zasobników w czasie. Liczbę węzłów można dostosować za pomocą interfejsu wiersza polecenia platformy Azure lub portalu.

Skalowanie automatyczne jest zalecanym podejściem, ponieważ niektóre z tych mechanizmów ręcznych są wbudowane w narzędzie do skalowania automatycznego.

Ogólnie rzecz biorąc, zacznij od testowania wydajnościowego z minimalną liczbą zasobników i węzłów. Użyj tych wartości, aby ustanowić oczekiwania bazowe. Następnie użyj kombinacji metryk wydajności i ręcznego skalowania, aby zlokalizować wąskie gardła i zrozumieć odpowiedź aplikacji na skalowanie. Na koniec użyj tych danych, aby ustawić parametry skalowania automatycznego. Aby uzyskać informacje na temat scenariusza dostrajania wydajności przy użyciu usługi AKS, zobacz Scenariusz dostrajania wydajności: transakcje biznesowe rozproszone.

Narzędzie do automatycznego skalowania zasobników w poziomie

Narzędzie Horizontal Pod Autoscaler (HPA) to zasób Kubernetes, który skaluje liczbę zasobników.

W zasobie HPA zalecane jest ustawienie minimalnej i maksymalnej liczby replik. Te wartości ograniczają ograniczenia skalowania automatycznego.

Narzędzie HPA może być skalowane na podstawie użycia procesora CPU, użycia pamięci i metryk niestandardowych. Poza tym dostępne jest tylko wykorzystanie procesora CPU. Definicja HorizontalPodAutoscaler określa wartości docelowe dla tych metryk. Na przykład specyfikacje określają docelowe wykorzystanie procesora CPU. Gdy zasobniki są uruchomione, kontroler HPA używa interfejsu API metryk platformy Kubernetes do sprawdzania wykorzystania procesora CPU każdego zasobnika. Porównuje to wartość z użyciem docelowym i oblicza stosunek. Następnie używa współczynnika, aby określić, czy zasobniki są nadmiernie alokowane, czy nieprzydzielone. Jest on oparty na harmonogramie Kubernetes w celu przypisania nowych zasobników do węzłów lub usunięcia zasobników z węzłów.

Może istnieć warunek wyścigu, w którym (HPA) sprawdza przed ukończeniem operacji skalowania. Wynik może być niepoprawnym obliczeniem współczynnika. Aby uzyskać szczegółowe informacje, zobacz Cooldown of scaling events (Chłodne skalowanie zdarzeń).

Jeśli obciążenie jest sterowane zdarzeniami, popularną opcją typu open source jest KEDA. Rozważ użycie usługi KEDA, jeśli obciążenie jest sterowane przez źródło zdarzeń, takie jak kolejka komunikatów, zamiast być związane z procesorem CPU lub pamięcią. Usługa KEDA obsługuje wiele źródeł zdarzeń (lub skalowania). Listę obsługiwanych skalowania KEDA można znaleźć tutaj , w tym narzędzie skalowania usługi Azure Monitor. Wygodny sposób skalowania obciążeń KEDA na podstawie metryk usługi Azure Monitor.

Narzędzie do automatycznego skalowania klastra

Narzędzie do automatycznego skalowania klastra to składnik dodatku usługi AKS, który skaluje liczbę węzłów w puli węzłów. Należy go dodać podczas aprowizacji klastra. Potrzebujesz oddzielnego modułu skalowania automatycznego klastra dla każdej puli węzłów użytkownika.

Narzędzie do automatycznego skalowania klastra jest wyzwalane przez harmonogram Kubernetes. Gdy harmonogram platformy Kubernetes nie może zaplanować zasobnika z powodu ograniczeń zasobów, narzędzie do automatycznego skalowania automatycznie aprowizuje nowy węzeł w puli węzłów. Z drugiej strony funkcja automatycznego skalowania klastra sprawdza nieużywaną pojemność węzłów. Jeśli węzeł nie jest uruchomiony w oczekiwanej pojemności, zasobniki zostaną przeniesione do innego węzła, a nieużywany węzeł zostanie usunięty.

Po włączeniu autoskalatora ustaw maksymalną i minimalną liczbę węzłów. Zalecane wartości zależą od oczekiwań związanych z wydajnością obciążenia, ilością, jaką ma zwiększyć klaster, oraz wpływem na koszty. Minimalna liczba to pojemność zarezerwowana dla tej puli węzłów. W tej implementacji referencyjnej minimalna wartość jest ustawiona na 2 ze względu na prosty charakter obciążenia.

W przypadku puli węzłów systemowych zalecana minimalna wartość to 3.

Aby zapoznać się ze zagadnieniami dotyczącymi skalowania uwzględnionych w kontenerach systemu Windows w architekturze referencyjnej punktu odniesienia usługi AKS, zobacz artykuł towarzyszący.

Decyzje dotyczące ciągłości działania

Aby zachować ciągłość działalności biznesowej, zdefiniuj umowę dotyczącą poziomu usług dla infrastruktury i aplikacji. Aby uzyskać informacje na temat obliczania miesięcznego czasu pracy, zobacz Umowa SLA dla usługi Azure Kubernetes Service (AKS).

Węzły klastra

Aby spełnić minimalny poziom dostępności dla obciążeń, wymagane jest wiele węzłów w puli węzłów. Jeśli węzeł ulegnie awarii, inny węzeł w puli węzłów w tym samym klastrze może kontynuować uruchamianie aplikacji. W celu uzyskania niezawodności zalecane są trzy węzły dla puli węzłów systemowych. W przypadku puli węzłów użytkownika zacznij od nie mniej niż dwóch węzłów. Jeśli potrzebujesz wyższej dostępności, aprowizuj więcej węzłów.

Izoluj aplikacje od usług systemowych, umieszczając je w oddzielnej puli węzłów, nazywanej pulą węzłów użytkownika. Dzięki temu usługi Kubernetes działają na dedykowanych węzłach i nie konkurują z obciążeniem. Użycie tagów, etykiet i defektów jest zalecane w celu zidentyfikowania puli węzłów w celu zaplanowana obciążenia i upewnienia się, że pula węzłów systemu jest skażona za pomocą pul węzłów krytycznychOnly [taint] (/azure/aks/use-system-pools#system-and-user-node-pools).

Regularne utrzymywanie klastra, takiego jak aktualizacje terminowe, ma kluczowe znaczenie dla niezawodności. Zalecane jest również monitorowanie kondycji zasobników za pośrednictwem sond.

Dostępność zasobnika

Upewnij się, że zasoby zasobnika. Zdecydowanie zaleca się, aby wdrożenia określały wymagania dotyczące zasobów zasobnika. Harmonogram może następnie odpowiednio zaplanować zasobnik. Niezawodność będzie znacznie przestarzała, jeśli nie można zaplanować zasobników.

Ustaw budżety zakłóceń zasobników. To ustawienie określa, ile replik we wdrożeniu może spaść podczas zdarzenia aktualizacji lub uaktualnienia. Aby uzyskać więcej informacji, zobacz Budżety zakłóceń zasobników.

Skonfiguruj wiele replik we wdrożeniu w celu obsługi zakłóceń, takich jak awarie sprzętowe. W przypadku planowanych zdarzeń, takich jak aktualizacje i uaktualnienia, budżet zakłóceń może zapewnić, że istnieje wymagana liczba replik zasobników do obsługi oczekiwanego obciążenia aplikacji.

Ustaw limity przydziału zasobów w przestrzeniach nazw obciążenia. Limit przydziału zasobów w przestrzeni nazw zapewni prawidłowe ustawienie żądań zasobników i limitów we wdrożeniu. Aby uzyskać więcej informacji, zobacz Wymuszanie przydziałów zasobów.

Ustawianie żądań zasobników i limitów. Ustawienie tych limitów umożliwia platformie Kubernetes efektywne przydzielanie zasobów procesora CPU i/lub pamięci zasobnikom oraz większej gęstości kontenera w węźle. Limity mogą również zwiększyć niezawodność dzięki zmniejszeniu kosztów ze względu na lepsze wykorzystanie sprzętu.

Aby oszacować limity, przetestuj i ustanów punkt odniesienia. Zacznij od równych wartości dla żądań i limitów. Następnie stopniowo dostrajaj te wartości do momentu ustanowienia progu, który może spowodować niestabilność klastra.

Te limity można określić w manifestach wdrożenia. Aby uzyskać więcej informacji, zobacz Ustawianie żądań zasobników i limitów.

Obsługa stref dostępności i wielu regionów

Jeśli umowa SLA wymaga wyższego czasu pracy, chroń przed awariami przy użyciu stref dostępności. Strefy dostępności można używać, jeśli region je obsługuje. Składniki płaszczyzny sterowania i węzły w pulach węzłów są następnie w stanie rozłożyć się między strefami. Jeśli cała strefa jest niedostępna, węzeł w innej strefie w regionie jest nadal dostępny. Każda pula węzłów jest mapowane na oddzielny zestaw skalowania maszyn wirtualnych, który zarządza wystąpieniami węzłów i skalowalnością. Operacje i konfiguracja zestawu skalowania są zarządzane przez usługę AKS. Poniżej przedstawiono kilka zagadnień dotyczących włączania wielostrefowej:

• Cała infrastruktura. Wybierz region obsługujący strefy dostępności. Aby uzyskać więcej informacji, zobacz Ograniczenia i dostępność regionów. Jeśli chcesz kupić umowę SLA czasu pracy, wybierz region, który obsługuje tę opcję. Umowa SLA czasu pracy jest większa w przypadku korzystania ze stref dostępności.

• Klaster. Strefy dostępności można ustawić tylko wtedy, gdy pula węzłów zostanie utworzona i nie można jej później zmienić. Rozmiary węzłów powinny być obsługiwane we wszystkich strefach, tak aby oczekiwany rozkład był możliwy. Podstawowy zestaw skalowania maszyn wirtualnych zapewnia tę samą konfigurację sprzętu w różnych strefach.

  Obsługa wielu stref nie tylko dotyczy pul węzłów, ale także płaszczyzny sterowania. Płaszczyzna sterowania usługi AKS będzie obejmować żądane strefy, takie jak pule węzłów. Jeśli w klastrze nie jest używana obsługa stref, składniki płaszczyzny sterowania nie będą mieć gwarancji rozrzuceń między strefami dostępności.

• Zasoby zależne. Aby uzyskać pełną korzyść strefową, wszystkie zależności usług muszą również obsługiwać strefy. Jeśli usługa zależna nie obsługuje stref, możliwe, że awaria strefy może spowodować niepowodzenie tej usługi.

Na przykład dysk zarządzany jest dostępny w strefie, w której jest aprowizowany. W przypadku awarii węzeł może przejść do innej strefy, ale dysk zarządzany nie zostanie przeniesiony z węzłem do tej strefy.

Dla uproszczenia w tej architekturze usługa AKS jest wdrażana w jednym regionie z pulami węzłów obejmującymi strefy dostępności 1, 2 i 3. Inne zasoby infrastruktury, takie jak Azure Firewall i Application Gateway, są wdrażane w tym samym regionie również z obsługą wielu stref. Replikacja geograficzna jest włączona dla usługi Azure Container Registry.

Wiele regionów

Włączenie stref dostępności nie będzie wystarczające, jeśli cały region ulegnie awarii. Aby zapewnić wyższą dostępność, uruchom wiele klastrów usługi AKS w różnych regionach.

• Użyj sparowanych regionów. Rozważ użycie potoku ciągłej integracji/ciągłego wdrażania skonfigurowanego do korzystania z sparowanego regionu w celu odzyskania po awarii regionów. Zaletą korzystania z sparowanych regionów jest niezawodność podczas aktualizacji. Platforma Azure zapewnia, że tylko jeden region w parze jest aktualizowany jednocześnie. Niektóre narzędzia DevOps, takie jak Flux, mogą ułatwić wdrażanie w wielu regionach.

• Jeśli zasób platformy Azure obsługuje nadmiarowość geograficzną, podaj lokalizację, w której usługa nadmiarowa będzie miała swoją pomocniczą. Na przykład włączenie replikacji geograficznej dla usługi Azure Container Registry spowoduje automatyczne replikowanie obrazów do wybranych regionów platformy Azure i zapewni stały dostęp do obrazów, nawet jeśli w regionie wystąpiła awaria.

• Wybierz router ruchu, który może dystrybuować ruch między strefami lub regionami, w zależności od wymagań. Ta architektura wdraża usługę Azure Load Balancer, ponieważ może dystrybuować ruch nienależący do sieci Web między strefami. Jeśli musisz dystrybuować ruch między regionami, należy wziąć pod uwagę usługę Azure Front Door. Aby zapoznać się z innymi zagadnieniami, zobacz Wybieranie modułu równoważenia obciążenia.

Odzyskiwanie po awarii

W przypadku awarii w regionie podstawowym powinno być możliwe szybkie utworzenie nowego wystąpienia w innym regionie. Poniżej przedstawiono kilka rekomendacji:

• Użyj sparowanych regionów.

• Obciążenie niestanowe można skutecznie replikować. Jeśli musisz przechowywać stan w klastrze (niezalecane), upewnij się, że kopie zapasowe danych są często przechowywane w sparowanym regionie.

• Zintegruj strategię odzyskiwania, taką jak replikowanie do innego regionu, w ramach potoku DevOps, aby spełnić cele poziomu usług (SLO).

• Podczas aprowizowania każdej usługi platformy Azure wybierz funkcje, które obsługują odzyskiwanie po awarii. Na przykład w tej architekturze usługa Azure Container Registry jest włączona na potrzeby replikacji geograficznej. Jeśli region ulegnie awarii, nadal możesz ściągnąć obrazy z zreplikowanego regionu.

Tworzenie kopii zapasowej klastra

W przypadku wielu architektur aprowizowanie nowego klastra i zwracanie go do stanu operacyjnego można wykonać za pomocą opartego na metodzie GitOps [bootstrapping klastra}(#cluster-bootstrapping) i po wdrożeniu aplikacji. Jeśli jednak w procesie uruchamiania nie można przechwycić krytycznego stanu zasobu, takiego jak mapy konfiguracji, zadania i potencjalnie wpisy tajne, które z jakiegoś powodu nie mogą być przechwytywane w procesie uruchamiania, rozważ strategię odzyskiwania. Ogólnie zaleca się uruchamianie bezstanowych obciążeń na platformie Kubernetes, ale jeśli architektura obejmuje stan oparty na dysku, należy również rozważyć strategię odzyskiwania dla tej zawartości.

Jeśli kopia zapasowa klastra musi być częścią strategii odzyskiwania, należy zainstalować rozwiązanie zgodne z wymaganiami biznesowymi w klastrze. Ten agent będzie odpowiedzialny za wypychanie stanu zasobu klastra do wybranego miejsca docelowego i koordynowanie migawek woluminów trwałych opartych na dyskach platformy Azure.

Rozwiązanie Velero firmy VMware to przykład typowego rozwiązania do tworzenia kopii zapasowych Kubernetes, które można zainstalować i zarządzać bezpośrednio. Alternatywnie można użyć rozszerzenia kopii zapasowej usługi AKS w celu zapewnienia zarządzanej implementacji platformy Velero. Rozszerzenie kopii zapasowej usługi AKS obsługuje tworzenie kopii zapasowych zarówno zasobów Kubernetes, jak i woluminów trwałych, z harmonogramami i zakresem kopii zapasowej zewnętrznie jako konfiguracją magazynu w usłudze Azure Backup.

Implementacja referencyjna nie implementuje kopii zapasowej, co wiązałoby się z dodatkowymi zasobami platformy Azure w architekturze w celu zarządzania, monitorowania, płacenia i zabezpieczania; na przykład konto usługi Azure Storage, magazyn i konfiguracja usługi Azure Backup oraz zaufany dostęp. Usługa GitOps połączona z zamiarem uruchamiania bezstanowego obciążenia to zaimplementowane rozwiązanie odzyskiwania.

Wybierz i zweryfikuj rozwiązanie spełniające cel biznesowy, w tym zdefiniowany cel punktu odzyskiwania (RPO) i cel czasu odzyskiwania (RTO). Zdefiniuj ten proces odzyskiwania w elemecie Runbook zespołu i przećwicz go dla wszystkich obciążeń o znaczeniu krytycznym dla działania firmy.

Umowa SLA serwera interfejsu API Platformy Kubernetes

Usługa AKS może być używana jako bezpłatna usługa, ale ta warstwa nie oferuje umowy SLA wspieranej finansowo. Aby uzyskać umowę SLA, musisz wybrać warstwę Standardowa. Zalecamy, aby wszystkie klastry produkcyjne używały warstwy Standardowa. Rezerwuj klastry warstwy Bezpłatna dla klastrów przedprodukcyjnych. W połączeniu z usługą Azure Strefy dostępności umowa SLA serwera interfejsu API Platformy Kubernetes jest zwiększana do 99,95%. Pule węzłów i inne zasoby są objęte umową SLA.

Kompromis

Istnieje koszt dostępności w przypadku wdrażania architektury między strefami, a zwłaszcza regionami. Niektóre funkcje replikacji, takie jak replikacja geograficzna w usłudze Azure Container Registry, są dostępne w jednostkach SKU w warstwie Premium, co jest droższe. Koszt będzie również zwiększany, ponieważ opłaty za przepustowość stosowane w przypadku ruchu w różnych strefach i regionach.

Ponadto spodziewaj się dodatkowego opóźnienia sieci w komunikacji węzłów między strefami lub regionami. Mierzenie wpływu tej decyzji architektonicznej na obciążenie.

Testowanie za pomocą symulacji i wymuszonych przejść w tryb failover

Zapewnij niezawodność dzięki wymuszonym testom trybu failover z symulowanymi awariami, takimi jak zatrzymanie węzła, wyłączenie wszystkich zasobów usługi AKS w określonej strefie w celu symulowania awarii strefowej lub wywołanie awarii zależności zewnętrznej. Program Azure Chaos Studio można również wykorzystać do symulowania różnych typów awarii na platformie Azure i w klastrze.

Aby uzyskać więcej informacji, zobacz Azure Chaos Studio.

Monitorowanie i zbieranie metryk

Usługa Azure Monitor Container Insights to zalecane narzędzie do monitorowania wydajności obciążeń kontenerów, ponieważ można wyświetlać zdarzenia w czasie rzeczywistym. Przechwytuje dzienniki kontenerów z uruchomionych zasobników i agreguje je do wyświetlania. Zbiera również informacje z interfejsu API metryk dotyczące wykorzystania pamięci i procesora CPU w celu monitorowania kondycji uruchomionych zasobów i obciążeń. Można go również użyć do monitorowania wydajności w miarę skalowania zasobników. Obejmuje ona zbieranie danych telemetrycznych krytycznych do monitorowania, analizy i wizualizacji zebranych danych w celu identyfikowania trendów oraz konfigurowania alertów w celu proaktywnego powiadamiania o krytycznych problemach.

Większość obciążeń hostowanych w zasobnikach emituje metryki Prometheus. Usługa Container Insights umożliwia integrację z rozwiązaniem Prometheus w celu wyświetlania metryk aplikacji i obciążeń zbieranych z węzłów i platformy Kubernetes.

Istnieje kilka rozwiązań innych firm, które integrują się z platformą Kubernetes, z których można korzystać, takich jak Datadog, Grafana lub New Relic, jeśli organizacja już ich używa.

Dzięki usłudze AKS platforma Azure zarządza niektórymi podstawowymi usługami Kubernetes, a dzienniki składników płaszczyzny sterowania usługi AKS są implementowane na platformie Azure jako dzienniki zasobów. Zaleca się, aby większość klastrów była włączona przez cały czas, ponieważ może pomóc w rozwiązywaniu problemów z klastrem i stosunkowo niskiej gęstości dziennika:

• Rejestrowanie w klastrzeAutoscaler w celu uzyskania wglądu w operacje skalowania. Aby uzyskać więcej informacji, zobacz Pobieranie dzienników i stanu automatycznego skalowania klastra.
• Narzędzie KubeControllerManager umożliwia obserwowanie interakcji między platformą Kubernetes i płaszczyzną sterowania platformy Azure.
• KubeAudit Administracja aby mieć wgląd w działania modyfikujące klaster. Nie ma powodu, aby zarówno kubeAudit, jak i KubeAudit Administracja oba włączone, ponieważ kubeAudit jest nadzbiorem kubeAudit Administracja który obejmuje również operacje niezmodyfikujące (odczyt).
• Funkcja Guard przechwytuje inspekcje microsoft Entra ID i RBAC platformy Azure.

Inne kategorie dzienników, takie jak KubeScheduler lub KubeAudit, mogą być bardzo pomocne podczas tworzenia wczesnego klastra lub cyklu życia obciążenia, gdzie dodano skalowanie automatyczne klastra, umieszczanie i planowanie zasobników oraz podobne dane mogą pomóc w rozwiązywaniu problemów z problemami z klastrem lub operacjami obciążenia. Przechowywanie rozszerzonych dzienników rozwiązywania problemów w pełnym wymiarze czasu, po zakończeniu rozwiązywania problemów, może być uznawane za niepotrzebny koszt pozyskiwania i przechowywania w usłudze Azure Monitor.

Usługa Azure Monitor zawiera zestaw istniejących zapytań dzienników do rozpoczęcia od, ale możesz również użyć ich jako podstawy, aby ułatwić tworzenie własnych zapytań. W miarę rozwoju biblioteki można zapisywać i ponownie używać zapytań dziennika przy użyciu co najmniej jednego pakietu zapytań. Niestandardowa biblioteka zapytań pomaga zapewnić dodatkową wgląd w kondycję i wydajność klastrów usługi AKS oraz obsługiwać cele poziomu usług (SLO).

Aby uzyskać więcej informacji na temat naszych najlepszych rozwiązań monitorowania dla usługi AKS, zobacz Monitorowanie usługi Azure Kubernetes Service (AKS) przy użyciu usługi Azure Monitor.

Aby zapoznać się z zagadnieniami dotyczącymi monitorowania specyficznymi dla systemu Windows zawartymi w kontenerach systemu Windows w architekturze referencyjnej punktu odniesienia usługi AKS, zobacz artykuł towarzyszący.

Włączanie samonaprawiania

Monitoruj kondycję zasobników, ustawiając sondy liveness i Readiness. Jeśli zostanie wykryty brak odpowiedzi zasobnika, platforma Kubernetes ponownie uruchomi zasobnik. Sonda liveness określa, czy zasobnik jest w dobrej kondycji. Jeśli nie odpowie, platforma Kubernetes uruchomi ponownie zasobnik. Sonda gotowości określa, czy zasobnik jest gotowy do odbierania żądań/ruchu.

Aktualizacje klastra usługi AKS

Definiowanie strategii aktualizacji zgodnej z wymaganiami biznesowymi jest najważniejsze. Zrozumienie poziomu przewidywalności daty i godziny aktualizacji wersji klastra usługi AKS lub jego węzłów oraz żądany stopień kontroli nad tym, jakie konkretne obrazy lub pliki binarne są podstawowymi aspektami, które będą określać strategię aktualizacji klastra usługi AKS. Przewidywalność jest powiązana z dwoma głównymi właściwościami aktualizacji klastra usługi AKS, które są cyklem aktualizacji i oknem obsługi. Kontrola określa, czy aktualizacje są instalowane ręcznie, czy automatycznie. Organizacje z klastrami usługi AKS, które nie są objęte rygorystycznymi przepisami dotyczącymi zabezpieczeń, mogą rozważyć cotygodniowe lub nawet miesięczne aktualizacje, podczas gdy pozostałe muszą aktualizować poprawki oznaczone etykietami zabezpieczeń tak szybko, jak tylko są dostępne (codziennie). Organizacje, które obsługują klastry usługi AKS jako niezmienną infrastrukturę, nie aktualizują ich. Oznacza to, że ani automatyczne, ani ręczne aktualizacje nie są przeprowadzane. Zamiast tego, gdy wymagana aktualizacja stanie się dostępna, sygnatura repliki zostanie wdrożona i tylko wtedy, gdy nowe wystąpienie infrastruktury jest gotowe, stary jest opróżniany, co daje im najwyższy poziom kontroli.

Po ustaleniu strategii aktualizacji klastra usługi AKS można ją łatwo mapować na dostępne opcje aktualizacji dla węzłów usługi AKS i wersji klastra usługi AKS:

• Węzły usługi AKS:

  1. Brak/ręczne aktualizacje: dotyczy to niezmiennej infrastruktury lub ręcznej aktualizacji. Zapewnia to większą przewidywalność i kontrolę nad aktualizacjami węzłów usługi AKS.
  2. Automatyczne aktualizacje nienadzorowane: usługa AKS wykonuje natywne aktualizacje systemu operacyjnego. Zapewnia to przewidywalność, konfigurując okna obsługi dostosowane do tego, co jest dobre dla firmy. Może to być oparte na godzinach szczytu i tym, co jest najlepsze operacje mądre. Poziom kontroli jest niski, ponieważ nie można wiedzieć z wyprzedzeniem, co zostanie specjalnie zainstalowane w węźle usługi AKS.
  3. Automatyczne aktualizacje obrazu węzła: zaleca się automatyczne aktualizowanie obrazów węzłów usługi AKS, gdy nowe wirtualne dyski twarde (VHD) staną się dostępne. Projektowanie okien obsługi tak, aby były jak najwięcej dopasowane do potrzeb biznesowych. W przypadku aktualizacji wirtualnego dysku twardego z etykietą zabezpieczeń zaleca się skonfigurowanie codziennych okien obsługi, które dają najniższą przewidywalność. Regularne aktualizacje wirtualnego dysku twardego można skonfigurować za pomocą cotygodniowego okna obsługi, co dwa tygodnie lub nawet co miesiąc. W zależności od tego, czy konieczne jest użycie dysków VHD z etykietą zabezpieczeń a zwykłymi dyskami VHD w połączeniu z zaplanowanym oknem obsługi, przewidywalność waha się oferująca większą lub mniejszą elastyczność, która ma być zgodna z wymaganiami biznesowymi. Pozostawiając to zawsze do wymagań biznesowych byłoby idealne, rzeczywistość nakazuje organizacjom znalezienie punktu zwrotnych. Poziom kontroli jest niski, ponieważ nie można wcześniej wiedzieć, jakie konkretne pliki binarne zostały uwzględnione w nowym dysku VHD i nadal tego typu aktualizacje automatyczne są zalecaną opcją, ponieważ obrazy są sprawdzane przed udostępnieniem.

  Uwaga

  Aby uzyskać więcej informacji na temat konfigurowania automatycznych aktualizacji węzłów usługi AKS, zapoznaj się z obrazami systemu operacyjnego węzła automatycznego uaktualniania.

• Wersja klastra usługi AKS:

  1. Brak/ręczne aktualizacje: dotyczy to niezmiennej infrastruktury lub ręcznej aktualizacji. Zapewnia to większą przewidywalność i kontrolę nad aktualizacjami wersji klastra usługi AKS. Zaleca się skorzystanie z tej opcji, ponieważ pozostawia to pełną kontrolę, co daje możliwość przetestowania nowej wersji klastra usługi AKS (tj. od 1.14.x do 1.15.x) w niższych środowiskach przed przejściem do środowiska produkcyjnego.
  2. Aktualizacje automatyczne: klaster produkcyjny nie jest zalecany do automatycznego poprawiania ani aktualizowania w dowolny sposób (tj. od 1.16.x do 1.16.y) do nowej wersji klastra usługi AKS dostępnej bez prawidłowego testowania w niższych środowiskach. Podczas gdy nadrzędne wydania platformy Kubernetes i aktualizacje wersji klastra AKS są koordynowane, zapewniając regularną kadencję, rekomendacja jest nadal defensywna z klastrami AKS w środowisku produkcyjnym, zwiększając przewidywalność i kontrolę nad procesem aktualizacji. Przed rozważenie tej konfiguracji dla niższych środowisk w ramach doskonałości operacyjnej, co umożliwia proaktywne wykonywanie rutynowych testów w celu wykrywania potencjalnych problemów tak szybko, jak to możliwe.

Zachowaj aktualność wersji rozwiązania Kubernetes z obsługiwanymi wersjami N-2. Uaktualnienie do najnowszej wersji platformy Kubernetes ma kluczowe znaczenie, ponieważ nowe wersje są często wydawane.

Aby uzyskać więcej informacji, zobacz Regularne aktualizowanie do najnowszej wersji rozwiązania Kubernetes i Uaktualnianie klastra usługi Azure Kubernetes Service (AKS).

Powiadomienie o zdarzeniach zgłaszanych przez klaster, takich jak dostępność nowej wersji usługi AKS dla klastra, można uzyskać za pośrednictwem tematu systemowego usługi AKS dla usługi Azure Event Grid. Implementacja referencyjna wdraża ten temat systemu usługi Event Grid, dzięki czemu można subskrybować Microsoft.ContainerService.NewKubernetesVersionAvailable zdarzenie z rozwiązania powiadomień strumienia zdarzeń.

Cotygodniowe aktualizacje

Usługa AKS udostępnia nowe obrazy węzłów, które mają najnowsze aktualizacje systemu operacyjnego i środowiska uruchomieniowego. Te nowe obrazy nie są automatycznie stosowane. Odpowiadasz za podjęcie decyzji, jak często obrazy powinny zostać zaktualizowane. Zaleca się przeprowadzenie procesu uaktualniania obrazu podstawowego pul węzłów co tydzień. Aby uzyskać więcej informacji, zobacz Uaktualnianie obrazu węzła usługi Azure Kubernetes Service (AKS) w informacjach o wersji usługi AKS.

Codzienne aktualizacje

Między uaktualnieniami obrazów węzły usługi AKS pobierają i instalują poprawki systemu operacyjnego i środowiska uruchomieniowego osobno. Instalacja może wymagać ponownego uruchomienia maszyn wirtualnych węzła. Usługa AKS nie uruchomi ponownie węzłów z powodu oczekujących aktualizacji. Proces, który monitoruje węzły dla zastosowanych aktualizacji, które wymagają ponownego uruchomienia i wykonuje ponowny rozruch tych węzłów w kontrolowany sposób. Opcja typu open source to Kured (demon ponownego uruchamiania Kubernetes).

Utrzymywanie synchronizacji obrazów węzłów z najnowszą cotygodniową wersją spowoduje zminimalizowanie tych okazjonalnych żądań ponownego uruchomienia przy zachowaniu zwiększonego poziomu zabezpieczeń. Poleganie tylko na uaktualnieniach obrazu węzła zapewni zgodność usługi AKS i tygodniowe stosowanie poprawek zabezpieczeń. Podczas gdy stosowanie codziennych aktualizacji przyspieszy rozwiązywanie problemów z zabezpieczeniami, niekoniecznie zostały przetestowane w usłudze AKS. Jeśli to możliwe, użyj uaktualnienia obrazu węzła jako podstawowej cotygodniowej strategii stosowania poprawek zabezpieczeń.

Monitorowanie zabezpieczeń

Monitoruj infrastrukturę kontenerów pod kątem aktywnych zagrożeń i potencjalnych zagrożeń bezpieczeństwa:

• Włącz usługę Microsoft Defender for Containers, aby identyfikować i korygować zalecenia Defender dla Chmury dotyczące obrazów kontenerów.
• Usługa Microsoft Defender for Containers regularnie skanuje obrazy kontenerów pod kątem luk w zabezpieczeniach.
• Usługa Microsoft Defender for Containers generuje również alerty zabezpieczeń w czasie rzeczywistym dla podejrzanych działań.
• Aby uzyskać informacje o wzmacnianiu zabezpieczeń zastosowanych do hostów maszyn wirtualnych usługi AKS, zobacz Zabezpieczanie zabezpieczeń w systemie operacyjnym hosta.

Operacje klastra i obciążenia (DevOps)

Oto kilka zagadnień. Aby uzyskać więcej informacji, zobacz filar doskonałości operacyjnej.

Uruchamianie klastra

Po zakończeniu aprowizacji masz działający klaster, ale przed wdrożeniem obciążeń nadal mogą być wymagane kroki. Proces przygotowywania klastra jest nazywany ładowaniem rozruchowym i może składać się z akcji, takich jak wdrażanie wstępnie wymaganych obrazów w węzłach klastra, tworzenie przestrzeni nazw i wszystkie inne elementy spełniające wymagania danego przypadku użycia lub organizacji.

Aby zmniejszyć lukę między aprowizowanego klastra a klastrem, który został prawidłowo skonfigurowany, operatorzy klastrów powinni zastanowić się, jak będzie wyglądał ich unikatowy proces uruchamiania i przygotuje odpowiednie zasoby z wyprzedzeniem. Jeśli na przykład platforma Kured jest uruchomiona na każdym węźle przed wdrożeniem obciążeń aplikacji, operator klastra będzie chciał upewnić się, że przed zainicjowaniem obsługi administracyjnej klastra istnieje już rekord ACR zawierający docelowy obraz Kured.

Proces uruchamiania można skonfigurować przy użyciu jednej z następujących metod:

• Samodzielna konfiguracja przy użyciu czegoś takiego jak Flux lub Argo CD
• Pipelines
• Rozszerzenie klastra GitOps Flux v2

Jedną z głównych zalet korzystania z rozszerzenia klastra GitOps Flux w wersji 2 dla usługi AKS jest to, że w rzeczywistości nie ma luki między aprowizowanym klastrem a klastrem uruchomionym. Konfiguruje środowisko z solidnym fundamentem zarządzania w przyszłości, a także obsługuje włączenie tego bootstrappingu jako szablonów zasobów, aby dostosować je do strategii IaC.

Na koniec w przypadku korzystania z rozszerzenia kubectl nie jest wymagane w żadnej części procesu uruchamiania aplikacji, a użycie dostępu opartego kubectlna użyciu można zarezerwować w sytuacjach awaryjnych. Między szablonami definicji zasobów platformy Azure i uruchamianiem manifestów za pośrednictwem rozszerzenia GitOps można wykonać wszystkie normalne działania konfiguracyjne bez konieczności używania polecenia kubectl.

Izolowanie obowiązków związanych z obciążeniem

Podziel obciążenie według zespołów i typów zasobów, aby indywidualnie zarządzać każdą częścią.

Zacznij od podstawowego obciążenia zawierającego podstawowe składniki i oparte na nim. Początkowe zadanie polega na skonfigurowaniu sieci. Aprowizuj sieci wirtualne dla piasty i szprych i podsieci w tych sieciach. Na przykład szprycha ma oddzielne podsieci dla pul węzłów systemu i użytkownika oraz zasobów przychodzących. Podsieć usługi Azure Firewall w centrum.

Inną częścią może być zintegrowanie podstawowego obciążenia z identyfikatorem Entra firmy Microsoft.

Używanie infrastruktury jako kodu (IaC)

W miarę możliwości wybierz metodę deklaratywną idempotentną za pomocą podejścia imperatywnego. Zamiast pisać sekwencję poleceń, które określają opcje konfiguracji, należy użyć składni deklaratywnej, która opisuje zasoby i ich właściwości. Jedną z opcji jest szablony usługi Azure Resource Manager (ARM). Innym jest Terraform.

Upewnij się, że podczas aprowizowania zasobów zgodnie z zasadami zarządzania. Na przykład podczas wybierania odpowiednich rozmiarów maszyn wirtualnych zachowaj ograniczenia kosztów, opcje strefy dostępności, aby spełnić wymagania aplikacji.

Jeśli musisz napisać sekwencję poleceń, użyj interfejsu wiersza polecenia platformy Azure. Te polecenia obejmują szereg usług platformy Azure i można je zautomatyzować za pomocą skryptów. Interfejs wiersza polecenia platformy Azure jest obsługiwany w systemach Windows i Linux. Inną opcją dla wielu platform jest program Azure PowerShell. Wybór zależy od preferowanego zestawu umiejętności.

Przechowywanie i przechowywanie skryptów wersji oraz plików szablonów w systemie kontroli źródła.

Ciągła integracja/ciągłe wdrażanie obciążenia

Potoki dla przepływu pracy i wdrażania muszą mieć możliwość ciągłego kompilowania i wdrażania aplikacji. Aktualizacje należy bezpiecznie i szybko wdrożyć i wycofać w przypadku wystąpienia problemów.

Strategia wdrażania musi obejmować niezawodny i zautomatyzowany potok ciągłego dostarczania (CD). Zmiany obrazów kontenerów obciążenia powinny być automatycznie wdrażane w klastrze.

W tej architekturze wybraliśmy funkcję GitHub Actions do zarządzania przepływem pracy i wdrażaniem. Inne popularne opcje to Usługi Azure DevOps Services i Jenkins.

Ciągła integracja/ciągłe wdrażanie klastra

Pobierz plik programu Visio z tą architekturą.

Zamiast używać podejścia imperatywnego, takiego jak kubectl, użyj narzędzi, które automatycznie synchronizują zmiany klastra i repozytorium. Aby zarządzać przepływem pracy, takim jak wydanie nowej wersji i walidacja tej wersji przed wdrożeniem w środowisku produkcyjnym, rozważ przepływ usługi GitOps.

Istotną częścią przepływu ciągłej integracji/ciągłego wdrażania jest uruchamianie nowo aprowizowanego klastra. Podejście GitOps jest przydatne w tym celu, co umożliwia operatorom deklaratywne definiowanie procesu bootstrapping w ramach strategii IaC i wyświetlanie konfiguracji odzwierciedlonej w klastrze automatycznie.

W przypadku korzystania z usługi GitOps agent jest wdrażany w klastrze, aby upewnić się, że stan klastra jest skoordynowany z konfiguracją przechowywaną w prywatnym repozytorium Git. Jednym z takich agentów jest strumień, który używa co najmniej jednego operatora w klastrze do wyzwalania wdrożeń wewnątrz platformy Kubernetes. Funkcja Flux wykonuje następujące zadania:

• Monitoruje wszystkie skonfigurowane repozytoria.
• Wykrywa nowe zmiany konfiguracji.
• Wyzwala wdrożenia.
• Aktualizacje żądaną konfigurację uruchomioną na podstawie tych zmian.

Można również ustawić zasady, które określają sposób wdrażania tych zmian.

Oto przykład pokazujący, jak zautomatyzować konfigurację klastra za pomocą metodyki GitOps i strumienia:

Pobierz plik programu Visio z tą architekturą.

1. Deweloper zatwierdza zmiany w kodzie źródłowym, takie jak pliki YAML konfiguracji, które są przechowywane w repozytorium git. Zmiany są następnie wypychane do serwera git.

2. Strumień działa w zasobniku wraz z obciążeniem. Platforma Flux ma dostęp tylko do odczytu do repozytorium git, aby upewnić się, że platforma Flux stosuje zmiany tylko zgodnie z żądaniem deweloperów.

3. Platforma Flux rozpoznaje zmiany w konfiguracji i stosuje te zmiany przy użyciu poleceń kubectl.

4. Deweloperzy nie mają bezpośredniego dostępu do interfejsu API Kubernetes za pośrednictwem narzędzia kubectl.

5. Zasady gałęzi na serwerze Git. Dzięki temu wielu deweloperów może zatwierdzić zmianę za pośrednictwem żądania ściągnięcia przed zastosowaniem go do środowiska produkcyjnego.

Chociaż metodyki GitOps i Flux można skonfigurować ręcznie, zaleca się użycie rozszerzenia klastra Flux w wersji 2 dla usługi AKS.

Strategie wdrażania obciążeń i klastrów

Wdróż dowolną zmianę (składniki architektury, obciążenie, konfiguracja klastra) w co najmniej jednym przedprodukcyjnym klastrze usługi AKS. W ten sposób zasymuluje to, że zmiany mogą rozwikłać problemy przed wdrożeniem w środowisku produkcyjnym.

Uruchom testy/walidacje na każdym etapie przed przejściem do następnego, aby upewnić się, że aktualizacje można wypchnąć do środowiska produkcyjnego w sposób wysoce kontrolowany i zminimalizować zakłócenia przed nieprzewidzianymi problemami z wdrażaniem. To wdrożenie powinno być zgodne z podobnym wzorcem co środowisko produkcyjne przy użyciu tego samego potoku funkcji GitHub Actions lub operatorów Flux.

Zaawansowane techniki wdrażania, takie jak wdrażanie niebieski-zielony, testowanie A/B i wydania Canary, będą wymagały dodatkowego procesu i potencjalnie narzędzi. Flagger to popularne rozwiązanie typu open source, które ułatwia rozwiązywanie problemów z zaawansowanymi scenariuszami wdrażania.

Zarządzanie kosztami

Zacznij od przejrzenia listy kontrolnej projektu optymalizacji kosztów i listy zaleceń opisanych w witrynie Well Architected Framework for AKS. Skorzystaj z kalkulatora cen platformy Azure, aby oszacować koszty usług używanych w architekturze. Inne najlepsze rozwiązania opisano w sekcji Optymalizacja kosztów w witrynie Microsoft Azure Well-Architected Framework.

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.

Aby zapoznać się z zagadnieniami dotyczącymi zarządzania kosztami specyficznymi dla obciążeń opartych na systemie Windows uwzględnionych w kontenerach systemu Windows w architekturze referencyjnej punktu odniesienia usługi AKS, zobacz artykuł towarzyszący.

Inicjowanie

• W przypadku wdrażania, zarządzania i operacji klastra Kubernetes nie są związane żadne koszty związane z usługą AKS. Wpływ na koszty mają wystąpienia maszyn wirtualnych, magazyn, dane dziennika i zasoby sieciowe używane przez klaster. Rozważ wybranie tańszych maszyn wirtualnych dla pul węzłów systemowych. Jednostka SKU DS2_v2 jest typowym typem maszyny wirtualnej dla puli węzłów systemowych.

• Nie ma tej samej konfiguracji dla środowisk deweloperskich/testowych i produkcyjnych. Obciążenia produkcyjne mają dodatkowe wymagania dotyczące wysokiej dostępności i są zwykle droższe. Ta konfiguracja nie jest konieczna w środowisku deweloperskim/testowym.

• W przypadku obciążeń produkcyjnych dodaj umowę SLA dotyczącą czasu pracy. Istnieją jednak oszczędności w przypadku klastrów przeznaczonych dla obciążeń deweloperskich/testowych lub eksperymentalnych, w przypadku których dostępność nie jest wymagana. Na przykład cel slo jest wystarczający. Ponadto jeśli obciążenie go obsługuje, rozważ użycie dedykowanych pul węzłów typu spot z uruchomionymi maszynami wirtualnymi typu spot.

  W przypadku obciążeń nieprodukcyjnych, które obejmują usługę Azure SQL Database lub aplikacja systemu Azure Service w ramach architektury obciążenia usługi AKS, oceń, czy kwalifikujesz się do korzystania z subskrypcji usługi Azure Dev/Test w celu otrzymywania rabatów na usługi.

• Zamiast rozpoczynać się od ponadwymiarowego klastra w celu spełnienia wymagań dotyczących skalowania, aprowizuj klaster z minimalną liczbą węzłów i włącz narzędzie do automatycznego skalowania klastra w celu monitorowania i podejmowania decyzji dotyczących rozmiaru.

• Ustaw żądania zasobnika i limity, aby umożliwić usłudze Kubernetes przydzielanie zasobów węzłów o wyższej gęstości, aby sprzęt był używany do pojemności.

• Włączenie diagnostyki w klastrze może zwiększyć koszt.

• Jeśli obciążenie istnieje przez długi czas, możesz zatwierdzić jedno lub trzy lata wystąpienia zarezerwowane maszyn wirtualnych, aby zmniejszyć koszty węzłów. Aby uzyskać więcej informacji, zobacz Zarezerwowane maszyny wirtualne.

• Użyj tagów podczas tworzenia pul węzłów. Tagi są przydatne podczas tworzenia raportów niestandardowych w celu śledzenia kosztów. Tagi umożliwiają śledzenie sumy wydatków i mapowanie dowolnego kosztu na określony zasób lub zespół. Ponadto jeśli klaster jest współużytkowany między zespołami, twórz raporty obciążenia zwrotnego dla poszczególnych konsumentów w celu zidentyfikowania taryfowych kosztów usług udostępnionych w chmurze. Aby uzyskać więcej informacji, zobacz Określanie defektu, etykiety lub tagu dla puli węzłów.

• Transfery danych między strefami dostępności w regionie nie są bezpłatne. Jeśli obciążenie jest wieloregionowe lub istnieją transfery między strefami dostępności, należy oczekiwać dodatkowych kosztów przepustowości. Aby uzyskać więcej informacji, zobacz Traffic across billing zones and regions (Ruch między strefami rozliczeniowymi i regionami).

• Utwórz budżety, aby pozostać w granicach ograniczeń kosztów zidentyfikowanych przez organizację. Jednym ze sposobów jest utworzenie budżetów za pomocą usługi Azure Cost Management. Możesz również utworzyć alerty, aby otrzymywać powiadomienia po przekroczeniu określonych progów. Aby uzyskać więcej informacji, zobacz Tworzenie budżetu przy użyciu szablonu.

Monitor

Aby monitorować koszt całego klastra wraz z kosztami obliczeniowymi, zbierać również informacje o kosztach magazynowania, przepustowości, zapory i dzienników. Platforma Azure udostępnia różne pulpity nawigacyjne do monitorowania i analizowania kosztów:

• Azure Advisor

• Azure Cost Management

Najlepiej monitorować koszty w czasie rzeczywistym lub co najmniej w regularnym tempie, aby podjąć działania przed końcem miesiąca, gdy koszty są już obliczane. Ponadto monitoruj trend miesięczny w miarę upływu czasu, aby utrzymać budżet.

Aby podejmować decyzje oparte na danych, należy określić, który zasób (poziom szczegółowy) wiąże się z największym kosztem. Warto również dobrze zrozumieć mierniki, które są używane do obliczania użycia poszczególnych zasobów. Analizując metryki, możesz określić, czy platforma jest na przykład nadmierna. Mierniki użycia są widoczne w metrykach usługi Azure Monitor.

Optymalizacja

Działanie na temat zaleceń dostarczonych przez usługę Azure Advisor. Istnieją inne sposoby optymalizacji:

• Włącz narzędzie do automatycznego skalowania klastra w celu wykrywania i usuwania nie w pełni wykorzystanych węzłów w puli węzłów.

• Wybierz niższą jednostkę SKU dla pul węzłów, jeśli obciążenie go obsługuje.

• Jeśli aplikacja nie wymaga skalowania w czasie, rozważ zmianę rozmiaru klastra na odpowiedni rozmiar, analizując metryki wydajności w czasie.

• Jeśli obciążenie go obsługuje, przeskaluj pule węzłów użytkownika do 0 węzłów, gdy nie ma oczekiwań, aby były uruchomione. Ponadto, jeśli w klastrze nie ma żadnych obciążeń, które nie mają być uruchamiane, rozważ użycie funkcji uruchamiania/zatrzymywania usługi AKS, aby zamknąć wszystkie zasoby obliczeniowe, w tym pulę węzłów systemowych i płaszczyznę sterowania usługi AKS.

Aby uzyskać inne informacje dotyczące kosztów, zobacz Cennik usługi AKS.

Następne kroki

Kontynuuj poznawanie architektury punktu odniesienia usługi AKS:

• Aby dowiedzieć się więcej na temat hostowania mikrousług w punkcie odniesienia usługi AKS, zobacz Zaawansowana architektura mikrousług usługi Azure Kubernetes Service (AKS).
• Aby wdrożyć punkt odniesienia usługi AKS w wielu regionach, zobacz Punkt odniesienia usługi AKS dla klastrów wieloregionowych.
• Aby wdrożyć punkt odniesienia usługi AKS w środowisku PCI-DSS 3.2.1, zobacz Klaster regulowany usługi AKS dla pci-DSS 3.2.1.
• Aby dowiedzieć się więcej o zagadnieniach dotyczących dodawania kontenerów systemu Windows do architektury referencyjnej, zobacz artykuł towarzyszący: Kontenery systemu Windows w architekturze referencyjnej punktu odniesienia usługi AKS

Dowiedz się więcej o usłudze AKS

• Zapoznaj się z planem działania produktu AKS, zobacz Azure Kubernetes Service Roadmap on GitHub (Harmonogram działania usługi Azure Kubernetes Service w witrynie GitHub).
• Jeśli potrzebujesz odświeżenia na platformie Kubernetes, ukończ wprowadzenie do platformy Kubernetes i Opracowywanie i wdrażanie aplikacji na ścieżce szkoleniowej platformy Kubernetes .

Powiązane zasoby

Zapoznaj się z następującymi powiązanymi przewodnikami:

• Przegląd platformy Azure Well-Architected Framework dla usługi Azure Kubernetes Service (AKS)
• Akcelerator strefy docelowej usługi AKS, który jest implementacją w skali przedsiębiorstwa na podstawie tej architektury. Akcelerator pomaga skonfigurować środowisko platformy Azure w spójny i powtarzany sposób przy użyciu infrastruktury jako kodu (IaC) dla wdrożenia usługi Azure Kubernetes Service (AKS).
• Przewodnik po operacjach usługi Azure Kubernetes Services (AKS) z dnia 2

Zapoznaj się z następującymi powiązanymi architekturami:

• Architektura mikrousług w usłudze Azure Kubernetes Service
• Używanie usługi Azure Firewall do ochrony klastra usługi Azure Kubernetes Service (AKS)
• GitOps dla usługi Azure Kubernetes Service
• Przesyłanie strumieniowe danych za pomocą usługi AKS