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

Ten artykuł zawiera zalecaną architekturę infrastruktury bazowej w celu wdrożenia klastra usługi Azure Kubernetes Service (AKS). Korzysta z naszych zasad projektowania i opiera się na najlepszych rozwiązaniach dotyczących architektury usługi AKS z platformy Azure Well-Architected Framework. Ten artykuł pomaga kierować wieloma różnymi grupami międzydyscyplinarne, takimi jak sieci, zabezpieczenia i zespoły tożsamości podczas wdrażania tej infrastruktury ogólnego przeznaczenia.

Ta architektura nie koncentruje się na obciążeniu. Koncentruje się on na samym klastrze usługi AKS. Te informacje są minimalnym zalecanym punktem odniesienia dla większości klastrów usługi AKS. Integruje się z usługami platformy Azure, które zapewniają wgląd, zapewniają topologię sieci, która obsługuje rozwój wielu regionów i zabezpiecza ruch w klastrze.

Wymagania biznesowe wpływają na architekturę docelową i mogą się różnić między różnymi kontekstami aplikacji. Weź pod uwagę architekturę jako punkt wyjścia dla etapów przedprodukcyjnych i produkcyjnych.

Kubernetes to zaawansowany ekosystem, który wykracza poza platformę Azure i technologie firmy Microsoft. Podczas wdrażania klastra usługi AKS należy podjąć odpowiedzialność za wiele decyzji dotyczących sposobu projektowania i obsługi klastra. Uruchomienie klastra usługi AKS obejmuje kombinację składników zamkniętych źródeł od różnych dostawców, w tym firmy Microsoft; i składniki open source z ekosystemu Kubernetes. Często zmienia się krajobraz i może być konieczne regularne ponowne zapoznanie się z decyzjami. Przyjmując platformę Kubernetes, uznajesz, że obciążenie potrzebuje swoich możliwości i że zespół ds. obciążeń jest przygotowany do ciągłego inwestowania.

Możesz użyć implementacji tej architektury w usłudze GitHub: implementacja referencyjna punktu odniesienia usługi AKS. Użyj go jako alternatywnego punktu wyjścia i skonfiguruj architekturę referencyjną 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 używa topologii sieci piasty i szprych. Wdróż piastę i szprychy w oddzielnych sieciach wirtualnych połączonych za pośrednictwem komunikacji równorzędnej sieci wirtualnych. Ta topologia ma kilka zalet. Użyj tej topologii, aby:

• Włącz zarządzanie segregowane. Możesz zastosować ład i przestrzegać zasady najniższych uprawnień. Obsługuje również koncepcję strefy docelowej platformy Azure z rozdzieleniem obowiązków.

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

• Podaj topologie piasty i szprych. W przyszłości można rozwinąć topologie sieci piasty i szprych oraz zapewnić izolację obciążenia.

• Użyj usługi zapory aplikacji internetowej, aby ułatwić sprawdzanie przepływu ruchu HTTP dla wszystkich aplikacji internetowych.

• Zapewnianie obsługi obciążeń obejmujących wiele subskrypcji.

• Rozszerz architekturę. Aby obsłużyć nowe funkcje lub obciążenia, można dodać nowe szprychy zamiast przeprojektować topologię sieci.

• Obsługa udostępniania zasobów, takich jak strefy zapory i systemu nazw domen (DNS) między sieciami.

• Dopasowanie do strefy docelowej 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 uzyskać więcej informacji na temat zmian projektu sieci zawartych w kontenerach systemu Windows w architekturze referencyjnej punktu odniesienia usługi AKS, zobacz Kontenery systemu Windows w usłudze AKS.

Sieć wirtualna koncentratora

Sieć wirtualna piasty jest centralnym punktem łączności i możliwości obserwacji. W tej architekturze koncentrator zawiera następujące elementy:

• Usługa Azure Firewall z globalnymi zasadami zapory zdefiniowanymi przez centralne zespoły IT w celu wymuszania zasad zapory dla całej organizacji.
• Usługa Azure Bastion umożliwia zdalny dostęp do maszyn wirtualnych.
• Podsieć bramy na potrzeby łączności sieci VPN.
• Usługa Azure Monitor umożliwia obserwowanie sieci.

W sieci architektura ma trzy podsieci.

Podsieć do hostowania usługi Azure Firewall

Usługa Azure Firewall to zarządzana usługa zapory. Wystąpienie usługi Azure Firewall zabezpiecza wychodzący ruch sieciowy. Bez tej warstwy zabezpieczeń ruch może komunikować się ze złośliwą usługą inną niż Microsoft, która może eksfiltrować poufne dane obciążenia. Użyj usługi Azure Firewall Manager , aby centralnie wdrożyć i skonfigurować wiele wystąpień usługi Azure Firewall oraz zarządzać zasadami usługi Azure Firewall dla tego typu architektury sieci wirtualnej koncentratora.

Podsieć do hostowania bramy

Ta podsieć jest symbolem zastępczym bramy sieci VPN lub bramy usługi Azure 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 Azure Bastion możesz bezpiecznie uzyskiwać dostęp do zasobów platformy Azure bez uwidaczniania zasobów w Internecie. Ta podsieć służy tylko do zarządzania i operacji.

Sieć wirtualna szprychy

Sieć wirtualna szprychy zawiera klaster usługi AKS i inne powiązane zasoby. Szprycha ma następujące podsieci.

Podsieć do hostowania bramy aplikacja systemu Azure

Application Gateway to internetowy moduł równoważenia obciążenia ruchu, który działa w warstwie 7. Implementacja referencyjna używa jednostki SKU usługi Application Gateway w wersji 2, która umożliwia zaporę aplikacji internetowej platformy Azure. Zapora aplikacji internetowej zabezpiecza ruch przychodzący z typowych ataków ruchu internetowego, 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 speł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ą AKS.

Podsieć do hostowania węzłów klastra

Usługa AKS obsługuje dwie pule węzłów, które są oddzielnymi grupami 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 Azure Private Link

Utwórz połączenia usługi Private Link dla usług Azure Container Registry i Azure Key Vault, aby użytkownicy mogli uzyskiwać dostęp do tych usług za pomocą prywatnego punktu końcowego w sieci wirtualnej będącej szprychą. Prywatne punkty końcowe nie wymagają dedykowanej podsieci. Prywatne punkty końcowe można również umieścić w sieci wirtualnej koncentratora. W implementacji punktu odniesienia punkty końcowe są wdrażane w dedykowanej podsieci w sieci wirtualnej będącej szprychą. Takie podejście zmniejsza ruch przechodzący przez równorzędne połączenie sieciowe. Przechowuje ona zasoby należące do klastra w tej samej sieci wirtualnej. Możesz również zastosować szczegółowe reguły 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ą.

Ta architektura referencyjna korzysta z wielu metod sieciowych, z których każda wymaga przestrzeni adresowej IP:

• Sieć wirtualna platformy Azure, która jest używana dla zasobów, takich jak węzły klastra, prywatne punkty końcowe i usługa Application Gateway.
• Klaster używa nakładki azure CNI, która przydziela adresy IP zasobnikom z oddzielnej przestrzeni adresowej do sieci wirtualnej platformy Azure.

Przestrzeń adresowa IP sieci wirtualnej

Przestrzeń adresowa sieci wirtualnej platformy Azure powinna być wystarczająco duża, aby przechowywać wszystkie podsieci. Uwzględnij wszystkie jednostki odbierające ruch. Platforma Kubernetes przydziela adresy IP dla tych jednostek z przestrzeni adresowej podsieci. Podczas planowania adresów IP sieci wirtualnej platformy Azure należy wziąć pod uwagę te punkty.

• Uaktualnienia: usługa AKS regularnie aktualizuje węzły, aby upewnić się, że podstawowe maszyny wirtualne są aktualne na temat funkcji zabezpieczeń i innych poprawek systemu. 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. Upewnij się, że masz wystarczającą przestrzeń adresową dla tych tymczasowych adresów IP węzła.

  W tej architekturze zasobniki są przydzielane adresom IP z poziomu przestrzeni adresowej zasobnika nakładki usługi Azure CNI, w tym podczas aktualizacji stopniowej. Takie podejście zmniejsza ogólną liczbę adresów IP używanych z sieci wirtualnej platformy Azure w porównaniu z innymi podejściami sieciowymi platformy Kubernetes.

• 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%. Potrzebujesz cztery razy więcej adresów dla wszystkich węzłów skalowanych w poziomie.

  Ponieważ ta architektura korzysta z nakładki usługi Azure CNI, skalowalność zasobników nie ma wpływu na przestrzeń adresową sieci wirtualnej.

• Adresy usługi Private Link: należy uwzględnić adresy wymagane do komunikacji z innymi usługami platformy Azure za pośrednictwem usługi Private Link. Ta architektura ma dwa adresy przypisane do linków do usługi Container Registry i Key Vault.

• Zarezerwowane adresy IP: platforma Azure rezerwuje określone adresy do użycia. Nie można ich przypisać.

Poprzednia lista nie jest wyczerpująca. Jeśli projekt ma inne zasoby wpływające na liczbę dostępnych adresów IP, uwzględnij te adresy.

Ta architektura jest przeznaczona dla pojedynczego obciążenia. W produkcyjnym klastrze usługi AKS zawsze oddzielaj pulę węzłów systemowych od puli węzłów użytkownika. Po uruchomieniu wielu obciążeń w klastrze możesz odizolować pule węzłów użytkownika od siebie. Gdy to zrobisz, powoduje to 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.

Przestrzeń adresowa IP zasobnika

Nakładka CNI platformy Azure przypisuje adresy IP do zasobników przy użyciu dedykowanej przestrzeni adresowej, która jest oddzielona od przestrzeni adresowej używanej w sieci wirtualnej. Użyj przestrzeni adresowej IP, która nie nakłada się na sieć wirtualną ani żadnych równorzędnych sieci wirtualnych. Jeśli jednak utworzysz wiele klastrów usługi AKS, możesz bezpiecznie użyć tej samej przestrzeni adresowej zasobnika w każdym klastrze.

Każdy węzeł ma przypisaną przestrzeń adresową /24 dla swoich zasobników, dlatego należy upewnić się, że przestrzeń adresowa zasobnika jest wystarczająco duża, aby umożliwić tyle bloków /24, ile jest potrzebnych dla liczby węzłów w klastrze. Pamiętaj, aby uwzględnić wszystkie węzły tymczasowe utworzone podczas uaktualniania lub operacji skalowania w poziomie. Jeśli na przykład używasz przestrzeni adresowej /16 dla zakresu CIDR, klaster może wzrosnąć do maksymalnie około 250 węzłów.

Każdy węzeł obsługuje maksymalnie 250 zasobników, a ten limit obejmuje wszystkie zasobniki, które są tymczasowo tworzone podczas uaktualniania.

Aby uzyskać więcej informacji, zobacz wskazówki dotyczące planowania adresów IP dla nakładki usługi Azure CNI

Inne zagadnienia dotyczące przestrzeni adresów IP

Aby zapoznać się z pełnym zestawem zagadnień dotyczących sieci dla tej architektury, zobacz Topologia sieci bazowej usługi AKS. Aby uzyskać informacje dotyczące planowania adresowania IP dla klastra usługi AKS, zobacz Planowanie adresowania IP dla klastra.

Aby uzyskać więcej informacji na temat zagadnień dotyczących planowania adresów IP uwzględnionych w kontenerach systemu Windows w architekturze referencyjnej punktu odniesienia usługi AKS, zobacz Kontenery systemu Windows w usłudze AKS.

Dodatki i funkcje w wersji zapoznawczej

Platforma Kubernetes i usługa AKS stale ewoluują dzięki szybszym cyklom 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. Oto różnica między nimi:

• Zespół usługi AKS opisuje funkcje w wersji zapoznawczej dostarczane i ulepszane , ponieważ wiele funkcji w wersji zapoznawczej pozostanie w tym stanie tylko przez kilka miesięcy przed przejściem do fazy ogólnej dostępności.

• Dodatki i rozszerzenia usługi AKS zapewniają dodatkowe, obsługiwane funkcje. Usługa AKS zarządza instalacją, konfiguracją i cyklem życia.

Ta architektura punktu odniesienia nie obejmuje każdej funkcji w wersji zapoznawczej ani dodatku. Zamiast tego obejmuje 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 jest odpowiednio zmieniana. Istnieją inne funkcje w wersji zapoznawczej lub dodatki usługi AKS, które warto ocenić w klastrach przedprodukcyjnych. Te funkcje mogą zwiększyć bezpieczeństwo, możliwości zarządzania lub inne wymagania. W przypadku dodatków innych niż Microsoft 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 obrazów do klastra należy wziąć pod uwagę te punkty.

• Uwierzytelnij klaster, aby ściągnąć obraz.

• Zaimportuj publiczny obraz do rejestru kontenerów, który jest zgodny z celem poziomu usługi (SLO), jeśli używasz obrazu publicznego. W przeciwnym razie obraz może podlegać nieoczekiwanym problemom z dostępnością. Jeśli obraz jest niedostępny, gdy jest potrzebny, może to spowodować problemy operacyjne. Poniżej przedstawiono niektóre korzyści wynikające z używania prywatnego rejestru kontenerów, takiego jak usługa Azure Container Registry, zamiast rejestru publicznego:

  • Możesz zablokować nieautoryzowany dostęp do obrazów.
  • Nie masz zależności publicznych.
  • Dostęp do dzienników ściągnięcia obrazu można uzyskać, aby monitorować działania i klasyfikację problemów z łącznością.
  • Możesz skorzystać ze zintegrowanego skanowania kontenerów i zgodności obrazów.

• Ściąganie obrazów z autoryzowanych rejestrów. To ograniczenie można wymusić za pomocą usługi Azure Policy. W tej implementacji referencyjnej klaster pobiera tylko obrazy z wystąpienia usługi Container Registry, które wdraża.

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. Duże węzły minimalizują ślad usług uruchamianych na wszystkich węzłach, takich jak monitorowanie i rejestrowanie.

• Wybierz odpowiedni typ maszyny wirtualnej, jeśli masz określone wymagania dotyczące obciążenia. Na przykład może być potrzebny produkt zoptymalizowany pod kątem pamięci dla niektórych obciążeń lub produkt przyspieszany przez procesor GPU dla innych. Aby uzyskać więcej informacji, zobacz Rozmiary maszyn wirtualnych na platformie Azure.

• Wdróż co najmniej dwa węzły. Dzięki temu obciążenie ma wzorzec wysokiej dostępności z dwiema replikami. Usługa AKS umożliwia zmianę liczby węzłów bez ponownego tworzenia klastra.

• Zaplanuj rzeczywiste rozmiary węzłów dla obciążenia na podstawie wymagań określonych przez zespół projektowy. Na podstawie wymagań biznesowych ta architektura używa DS4_v2 dla obciążenia produkcyjnego. Aby obniżyć koszty, możesz zmniejszyć rozmiar do DS3_v2, co jest minimalnym zaleceniem.

• Załóżmy, że obciążenie zużywa do 80% każdego węzła podczas planowania pojemności klastra. 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.

Wybór systemu operacyjnego

Większość klastrów usługi AKS używa systemu Linux jako systemu operacyjnego dla pul węzłów. W tej implementacji referencyjnej używamy platformy Azure z systemem Linux, która jest uproszczoną, wzmocnioną dystrybucją systemu Linux, która została dostrojona dla platformy Azure. Możesz użyć innej dystrybucji systemu Linux, takiej jak Ubuntu, jeśli wolisz, lub jeśli masz wymagania, których platforma Azure Linux nie może spełnić.

Usługa AKS obsługuje również pule węzłów z systemem operacyjnym Windows Server. Istnieją specjalne wymagania dotyczące niektórych aspektów klastra z systemem Windows. Aby dowiedzieć się więcej na temat architektury puli węzłów systemu Windows, zobacz Running Windows containers on AKS (Uruchamianie kontenerów systemu Windows w usłudze AKS).

Jeśli masz obciążenie składające się z różnych technologii, możesz użyć różnych systemów operacyjnych w różnych pulach węzłów. Jeśli jednak nie potrzebujesz różnych systemów operacyjnych dla obciążenia, zalecamy użycie jednego systemu operacyjnego dla wszystkich pul węzłów obciążenia.

Integrowanie identyfikatora Entra firmy Microsoft dla klastra

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

• Dostęp wewnętrzny. Rozważ dostęp usługi AKS do składników platformy Azure, takich jak infrastruktura sieciowa, usługa Container Registry i usługa Key Vault. Autoryzuj tylko zasoby, do których klaster powinien mieć dostęp.
• Dostęp zewnętrzny. Zapewnij tożsamościom dostęp 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.

Z dwóch metod zarządzania dostępem usługi AKS do platformy Azure zalecamy tożsamości zarządzane. W przypadku jednostek usługi należy zarządzać wpisami tajnymi i obracać je ręcznie lub programowo. Dzięki tożsamościom zarządzanym identyfikator Entra firmy Microsoft zarządza uwierzytelnianiem i terminowym rotacją wpisów tajnych.

Zalecamy włączenie i użycie tożsamości zarządzanych, aby klaster mógł wchodzić w interakcje z zewnętrznymi zasobami platformy Azure za pomocą identyfikatora Entra firmy Microsoft. Nawet jeśli nie korzystasz od razu z integracją identyfikatora Entra firmy Microsoft, możesz dołączyć ją później.

Domyślnie istnieją dwie podstawowe tożsamości , które są używane przez klaster: tożsamość klastra i tożsamość kubelet. Składniki płaszczyzny sterowania usługi AKS używają tożsamości klastra do zarządzania zasobami klastra, w tym modułami równoważenia obciążenia ruchu przychodzącego, oraz zarządzanymi publicznymi adresami IP usługi AKS. Tożsamość kubelet uwierzytelnia się za pomocą usługi Container Registry. Niektóre dodatki obsługują również uwierzytelnianie przy użyciu tożsamości zarządzanej.

Tożsamości zarządzane należy używać, gdy klaster musi ściągać obrazy z rejestru kontenerów. Ta akcja wymaga, aby klaster pobierał poświadczenia rejestru. Jeśli nie używasz tożsamości zarządzanej, możesz przechowywać te informacje w postaci obiektu tajnego kubernetes i używać imagePullSecrets ich do pobierania wpisu tajnego. Nie zalecamy tego podejścia ze względu na złożoność zabezpieczeń. Nie tylko potrzebujesz wcześniejszej wiedzy o wpisie tajnym, ale także musisz przechowywać ten wpis tajny w potoku DevOps. Innym powodem, dla którego nie zalecamy tego podejścia, 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 problemy.

W tej architekturze klaster uzyskuje dostęp do zasobów platformy Azure zabezpieczonych przez firmę Microsoft Entra ID, a klaster 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 wykonywanych przez klaster. Klaster uwierzytelnia się w usłudze Microsoft Entra ID, a następnie jest dozwolony lub blokowany dostęp na podstawie przypisanych do niego ról. Oto kilka przykładów z tej implementacji referencyjnej, w której wbudowane role platformy Azure są przypisywane do klastra:

• Rola Współautor sieci. Zarządza możliwością sterowania siecią wirtualną będącej szprychą. Dzięki temu przypisaniu roli tożsamość przypisana przez system klastra usługi AKS może współdziałać z dedykowaną podsiecią dla wewnętrznej usługi kontrolera ruchu przychodzącego.

• Rola wydawcy metryk monitorowania. Zarządza możliwością wysyłania metryk do usługi Azure Monitor przez klaster.

• Rola AcrPull. Zarządza możliwością ściągania obrazów z określonych wystąpień usługi Azure Container Registry przez klaster.

Dostęp do klastra

Integracja z firmą Microsoft Entra upraszcza również zabezpieczenia dostępu zewnętrznego. Na przykład możesz chcieć użyć narzędzia kubectl. W ramach początkowego kroku możesz uruchomić az aks get-credentials polecenie , aby pobrać poświadczenia klastra. Microsoft Entra ID uwierzytelnia twoją tożsamość 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 obsługuje dostęp do platformy Kubernetes przy użyciu identyfikatora Entra firmy Microsoft na dwa sposoby. Pierwszym z nich jest użycie identyfikatora Entra firmy Microsoft jako dostawcy tożsamości zintegrowanego z natywnym systemem kontroli dostępu opartej na rolach Kubernetes. Druga metoda używa natywnej kontroli dostępu opartej na rolach platformy Azure do kontrolowania dostępu do klastra. W poniższych sekcjach opisano oba podejścia.

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

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

• Zestaw uprawnień zdefiniowanych przy użyciu Role obiektu lub ClusterRole dla uprawnień dla całego klastra.

• Powiązania, które przypisują użytkowników i grupy, którzy mają uprawnienia do wykonywania akcji. Zdefiniuj powiązania przy użyciu RoleBinding obiektu lub ClusterRoleBinding .

Platforma Kubernetes ma wbudowane role, takie jak cluster-admin, edit i view. 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 w przeglądach dostępu firmy Microsoft entra uwzględnisz grupy firmy Microsoft dla klastra i przestrzeni nazw.

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

Zamiast korzystać z natywnej kontroli dostępu opartej na rolach ClusterRoleBindings platformy Kubernetes i RoleBindings autoryzacji ze zintegrowanym uwierzytelnianiem firmy Microsoft Entra, zalecamy używanie kontroli dostępu opartej na rolach platformy Azure i przypisań ról platformy Azure. To podejście wymusza kontrole autoryzacji w klastrze. Te role można nawet przypisywać w zakresach grupy zarządzania, subskrypcji lub grupy zasobów. Wszystkie klastry w zakresie dziedziczą następnie 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 oparta na rolach platformy Azure dla autoryzacji na platformie Kubernetes).

Konta lokalne

Usługa AKS obsługuje natywne uwierzytelnianie użytkowników platformy Kubernetes. Nie zalecamy używania tej metody w celu zapewnienia dostępu użytkowników do klastrów. Ta metoda jest oparta na certyfikatach i wykonywana poza podstawowym dostawcą tożsamości, co sprawia, że scentralizowana kontrola dostępu użytkowników i nadzór są trudne. 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 do kont klastra lokalnego jest jawnie wyłączony, gdy system wdraża klaster.

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 musi uzyskać dostęp do tych plików, zasobnik uwierzytelnia się w odniesieniu do zasobu jako tożsamości zarządzanej platformy Azure.

W tej implementacji referencyjnej Tożsamość obciążeń Microsoft Entra w usłudze AKS udostępnia tożsamości zarządzane dla zasobników. Takie podejście integruje się 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 Federacja tożsamości obciążenia.

Wybieranie modelu sieci

Usługa AKS obsługuje wiele modeli sieciowych, w tym kubenet, CNI i Azure CNI Overlay. Modele CNI są bardziej zaawansowanymi modelami i są wysoce wydajne. Podczas komunikacji między zasobnikami wydajność sieci CNI jest podobna do wydajności maszyn wirtualnych w sieci wirtualnej. Usługa CNI oferuje również rozszerzoną kontrolę zabezpieczeń, ponieważ umożliwia korzystanie z zasad sieciowych platformy Azure. Zalecamy model sieci oparty na sieci CNI.

W modelu CNI bez nakładki każdy zasobnik pobiera adres IP z przestrzeni adresowej podsieci. Zasoby w tej samej sieci (lub zasobach równorzędnych) mogą uzyskiwać dostęp do zasobników bezpośrednio za pośrednictwem ich adresu IP. Translator adresów sieciowych (NAT) nie jest wymagany do routingu tego ruchu.

W tej implementacji referencyjnej używamy nakładki usługi Azure CNI, która przydziela tylko adresy IP z podsieci puli węzłów dla węzłów i używa wysoce zoptymalizowanej warstwy nakładki dla adresów IP zasobników. Ponieważ nakładka CNI platformy Azure używa mniejszej liczby adresów IP sieci wirtualnej niż wiele innych podejść, zalecamy użycie jej w przypadku wdrożeń ograniczonych adresami IP.

Aby uzyskać informacje o modelach, zobacz Wybieranie modelu sieciowego interfejsu sieci kontenera do użycia i porównania modeli sieciowych kubenet i Azure Container Networking Interface.

Wdrażanie zasobów ruchu przychodzącego

Zasoby ruchu przychodzącego platformy Kubernetes obsługują routing i dystrybucję dla ruchu przychodzącego do klastra. Istnieją dwie części zasobów ruchu przychodzącego:

• Wewnętrzny moduł równoważenia obciążenia zarządzany przez usługę AKS. 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.

  Ta architektura korzysta z usługi Azure Load Balancer. Usługa Load Balancer znajduje się poza klastrem w podsieci dedykowanej dla zasobów przychodzących. Odbiera ruch z usługi Application Gateway i że komunikacja odbywa się za pośrednictwem zabezpieczeń warstwy transportu (TLS). Aby uzyskać więcej informacji na temat szyfrowania TLS dla ruchu przychodzącego, zobacz Przepływ ruchu przychodzącego.

• Kontroler ruchu przychodzącego. W tym przykładzie użyto 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ę następujące kwestie.

• Ogranicz kontroler ruchu przychodzącego do określonego zakresu operacji w ramach decyzji projektowych. 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 w przypadku awarii węzł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 izoluje obciążenia i zasobniki systemowe.

• 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 usługi Application Gateway.

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

• 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 ma przyznane 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 uzyskać więcej informacji na temat projektu ruchu przychodzącego dla kontenerów systemu Windows w usłudze AKS w architekturze referencyjnej punktu odniesienia, zobacz Kontenery systemu Windows w usłudze AKS.

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. Opcje annotations, tlsi entrypoints wskazują, że trasy są obsługiwane za pośrednictwem protokołu HTTPS. Opcja middlewares określa, że dozwolony jest tylko ruch z podsieci usługi Application Gateway. Odpowiedzi używają 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 tej architekturze przepływ sieci obejmuje następujące elementy:

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

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

• Ruch między zasobnikami. Ten ruch obejmuje komunikację między kontrolerem ruchu przychodzącego a obciążeniem. Jeśli obciążenie składa się z wielu aplikacji wdrożonych w klastrze, komunikacja między tymi aplikacjami również należy do tej kategorii.

• Ruch zarządzania 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 szyfrów. Włączone jest ścisłe dopasowywanie nazwy serwera (SNI). Kompleksowa konfiguracja protokołu TLS odbywa się za pośrednictwem usługi Application Gateway przy użyciu dwóch różnych certyfikatów TLS, jak pokazano na poniższym diagramie.

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 usługi Application Gateway. Ten ruch jest szyfrowany, aby zapewnić, że ruch między przeglądarką klienta i bramą nie może być sprawdzany ani zmieniany.

2. Usługa Application Gateway ma zintegrowaną zaporę aplikacji internetowej i negocjuje uzgadnianie protokołu TLS dla bicycle.contoso.comusługi , umożliwiając tylko bezpieczne szyfry. Usługa Application Gateway to punkt zakończenia protokołu TLS, który jest ważny, ponieważ zapora aplikacji internetowej usługi Application Gateway musi sprawdzać odpowiedź w postaci zwykłego tekstu. Usługa Key Vault przechowuje certyfikat TLS. Klaster uzyskuje do niego dostęp za pomocą tożsamości zarządzanej przypisanej przez użytkownika zintegrowanej z usługą Application Gateway. Aby uzyskać więcej informacji, zobacz Zakończenie szyfrowania TLS z certyfikatami usługi Key Vault.

   Usługa Application Gateway przetwarza reguły inspekcji zapory aplikacji internetowej i uruchamia reguły routingu, które przekazują ruch do skonfigurowanego zaplecza.

3. W miarę jak ruch przechodzi z usługi Application Gateway do zaplecza, jest on ponownie szyfrowany przy użyciu innego certyfikatu TLS, który jest symbolem wieloznacznymi dla *.aks-ingress.contoso.comusługi , ponieważ jest przekazywany do wewnętrznego modułu równoważenia obciążenia. To ponowne szyfrowanie pomaga zagwarantować, że niezabezpieczony ruch 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 to kolejny punkt 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 Key Vault, a sterownik interfejsu magazynu kontenerów (CSI) instaluje je w klastrze. Aby uzyskać więcej informacji, zobacz Dodawanie zarządzania wpisami tajnymi.

Możesz zaimplementować pełny ruch TLS na każdym przeskoku za pośrednictwem zasobnika obciążenia. Pamiętaj, aby zmierzyć wydajność, opóźnienie i efekty operacyjne 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. Takie podejście minimalizuje obciążenie związane z zarządzaniem obciążeniami i obciążeniem ze względu na niską wydajność sieci. Wymagania dotyczące obciążenia i zgodności określają, gdzie wykonujesz 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. Możesz też użyć własnego podobnego wirtualnego urządzenia sieciowego. Nie zalecamy używania innych opcji ruchu wychodzącego, takich jak usługa Azure NAT Gateway lub serwer proxy HTTP, ponieważ nie zapewniają inspekcji ruchu sieciowego. W przypadku kontroli zerowej zaufania i możliwości inspekcji ruchu cały ruch wychodzący z klastra przechodzi przez zaporę. Tę konfigurację można zaimplementować za pomocą tras zdefiniowanych przez użytkownika (UDR). Następny przeskok trasy to prywatny adres IP usługi Azure Firewall. 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 usługi Azure Firewall jest użycie funkcji serwera proxy HTTP usługi AKS. Cały ruch, który opuszcza klaster, przechodzi do adresu IP serwera proxy HTTP, który przekazuje ruch lub porzuca go.

W przypadku każdej metody zapoznaj się z wymaganymi regułami ruchu sieciowego ruchu wychodzącego dla usługi AKS.

Wyjątkiem od kontrolki Zero Trust jest to, że klaster musi komunikować się z innymi zasobami platformy Azure. Na przykład klaster może wymagać ściągnięcia zaktualizowanego obrazu z rejestru kontenerów lub wpisów tajnych z usługi Key Vault. W tych scenariuszach zalecamy użycie usługi Private Link. Zaletą jest to, że określone podsieci docierają bezpośrednio do usługi, a ruch między klastrem a usługami nie przechodzi 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 lub produkty platformy Azure 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 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 przechodzi przez statyczne adresy IP zapory, możesz dodać te adresy do listy dozwolonych adresów IP usługi. Jedną z wad jest to, że usługa Azure Firewall potrzebuje większej liczby reguł, aby upewnić się, że zezwala tylko na ruch z określonej podsieci. Podczas planowania wielu adresów IP dla ruchu wychodzącego za pomocą usługi Azure Firewall należy uwzględnić te adresy. W przeciwnym razie można uzyskać dostęp do wyczerpania portów. Aby uzyskać więcej informacji na temat planowania wielu adresów IP, zobacz Tworzenie usługi Azure Firewall z wieloma adresami IP.

Aby uzyskać informacje na temat zagadnień dotyczących ruchu wychodzącego specyficznego dla systemu Windows w kontenerach systemu Windows w architekturze referencyjnej punktu odniesienia usługi AKS, zobacz Kontenery systemu Windows w usłudze AKS.

Ruch zasobnik-zasobnik

Domyślnie zasobnik może akceptować ruch z dowolnego innego zasobnika w klastrze. Użyj platformy Kubernetes NetworkPolicy , aby ograniczyć ruch sieciowy między zasobnikami. Stosowanie zasad w sposób rozsądny lub 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 podczas aprowizacji klastra, ponieważ nie można go dodać później. Istnieje kilka opcji dotyczących technologii implementujących NetworkPolicyprogram . Zalecamy zasady sieciowe platformy Azure, które wymagają interfejsu azure Container Networking Interface (CNI). Aby uzyskać więcej informacji, zobacz następującą notatkę. 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 aparatami zasad sieciowych platformy Azure.

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 w celu skalowania klastra. Przykłady tych zasobów obejmują pulę agentów kompilacji w potoku DevOps, wystąpienie usługi Azure Bastion w podsieci usługi Azure Bastion i same pule węzłów. Zamiast akceptować ten ruch zarządzania ze wszystkich adresów IP, użyj funkcji zakresów adresów IP autoryzowanych przez usługę AKS, aby zezwolić tylko na ruch z autoryzowanych zakresów adresów IP do serwera interfejsu API

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

W przypadku innej 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 i nigdy nie jest uwidoczniony 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 Key Vault. Zaletą jest to, że zarządzany magazyn kluczy obsługuje rotację wpisów tajnych. Zapewnia silne szyfrowanie i dziennik inspekcji dostępu. Ponadto przechowuje podstawowe wpisy tajne z potoku wdrażania. W tej architekturze zapora usługi Key Vault jest włączona i skonfigurowana, a usługa Private Link jest używana podczas nawiązywania połączenia z zasobów na platformie Azure, które muszą uzyskiwać dostęp do wpisów tajnych i certyfikatów.

Usługa 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 uzyskać więcej informacji na temat sposobu uzyskiwania przez usługę Application Gateway dostępu do certyfikatów TLS 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 przypisywanie 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 Access Key Vault by using RBAC (Uzyskiwanie dostępu do usługi 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, użyj 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. Ta implementacja używa usługi Key Vault ze sterownikiem CSI magazynu wpisów tajnych. Dodatek pobiera certyfikat TLS z usługi Key Vault i ładuje sterownik w zasobniku z uruchomionym kontrolerem ruchu przychodzącego. Ta operacja występuje podczas tworzenia zasobnika, a wolumin przechowuje zarówno klucze publiczne, jak i prywatne.

Magazyn obciążeń

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

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

Zarządzanie zasadami

Skutecznym sposobem zarządzania klastrem usługi AKS jest wymuszanie ładu za pomocą zasad. Platforma Kubernetes implementuje zasady za pomocą programu Open Policy Agent (OPA) Gatekeeper. W przypadku usługi AKS dostarczaj zasady za pośrednictwem usługi Azure Policy. Każda zasada ma zastosowanie do wszystkich klastrów w swoim zakresie. Usługa OPA Gatekeeper obsługuje wymuszanie zasad w klastrze i rejestruje wszystkie kontrole zasad. Zmiany zasad nie zostaną natychmiast odzwierciedlone w klastrze, więc spodziewaj się pewnych opóźnień.

Aby zarządzać klastrami usługi AKS, możesz użyć usługi Azure Policy do:

• Zapobiegaj lub ograniczaj wdrażanie klastrów usługi AKS w grupie zasobów lub subskrypcji. Stosowanie standardów dla organizacji. Można na przykład postępować zgodnie z konwencją nazewnictwa lub określić tag.
• 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 również inicjatywami, czy 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. Zalecamy wybranie inicjatywy i wybranie innych zasad dla klastra i zasobów, takich jak Container Registry, Application Gateway lub Key Vault, które współdziałają z klastrem. Wybierz zasady na podstawie wymagań organizacji.

• Czy chcesz przeprowadzić inspekcję lub odmówić akcji? W trybie inspekcji akcja jest dozwolona, ale oznaczona jako niezgodna. Mieć procesy do sprawdzania niezgodnych stanów w regularnym tempie i podjęcia niezbędnych działań. 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. Zalecamy 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 uzyskać więcej informacji, 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.

• Czy przypisujesz zasady platformy Azure 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 są uwzględniane w środowisku przedprodukcyjnym.

Ta implementacja referencyjna umożliwia usłudze Azure Policy po utworzeniu klastra usługi AKS. Restrykcyjna inicjatywa jest przypisywana w trybie inspekcji , aby uzyskać wgląd w niezgodności.

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 wystąpienia usługi Container Registry. 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 oraz dzienników dla azure-policy zasobników i azure-policy-webhook w kube-system przestrzeni nazw.

Aby uzyskać więcej informacji na temat zagadnień dotyczących usługi Azure Policy specyficznych dla systemu Windows, zobacz artykuł Dotyczący kontenerów systemu Windows w usłudze AKS dotyczący zarządzania zasadami .

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 za pomocą skalowania automatycznego zasobników poziomych. Gdy platforma Kubernetes nie może już zaplanować większej liczby zasobników, liczba węzłów musi zostać zwiększona 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.

Zarówno skalowanie automatyczne, jak i podejście ręczne wymagają 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 jedna metoda ma być powiadamiana, 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 witryny Azure Portal.

Zalecamy podejście do skalowania automatycznego, 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ć więcej informacji 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 zalecamy ustawienie minimalnej i maksymalnej liczby replik. 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 użycie procesora CPU. Definicja HorizontalPodAutoscaler określa wartości docelowe dla metryk. Na przykład specyfikacje określają docelowe użycie procesora CPU. Gdy zasobniki są uruchomione, kontroler HPA używa interfejsu API metryk platformy Kubernetes do sprawdzania użycia 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 narzędzie HPA sprawdza przed zakończeniem operacji skalowania. Wynik może być niepoprawnym obliczeniem współczynnika. Aby uzyskać więcej informacji, zobacz Cooldown of scaling events (Chłodne skalowanie zdarzeń).

Jeśli obciążenie jest sterowane zdarzeniami, popularną opcją typu open source jest automatyczne skalowanie oparte na zdarzeniach (KEDA) platformy Kubernetes. Rozważ użycie usługi KEDA, jeśli źródło zdarzeń, takie jak kolejka komunikatów, napędza obciążenie, a nie obciążenie związane z procesorem CPU lub związane z pamięcią. Usługa KEDA obsługuje wiele źródeł zdarzeń lub skalowania. Użyj listy źródeł zdarzeń, które usługa KEDA może skalować w narzędziach skalowania KEDA. Lista zawiera narzędzie skalowania usługi Azure Monitor, które jest wygodnym sposobem 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. Dodaj go podczas aprowizacji klastra. Potrzebujesz oddzielnego modułu skalowania automatycznego klastra dla każdej puli węzłów użytkownika.

Harmonogram Kubernetes wyzwala narzędzie do automatycznego skalowania klastra. 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 dwie ze względu na prostotę obciążenia.

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

Aby uzyskać informacje o zagadnieniach dotyczących skalowania specyficznych dla systemu Windows uwzględnionych w tej architekturze referencyjnej punktu odniesienia, zobacz artykuł Kontenery systemu Windows w usłudze AKS .

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

Aby zachować ciągłość działalności biznesowej, zdefiniuj cel slo dla infrastruktury i aplikacji. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące definiowania celów niezawodności. Zapoznaj się z warunkami umowy dotyczącej poziomu usług (SLA) dla usługi AKS w najnowszej umowie SLA dla Usługi online artykułu.

Węzły klastra

Aby spełnić minimalny poziom dostępności dla obciążeń, potrzebujesz wielu węzłów w puli węzłów. Jeśli węzeł ulegnie awarii, inny węzeł w tej samej puli węzłów i klaster może kontynuować uruchamianie aplikacji. W celu uzyskania niezawodności zalecamy użycie trzech węzłów 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 aplikację od usług systemowych, umieszczając ją 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. Zalecamy użycie tagów, etykiet i defektów w celu zidentyfikowania puli węzłów i zaplanowanie obciążenia. Upewnij się, że pula węzłów systemu jest skażona za pomocą defektuCriticalAddonsOnly.

Regularne utrzymanie klastra, takie jak aktualizacje terminowe, mają kluczowe znaczenie dla niezawodności. Zalecamy również monitorowanie kondycji zasobników za pośrednictwem sond.

Dostępność zasobnika

Określ wymagania dotyczące zasobów zasobnika: zalecamy określenie wymagań dotyczących zasobów zasobnika we wdrożeniach. Harmonogram może następnie odpowiednio zaplanować zasobnik. Niezawodność jest znacznie ograniczona, 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 pomóc w zapewnieniu, że wymagana liczba replik zasobników istnieje do obsługi oczekiwanego obciążenia aplikacji.

Ustawianie przydziałów zasobów w przestrzeniach nazw obciążenia: limit przydziału zasobów w przestrzeni nazw pomaga zapewnić prawidłowe ustawianie żą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: ustawianie żądań i limitów umożliwia platformie Kubernetes efektywne przydzielanie zasobów procesora CPU i pamięci do zasobników i umożliwia uzyskanie większej gęstości kontenera w węźle. Żądania i limity mogą również zwiększyć niezawodność, jednocześnie zmniejszając koszty ze względu na lepsze użycie sprzętu.

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

Żądania i 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

Aby chronić przed niektórymi typami awarii, użyj stref dostępności, 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ą. Usługa AKS zarządza operacjami i konfiguracją zestawu skalowania. Poniżej przedstawiono niektóre zagadnienia dotyczące włączania wielu stref:

• Cała infrastruktura: wybierz region obsługujący strefy dostępności. Aby uzyskać więcej informacji, zobacz Ograniczenia. Aby uzyskać umowę SLA czasu pracy, musisz wybrać warstwę Standardowa lub Premium. Umowa SLA dotycząca czasu pracy jest większa w przypadku korzystania ze stref dostępności.

• Klaster: strefy dostępności można ustawić tylko podczas tworzenia puli węzłów. Nie można ich 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 obejmuje żądane strefy, takie jak pule węzłów. Jeśli nie używasz obsługi stref w klastrze, składniki płaszczyzny sterowania nie mają 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 została aprowizowana. Jeśli wystąpi awaria, 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 jedną, dwie i trzy. Inne zasoby infrastruktury, takie jak Azure Firewall i Application Gateway, są również wdrażane w tym samym regionie z obsługą wielu stref. Replikacja geograficzna jest włączona dla usługi Container Registry.

Wiele regionów

Po włączeniu stref dostępności nie jest wystarczające pokrycie w mało prawdopodobnym przypadku, w którym cały region ulegnie awarii. Aby uzyskać większą dostępność, uruchom wiele klastrów usługi AKS w różnych regionach.

• Preferuj sparowane regiony , gdy są dostępne. Zaletą korzystania z sparowanych regionów jest niezawodność podczas aktualizacji platformy. Platforma Azure zapewnia, że tylko jeden region w parze jest aktualizowany jednocześnie. Niektóre regiony nie mają par. Jeśli region nie jest sparowany, nadal możesz wdrożyć rozwiązanie z wieloma regionami, wybierając inne regiony do użycia. Rozważ użycie potoku ciągłej integracji i ciągłego dostarczania (CI/CD), który można skonfigurować do organizowania odzyskiwania po awarii regionu. Niektóre narzędzia DevOps, takie jak Flux, mogą ułatwić wdrażanie w wielu regionach.

• Podaj lokalizację, w której usługa nadmiarowa ma swoje wystąpienie pomocnicze, jeśli zasób platformy Azure obsługuje nadmiarowość geograficzną. Na przykład przez włączenie replikacji geograficznej dla usługi Container Registry automatycznie replikuje obrazy do wybranych regionów świadczenia usługi Azure. Zapewnia również stały dostęp do obrazów, nawet jeśli region podstawowy ulegnie awarii.

• Wybierz router ruchu, który może dystrybuować ruch między strefami lub regionami, w zależności od wymagań. Ta architektura wdraża moduł równoważenia obciążenia, ponieważ może dystrybuować ruch niezwiązany z siecią w różnych strefach. Jeśli musisz dystrybuować ruch między regionami, rozważ usługę Azure Front Door. Aby uzyskać inne opcje, zobacz Wybieranie modułu równoważenia obciążenia.

Odzyskiwanie po awarii

Jeśli wystąpi awaria w regionie podstawowym, w idealnym przypadku możesz szybko utworzyć nowe wystąpienie w innym regionie. Poniżej przedstawiono kilka rekomendacji:

• Użyj wielu regionów. Jeśli region podstawowy ma sparowany region, użyj tej pary. Jeśli nie, wybierz regiony na podstawie wymagań dotyczących rezydencji danych i opóźnień.

• Użyj niestanowego obciążenia, które można wydajnie replikować. Jeśli musisz przechowywać stan w klastrze, którego nie zalecamy, pamiętaj, aby wykonać kopię zapasową danych często w innym regionie.

• Zintegruj strategię odzyskiwania, taką jak replikowanie do innego regionu, w ramach potoku DevOps, aby spełnić cel slo.

• Aprowizuj każdą usługę platformy Azure przy użyciu funkcji, które obsługują odzyskiwanie po awarii. Na przykład w tej architekturze usługa Container Registry jest włączona na potrzeby replikacji geograficznej. Jeśli region ulegnie awarii, nadal możesz ściągnąć obrazy z zreplikowanego regionu.

• Wdróż infrastrukturę jako kod, w tym klaster usługi AKS i wszystkie inne potrzebne składniki. Jeśli musisz wdrożyć w innym regionie, możesz ponownie użyć skryptów lub szablonów, aby utworzyć identyczne wystąpienie.

Tworzenie kopii zapasowej klastra

W przypadku wielu architektur można aprowizować nowy klaster i zwracać go do stanu operacyjnego za pomocą uruchamiania klastra opartego na operacjach Git, a następnie wdrażania aplikacji. Jeśli jednak stan zasobu krytycznego, taki jak mapy konfiguracji, zadania i wpisy tajne, których nie można przechwycić w procesie uruchamiania, rozważ strategię odzyskiwania. Zalecamy uruchamianie bezstanowych obciążeń na platformie Kubernetes. Jeśli architektura obejmuje stan oparty na dysku, należy również rozważyć strategię odzyskiwania dla tej zawartości.

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

VMware Velero to przykład typowego rozwiązania do tworzenia kopii zapasowych Kubernetes, które można zainstalować i zarządzać bezpośrednio. Możesz też użyć rozszerzenia kopii zapasowej usługi AKS, aby zapewnić zarządzaną implementację 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, która obejmuje dodatkowe zasoby platformy Azure do zarządzania, monitorowania, kupowania i zabezpieczania. Te zasoby mogą obejmować konto usługi Azure Storage, magazyn usługi Azure Backup i konfigurację oraz funkcję zaufanego dostępu. Zamiast tego operacje git połączone z zamiarem uruchomienia bezstanowego obciążenia to rozwiązanie odzyskiwania.

Wybierz i zweryfikuj rozwiązanie do tworzenia kopii zapasowych, które spełnia twój cel biznesowy, w tym zdefiniowany cel punktu odzyskiwania i cel czasu odzyskiwania. Zdefiniuj proces odzyskiwania w elemecie Runbook zespołu i przećwicz go dla wszystkich obciążeń krytycznych dla działania firmy.

Umowa SLA serwera interfejsu API platformy Kubernetes

Usługę AKS można używać jako bezpłatnej usługi, 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 warstwę Bezpłatna dla klastrów przedprodukcyjnych i warstwę Premium tylko dla obciążeń o znaczeniu krytycznym. W przypadku korzystania ze stref dostępności platformy Azure umowa SLA serwera interfejsu API platformy Kubernetes jest wyższa. Pule węzłów i inne zasoby są objęte własnymi umowami SLA. Aby uzyskać więcej informacji na temat określonych umów SLA dla każdej usługi, zobacz umowa SLA dla Usługi online.

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 Container Registry, są dostępne w jednostkach SKU w warstwie Premium, co jest droższe. W przypadku wdrożeń obejmujących wiele regionów koszt zwiększa się również dlatego, że opłaty za przepustowość są naliczane podczas przenoszenia ruchu między regionami.

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

Przetestuj niezawodność rozwiązania za pomocą wymuszonego testowania trybu failover z symulowanymi awariami. Symulacje mogą obejmować zatrzymywanie węzła, obniżanie wszystkich zasobów usługi AKS w określonej strefie w celu symulowania awarii strefowej lub wywoływania awarii zależności zewnętrznej. Za pomocą usługi Azure Chaos Studio można również symulować różne typy awarii na platformie Azure i w klastrze.

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

Monitorowanie i zbieranie dzienników i metryk

Zalecamy usługę Azure Monitor container insights , aby monitorować wydajność 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 o użyciu pamięci i procesora CPU w celu monitorowania kondycji uruchomionych zasobów i obciążeń. Możesz również użyć szczegółowych informacji o kontenerach, aby monitorować wydajność w miarę skalowania zasobników. Obejmuje ona dane telemetryczne, które mają kluczowe znaczenie dla monitorowania, analizy i wizualizacji zebranych danych. Usługa Container Insights identyfikuje trendy i umożliwia skonfigurowanie alertów w celu otrzymywania proaktywnych powiadomień o krytycznych problemach.

Schemat dziennika ContainerLogV2 jest przeznaczony do przechwytywania dzienników kontenera z zasobników Kubernetes w usprawnionej metodzie. Wpisy dziennika są konsolidowane w tabeli ContainerLogV2 w obszarze roboczym usługi Azure Log Analytics.

Większość obciążeń hostowanych w zasobnikach emituje metryki Prometheus. Usługa Container Insights może integrować się z rozwiązaniem Prometheus. Metryki aplikacji i obciążenia zebrane z węzłów i platformy Kubernetes można wyświetlić.

Niektóre rozwiązania firmy innej niż Microsoft integrują się z platformą Kubernetes, taką jak Datadog, Grafana lub New Relic. Jeśli więc twoja organizacja korzysta już z tych rozwiązań, możesz z nich korzystać.

Dzięki usłudze AKS platforma Azure zarządza niektórymi podstawowymi usługami Kubernetes. Platforma Azure implementuje dzienniki składników płaszczyzny sterowania usługi AKS jako dzienniki zasobów. Zalecamy włączenie następujących opcji w większości klastrów. Opcje mogą pomóc w rozwiązywaniu problemów z klastrem i mają stosunkowo niską gęstość dziennika.

• ClusterAutoscaler: zyskaj wgląd w operacje skalowania przy użyciu rejestrowania. Aby uzyskać więcej informacji, zobacz Pobieranie dzienników i stanu automatycznego skalowania klastra.
• KubeControllerManager: zyskaj wgląd w interakcję między platformą Kubernetes i płaszczyzną sterowania platformy Azure.
• kube-audit-admin: zyskaj wgląd w działania modyfikujące klaster. Nie ma powodu zarówno, jak kube-audit i kube-audit-admin włączonego. kube-audit jest nadzbiorem kube-audit-admin , który obejmuje również niemodyfikowane (odczyt) operacje.
• guard: przechwyć inspekcje microsoft Entra ID i Azure RBAC.

Przydatne może być włączenie innych kategorii dzienników, takich jak KubeScheduler lub kube-audit, podczas opracowywania wczesnego klastra lub cyklu życia obciążenia. Dodane skalowanie automatyczne klastra, umieszczanie i planowanie zasobników oraz podobne dane mogą pomóc w rozwiązywaniu problemów z operacjami klastra lub obciążenia. Jednak jeśli po zakończeniu rozwiązywania problemów zachowasz rozszerzone dzienniki rozwiązywania problemów po zakończeniu rozwiązywania problemów, możesz ponieść niepotrzebne koszty pozyskiwania i przechowywania danych 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ń zapewnia większą wgląd w kondycję i wydajność klastrów usługi AKS. Obsługuje ona osiąganie celów SLO.

Aby uzyskać więcej informacji na temat naszych najlepszych rozwiązań monitorowania dla usługi AKS, zobacz Monitorowanie usługi AKS za pomocą usługi Azure Monitor.

Aby uzyskać więcej informacji na temat zagadnień dotyczących monitorowania specyficznych dla systemu Windows, zobacz Kontenery systemu Windows w usłudze AKS.

Metryki sieci

Podstawowe metryki sieci na poziomie klastra są dostępne za pośrednictwem platformy natywnej i metryk Prometheus. Aby uwidocznić metryki sieci na poziomie węzła, można jeszcze bardziej wykorzystać możliwość obserwacji sieci usługi AKS przy użyciu metryk rozwiązania Prometheus. Większość klastrów powinna obejmować możliwość obserwowania sieci, aby zapewnić dodatkowe możliwości rozwiązywania problemów z siecią oraz wykrywać nieoczekiwane użycie sieci lub problemy na poziomie węzła.

Implementacja referencyjna korzysta ze szczegółowych informacji o kontenerach usługi Azure Monitor, która zbiera również niektóre metryki związane z siecią. Implementacja referencyjna wyłącza zbieranie metryk ze szczegółowych informacji o kontenerze usługi Azure Monitor, a zamiast tego zbiera metryki obserwacji sieci przy użyciu obszaru roboczego usługi Azure Monitor z zarządzanym rozwiązaniem Prometheus.

W przypadku obciążeń, które są bardzo wrażliwe na utraty pakietów protokołu TCP (Transmission Control Protocol) lub User Datagram Protocol (UDP), opóźnienia lub ciśnienia DNS, metryki sieci na poziomie zasobnika są ważne. W usłudze AKS można znaleźć ten poziom szczegółowości z zaawansowaną funkcją obserwacji sieci. Większość obciążeń nie wymaga tej głębokości wglądu w sieć. Nie należy włączać zaawansowanej możliwości obserwowania sieci, chyba że zasobniki wymagają wysoce zoptymalizowanej sieci z czułością na poziomie pakietu.

Optymalizacja kosztów rejestrowania

Implementacja referencyjna konfiguruje tabelę ContainerLogV2 do używania planu podstawowego jako punktu początkowego. Usługa Microsoft Defender for Containers i alerty utworzone na potrzeby implementacji referencyjnej nie wysyłają zapytań do tej tabeli, więc plan podstawowy może być opłacalny, ponieważ zmniejsza koszty pozyskiwania.

W miarę rozwoju wymagań dotyczących woluminu dziennika i zapytań wybierz najbardziej ekonomiczny plan tabeli dla Twoich potrzeb. Jeśli rozwiązanie stanie się intensywnie korzystające z odczytu, w którym zapytania często skanują dane tabeli, domyślny plan analizy może być bardziej odpowiedni. Plan analizy eliminuje opłaty za zapytania, co optymalizuje się pod kątem scenariuszy, w których aktywność zapytań przewyższa koszty pozyskiwania. Monitorując wzorce użycia i dostosowując plany tabel zgodnie z potrzebami, można osiągnąć równowagę między kosztami i funkcjami rozwiązania do monitorowania.

Aby uzyskać więcej informacji, zobacz Wybieranie planu tabeli na podstawie użycia danych w obszarze roboczym usługi Log Analytics.

Włączanie samonaprawiania

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

Rutynowe aktualizacje klastrów usługi AKS

Częścią codziennych operacji dla klastrów Kubernetes jest wykonywanie rutynowych aktualizacji platformy i systemu operacyjnego. W każdym klastrze usługi AKS istnieją trzy warstwy aktualizacji:

• Wersja kubernetes (na przykład Kubernetes 1.30.3 do 1.30.7 lub Kubernetes 1.30.7 do 1.31.1), która może pochodzić ze zmianami i wycofaniem interfejsu API Kubernetes. Zmiany wersji w tej warstwie wpływają na cały klaster.
• Obraz wirtualnego dysku twardego (VHD) w każdym węźle, który łączy aktualizacje systemu operacyjnego i aktualizacje składników usługi AKS. Te aktualizacje są testowane pod kątem wersji rozwiązania Kubernetes klastra. Zmiany wersji w tej warstwie są stosowane na poziomie puli węzłów i nie mają wpływu na wersję platformy Kubernetes.
• Własny natywny proces aktualizacji systemu operacyjnego, taki jak Windows Update lub apt. Dostawca systemu operacyjnego dostarcza te aktualizacje bezpośrednio i nie jest testowany względem wersji rozwiązania Kubernetes klastra. Zmiany wersji w tej warstwie mają wpływ na jeden węzeł i nie mają wpływu na wersję platformy Kubernetes.

Każda z tych warstw jest kontrolowana niezależnie. Decydujesz, jak każda warstwa jest obsługiwana dla klastrów obciążenia. Wybierz częstotliwość aktualizowania poszczególnych klastrów usługi AKS, pul węzłów lub węzłów (cykl). Ponadto wybierz dni lub godziny stosowania aktualizacji ( okno obsługi). Wybierz, czy aktualizacje są instalowane ręcznie, czy automatycznie, czy w ogóle. Podobnie jak obciążenie uruchamiane w klastrze wymaga bezpiecznej praktyki wdrażania, dlatego należy przeprowadzić aktualizacje klastrów.

Aby uzyskać kompleksową perspektywę dotyczącą stosowania poprawek i uaktualniania, zobacz Wskazówki dotyczące poprawek i uaktualniania usługi AKS w przewodniku obsługi dnia 2 usługi AKS. Skorzystaj z poniższych informacji, aby uzyskać zalecenia dotyczące linii bazowej w odniesieniu do tej architektury.

Niezmienna infrastruktura

Obciążenia, które obsługują klastry usługi AKS jako niezmienną infrastrukturę, nie aktualizują klastrów automatycznie ani ręcznie. Ustaw uaktualnienie obrazu węzła none klastra na none. W tej konfiguracji ponosisz wyłączną odpowiedzialność za wszystkie uaktualnienia we wszystkich warstwach. Gdy wymagana aktualizacja stanie się dostępna, należy przetestować aktualizację w środowisku przedprodukcyjnym i ocenić jego zgodność w nowym klastrze. Następnie wdróż sygnaturę repliki produkcyjnej zawierającą zaktualizowaną wersję usługi AKS i dyski VHD puli węzłów. Gdy nowy klaster produkcyjny będzie gotowy, stary klaster zostanie opróżniony i ostatecznie zostanie zlikwidowany.

Niezmienna infrastruktura z regularnymi wdrożeniami nowej infrastruktury jest jedyną sytuacją, w której klaster produkcyjny nie powinien mieć zastosowanej strategii uaktualniania w miejscu. Wszystkie inne klastry powinny mieć strategię uaktualniania w miejscu.

Uaktualnienia w miejscu

Obciążenia, które nie obsługują klastrów usługi AKS jako niezmiennej infrastruktury, powinny regularnie aktualizować uruchomione klastry, aby obsługiwać wszystkie trzy warstwy. Dopasuj proces aktualizacji do wymagań obciążenia. Skorzystaj z poniższych zaleceń jako punktu wyjścia do projektowania rutynowego procesu aktualizacji.

• Zaplanuj funkcję planowanej konserwacji usługi AKS, aby można było kontrolować uaktualnienia w klastrze. Ta funkcja umożliwia wykonywanie aktualizacji, z natury ryzykownych operacji, w kontrolowanym czasie w celu zmniejszenia wpływu nieoczekiwanej awarii.
• Skonfiguruj budżety zakłóceń zasobników, tak aby aplikacja pozostała stabilna podczas uaktualniania stopniowego. Nie należy jednak konfigurować budżetów tak agresywnie, że blokują uaktualnienia węzłów, ponieważ większość uaktualnień wymaga procesu kordonu i opróżniania w każdym węźle.
• Potwierdź limit przydziału zasobów platformy Azure i dostępność zasobów. Uaktualnienia w miejscu wdrażają nowe wystąpienia węzłów, znane jako węzły przepięcia, zanim stare węzły zostaną usunięte. Oznacza to, że limit przydziału platformy Azure i przestrzeń adresów IP musi być dostępna dla nowych węzłów. Wartość wzrostu 33% jest dobrym punktem wyjścia dla większości obciążeń.
• Przetestuj zgodność z narzędziami, takimi jak siatki usług lub agenci zabezpieczeń dodani do klastra. Przetestuj składniki obciążenia, takie jak kontrolery ruchu przychodzącego, siatki usług i zasobniki obciążenia. Wykonywanie testów w środowisku przedprodukcyjnym.

Uaktualnienia w miejscu dla węzłów

Użyj kanału automatycznego uaktualniania NodeImage dla uaktualnień obrazu systemu operacyjnego węzła. Ten kanał umożliwia skonfigurowanie klastra w celu zaktualizowania dysku VHD w każdym węźle za pomocą aktualizacji na poziomie węzła. Firma Microsoft testuje aktualizacje wersji usługi AKS. W przypadku węzłów systemu Windows aktualizacje są aktualizowane co miesiąc. W przypadku węzłów systemu Linux te aktualizacje są wykonywane co tydzień.

• Uaktualnienia nigdy nie zmieniają wersji usługi AKS lub Kubernetes, więc zgodność interfejsu API Kubernetes nie jest problemem.
• Jeśli używasz NodeImage jako kanału uaktualniania, uwzględnia planowane okno obsługi, które należy ustawić przez co najmniej raz w tygodniu. Ustaw go niezależnie od używanego systemu operacyjnego obrazu węzła, aby zapewnić terminowe działanie aplikacji.
• Te aktualizacje obejmują zabezpieczenia na poziomie systemu operacyjnego, zgodność i aktualizacje funkcjonalne, ustawienia konfiguracji systemu operacyjnego i aktualizacje składników usługi AKS.
• Wersje obrazów i zawarte w nich numery wersji składników są śledzone przy użyciu monitora wersji usługi AKS.

Jeśli wymagania dotyczące zabezpieczeń klastra wymagają bardziej agresywnego cyklu stosowania poprawek, a klaster może tolerować potencjalne przerwy, należy zamiast tego użyć kanału SecurityPatch uaktualniania. Firma Microsoft testuje również te aktualizacje. Aktualizacje są publikowane tylko w przypadku uaktualnień zabezpieczeń, które firma Microsoft uważa za wystarczająco ważne do wydania przed następnym zaplanowanym uaktualnieniem obrazu węzła. Gdy używasz kanału SecurityPatch , otrzymujesz również aktualizacje odebrane przez NodeImage kanał. Opcja SecurityPatch kanału nadal obsługuje okna obsługi, więc upewnij się, że okno obsługi ma częstsze luki (takie jak codziennie lub co drugi dzień), aby obsługiwać te nieoczekiwane aktualizacje zabezpieczeń.

Większość klastrów, które wykonują uaktualnienia w miejscu, powinna unikać None opcji kanału uaktualniania obrazu węzła i .Unmanaged

Aktualizacje w miejscu klastra

Platforma Kubernetes to szybko rozwijająca się platforma, a regularne aktualizacje zapewniają ważne poprawki zabezpieczeń i nowe możliwości. Ważne jest, aby zachować aktualność aktualizacji platformy Kubernetes. Należy pozostać w dwóch najnowszych wersjach lub N-2. Ważne jest, aby uaktualnić platformę Kubernetes do najnowszej wersji, ponieważ nowe wersje są często wydawane.

Większość klastrów powinna mieć możliwość przeprowadzania aktualizacji wersji usługi AKS w miejscu z wystarczającą ostrożnością i rygorem. Ryzyko przeprowadzenia uaktualnienia wersji usługi AKS w miejscu może być głównie zminimalizowane dzięki wystarczającej fazie testowania przedprodukcyjnego, weryfikacji limitu przydziału i konfiguracji budżetu zasobnika. Jednak każde uaktualnienie w miejscu może spowodować nieoczekiwane zachowanie. Jeśli uaktualnienia w miejscu są uznawane za zbyt ryzykowne dla obciążenia, zalecamy użycie podejścia blue-green klastrów usługi AKS zamiast stosowania pozostałych zaleceń.

Zalecamy unikanie funkcji automatycznego uaktualniania klastra podczas pierwszego wdrażania klastra Kubernetes. Użyj podejścia ręcznego, które zapewnia czas testowania nowej wersji klastra usługi AKS w środowiskach przedprodukcyjnych, zanim aktualizacje trafią do środowiska produkcyjnego. Takie podejście zapewnia również największy poziom przewidywalności i kontroli. Należy jednak sumiennie monitorować nowe aktualizacje platformy Kubernetes i szybko wdrażać nowe wersje w miarę ich wydawania. Lepiej jest przyjąć "bądź na bieżąco" sposób myślenia w odniesieniu do długoterminowego podejścia do wsparcia .

Powiadomienia można otrzymywać, gdy dla klastra jest dostępna nowa wersja usługi AKS, korzystając z 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ń. Przejrzyj informacje o wersji usługi AKS, aby uzyskać szczegółowe informacje o zgodności, zmianach zachowania lub wycofaniu funkcji.

W końcu możesz uzyskać pewność, że wersje platformy Kubernetes, wydania usługi AKS, klaster, jego składniki na poziomie klastra i obciążenie będą eksplorować funkcję automatycznego uaktualniania. W przypadku systemów produkcyjnych rzadko zdarzałoby się, aby kiedykolwiek wykraczać poza patchsystem . Ponadto podczas automatycznego uaktualniania wersji usługi AKS sprawdź również ustawienie wersji usługi AKS infrastruktury jako kodu (IaC) dla klastra, aby nie były synchronizowane. Skonfiguruj zaplanowane okno obsługi , aby obsługiwać operację automatycznego uaktualniania.

Monitorowanie zabezpieczeń

Monitoruj infrastrukturę kontenerów pod kątem zarówno aktywnych zagrożeń, jak i potencjalnych zagrożeń bezpieczeństwa. Oto kilka zasobów:

• Usługa Microsoft Defender for Containers umożliwia identyfikowanie i korygowanie Defender dla Chmury rekomendacji dotyczących obrazów kontenerów.
• Usługa Defender for Containers regularnie skanuje obrazy kontenerów pod kątem luk w zabezpieczeniach.
• Usługa Defender for Containers generuje również alerty zabezpieczeń w czasie rzeczywistym dla podejrzanych działań.
• Pojęcia dotyczące zabezpieczeń usługi AKS dla aplikacji i klastrów zawierają szczegółowe informacje o sposobie ochrony całego kompleksowego potoku przed kompilacją do obciążeń aplikacji działających w usłudze AKS.

Operacje klastra i obciążenia

Aby zapoznać się z zagadnieniami dotyczącymi operacji klastra i obciążeń (DevOps), zobacz filar zasad projektowania doskonałości operacyjnej.

Uruchamianie klastra

Po zainicjowaniu obsługi administracyjnej masz działający klaster, ale możesz nadal wykonać pewne wymagane kroki, zanim będzie można wdrożyć obciążenia. Proces przygotowywania klastra nosi nazwę bootstrapping. Bootstrapping może składać się z wdrażania wstępnie wymaganych obrazów na węzłach klastra, tworzenia przestrzeni nazw i wykonywania innych zadań spełniających wymagania przypadku użycia organizacji.

Aby zmniejszyć lukę między aprowizowanego klastra i prawidłowo skonfigurowanym klastrem, operatorzy klastra powinni zastanowić się, jak wygląda ich unikatowy proces uruchamiania. Muszą one przygotować 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 powinien sprawdzić, czy wystąpienie usługi Container Registry zawierające docelowy obraz Kured już istnieje przed aprowizowaniem klastra.

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

• Rozszerzenie klastra GitOps Flux v2
• Pipelines
• Samodzielna konfiguracja z płytą Flux lub Argo CD, na przykład

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 przy użyciu solidnej podstawy zarządzania w przyszłości, a także obsługuje takie uruchamianie jako szablony zasobów, aby dostosować je do strategii IaC.

Na koniec w przypadku korzystania z rozszerzenia narzędzie kubectl nie jest wymagane w żadnej części procesu uruchamiania aplikacji. Możesz zarezerwować dostęp oparty na rozwiązaniu kubectl w sytuacjach awaryjnych. Między szablonami definicji zasobów platformy Azure i uruchamianiem manifestów za pośrednictwem rozszerzenia GitOps można wykonywać wszystkie normalne działania konfiguracyjne bez konieczności używania narzędzia 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ątkowym zadaniem jest skonfigurowanie sieci. Aprowizuj sieci wirtualne dla piasty i szprych, a także podsieci w tych sieciach. Na przykład szprycha ma oddzielne podsieci dla pul węzłów systemu i użytkownika oraz zasobów ruchu przychodzącego. Wdróż podsieć dla usługi Azure Firewall w centrum.

Innym zadaniem jest zintegrowanie podstawowego obciążenia z identyfikatorem Entra firmy Microsoft.

Korzystanie z 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. Możesz użyć szablonów Bicep, szablonów usługi Azure Resource Manager (szablonów usługi ARM) lub narzędzia Terraform.

Pamiętaj, aby aprowizować zasoby zgodnie z zasadami zarządzania. Na przykład po wybraniu rozmiarów maszyn wirtualnych zachowaj ograniczenia kosztów i opcje strefy dostępności, aby spełnić wymagania aplikacji. Możesz również użyć usługi Azure Policy, aby wymusić zasady organizacji dotyczące tych decyzji.

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. Systemy Windows i Linux obsługują interfejs wiersza polecenia platformy Azure. Inną opcją dla wielu platform jest program Azure PowerShell. Wybór zależy od preferowanego zestawu umiejętności.

Przechowywanie i przechowywanie wersji skryptów i 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ą być w stanie w sposób ciągły tworzyć i wdrażać aplikacje. Aktualizacje muszą być wdrażane bezpiecznie i szybko i w razie wystąpienia problemów.

Strategia wdrażania musi obejmować niezawodny i zautomatyzowany potok ciągłego dostarczania. Automatycznie wdróż zmiany w obrazach kontenerów obciążenia w klastrze.

W tej architekturze funkcja GitHub Actions zarządza przepływem pracy i wdrażaniem. Inne popularne opcje obejmują usługi Azure DevOps 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, ponieważ umożliwia operatorom deklaratywne definiowanie procesu uruchamiania 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.
• Aktualizuje żądaną konfigurację uruchomioną na podstawie tych zmian.

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

Oto przykład pokazujący, jak zautomatyzować konfigurację klastra za pomocą usług GitOps i Flux:

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.

Możesz mieć zasady gałęzi na serwerze Git, aby wielu deweloperów mogło następnie zatwierdzać zmiany za pośrednictwem żądania ściągnięcia przed zastosowaniem zmiany do środowiska produkcyjnego.

Chociaż można ręcznie skonfigurować metodyki GitOps i flux, zalecamy użycie metodyki GitOps z rozszerzeniem klastra Flux w wersji 2 dla usługi AKS.

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

Wdróż wszelkie zmiany, takie jak składniki architektury, obciążenie i konfiguracja klastra w co najmniej jednym klastrze przedprodukcyjnym usługi AKS. W ten sposób symuluje zmianę i może identyfikować problemy przed ich wdrożeniem w środowisku produkcyjnym.

Uruchom testy i walidacje na każdym etapie przed przejściem do następnego. Pomaga to zapewnić możliwość wypychania aktualizacji do środowiska produkcyjnego w wysoce kontrolowany sposób i minimalizowania zakłóceń przed nieprzewidzianymi problemami z wdrażaniem. 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 kanary, wymagają dodatkowych procesów i potencjalnie dodatkowych narzędzi. Flagger to popularne rozwiązanie typu open source ułatwiające 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. Aby uzyskać inne najlepsze rozwiązania, zobacz Optymalizacja kosztów.

Rozważ użycie analizy kosztów usługi AKS na potrzeby szczegółowej alokacji kosztów infrastruktury klastra według konstrukcji specyficznych dla platformy Kubernetes.

Aby uzyskać informacje na temat zagadnień dotyczących zarządzania kosztami specyficznych dla systemu Windows, zobacz Kontenery systemu Windows w usłudze AKS.

Inicjowanie

• Dowiedz się, skąd pochodzą koszty. W przypadku wdrażania, zarządzania i operacji klastra Kubernetes związane są minimalne koszty związane z usługą AKS. To, co wpływa na koszt, to 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. Seria 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.

• Dodaj umowę SLA dotyczącą czasu pracy dla obciążeń produkcyjnych. Istnieją jednak oszczędności w przypadku klastrów przeznaczonych dla obciążeń deweloperskich/testowych lub eksperymentalnych, w których dostępność nie jest wymagana do zagwarantowania. 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, które uruchamiają maszyny wirtualne 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.

• Aprowizuj klaster z minimalną liczbą węzłów i włącz narzędzie do automatycznego skalowania klastra, aby monitorować i podejmować decyzje dotyczące ustalania rozmiaru zamiast rozpoczynać się od ponadwymiarowego klastra w celu spełnienia wymagań skalowania.

• Ustaw żądania zasobnika i limity, aby umożliwić usłudze Kubernetes przydzielanie zasobów węzłów o większej gęstości, aby używać sprzętu do pojemności.

• Należy wziąć pod uwagę, że po włączeniu diagnostyki w klastrze może zwiększyć koszt.

• Zatwierdź jedną lub trzyletnią usługę Azure Reserved Virtual Machine Instances, aby zmniejszyć koszty węzłów, jeśli obciążenie musi istnieć przez długi czas. Aby uzyskać więcej informacji, zobacz Oszczędzanie kosztów za pomocą wystąpień zarezerwowanych maszyn wirtualnych platformy Azure.

• Użyj tagów podczas tworzenia pul węzłów. Tagi ułatwiają tworzenie niestandardowych raportów w celu śledzenia kosztów poniesionych. Tagi umożliwiają śledzenie całkowitych 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.

• Spodziewaj się dodatkowych kosztów przepustowości, jeśli obciążenie jest w wielu regionach i replikujesz dane między regionami. Aby uzyskać więcej informacji, zobacz Cennik przepustowości.

• Utwórz budżety, aby pozostać w granicach ograniczeń kosztów zidentyfikowanych przez organizację. Budżety można tworzyć za pomocą usługi Microsoft 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

Można monitorować cały klaster i koszt obliczeń, magazynu, przepustowości, dzienników i zapory. Platforma Azure udostępnia opcje monitorowania i analizowania kosztów:

• Azure Advisor

• Microsoft Cost Management

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

Aby podejmować decyzje oparte na danych, należy wskazać, który zasób na poziomie szczegółowym wiąże się z największymi kosztami. Ponadto dobrze zrozumieć mierniki, które obliczają użycie zasobów. Na przykład analizując metryki, można określić, czy platforma jest zawygodowana. 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, aby wykrywać i usuwać niedouczone węzły w puli węzłów.

  Ważne

  Agresywne zmienianie ustawień automatycznego skalowania klastra, takich jak minimalne i maksymalne ustawienia węzłów dla puli węzłów, aby mieć wpływ na koszty, mogą mieć wyniki przeciwproduktywne. Jeśli na przykład scale-down-unneeded-time ustawiono wartość 10 minut, a minimalne i maksymalne ustawienia węzła są modyfikowane co pięć minut w oparciu o charakterystykę obciążenia, liczba węzłów nigdy nie zostanie zmniejszona. Wynika to z faktu, że obliczenie niepotrzebnego czasu dla każdego węzła jest resetowane z powodu odświeżenia ustawień automatycznego skalowania klastra.

• 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 mają być uruchamiane zgodnie z harmonogramem, 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

• Zaawansowana architektura mikrousług usługi AKS
• Punkt odniesienia usługi AKS dla klastrów wieloregionowych
• Klaster regulowany usługi AKS dla standardu PCI-DSS 3.2.1
• Kontenery systemu Windows w architekturze referencyjnej punktu odniesienia usługi AKS

Powiązane zasoby

• Plan usługi AKS w usłudze GitHub
• Wprowadzenie do platformy Kubernetes
• Tworzenie i wdrażanie aplikacji na platformie Kubernetes
• Przegląd dobrze zaprojektowanej struktury dla usługi AKS
• Akcelerator strefy docelowej usługi AKS
• Przewodnik obsługi dnia 2 usługi AKS
• Architektura mikrousług w usłudze AKS
• Korzystanie z usługi Azure Firewall w celu ochrony klastra usługi AKS
• Operacje usługi Git dla usługi AKS
• Przesyłanie strumieniowe danych za pomocą usługi AKS