Architektura linii bazowej dla klastra Azure Kubernetes Service (AKS)

Usługa Azure Application Gateway

Azure Container Registry

Azure Firewall

Azure Kubernetes Service (AKS)

Kontrola dostępu na podstawie ról na platformie Azure

Ten artykuł zawiera zalecaną architekturę infrastruktury bazowej w celu wdrożenia klastra Azure Kubernetes Service (AKS). Są zgodne z naszymi zasadami projektowania oraz z najlepszymi praktykami architektonicznymi z ram architektonicznych Azure Well-Architected Framework. Artykuł prowadzi wiele różnych wyodrębnionych grup międzydyscyplinarnych, takich jak zespoły sieci, zabezpieczeń i tożsamości, podczas wdrażania tej infrastruktury ogólnego przeznaczenia.

Ta architektura nie koncentruje się na obciążeniu. Skupia się wyłącznie na klastrze AKS. Ten zakres informacji stanowi minimalną zalecaną podstawę dla większości klastrów AKS. Integruje się z usługami Azure, które zapewniają wgląd, zapewniają topologię sieci, która obsługuje rozwój wielu regionów i bezpieczny ruch w klastrze.

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

Tip

W tym artykule omówiono szeroki zakres kwestii związanych z projektowaniem klastrów AKS. Usługa AKS Automatic implementuje wiele decyzji projektowych, aby zmniejszyć liczbę zagadnień, które należy ocenić i zoptymalizować pod kątem typowych przypadków użycia. Na przykład usługa AKS Automatic automatycznie udostępnia i zarządza zarządzaną pulą węzłów systemowych, dlatego opisane w tym artykule decyzje dotyczące doboru rozmiaru, izolacji i uaktualniania puli węzłów systemowych nie mają zastosowania na tej platformie.

Nawet jeśli Twoje obciążenie robocze będzie hostowane w środowisku AKS Automatic, znajomość podstaw samodzielnie zarządzanego klastra AKS może pomóc Ci w dokonywaniu właściwych wyborów, gdy wymagania obciążenia roboczego się zmieniają.

Kubernetes to szeroki ekosystem, który wykracza poza technologie Azure i Microsoft. Podczas wdrażania klastra usługi AKS odpowiadasz za wiele decyzji dotyczących projektowania i obsługi klastra. Uruchomienie klastra usługi AKS obejmuje składniki zamkniętego źródła od różnych dostawców, w tym Microsoft, wraz ze składnikami typu open source z ekosystemu Kubernetes. Krajobraz zmienia się często, więc regularnie ponownie przemyśl decyzje. Podczas wdrażania platformy 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 na GitHub: implementacja referencyjna punktu odniesienia usługi AKS jako alternatywny punkt początkowy i skonfigurować ją zgodnie z potrzebami.

Note

Architektura referencyjna wymaga znajomości platformy Kubernetes i jej pojęć. Jeśli potrzebujesz odświeżenia, zobacz Wprowadzenie do Kubernetes oraz Opracowywanie i wdrażanie aplikacji na Kubernetes ścieżki szkoleniowe.

Konfiguracja sieci

Topologia sieci
Planowanie adresów IP
Routing aplikacji

Obliczenia klastra

Obliczenia dla klastra podstawowego
Odwołanie do obrazu kontenera
Zarządzanie zasadami

Zarządzanie tożsamościami

Integrate Microsoft Entra ID do klastra
Zintegrować Microsoft Entra ID z obciążeniem

Zabezpieczanie przepływu danych

Zabezpieczanie przepływu sieci
Dodawanie zarządzania tajnymi

Ciągłość biznesowa

Skalowalność węzłów i podów
Decyzje dotyczące ciągłości działania
Strefy dostępnościWiele regionów

Operations

Operacje klastra i obciążenia roboczego
Monitorowanie i zbieranie dzienników i metryk
Zarządzanie kosztami

Architecture

Na diagramie przedstawiono dwie połączone sieci wirtualne. Sieć wirtualna koncentratora zawiera Azure Firewall, Azure Bastion oraz podsieć bramy połączoną ze środowiskiem lokalnym. Sieć wirtualna 'spoke' zawiera kilka podsieci, klaster AKS i pule węzłów. Komunikacja równorzędna sieci wirtualnych łączy wirtualne sieci centralne (hub) i peryferyjne (spoke) za pośrednictwem linku dwukierunkowego. Strzałki wskazują z Key Vault i Container Registry w stronę podsieci punktów końcowych sieci Private Link. Strzałka wskazuje z podsieci Azure Bastion (zarządzanie) do wewnętrznego równoważnika obciążenia w sieci wirtualnej typu szprychowego. Strzałka wskazuje z sieci lokalnej do bramy lokalnej. Dwukierunkowa strzałka, oznaczona jako komunikacja równorzędna wirtualnej sieci, wskazuje z centralnej sieci wirtualnej hub do wirtualnej sieci odgałęzień w biurze zdalnym. Strzałka wskazuje z Internetu do podsieci Azure Application Gateway. Strzałka wskazuje z klastra usługi AKS do sekcji obszaru roboczego Azure Monitor, która zawiera metryki i zarządzaną aplikację Prometheus.

Pobierz plik Visio tej architektury.

Aby uzyskać więcej informacji, zobacz topologia sieci Hub-spoke w Azure.

Topologia sieci

Ta architektura korzysta z topologii sieci piasty i szprych. Wdróż piastę i szprychy w oddzielnych sieciach wirtualnych połączonych za pośrednictwem komunikacji równorzędnej virtual network. Ta topologia ma kilka zalet:

• Włącz zarządzanie segregowane. Możesz zastosować ład i przestrzegać zasady najniższych uprawnień (PoLP). Obsługuje również koncepcję strefy bazowej Azure z podziałem obowiązków.

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

• Zapewnij regionalne topologie typu hub-and-spoke. W przyszłości można rozszerzyć topologie sieci typu hub-and-spoke oraz zapewnić izolację zadań.

• Zastosowanie usługi web application firewall w celu sprawdzenia 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.

• Dostosuj się do strefy docelowej w skali przedsiębiorstwa Azure.

Wirtualna sieć węzła

Wirtualna sieć centralna jest centralnym punktem łączności i monitorowania. W tej architekturze centrum zawiera następujące składniki:

• Azure Firewall z globalnymi zasadami zapory zdefiniowanymi przez centralne zespoły IT w celu egzekwowania reguł w całej organizacji

• Azure Bastion, która ustanawia bezpieczny tunel do obwodu sieci prywatnej, dzięki czemu można wykonywać operacje zarządzania klastrem

• Podsieć bramy dla VPN

• Azure Monitor na potrzeby obserwacji sieci

W sieci architektura ma trzy podsieci.

Podsieć obsługująca Azure Firewall

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

Podsieć do hostowania bramy sieciowej

Ta podsieć jest symbolem zastępczym bramy sieci VPN lub bramy Azure ExpressRoute. Brama sieciowa zapewnia łączność między routerami w twojej sieci lokalnej a siecią wirtualną.

Podsieć przeznaczona na hostowanie Azure Bastion

Ta podsieć jest używana dla Azure Bastion. Za pomocą Azure Bastion można bezpiecznie uzyskiwać dostęp do zasobów Azure bez uwidaczniania zasobów w Internecie. Ta architektura używa Azure Bastion do bezpiecznego łączenia się z serwerem interfejsu API klastra usługi AKS na potrzeby operacji zarządzania. Podsieć dotyczy tylko operacji zarządzania.

Sieć wirtualna szprychowy

Ta sieć wirtualna typu szprychowego zawiera klaster usługi AKS i inne powiązane zasoby. Szprycha ma następujące podsieci.

Podsieć do obsługi Azure Application Gateway

Azure Application Gateway to internetowy moduł równoważenia obciążenia ruchu, który działa w warstwie 7. Implementacja referencyjna używa SKU Application Gateway w wersji v2, która umożliwia Azure Web Application Firewall. Web Application Firewall zabezpiecza ruch przychodzący z typowych ataków na ruch internetowy, w tym botów. Instancja ma publiczną konfigurację adresu IP frontonu, która odbiera żądania użytkowników. Zgodnie z projektem Application Gateway wymaga dedykowanej podsieci.

Podsieć dla wewnętrznych adresów IP modułu równoważenia obciążenia

Ta podsieć zapewnia przestrzeń adresową dla wewnętrznych adresów IP frontonu modułu równoważenia obciążenia. Usługa Application Gateway wysyła ruch do przypisanego prywatnego wewnętrznego adresu IP modułu równoważenia obciążenia, a moduł równoważenia obciążenia dystrybuuje ruch do dowolnego węzła w klastrze.

Agent kube-proxy w węźle odbierającego przekazuje pakiet do zasobnika serwera proxy bramy w puli węzłów systemu, co potencjalnie powoduje dodanie dodatkowego przeskoku sieciowego. Serwer proxy kończy protokół Transport Layer Security (TLS) i przekazuje żądania do zasobników obciążeń za pośrednictwem protokołu HTTP.

Korzystając z dedykowanej podsieci dla adresów IP modułu równoważenia obciążenia frontonu, można zastosować reguły sieciowej grupy zabezpieczeń, które mają zakres ruchu przychodzącego do modułu równoważenia obciążenia bez wpływu na podsieć węzła. Aby uzyskać więcej informacji, zobacz Jak użyć wewnętrznego równoważnika obciążenia z AKS.

Podsieć do hostowania węzłów klastra

Ta architektura używa dwóch pul węzłów, które są oddzielnymi grupami węzłów. Pula węzłów systemowych obsługuje zasobniki uruchamiające podstawowe usługi klastra, w tym proxy bramy, które kieruje ruch do obciążeń. Pula węzłów użytkownika uruchamia obciążenie.

Podsieć do hostowania punktów końcowych Azure Private Link

Utwórz połączenia Azure Private Link dla Azure Container Registry i Azure Key Vault, aby użytkownicy mogli uzyskiwać dostęp do tych usług za pośrednictwem prywatnego punktu końcowego w sieci wirtualnej typu szprycha. Prywatne punkty końcowe nie wymagają dedykowanej podsieci. Prywatne punkty końcowe można również umieścić w virtual network centrum. W implementacji wersji podstawowej punkty końcowe są wdrażane w dedykowanej podsieci w sieci wirtualnej szprychy. Takie podejście zmniejsza ruch przechodzący przez równorzędne połączenie sieciowe i utrzymuje 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 Private Link.

Podsieć serwera API AKS

Możesz skonfigurować klaster AKS do wykorzystania integracji z siecią wirtualną serwera API, co projektuje punkt końcowy serwera API klastra do delegowanej podsieci w sieci wirtualnej. Ta konfiguracja jest nazywana klastrem prywatnym , ponieważ gwarantuje, że cały ruch między serwerem interfejsu API, pulami węzłów i połączonymi klientami pozostaje całkowicie w sieci prywatnej.

Cała komunikacja między serwerem interfejsu API Kubernetes zarządzanym przez usługę AKS i klientami wewnętrznymi i zewnętrznymi jest ograniczona do zaufanej sieci.

Dzięki klastrowi prywatnemu można zabezpieczyć środowisko za pomocą sieciowych grup zabezpieczeń i innych wbudowanych narzędzi kontroli sieci. Ta konfiguracja uniemożliwia wszelkie nieautoryzowane publiczne dostępy między internetem a środowiskiem. Aby uzyskać więcej informacji, zobacz sekcję Tworzenie prywatnego klastra AKS.

Planowanie adresów IP

Diagram przedstawia prostą topologię sieci typu hub-and-spoke AKS. Sieć wirtualna piasty ma Azure Firewall, Azure Bastion i podsieć bramy. Sieć wirtualna będącej szprychą ma podsieci dla usługi Application Gateway, ruchu przychodzącego, węzłów, prywatnych punktów końcowych i klastra prywatnego. Strzałki pokazują połączenia komunikacji równorzędnej z sieci szprych do sieci piasty.

Pobierz plik Visio tej architektury.

Ta architektura referencyjna używa następujących metod sieciowych, z których każda wymaga oddzielnej przestrzeni adresowej IP.

• Twoja Azure sieci wirtualnej używanej dla zasobów, takich jak węzły klastra, serwer interfejsu API klastra, prywatne punkty końcowe dla usług Azure i Application Gateway.

• Nakładka Azure Container Networking Interface (CNI), która jest używana przez klaster do przydzielania adresów IP zasobnikom z przestrzeni adresowej oddzielonej od sieci wirtualnej Azure.

przestrzeń adresowa IP sieci wirtualnej

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

• Uaktualnienie: Usługa AKS regularnie aktualizuje węzły, aby upewnić się, że podstawowe maszyny wirtualne są aktualne pod względem zabezpieczeń i innych poprawek systemowych. Podczas procesu uaktualniania usługa AKS tworzy węzeł, który tymczasowo hostuje zasobniki, podczas gdy węzeł uaktualniania jest odgrodzony i opróżniony. Ten węzeł tymczasowy odbiera adres IP z podsieci klastra. Upewnij się, że masz wystarczającą przestrzeń adresową dla tymczasowych adresów IP węzła.

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

• Skalowalność: Rozważ łączną liczbę węzłów systemu i użytkownika oraz ich maksymalne limity skalowalności. Na przykład, jeśli chcesz rozszerzyć o 400%, potrzebujesz czterokrotnie więcej adresów dla wszystkich rozszerzonych węzłów.

  Ponieważ ta architektura używa Azure CNI Overlay, skalowalność podów nie ma wpływu na przestrzeń adresową sieci wirtualnej.

• Adresy Private Link: Uwzględnij adresy niezbędne do komunikacji z innymi usługami Azure za pośrednictwem Private Link. Ta architektura ma dwa adresy przypisane do linków do usługi Container Registry i Key Vault.

• Prywatne adresy serwerów API klastra: integracja serwera API z siecią wirtualną pomaga przedstawiać serwer API usługi AKS jako punkt końcowy wewnątrz sieci wirtualnej. Ta funkcja wymaga minimum rozmiaru podsieci więc upewnij się, że spełnisz te wymagania wstępne podczas planowania sieci.

• Zastrzeżone adresy IP: Azure rezerwuje określone adresy do własnych celów. 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żna również odizolować pule węzłów użytkownika od siebie. Ta izolacja skutkuje większą mniejszą podsiecią. Topologia bramy może również zostać rozwinięta, ponieważ każdy zasób bramy generuje własne wdrożenie serwera proxy bramy i adres IP frontonu modułu równoważenia obciążenia. Zaplanuj odpowiednio przestrzeń adresową podsieci.

Przestrzeń adresowa IP Pod

Nakładka Azure CNI przypisuje adresy IP do podsów przez dedykowaną przestrzeń adresową, która jest oddzielona od przestrzeni adresowej używanej w sieci wirtualnej. Użyj przestrzeni adresów IP, która nie nakłada się na sieć wirtualną ani na żadną równorzędną sieć wirtualną. Jeśli jednak utworzysz wiele klastrów usługi AKS, możesz bezpiecznie użyć tej samej przestrzeni adresowej zasobnika w każdym klastrze.

Nakładka Azure CNI przypisuje każdemu węzłowi przestrzeń adresową /24 dla jego podów. Ważne jest, aby przestrzeń adresowa poda była wystarczająco duża. Zezwalaj na tyle bloków /24, ile jest potrzebnych dla liczby węzłów w klastrze. Pamiętaj, aby uwzględnić wszystkie tymczasowe węzły utworzone podczas aktualizacji lub operacji skalowania w poziomie. Jeśli na przykład używasz przestrzeni adresowej /16 dla zakresu usługi Classless Inter-Domain Routing (CIDR), klaster może wzrosnąć do maksymalnie 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, zapoznaj się z wskazówkami dotyczącymi planowania adresów IP dla Azure CNI Overlay.

Inne zagadnienia dotyczące przestrzeni adresów IP

Aby zapoznać się z pełnym zestawem zagadnień dotyczących sieci dla tej architektury, zobacz topologię sieci bazowej AKS. Aby uzyskać więcej informacji na temat planowania adresowania IP dla klastra usługi AKS, zobacz Konfigurowanie sieci Azure CNI 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 punktu odniesienia zależy od określonych funkcji usługi AKS w wersji zapoznawczej i dodatków usługi AKS. Rozważ następujące różnice między funkcjami w wersji zapoznawczej i dodatkami:

• Zespół AKS opisuje funkcje w wersji zapoznawczej jako dostarczane i ulepszane, ponieważ wiele funkcji w wersji zapoznawczej pozostaje w tym stanie tylko przez kilka miesięcy, zanim przejdą do fazy ogólnej dostępności.

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

Architektura punktu odniesienia nie obejmuje każdej funkcji lub dodatku w wersji zapoznawczej, ale tylko te, które dodają znaczącą wartość do klastra ogólnego przeznaczenia. W miarę jak te funkcje wychodzą z wersji zapoznawczej, ta architektura bazowa jest odpowiednio zmieniana.

Możesz ocenić inne funkcje w wersji zapoznawczej lub dodatki usługi AKS w klastrach przedprodukcyjnych. Te funkcje mogą zwiększyć bezpieczeństwo, możliwości zarządzania lub inne wymagania. Należy zainstalować i obsługiwać wszelkie dodatki inne niż Microsoft, które obejmują śledzenie dostępnych wersji i instalowanie aktualizacji po uaktualnieniu wersji rozwiązania Kubernetes klastra.

Odwołanie do obrazu kontenera

Klaster może zawierać obciążenie i kilka innych obrazów, takich jak infrastruktura bramy zarządzanej samodzielnie lub kontener narzędzi, który synchronizuje certyfikaty TLS z Key Vault. Niektóre z tych obrazów mogą znajdować się w rejestrach publicznych, ale dobrym rozwiązaniem jest ich skanowanie, inspekcja i przechowywanie w dedykowanym rejestrze prywatnym, na przykład Azure Container Registry. Podczas ściągania obrazów do klastra należy wziąć pod uwagę następujące kwestie:

• Uwierzytelnij klaster, aby pobrać obraz.

• Jeśli używasz obrazu publicznego, zaimportuj obraz do rejestru kontenerów, który jest zgodny z celem poziomu usługi (SLO). W przeciwnym razie obraz może podlegać nieoczekiwanym problemom z dostępnością. Jeśli obraz jest niedostępny, gdy jest potrzebny, mogą wystąpić problemy operacyjne. Rozważ następujące korzyści wynikające z używania prywatnego rejestru kontenerów, takiego jak Azure Container Registry, zamiast rejestru publicznego:

  • Możesz zablokować nieautoryzowany dostęp do obrazów.
  • Nie masz zależności publicznych.
  • Można uzyskać dostęp do dzienników pobierania obrazów w celu monitorowania działań i klasyfikacji 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ą Azure Policy. W implementacji referencyjnej klaster pobiera obrazy tylko z dedykowanego wystąpienia Azure Container Registry wdrażanego w klastrze.

Konfigurowanie zasobów obliczeniowych dla klastra podstawowego

W usłudze AKS, zwykle każda pula węzłów jest mapowana na zestaw skalowania maszyn wirtualnych. Węzły są virtual machines (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. Implementacja referencyjna wdraża pulę węzłów systemowych z trzema węzłami D2dv5. Ten rozmiar jest wystarczający do spełnienia oczekiwanego obciążenia systemowych podów. Efemeryczny dysk systemu operacyjnego to 64 GB.

Podczas planowania pojemności puli węzłów użytkownika należy wziąć pod uwagę następujące zalecenia:

• Wybierz większe rozmiary węzłów, aby umieścić maksymalną liczbę podów na węźle. Duże węzły minimalizują ślad usług uruchamianych na wszystkich węzłach, takich jak monitorowanie i logowanie.

• 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, aby obciążenie działało zgodnie z wzorcem wysokiej dostępności z dwoma replikami. Usługa AKS umożliwia zmianę liczby węzłów bez ponownego tworzenia klastra.

• Zaplanuj właściwe rozmiary węzłów dla obciążenia na podstawie wymagań, które określa zespół projektowy. Na podstawie wymagań biznesowych ta architektura używa jednostki SKU D4dv5 dla obciążenia produkcyjnego.

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

• Ustaw maksymalne pody dla każdego węzła na podstawie planowania pojemności. Jeśli spró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. Implementacja referencyjna używa Azure Linux, która jest uproszczoną, wzmocnioną dystrybucją systemu Linux dostosowaną do Azure. Możesz wybrać inną dystrybucję systemu Linux, na przykład Ubuntu, jeśli wolisz lub jeśli Azure Linux nie spełnia Twoich wymagań. Jeśli wybierzesz inny system operacyjny, upewnij się, że rozmiar dysku systemu operacyjnego jest odpowiedni dla tego obrazu. Niektóre dystrybucje wymagają więcej miejsca niż Azure Linux, więc może być konieczne zwiększenie rozmiaru dysku, aby uniknąć problemów z wdrożeniem lub środowiskiem uruchomieniowym.

Jeśli obciążenie składa się z technologii mieszanych, możesz użyć różnych systemów operacyjnych w różnych pulach węzłów. Jeśli nie potrzebujesz różnych systemów operacyjnych, zalecamy użycie jednego systemu operacyjnego dla wszystkich pul węzłów obciążenia w celu zmniejszenia złożoności operacyjnej.

Integrowanie Microsoft Entra ID dla klastra

Zabezpieczenie dostępu do klastra i z klastra ma kluczowe znaczenie. Skorzystaj z perspektywy klastra, aby zrozumieć różnicę między ruchem wewnątrz i na zewnątrz .

• Dostęp wewnętrzny: Rozważ dostęp AKS do składników Azure, takich jak infrastruktura sieciowa, Container Registry i Key Vault. Autoryzuj tylko te zasoby, do których klastry powinny mieć dostęp.

• Dostęp poza dostępem: Podaj tożsamości z dostępem do klastra Kubernetes. Autoryzuj tylko te jednostki zewnętrzne, które mogą uzyskiwać dostęp do serwera interfejsu API Kubernetes i Azure Resource Manager.

Dostęp usługi AKS do składników Azure

Istnieją dwa sposoby zarządzania dostępem AKS do Azure za pośrednictwem Microsoft Entra ID: podmioty zabezpieczeń usługi lub zarządzane tożsamości dla zasobów Azure.

Z dwóch metod zarządzania dostępem usługi AKS do 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. W przypadku tożsamości zarządzanych Microsoft Entra ID zarządza uwierzytelnianiem i terminowym rotacją wpisów tajnych.

Zalecamy włączenie i użycie tożsamości zarządzanych w usłudze AKS aby klaster mógł wchodzić w interakcje z zasobami zewnętrznymi Azure za pośrednictwem Microsoft Entra ID. Jeśli nie używasz integracji Microsoft Entra ID natychmiast, możesz dodać ją później.

Domyślnie klaster używa dwóch podstawowych tożsamości: tożsamości klastra i tożsamości 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 i 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.

Należy użyć tożsamości zarządzanej, gdy klaster musi ściągać obrazy z rejestru kontenerów. Ta akcja wymaga, aby klaster pobierał poświadczenia rejestru, które można zezwolić, udzielając tożsamości AcrPull zarządzanej kubelet klastra dostępu do rejestru. Jeśli nie używasz tożsamości zarządzanej, możesz przechowywać te informacje w kluczu tajnym kubernetes i używać imagePullSecrets ich do ich pobierania. Nie zalecamy tego podejścia, ponieważ wprowadza on złożoność zabezpieczeń, takie jak konieczność wcześniejszego poznania wpisu tajnego i przechowywania go w potoku DevOps. Dodaje również nakład pracy operacyjnej, ponieważ należy zmienić tajny klucz.

W tej architekturze klaster uzyskuje dostęp do Azure zasobów, które Microsoft Entra ID zabezpieczają, a klaster wykonuje operacje obsługujące tożsamości zarządzane. Przypisz Azure role kontroli dostępu opartej na rolach (Azure RBAC) i uprawnienia do tożsamości zarządzanych klastra, w zależności od operacji wykonywanych przez klaster. Klaster uwierzytelnia się w Microsoft Entra ID i jest dozwolony lub blokowany dostęp na podstawie przypisanych do niego ról. W poniższych przykładach z implementacji referencyjnej przedstawiono Azure wbudowanych ról przypisanych do klastra:

• Rola współautora sieci zarządza zdolnością klastra do kontrolowania wirtualnej sieci opartej na szprychach. Dzięki temu przypisaniu roli tożsamość przypisana przez system klastra usługi AKS może wchodzić w interakcje z dedykowaną podsiecią wewnętrznego modułu równoważenia obciążenia, który kieruje serwerem proxy bramy i prywatnym serwerem interfejsu API usługi AKS.

• Rola Wkładowca strefy Prywatna strefa DNS zarządza możliwością łączenia strefy bezpośrednio z podsiecią wirtualną typu 'spoke', która hostuje klaster. Klaster prywatny przechowuje rekordy DNS poza publicznym Internetem przy użyciu prywatnej strefy DNS, ale nadal istnieje możliwość utworzenia prywatnego klastra usługi AKS z publicznym adresem DNS. Zalecamy jawne zablokowanie tej funkcji przez ustawienie enablePrivateClusterPublicFQDN , aby false zapobiec ujawnieniu prywatnego adresu IP płaszczyzny sterowania. Rozważ użycie Azure Policy, aby wymusić użycie klastrów prywatnych bez publicznych rekordów DNS.

• Rola Publisher metryk monitorujących zarządza możliwością klastra do wysyłania metryk do usługi Azure Monitor.

• Rola AcrPull zarządza zdolnością klastra do ściągania obrazów z wymienionych wystąpień usługi Container Registry.

Dwa dodatki usługi AKS udostępniają dodatkowe tożsamości zarządzane, które wymagają przypisań ról. Dodatek sterownika CSI magazynu wpisów tajnych pobiera certyfikaty TLS z Key Vault. Tożsamość dodatku routingu aplikacji zarządza rekordami DNS i uzgadnianiem bramy.

Przyznaj tym dwóm tożsamościom następujący dostęp do zasobów, z którymi korzystają:

• Dodatek sterownik CSI magazynu wpisów tajnych wymaga roli użytkownika certyfikatu Key Vault w key vault, aby sterownik mógł pobrać certyfikaty TLS.

  Note

  Alternatywnie możesz zamienić tożsamość zarządzaną sterownika CSI na tożsamość zarządzaną Microsoft Entra obciążenia na potrzeby dostępu Key Vault. W przypadku korzystania z tożsamości obciążenia należy powiązać tożsamość zarządzaną przypisaną przez użytkownika z usługą Kubernetes ServiceAccount przy użyciu poświadczeń federacyjnych i odwołać się do konta usługi ServiceAccount w opcjach protokołu TLS odbiornika bramy. Dodatek routingu aplikacji następnie automatycznie tworzy element SecretProviderClass.

  Zazwyczaj wybiera się tożsamość zarządzaną dodatku albo Workload Identity w celu uzyskania dostępu do usługi Key Vault za pośrednictwem sterownika CSI. Tożsamość obciążenia zapewnia izolację tożsamości w zakresie przestrzeni nazw i zmniejsza ręczne zarządzanie zasobami kosztem dodatkowego wzmacniania zabezpieczeń tożsamości za pośrednictwem poświadczeń federacyjnych.

• Tożsamość zarządzana dotycząca routingu aplikacji wymaga ról użytkownika Key Vault Secrets i Key Vault Reader w key vault. W przypadku wbudowanego składnika DNS do uzgadniania zasobów bramy ta tożsamość wymaga również roli współautora strefy Prywatna strefa DNS w strefie ruchu przychodzącego private DNS.

  Note

  Wbudowany składnik DNS wdrożony z dodatkiem nie uzgadnia automatycznie rekordów DNS. W przypadku rekordów interfejsu API bramy użyj podejścia Do obsługi tożsamości obciążenia.

Aby uzyskać więcej informacji, zobacz Konfigurowanie Azure DNS i protokołu TLS przy użyciu implementacji interfejsu API routingu aplikacji.

Dostęp do klastra

Integracja z Microsoft Entra upraszcza również zabezpieczenia dostępu od zewnątrz do wewnątrz. Na przykład możesz chcieć użyć narzędzia kubectl. Na początek możesz uruchomić polecenie az aks get-credentials, aby pobrać poświadczenia klastra. Microsoft Entra ID uwierzytelnia Twoją tożsamość na podstawie ról Azure, które mogą uzyskać poświadczenia klastra. Aby uzyskać więcej informacji, zobacz Uprawnienia dostępnych ról klastra.

Usługa AKS obsługuje dostęp do platformy Kubernetes za pośrednictwem Microsoft Entra ID, wykorzystując Microsoft Entra ID jako dostawcę tożsamości zintegrowanego z wbudowanym RBAC Kubernetes lub korzystając z wbudowanego RBAC Azure do zarządzania dostępem do klastra. W poniższych sekcjach opisano oba podejścia.

Kojarzenie Kubernetes RBAC z usługą Microsoft Entra ID

Kubernetes obsługuje RBAC poprzez następujące obiekty interfejsu API:

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

• Powiązania, które przypisują użytkownikom i grupom 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 Microsoft Entra, aby zarządzać dostępem za pomocą katalogu przedsiębiorstwa. Aby uzyskać więcej informacji, zobacz Użyj Kubernetes RBAC z integracją Microsoft Entra.

Upewnij się, że grupy Microsoft Entra dla dostępu do klastra i przestrzeni nazw znajdują się w przeglądach dostępu Microsoft Entra.

Użyj kontroli dostępu opartej na rolach Azure do autoryzacji w Kubernetes

Zalecamy użycie Azure RBAC i przypisań ról Azure w celu egzekwowania autoryzacji w klastrze. Takie podejście autoryzacji integruje się z uwierzytelnianiem Microsoft Entra. Role można przypisywać w różnych zakresach, takich jak grupa zarządzania, subskrypcja lub grupa zasobów. Wszystkie klastry objęte zakresem dziedziczą następnie spójny zestaw przypisań ról w kontekście osób z uprawnieniami do dostępu do obiektów w klastrze Kubernetes.

Nie zalecamy używania natywnej kontroli dostępu opartej na rolach (RBAC) platformy Kubernetes z ClusterRoleBindings i RoleBindings.

Aby uzyskać więcej informacji, zobacz Azure RBAC for Kubernetes authorization.

Konta lokalne

Usługa AKS obsługuje natywne uwierzytelnianie użytkowników Kubernetes. Nie zalecamy używania tej metody do zapewniania dostępu użytkownika klastrom. Ta metoda jest oparta na certyfikacie i wykonywana zewnętrznie względem podstawowego dostawcy tożsamości, co sprawia, że scentralizowana kontrola dostępu i zarządzanie dostępem są trudne. Zawsze zarządzaj dostępem do klastra przy użyciu Microsoft Entra ID i skonfiguruj klaster, aby jawnie uniemożliwić dostęp do konta lokalnego.

W implementacji referencyjnej dostęp kont klastrów lokalnych jest jawnie zabroniony, gdy system wdraża klaster.

Zintegruj Microsoft Entra ID dla obciążenia roboczego

Podobnie jak w przypadku systemowo przypisanej tożsamości zarządzanej Azure dla całego klastra, można przypisać tożsamości zarządzane na poziomie podu. Tożsamość zadania umożliwia hostowanemu zadaniu dostęp do zasobów za pośrednictwem Microsoft Entra ID. Na przykład obciążenie może przechowywać pliki w Azure Storage. Gdy zasobnik musi uzyskać dostęp do tych plików, uwierzytelnia się względem zasobu jako Azure tożsamości zarządzanej.

W 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, zobacz Federacja tożsamości obciążeń roboczych.

Wybieranie modelu sieci

Usługa AKS udostępnia wtyczki CNI w dwóch modelach sieciowych: nakładki i płaskie. Oba modele obsługują zasady sieciowe dla kontroli ruchu w klastrze.

W przypadku płaskiej wtyczki sieciowej, takiej jak Azure CNI Pod Subnet, każdy zasobnik otrzymuje adres IP z podsieci sieci wirtualnej. Zasoby w tej samej sieci lub równorzędnych sieciach mogą uzyskiwać dostęp do zasobników bezpośrednio przez ich adresy IP bez translatora adresów sieciowych (NAT). Użyj modelu płaskiej sieci, gdy obciążenie wymaga, aby zasobniki były bezpośrednio routowane do sieci wirtualnej.

Ta implementacja używa Azure nakładki CNI, wtyczki sieci nakładki, która przydziela adresy IP sieci wirtualnej tylko do węzłów i przypisuje adresy IP zasobników z oddzielnego zakresu CIDR. Dlatego, że Nakładka Azure CNI zużywa znacznie mniej adresów IP sieci wirtualnej niż modele płaskie, zalecamy ją dla większości wdrożeń.

Aby uzyskać więcej informacji na temat modeli, zobacz Omówienie sieci usługi AKS CNI i Najlepsze rozwiązania dotyczące łączności sieciowej i zabezpieczeń w usłudze AKS.

Marszruta zgłoszenia

Ta architektura korzysta z dodatku routingu aplikacji z interfejsem API Kubernetes Gateway. Dodatek trasowania aplikacji to konfiguracja klastra AKS, która określa, że klaster ma obejmować zarządzaną infrastrukturę bramy. Gateway API to zestaw niestandardowych definicji zasobów Kubernetes (CRD), w tym GatewayClass, Gateway, HTTPRoute i innych. Społeczność platformy Kubernetes wyznaczyła interfejs API bramy jako następcę poprzedniego interfejsu API ruchu przychodzącego. Interfejs API bramy zapewnia ustandaryzowaną, zorientowaną na rolę i rozszerzalną platformę do zarządzania ruchem.

Składniki interfejsu API bramy są wdrażane na następujących etapach cyklu życia:

• Projekt klastra. Zespół aplikacji decyduje, który kontroler bramy powinien zarządzać ruchem przychodzącym i jak zarządzać cyklem życia tego kontrolera. Kontrolery bramy zwykle łączą swoje serwery proxy płaszczyzny danych, dlatego ta decyzja określa również, który serwer proxy obsługuje ścieżkę ruchu. Ta architektura umożliwia zarządzanie obiektami CRD interfejsu Gateway API. Konfiguruje dodatek tak, aby używał zarządzanego Istio jako kontrolera bramy, który współpracuje z Envoy jako proxy bramy. Mimo że można również użyć istio jako siatki usług, ta architektura używa istio tylko jako kontrolera bramy i nie włącza jej możliwości siatki usług.

  Jeśli zespół potrzebuje innej implementacji, może użyć innych kontrolerów Gateway API, takich jak NGINX Gateway Fabric, Envoy Gateway i Traefik. Samodzielne zarządzanie tymi kontrolerami wymaga posiadania manifestów, ochrony przed koligacją, umieszczania węzłów, sond, określania zakresu kontroli dostępu opartej na rolach, zasad skalowania, ograniczeń źródłowych adresów IP i cyklu życia wersji. W zamian zespoły uzyskują pełny nadzór nad zachowaniem serwera proxy, przypinaniem wersji niezależnie od uaktualnień klastra i nieprzyciągniętymi konfiguracjami.

• Inicjowanie obsługi administracyjnej klastra. Na tym etapie nie są podejmowane żadne decyzje projektowe. Usługa AKS instaluje identyfikatory CRD interfejsu API bramy, zasobniki kontrolera bramy Istio w aks-istio-system przestrzeni nazw i approuting-istio gatewayClass. Na tym etapie nie istnieją zasobniki płaszczyzny danych dla serwera proxy bramy.

• Uruchamianie klastra. Zespół obciążenia określa, czy serwer proxy bramy jest uwidoczniony za pośrednictwem wewnętrznego lub zewnętrznego modułu równoważenia obciążenia, który podsieć hostuje adres IP frontonu modułu równoważenia obciążenia i w której przestrzeni nazw działa serwer proxy bramy. W tej architekturze serwer proxy bramy jest uwidaczniony w wewnętrznym module równoważenia obciążenia. Istnieje dedykowana podsieć adresów IP modułua0008 równoważenia obciążenia, a serwer proxy bramy jest wdrażany w przestrzeni nazw obciążenia.

  Zasób Gateway odwołujący się do klasy GatewayClass approuting-istio odzwierciedla te decyzje. Kontroler bramy uzgadnia zasób z wdrożeniami serwera proxy bramy envoy, usługą LoadBalancer, elementem HorizontalPodAutoscaler i zasobem PodDisruptionBudget w tej samej przestrzeni nazw co zasób bramy.

  Gdy prywatna strefa DNS jest dołączona do dodatku, składnik DNS dodatku może zarządzać rekordami DNS A, dzięki czemu nie trzeba utrzymywać rekordów statycznych w infrastrukturze jako szablonów kodu (IaC). Bootstrapping wdraża również zasoby synchronizacji certyfikatów TLS opisane w temacie Access cluster secrets (Uzyskiwanie dostępu do wpisów tajnych klastra).

  Note

  Wbudowany składnik DNS wdrożony wraz z dodatkiem nie synchronizuje automatycznie rekordów DNS w przypadku korzystania z zasobów Gateway API. Aby włączyć automatyczne uzgadnianie prywatnych rekordów DNS, wdróż zasób niestandardowy ClusterExternalDNS lub ExternalDNS . Składnik operatora routingu aplikacji wdraża następnie wystąpienie zarządzane external-dns , które obserwuje zasoby usługi Gateway i HTTPRoute, a następnie publikuje rekordy A w dołączonej strefie DNS.

  Ponieważ zapisywanie w strefie DNS wymaga uprawnień RBAC, ta integracja wymaga Microsoft Entra tożsamości obciążenia, w tym tożsamości zarządzanej przypisanej przez użytkownika z współautorem strefy DNS w strefie docelowej, poświadczenia tożsamości federacyjnej, które ufają wystawcy OpenID Connect (OIDC) klastra i dedykowanemu usłudze Kubernetes ServiceAccount. Oceń dodatkowe wymagania dotyczące infrastruktury tożsamości pod kątem zabezpieczeń i potrzeb operacyjnych.

• Wdrożenie obciążenia roboczego. Zespół aplikacji definiuje, które nazwy hostów, ścieżki i zaplecza powinny odbierać ruch. Zasoby usługi HTTPRoute powiązane z bramą wyrażają te decyzje dotyczące routingu. Kontroler bramy przekazuje zadeklarowane reguły routingu do podów Envoy.

• Ciągła konserwacja: Dodatek wiąże wersję kontrolera bramy Istio z wersją klastra usługi AKS, dlatego uaktualnienia odbywają się wraz z uaktualnieniami klastra, a nie wymaga niezależnego zarządzania cyklem życia. Ten dodatek używa Istio wyłącznie do zarządzania proxy bramy. Nie włącza wstrzykiwania sidecara ani pełnej siatki usług Istio, która stanowi oddzielny dodatek.

Note

Wybierz opcję samodzielnego zarządzania, gdy obciążenie wymaga możliwości, których dodatek jeszcze nie obsługuje, takich jak TLSRoute for Server Name Indication (SNI), zaawansowane przekształcenia ruchu za pośrednictwem niestandardowych wtyczek Lua lub Wasm albo gdy zgodność wymusza określony produkt proxy. Wybierz również opcję samodzielnego zarządzania, jeśli musisz uruchomić wersję serwera proxy niezależnie od uaktualnień klastra lub jeśli klaster korzysta już z dodatku siatki usługi Istio, ponieważ dwa dodatki nie mogą współistnieć.

Zastosowanie zasobów Gateway i HTTPRoute

Ta architektura korzysta z dodatku routingu aplikacji z interfejsem API Kubernetes Gateway do zarządzania ruchem przychodzącym. W tej sekcji opisano etapy uruchamiania klastra i wdrażania obciążenia opisane w poprzedniej sekcji. W tym momencie kontroler bramy jest uruchomiony i oczekuje na uzgadnianie zasobów interfejsu API bramy.

Interfejs API bramy jest neutralnym dla dostawcy standardem, który wyraża zasady protokołu TLS, routing oparty na nagłówkach i podział ruchu jako pola natywnego interfejsu API, a nie adnotacje specyficzne dla implementacji. Ponieważ konfiguracja routingu nie zależy od żadnej konkretnej technologii serwera proxy, możesz zmienić podstawową implementację później bez ponownego zapisywania. Dodatek routingu aplikacji determinuje cykl życia kontrolera bramy i proxy, co eliminuje konieczność zarządzania aktualizacjami, poprawkami zabezpieczeń, konfiguracją skalowania i zakresami uprawnień RBAC.

Interfejs API bramy oddziela ruch przychodzący na dwa zasoby, które zmieniają się niezależnie:

• Zasób bramy deklaruje powierzchnię sieci, w tym porty i protokoły do uwidocznienia, certyfikatów TLS i podsieci wewnętrznego modułu równoważenia obciążenia. Ten zasób zmienia się rzadko i wpływa na wszystkie dołączone do niego trasy.

• Zasób HTTPRoute deklaruje logikę routingu lub hosty, ścieżki i nagłówki mapują usługi zaplecza. Ten zasób zmienia się wraz z każdym wdrożeniem i ma zakres dla poszczególnych usług.

Ta architektura zmniejsza ryzyko zmiany routingu zakłócającej konfigurację sieci lub odwrotnie, ponieważ każdy zasób ma inny cykl zmian i promień wybuchu. Usuwa również kilka zależności.

• Konfiguracja routingu nie jest powiązana z określoną technologią serwera proxy.
• Wersja serwera proxy jest przenosina z wersją klastra usługi AKS, a nie wymaga niezależnego śledzenia.
• Każdy zasób bramy pobiera własne wdrożenie serwera proxy, a nie współużytkuje pojedynczy kontroler we wszystkich trasach.

Zgodnie z opisem w sekcji etapy cyklu życia po zastosowaniu zasobu bramy, który odwołuje się do skonfigurowanej klasy GatewayClass, kontroler bramy uzgadnia go z zasobami wdrażania serwera proxy bramy i zasobami pomocniczymi. Rozmieszczenie podsieci kontrolujesz za pomocą adnotacji infrastrukturalnych w zasobie Gateway.

Ten model deklaratywny eliminuje konieczność zarządzania chartami Helm, obrazami kontenerów lub manifestami wdrożeniowymi serwera proxy. Określasz zamierzony stan za pomocą konfiguracji zasobów Gateway API, a kontroler bramy doprowadza serwer proxy do pożądanego stanu.

Zazwyczaj kontroler bramy zarządzanej aprowizuje serwer proxy bramy z ustawieniami domyślnymi zorientowanymi na środowisko produkcyjne, w tym sondami gotowości i dostępnością, uprawnieniami RBAC, skalowaniem replik przy użyciu skalowania automatycznego opartego na procesorze CPU i zasobnikem Zasobniku, który utrzymuje co najmniej jeden dostępny zasobnik podczas dobrowolnych zakłóceń.

Topologia planowania dodatków

Dodatki AKS umieszczają zarządzane komponenty w pulach węzłów na podstawie decyzji harmonogramowania, nad którymi zespół aplikacji nie ma kontroli. Przed ustalaniem rozmiaru pul węzłów systemu i użytkownika określ, gdzie każdy z włączonych dodatków planuje jego zasobniki. Niektóre dodatki tolerują defekty puli węzłów systemowych i dlatego są uruchamiane tylko w puli systemu. Inne dodatki są przeznaczone dla pul użytkowników. Ta topologia ma bezpośredni wpływ na pojemność wymaganą w każdej puli.

Zarządzany serwer proxy bramy usługi Envoy działa w puli węzłów systemu zgodnie z projektem, a nie w puli węzłów użytkownika. Dostosuj rozmiar puli systemowej, aby uwzględnić dodatkowe zapotrzebowanie proxy na zasoby. Jeśli ta domyślna topologia nie spełnia wymagań organizacji, na przykład jeśli potrzebujesz serwera proxy w pulach użytkowników na potrzeby izolacji kosztów, segmentacji sieci lub powodów zgodności, przejdź do kontrolera bramy zarządzanej samodzielnie, w którym można podejmować decyzje dotyczące umieszczania węzłów.

Nawet w przypadku zarządzanego kontrolera bramy, zespół aplikacji może skonfigurować antykoligację podów, aby rozłożyć repliki serwera proxy między węzłami. Te ustawienia można skonfigurować za pomocą ustawień dostosowywania bramy dozwolonych. Aby uzyskać więcej informacji, zobacz Dostosowywanie zasobów bramy.

Ponieważ proxy bramy działa w puli węzłów systemowych, a obciążenie robocze działa w puli węzłów użytkownika, harmonogramista traktuje je jako niezależne domeny harmonogramowania. Usługi serwera proxy i obciążenia bramy często komunikują się, ponieważ każde żądanie przychodzące przepływa przez serwer proxy przed dotarciem do obciążenia. Żaden wbudowany mechanizm nie koreluje rozmieszczenia podów w strefach między różnymi pulami węzłów. Bez wyraźnych wskazówek harmonogram może umieszczać zasobniki obciążenia w strefach, w których nie istnieje żadna replika serwera proxy, wymuszając ruch do przekraczania granicy strefy dostępności i dodawania opóźnień i kosztów transferu danych między strefami.

Aby ograniczyć ten ruch między strefami, skonfiguruj dla swojego obciążenia preferowane powinowactwo podów, aby umieścić je wspólnie z replikami proxy w obrębie strefy. Ta wspólna lokalizacja jest najbliższa, gdy serwer proxy i obciążenie działają w oddzielnych pulach węzłów, ponieważ koligacja na poziomie węzła nie ma wpływu na pule. Należy pamiętać, że koligacja międzypodów dodaje obciążenie przetwarzania do harmonogramu i może spowolnić planowanie w dużych klastrach.

Wymagania dotyczące zasobów dodatków w zasadach ładu

Dodatki usługi AKS wdrażają składniki zarządzane, których wymagania dotyczące zasobów są definiowane i kontrolowane przez usługę AKS, a nie przez zespół aplikacji. Gdy klaster wymusza zasady limitu zasobów kontenera w trybie odmowy za pomocą Azure Policy i Open Policy Agent (OPA) Gatekeeper, zasady muszą być zgodne z każdym włączonym dodatkiem. W przeciwnym razie program Gatekeeper dyskretnie blokuje tworzenie zarządzanych zasobników, co wyłącza możliwości platformy, takie jak ruch przychodzący, synchronizacja wpisów tajnych i możliwość obserwacji bez wyświetlania żadnych oczywistych błędów wdrażania.

Traktuj profilowanie zasobów dodatku jako wymaganie wstępne dotyczące tworzenia zasad. Przed zdefiniowaniem ograniczeń procesora CPU kontenera, pamięci, typu woluminu lub kontekstu zabezpieczeń należy spisać każdy włączony dodatek i określić wymagania dotyczące zasobów środowiska uruchomieniowego. Użyj testów obciążeniowych lub kontrolowanych wdrożeń w środowisku przedprodukcyjnym, aby przechwycić rzeczywiste zużycie zasobów w realistycznych warunkach ruchu. Następnie ustaw limity zasad tak, aby uwzględniały zarówno komponenty dodatków, jak i kontenery obciążeń roboczych. Takie podejście gwarantuje, że zabezpieczenia ładu chronią klaster bez zakłócania infrastruktury zarządzanej przez platformę.

Na przykład zarządzany serwer proxy bramy Envoy wymaga do 2 rdzeni CPU i 1 GiB pamięci na replikę. Te wartości prawdopodobnie przekraczają potrzeby małego lub niskiego obciążenia zasobów. Ustaw limity zasad, aby uwzględnić serwer proxy bramy wraz z kontenerami aplikacji. Bez tego dostosowania program Gatekeeper odrzuca zasobniki serwera proxy bramy, a cały potok ruchu przychodzącego nie zmaterializuje się.

Kończenie żądań protokołu TLS bramy w klastrze i wymuszanie protokołu HTTPS

Ta architektura umożliwia skonfigurowanie bramy przy użyciu protokołu HTTPS na porcie 443 przy użyciu certyfikatu TLS zsynchronizowanego z Key Vault oraz odbiornika HTTP na porcie 80 na potrzeby przekierowania. Adnotacje infrastruktury w bramie umieszczają moduł równoważenia obciążenia w podsieci ruchu przychodzącego i sprawiają, że jest on wewnętrzny. Przekierowanie usługi HTTPRoute powiązanej z odbiornikiem HTTP powraca 301 Moved Permanently w celu uaktualnienia wszystkich żądań HTTP do protokołu HTTPS. Aplikacja HTTPRoute wiąże się z odbiornikiem HTTPS i kieruje ruch do usługi obciążenia za pośrednictwem protokołu HTTP. Ponieważ serwer proxy bramy wykonuje zakończenie szyfrowania TLS, komunikacja z usługami zaplecza jest niezaszyfrowana.

Zabezpieczanie przepływu sieci

W tej architekturze przepływ sieci obejmuje następujące typy ruchu:

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

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

• Ruch między zasobnikami, który obejmuje komunikację między serwerem proxy bramy 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.

Na diagramie przedstawiono cztery odrębne wzorce ruchu w architekturze. Jedno pole zawiera sieć koncentratora z polem podsieci zawierającym Azure Firewall. Oddzielne pole zawiera sieć szprychy i ma pola podsieci dla Web Application Firewall (WAF), wewnętrznego modułu równoważenia obciążenia zarządzanego przez usługę AKS i usługi AKS. Dwukierunkowa strzałka przedstawia komunikację równorzędną sieci wirtualnych między dwiema sieciami. Stałe zielone strzałki pokazują ruch żądań inicjowany przez użytkownika z publicznego Internetu do zapory aplikacji internetowej w sieci szprychy, z podsieci zapory aplikacji internetowej do wewnętrznej podsieci modułu równoważenia obciążenia i stamtąd do podsieci usługi AKS. Stałe pomarańczowe strzałki pokazują ruch żądania zainicjowanego przez klaster z podsieci AKS sieci szprychy do sieci piasty i wychodzący z podsieci Azure Firewall sieci koncentratora do publicznego Internetu. Kropkowane pomarańczowe strzałki pokazują zwracany ruch odpowiedzi z publicznego Internetu do podsieci Azure Firewall sieci piasty i z sieci piasty do podsieci AKS sieci szprychy. Zielone kropkowane strzałki pokazują ruch odpowiedzi z podsieci AKS do podsieci modułu równoważenia obciążenia, a następnie do podsieci zapory aplikacji internetowej sieci szprychy i z podsieci zapory aplikacji internetowej sieci szprychy z powrotem do publicznego Internetu.

Pobierz plik Visio tej architektury.

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

Przepływ ruchu przychodzącego

Architektura akceptuje tylko żądania szyfrowane protokołem TLS od klienta. Protokół TLS w wersji 1.2 jest minimalną dozwoloną wersją i umożliwia ograniczony zestaw szyfrów. SNI ścisłe dopasowywanie jest włączone. Kompleksowa konfiguracja protokołu TLS odbywa się za pośrednictwem Application Gateway przy użyciu dwóch różnych certyfikatów TLS, jak pokazano na poniższym diagramie.

Na diagramie przedstawiono pełny przepływ ruchu TLS z klienta do obciążenia. Krok 1 przedstawia użytkownika wysyłającego ruch HTTPS do usługi Application Gateway. W kroku 2 strzałka przechodzi z usługi Application Gateway do serwera proxy usługi Envoy w klastrze usługi AKS. Krok 3 przedstawia strzałkę wskazującą z serwera proxy usługi Envoy do obciążenia w klastrze usługi AKS. Krok 4 przedstawia wiersze przechodzące z usługi Application Gateway i serwera proxy usługi Envoy do Key Vault, które zawierają dwa certyfikaty, bicycle.contoso.com i *.aks-ingress.contoso.com. Każdy punkt zakończenia protokołu TLS jest oznaczony ikoną blokady.

Pobierz plik Visio tej architektury.

1. Klient wysyła żądanie HTTPS do nazwy domeny: bicycle.contoso.com, nazwa skojarzona z rekordem DNS A do publicznego adresu 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. Application Gateway ma zintegrowaną zaporę aplikacji internetowej i obsługuje procedurę uzgadniania TLS dla bicycle.contoso.com, zezwalając tylko na bezpieczne szyfry.

   Application Gateway jest punktem zakończenia protokołu TLS, który jest ważny, ponieważ Application Gateway web application firewall musi sprawdzić żądanie i odpowiedź w postaci zwykłego tekstu.

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

   W miarę jak ruch przechodzi z Application Gateway do backendu, jest ponownie szyfrowany za pomocą innego certyfikatu TLS, który jest symbolem wieloznacznym dla *.aks-ingress.contoso.com, ponieważ przekazuje go do wewnętrznego load balancera. To ponowne szyfrowanie pomaga zagwarantować, że niezabezpieczony ruch nie przepływa do podsieci klastra.

3. Serwer proxy bramy odbiera zaszyfrowany ruch za pośrednictwem modułu równoważenia obciążenia. Proxy to kolejny punkt terminacji TLS dla *.aks-ingress.contoso.com i przekazuje ruch do podów obciążenia przez protokół HTTP.

4. Oba certyfikaty TLS są przechowywane w Key Vault.

   Klaster uzyskuje dostęp do certyfikatu bicycle.contoso.com przy użyciu tożsamości zarządzanej przypisanej przez użytkownika, która integruje się z usługą Application Gateway. Aby uzyskać więcej informacji, zobacz terminacja TLS z certyfikatami Key Vault. Certyfikat TLS dla programu *.aks-ingress.contoso.com jest synchronizowany z klastrem jako wpis tajny Kubernetes, do którego odwołuje się zasób bramy. Aby uzyskać więcej informacji, zobacz Dodawanie zarządzania tajnymi danymi.

Możesz zaimplementować pełny ruch TLS na każdym przeskoku. Pamiętaj, aby wziąć pod uwagę wydajność, opóźnienie i skutki operacyjne wszelkich decyzji dotyczących zabezpieczania ruchu między zasobnikami. W przypadku większości klastrów z jedną dzierżawą, które mają odpowiednią kontrolę dostępu opartą na rolach płaszczyzny sterowania i dojrzałych praktyk cyklu życia tworzenia oprogramowania, wystarczy zaszyfrować protokół TLS do serwera proxy bramy i chronić go przy użyciu Web Application Firewall. Takie podejście minimalizuje obciążenie związane z zarządzaniem obciążeniami i niską wydajnością sieci. Wymagania dotyczące obciążenia i zgodności określają, gdzie wykonujesz terminację TLS.

Przepływ ruchu wychodzącego

W tej architekturze zalecamy, aby cały ruch wychodzący z klastra przechodził przez Azure Firewall. Możesz również użyć własnego podobnego wirtualnego urządzenia sieciowego. Nie zalecamy innych opcji ruchu wychodzącego, takich jak Azure NAT Gateway lub HTTP proxy ponieważ nie zapewniają inspekcji ruchu sieciowego. Dla kontroli Zero Trust i możliwości inspekcji ruchu, wyślij cały ruch wychodzący przez Azure Firewall. Zaimplementuj tę konfigurację przy użyciu tras zdefiniowanych przez użytkownika (UDR). Następnym przeskokiem trasy jest prywatny adres IP Azure Firewall. Azure Firewall decyduje, czy blokować lub zezwalać na ruch wychodzący na podstawie zdefiniowanych reguł, czy wbudowanych reguł analizy zagrożeń.

Alternatywą dla Azure Firewall jest użycie funkcji serwera proxy HTTP AKS. Cały ruch opuszczający klaster jest kierowany do adresu IP serwera proxy HTTP, który następnie przekazuje ruch lub go odrzuca.

W przypadku każdej metody przejrzyj wymagane reguły ruchu sieciowego wyjściowego dla usługi AKS.

Note

Jeśli używasz publicznego modułu równoważenia obciążenia jako publicznego punktu dla ruchu przychodzącego i wychodzącego przez Azure Firewall przy użyciu tras zdefiniowanych przez użytkownika, może wystąpić scenariusz routingu asymetrycznego. Ta architektura używa wewnętrznych modułów równoważenia obciążenia w dedykowanej podsieci wejściowej za Application Gateway. Ten wybór projektu zwiększa bezpieczeństwo, a także eliminuje problemy z routingiem asymetrycznym. Możesz też kierować ruch przychodzący przez zaporę przed lub po Application Gateway, ale takie podejście nie jest konieczne w przypadku większości sytuacji i nie zalecamy go. Aby uzyskać więcej informacji na temat routingu asymetrycznego, zobacz Integrate Firewall with an Azure standard load balancer.

Wyjątkiem od kontrolki Zero Trust jest to, że klaster musi komunikować się z innymi zasobami Azure. Na przykład klaster może wymagać ściągnięcia zaktualizowanego obrazu z rejestru kontenerów lub wpisów tajnych z Key Vault. W tych scenariuszach zalecamy użycie Private Link.

Zaletą korzystania z Private Link 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 Private Link wymaga dodatkowej konfiguracji zamiast używania usługi docelowej za pośrednictwem publicznego punktu końcowego. Ponadto nie wszystkie usługi Azure lub produkty obsługują Private Link. W takich przypadkach rozważ włączenie punktu końcowego usługi sieci wirtualnej w podsieci, aby uzyskać dostęp do usługi.

W przypadku usługi Container Registry należy używać dedykowanych punktów końcowych danych. Bez nich pobieranie warstw obrazu jest przekierowywane do punktu końcowego *.blob.core.windows.net, a nie do prywatnego punktu końcowego rejestru, a reguły zapory dla ruchu wychodzącego musiałyby zezwalać na niebezpieczny wzorzec wieloznaczny usługi Blob Storage. Ta reguła zezwalałaby na ruch wychodzący z węzłów do dowolnego konta usługi Azure Storage. Dedykowane punkty końcowe danych zastępują symbol wieloznaczny nazwami FQDN specyficznymi dla rejestru (<registry>.<region>.data.azurecr.io), które są rozpoznawane za pośrednictwem Private Link do prywatnego punktu końcowego, zachowując ruch w warstwie obrazu na ścieżce prywatnej i umożliwiając określanie zakresu reguł ruchu wychodzącego do rejestru klastra.

Jeśli 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ł Azure Firewall i zapory wbudowanej w usługę docelową. Zapora stosuje translowanie źródłowych adresów sieciowych (SNAT) do przepływów wychodzących, zastępując adres IP zasobnika jednym z dołączonych publicznych adresów IP na przepływ, a wybór nie jest deterministyczny. Dodaj cały zestaw dołączonych publicznych adresów IP do listy dozwolonych adresów IP usługi docelowej lub użyj prefiksu publicznego adresu IP , aby wyrazić ten zestaw jako ciągły zakres.

Jednym z wad nawiązywania połączenia z usługami Azure za pośrednictwem publicznych punktów końcowych jest to, że Azure Firewall następnie potrzebuje więcej reguł, aby upewnić się, że zezwala tylko na ruch z określonej podsieci. Liczba przypisanych publicznych adresów IP również ogranicza pulę portów SNAT i dlatego maksymalny jednoczesny limit połączeń wychodzących klastra. Zaplanuj wiele adresów IP na Azure Firewall zanim wyczerpią się porty. W przypadku klastrów, które otwierają dużą liczbę współbieżnych połączeń wychodzących, dołącz Azure NAT Gateway do AzureFirewallSubnetsieci wirtualnej, aby znacznie rozszerzyć pulę portów SNAT przy jednoczesnym zachowaniu całego ruchu wychodzącego pod kontrolą zapory.

Ruch między zasobnikami

Domyślnie pod może akceptować ruch z dowolnego innego podu w klastrze. Użyj platformy Kubernetes NetworkPolicy, aby ograniczyć ruch sieciowy między podami. Ostrożnie stosuj zasady, aby zapobiec blokowaniu krytycznych przepływów sieci. Zezwalaj tylko na określone ścieżki komunikacyjne, takie jak ruch między serwerem proxy bramy a obciążeniem zgodnie z potrzebami. Ponieważ serwer proxy bramy działa w tej samej przestrzeni nazw co obciążenie, należy go kierować według etykiety zasobnika, a nie selektora przestrzeni nazw. Aby uzyskać więcej informacji, zobacz Network policies.

Włącz zasady sieciowe podczas konfigurowania klastra, ponieważ nie można go dodać później. Masz kilka możliwości technologii do implementacji NetworkPolicy. Azure zasady sieciowe wymagają Azure CNI. 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ęta standardowym wsparciem Azure.

Aby uzyskać więcej informacji, zobacz Differences between Azure network policy engines.

Ruch zarządzania siecią

W ramach uruchamiania klastra serwer interfejsu API Kubernetes otrzymuje ruch od zasobów, które chcą przeprowadzać operacje zarządzania w klastrze, takie jak żądania utworzenia zasobów w celu zwiększenia skali klastra. Przykładami takich zasobów są pula agentów kompilacji w potoku DevOps, instancja Azure Bastion w podsieci Azure Bastion oraz same pule węzłów. Zamiast akceptować ten ruch zarządzania ze wszystkich adresów IP, zalecamy skonfigurowanie prywatnego klastra AKS.

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

Proponujemy wdrożenie klastra AKS jako klaster prywatny. Cały ruch płaszczyzny sterowania i puli węzłów pozostaje w sieci prywatnej i nie jest udostępniany publicznemu Internetowi. Implementacja referencyjna konfiguruje klaster prywatny przy użyciu integracji sieci wirtualnej serwera interfejsu API. Niższe środowiska mogą rozważyć złagodzenie tego zalecenia dotyczącego klastra prywatnego dla wygody, ale produkcyjne klastry usługi AKS powinny być zawsze wdrażane jako klastry prywatne na potrzeby bezpiecznego punktu odniesienia wdrożenia.

Ruch prywatny do prywatnego klastra usługi AKS może pochodzić z sieci wirtualnej odgałęzień, sieci połączonych równorzędnie lub prywatnych punktów końcowych w sieciach zdalnych. Chociaż węzły usługi AKS znajdują się naturalnie w sieci szprychy, operatorzy wykonujący zadania administracyjne potrzebują dedykowanego połączenia sieciowego, aby w sposób prywatny uzyskać dostęp do serwera interfejsu API usługi AKS. Tę łączność można ustanowić na następujące sposoby:

• Tunelowanie: Użyj Azure Bastion, aby otworzyć tunel bezpośrednio do serwera API klastra.
• Pole skoku: Aprowizuj maszynę wirtualną przesiadkową i użyj Azure Bastion, aby nawiązać z nią połączenie za pośrednictwem protokołu SSH lub RDP. Z tego miejsca operator wysyła żądania do serwera interfejsu API klastra za pośrednictwem jego prywatnego adresu IP.

Ta architektura wykorzystuje natywne tunelowanie klienta w usłudze Azure Bastion, aby połączyć komputer lokalny operatora z prywatnym serwerem interfejsu API platformy AKS za pomocą poleceń Azure CLI. Tunel obsługuje bezpośrednie przepływy pracy narzędzia kubectl i Helm bez pola przesiadkowego. To podejście jest zalecane, ponieważ zachowuje prywatny punkt końcowy interfejsu API usługi AKS, a jednocześnie pozostaje prostszy i mniej kosztowny do działania niż serwer przesiadkowy. Jest również mniej złożony do koordynowania między wieloma operatorami.

Możesz jednak użyć pola przesiadkowego, jeśli masz jakiekolwiek z następujących wymagań:

• Operatorzy używają niezabezpieczonych urządzeń. Serwer przesiadkowy może zapewnić silniejsze wzmocnienie zabezpieczeń, jeśli urządzenia klienckie nie są zaufane.

• Operatorzy łączą się za pośrednictwem niestabilnych sieci. Serwer przesiadkowy może zapewnić bardziej stabilne połączenie z klastrem, szczególnie w przypadku długotrwałych lub wsadowych operacji zarządzania.

• Operatory używają zaawansowanych narzędzi diagnostycznych. Niektóre typy narzędzi diagnostycznych, takie jak przechwytywanie pakietów, mogą nie działać prawidłowo w przypadku metod tunelowania.

Dodawanie funkcji zarządzania wpisami tajnymi

Przechowywanie wpisów tajnych w zarządzanym magazynie kluczy, takich jak Key Vault. Zaletą jest to, że zarządzany magazyn kluczy obsługuje rotację wpisów tajnych, zapewnia silne szyfrowanie i dziennik inspekcji dostępu oraz przechowuje podstawowe wpisy tajne z potoku wdrażania. W tej architekturze zapora Key Vault jest włączona i skonfigurowana, a Private Link służy do nawiązywania połączenia z zasobami Azure, takimi jak uzyskiwanie dostępu do wpisów tajnych i certyfikatów.

Key Vault jest dobrze zintegrowana z innymi usługami Azure. Użyj wbudowanej funkcji tych usług, aby uzyskać dostęp do sekretów. Aby uzyskać więcej informacji na temat tego, jak Application Gateway uzyskuje dostęp do certyfikatów TLS dla przepływu ruchu przychodzącego, zobacz sekcję Przepływ ruchu przychodzącego.

Model uprawnień RBAC Azure dla Key Vault umożliwia przypisanie tożsamości obciążeń Key Vault Secrets User lub Key Vault Reader w celu uzyskania dostępu do wpisów tajnych. Aby uzyskać więcej informacji, zobacz Access Key Vault using Azure RBAC.

Access sekrety klastra

Należy użyć tożsamości obciążeń, aby umożliwić zasobnikowi uzyskanie dostępu do tajemnic z określonego magazynu. Aby ułatwić proces pobierania, należy użyć secrets przechowywać sterownik CSI. 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 Key Vault ze sterownikiem CSI magazynu wpisów tajnych z ręcznym podejściem do konfiguracji protokołu TLS. Zasób SecretProviderClass definiuje, które certyfikaty z usługi Key Vault mają być synchronizowane do klastra jako obiekty Secret platformy Kubernetes. Sterownik CSI wymaga co najmniej jednego poda, który zamontuje odpowiedni wolumin CSI, aby utworzyć i utrzymywać zsynchronizowany Secret. Jeśli usuniesz wszystkie zainstalowane zasobniki, sterownik odśmieca wpis tajny, co oznacza, że brama utraci certyfikat TLS. Aby temu zapobiec, należy wdrożyć dedykowany, zawsze uruchomiony zasobnik, który utrzymuje wolumin CSI zainstalowany niezależnie od cykli życia zasobników obciążenia.

Ta architektura wykorzystuje obraz kontenera BusyBox, w którym działa lekki kontener z pozornym zadaniem. Zaimportuj obraz kontenera do Azure Container Registry przed utworzeniem klastra, ponieważ platforma Flux wdraża go podczas uruchamiania. Włącz rotację wpisów tajnych i ustaw interwał sondowania rotacji, taki jak dwie minuty dodatku CSI, dzięki czemu Key Vault odnawianie certyfikatów jest propagowane automatycznie. Zasób Gateway odwołuje się do zsynchronizowanego obiektu Secret TLS na potrzeby terminacji HTTPS. Aby uzyskać więcej informacji, zobacz Zabezpieczanie ruchu przychodzącego przy użyciu implementacji interfejsu API routingu aplikacji.

Jak wspomniano w artykule Dostęp usługi AKS do Azure składników, tę konfigurację ręczną można zastąpić podejściem TLS zarządzanym przez operator. W tym podejściu należy zadeklarować identyfikator URI certyfikatu Key Vault i konto Usługi tożsamości obciążenia bezpośrednio na odbiorniku bramy. Operator routingu aplikacji tworzy klasę SecretProviderClass i automatycznie stosuje poprawki do odwołania certyfikatu bramy, co eliminuje konieczność tworzenia tych zasobów podczas uruchamiania klastra lub tworzenia dedykowanego zasobnika synchronizacji tls. Oba podejścia polegają na mechanizmie rotacji sterownika CSI w celu pobrania odnawiania certyfikatów z Key Vault.

Przechowywanie obciążenia roboczego

Obciążenie robocze 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, zapoznaj się z opcje magazynowania dla aplikacji w AKS.

Zarządzanie zasadami

Skutecznym sposobem zarządzania klastrem usługi AKS jest wymuszanie ładu za pomocą zasad. Platforma Kubernetes implementuje zasady za pośrednictwem usługi OPA Gatekeeper. W przypadku usługi AKS dostarczaj zasady za pośrednictwem 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żna użyć Azure Policy na kilka sposobów:

• Uniemożliwiaj 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ą Azure Policy dla platformy Kubernetes.

Typowym przykładem, w którym zasady mogą być przydatne, jest zarządzanie i walidacja obrazów kontenerowych. Obrazy kontenerów mogą być źródłem luk w zabezpieczeniach, a niektóre organizacje wymagają, aby niezaufane obrazy kontenerów były najpierw weryfikowane przy użyciu narzędzia do skanowania obrazów, a następnie zatwierdzane, zanim będą mogły być używane w klastrze produkcyjnym. Ten proces można wymusić przy użyciu Azure Policy i zablokować rozmieszczenie niezaufanych obrazów kontenerów w klastrze. Aby uzyskać więcej informacji, zobacz wzorzec Quarantine.

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

• Zdecyduj, czy ustawić kolekcję zasad, znaną jako inicjatywy, czy wybrać poszczególne zasady. Azure Policy oferuje dwie wbudowane inicjatywy: podstawowe i ograniczone. Każda inicjatywa to zbiór wbudowanych zasad stosowanych do klastra 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.

• Zdecyduj, czy chcesz przeprowadzić inspekcję lub odmówić akcji. W trybie inspekcji akcja jest dozwolona, ale oznaczona jako niezgodna. Posiadanie procesów do sprawdzania niezgodnych stanów w regularnych odstępach czasu i podejmowania niezbędnych działań. W trybie odmowy akcja jest blokowana, ponieważ narusza zasady. Podczas wybierania trybu odmowy należy zachować ostrożność, ponieważ może to być zbyt restrykcyjne, aby obciążenie działało.

• Zdecyduj, czy masz obszary w obciążeniu, które nie powinny być zgodne z projektem. Azure Policy określa przestrzenie nazw Kubernetes, które są wykluczone z wymuszania zasad. Zalecamy stosowanie zasad w trybie inspekcji, aby pamiętać o tych wystąpieniach.

• Zdecyduj, czy masz wymagania, które nie są objęte wbudowanymi zasadami. Możesz utworzyć niestandardową definicję 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.

• Zdecyduj, 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.

• Zdecyduj, czy musisz przypisać zasady 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 zostały uwzględnione w przedprodukcji.

Implementacja referencyjna umożliwia Azure Policy podczas tworzenia 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 sprawdzić, jak działa Azure Policy w Twoim klastrze, możesz uzyskać dostęp do logów podów dla wszystkich podów w przestrzeni nazw gatekeeper-system oraz logów dla podów azure-policy i azure-policy-webhook w przestrzeni nazw kube-system.

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

Wraz z rosnącym zapotrzebowaniem, Kubernetes może się skalować poprzez dodanie większej liczby zasobników do istniejących węzłów, dzięki poziomemu automatycznemu skalowaniu zasobników. Gdy Kubernetes nie może już zaplanować większej liczby zasobników, liczba węzłów musi zostać zwiększona za pomocą automatycznego skalowania klastra AKS. Kompletne rozwiązanie skalowania musi mieć metody skalowania zarówno replik podó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 podów z biegiem czasu. Liczbę węzłów można dostosować za pomocą Azure CLI lub portalu Azure.

Zalecamy użycie podejścia do skalowania automatycznego, ponieważ niektóre mechanizmy ręczne 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ściowych i ręcznego skalowania, aby zlokalizować wąskie gardła i zrozumieć, jak aplikacja reaguje na skalowanie. Na koniec użyj tych danych, aby ustawić parametry skalowania automatycznego.

Narzędzie do automatycznego skalowania zasobników w poziomie

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

W zasobie HPA zalecamy ustawienie minimalnej i maksymalnej liczby replik. Wartości ograniczają ograniczenia skalowania automatycznego.

HPA może być skalowane na podstawie użycia CPU, użycia pamięci i metryk niestandardowych. Tylko użycie procesora CPU jest udostępniane natywnie. 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 niedostatecznie alokowane. 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 wystąpić stan wyścigu, na przykład kiedy HPA sprawdza coś przed zakończeniem operacji skalowania. W związku z tym wynik może być niepoprawnym obliczeniem współczynnika. Więcej informacji znajdziesz w sekcji Okres oczekiwania wydarzeń skalowania.

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 skalery. Użyj listy źródeł zdarzeń, które usługa KEDA może skalować w narzędziach skalowania KEDA. Lista zawiera Azure Monitor scaler, który jest wygodnym sposobem skalowania obciążeń KEDA opartych na metrykach Azure Monitor.

Automatyczny skalownik klastra

cluster autoscaler to składnik dodatku usługi AKS, który skaluje liczbę węzłów w puli węzłów. Dodaj go podczas tworzenia 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 harmonogramator platformy Kubernetes nie może zaplanować podu z powodu ograniczeń zasobów, narzędzie do automatycznego skalowania automatycznie konfiguruje 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 działa 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 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.

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

Aby zachować ciągłość działalności biznesowej, zdefiniuj poziom SLO dla infrastruktury i aplikacji. Aby uzyskać więcej informacji, zobacz Poleceń dotyczące definiowania celów niezawodności. Zapoznaj się z postanowieniami umowy dotyczącej poziomu usług (SLA) dla usługi AKS w najnowszym artykule SLA dla usług online.

Węzły klastra

Aby zapewnić minimalną dostępność dla zadań roboczych, konieczne jest posiadanie 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 lub pojemności, rozszerz skalę, aby dodać 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 znamion w celu zidentyfikowania puli węzłów i zaplanowania obciążenia roboczego. Upewnij się, że pula węzłów systemu jest oznaczona CriticalAddonsOnly taint, aby zapobiec zaplanowaniu zasobników aplikacji w pulach węzłów systemu.

Regularne zadania utrzymania w klastrze, takie jak aktualizacje terminowe, mają kluczowe znaczenie dla niezawodności. Zalecamy również, aby monitorować kondycję podów za pomocą sond.

Dostępność zasobnika

• Określ wymagania dotyczące zasobów podu: Zalecamy określenie wymagań dotyczących zasobów podu w ramach wdrożeń. Harmonogram może następnie odpowiednio zaplanować zasobnik. Niezawodność jest znacznie ograniczona, jeśli nie można zaplanować podó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ń Podów.

  Skonfiguruj wiele replik we wdrożeniu, aby obsługiwać zakłócenia, takie jak awarie sprzętowe. W przypadku planowanych zdarzeń, takich jak aktualizacje i uaktualnienia, budżet przerw może pomóc w zapewnieniu, że istnieje wymagana liczba replik podów do obsługi przewidywanego obciążenia aplikacji.

• Ustaw limity zasobów w obszarach nazw obciążenia: Limit zasobów w obszarze nazw pomaga upewnić się, że żądania podów i limity są prawidłowo ustawione we wdrożeniu. Aby uzyskać więcej informacji, zobacz Wdrażanie limitów zasobów.

  Note

  Jeśli ustawisz limity przydziału zasobów na poziomie klastra, problemy mogą wystąpić w przypadku wdrażania obciążeń zewnętrznych, które nie mają odpowiednich żądań i limitów. Ustawienie limitów przydziału na poziomie przestrzeni nazw zapewnia, że mają zastosowanie tylko do składników obciążenia.

• Ustaw żądania i limity podów: Ustaw żądania i limity, aby umożliwić platformie Kubernetes efektywne przydzielanie zasobów CPU i pamięci do podów. Zapewnia większą gęstość kontenerów 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 powoduje niestabilność klastra.

  Żądania i limity można określić w manifestach wdrożenia. Aby uzyskać więcej informacji, zobacz Podstawowe ustawienia żądań i limitów poda.

Strefy dostępności

Aby chronić przed niektórymi typami awarii, użyj availability zones jeśli region je obsługuje. Zarówno składniki płaszczyzny sterowania, jak i węzły w pulach węzłów są następnie strefowo nadmiarowe, co oznacza, że są one rozmieszczone w wielu strefach. 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 mapowana na oddzielny skalowalny zestaw maszyn wirtualnych, który zarządza instancjami 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 Limitations. Aby uzyskać umowę SLA czasu pracy, musisz wybrać poziom Standardowy lub Premium. SLA dotycząca dostępności jest wyższa, gdy używasz 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.

  Nadmiarowość strefy ma zastosowanie nie tylko do pul węzłów, ale także do 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, komponenty płaszczyzny kontrolnej nie mają gwarancji rozproszenia pomiędzy strefami dostępności.

• Zależne zasoby: Aby osiągnąć korzyść z odporności dzięki użyciu stref dostępności, wszystkie zależności usługowe 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.

  Załóżmy na przykład, że obciążenie używa bazy danych, która nie jest odporna na strefy. Jeśli wystąpi awaria, węzeł usługi AKS może przejść do innej strefy, ale baza danych nie zostanie przeniesiona z węzłem do tej strefy, więc obciążenie zostanie przerwane.

Dla uproszczenia tej architektury, usługa AKS jest wdrożona w jednym regionie, a pule węzłów obejmują trzy strefy dostępności. 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 gwarantuje się wystarczającej ochrony w mało prawdopodobnym przypadku awarii całego regionu. Aby uzyskać większą dostępność, uruchom wiele klastrów usługi AKS w różnych regionach.

• Preferuj sparowane regiony, kiedy są dostępne. Zaletą korzystania z sparowanych regionów jest niezawodność podczas aktualizacji platformy. Azure upewnia się, ż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 skonfigurujesz do zarządzania procesem odzyskiwania po awarii regionu. Określone 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 Azure obsługuje nadmiarowość geograficzną. Na przykład włączenie replikacji geograficznej dla usługi Container Registry powoduje automatyczne replikowanie obrazów do wybranych regionów Azure. Zapewnia również dalszy dostęp do obrazów, nawet jeśli główny region 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 Load Balancer, ponieważ może dystrybuować ruch niezwiązany z siecią w różnych strefach. Jeśli musisz dystrybuować ruch między regionami, rozważ Azure Front Door. Aby zobaczyć inne opcje, przejdź do Wybierz równoważenie obciążenia.

Note

Przykładowy scenariusz AKS dla klastrów wieloregionowych rozszerza architekturę w tym artykule, aby uwzględnić wiele regionów w konfiguracji aktywne-aktywne i wysokiej dostępności.

Odzyskiwanie po awarii

Najlepiej, jeśli wystąpi awaria w regionie głównym, możesz szybko przełączyć się do wystąpienia w innym regionie. Możesz wstępnie utworzyć klaster lub poczekać na jego utworzenie, dopóki nie będzie to wymagane. Rozważmy następujące zalecenia:

• Użyj wielu regionów. Jeśli region podstawowy ma sparowany region, skorzystaj z 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, na przykład replikowanie do innego regionu w ramach potoku DevOps, w celu spełnienia SLO.

• Skonfiguruj każdą usługę 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, mechanizm automatycznego przełączania awaryjnego ACR uwzględniający kondycję usługi automatycznie przekierowuje żądania pobierania do sprawnej repliki za pośrednictwem globalnego punktu końcowego bez konieczności zmiany konfiguracji klastra.

• 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.

Kopia zapasowa klastra

W przypadku wielu architektur można skonfigurować nowy klaster i zwrócić go do stanu operacyjnego za pomocą uruchamiania klastra opartego na metodyce GitOps, a następnie wdrożenia aplikacji. Jeśli jednak chodzi o krytyczny stan zasobów, takich jak mapy konfiguracji, zadania i sekrety, których nie można przechwycić w procesie uruchamiania, rozważ swoją 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 kopia zapasowa klastra musi być częścią strategii odzyskiwania, musisz zainstalować rozwiązanie zgodne z wymaganiami biznesowymi w klastrze. Ten agent jest odpowiedzialny za wypychanie stanu zasobu klastra do wybranego miejsca docelowego i koordynowanie Azure migawek woluminów trwałych opartych na dyskach.

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 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, przy czym harmonogramy i zakres kopii zapasowej są określane jako konfiguracja magazynu w Azure Backup.

Implementacja referencyjna nie implementuje kopii zapasowej, która obejmuje dodatkowe zasoby Azure do zarządzania, monitorowania, kupowania i zabezpieczania. Te zasoby mogą obejmować konto Azure Storage, magazyn Azure Backup i konfigurację oraz funkcję trusted access. Zamiast tego usługa GitOps połączona z zamiarem uruchamiania obciążenia bezstanowego jest rozwiązaniem odzyskiwania.

Wybierz i zweryfikuj rozwiązanie do tworzenia kopii zapasowej spełniające cel biznesowy, który obejmuje zdefiniowany cel punktu odzyskiwania i cel czasu odzyskiwania. Zdefiniuj proces odzyskiwania w elemencie runbooku zespołowego i przećwicz go dla wszystkich obciążeń krytycznych dla działania biznesu.

Jeśli musisz obsługiwać obciążenia stanowe i wdrażać AKS Backup, użyj Azure Policy, aby wymusić skonfigurowanie tej kopii zapasowej w klastrze. Azure Monitor przedstawia kondycję zadania tworzenia kopii zapasowej za pomocą tego samego stosu możliwości obserwowania, który został już utworzony w tej architekturze. Oprócz tych zasad ładu w projekcie należy uwzględnić następujące kwestie architektoniczne:

• Zakres kopii zapasowej. Zdecyduj, czy tworzysz kopię zapasową całego klastra, czy określonych przestrzeni nazw. AKS Backup przechowuje dane w kontenerze obiektów blob oraz w postaci migawek dysków lub plików. Zdefiniuj ten zakres na wczesnym etapie, ponieważ determinuje on rozmiar konta magazynowego, zasady przechowywania i poziom szczegółowości odzyskiwania w scenariuszach takich jak odzyskiwanie operacyjne, klonowanie środowiska i aktualizacje klastra.
• Zaufany dostęp. Usługa AKS Backup wymaga zaufanego dostępu między magazynem kopii zapasowych a klastrem usługi AKS, niezależnie od tego, czy klaster jest publiczny, prywatny, czy ograniczony przez adres IP.
• Uprawnienia RBAC. Tożsamość zarządzana magazynu kopii zapasowych wymaga zestawu uprawnień w klastrze usługi AKS do konfigurowania i wykonywania kopii zapasowych. Rozszerzenie kopii zapasowej tworzy również tożsamość użytkownika z uprawnieniami na koncie magazynu, na którym są przechowywane kopie zapasowe.
• Ruch wychodzący sieci. Rozszerzenie kopii zapasowej komunikuje się z usługami Azure Backup z poziomu klastra. Uwzględnij wymagane wychodzące punkty końcowe w regułach usługi Azure Firewall i NSG.
• Zajętość zasobów w klastrze. Rozszerzenie wdraża zasobniki na Twoich węzłach. Uwzględnij dodatkowe zużycie zasobów obliczeniowych i pamięci w limitach zasobów węzłów oraz uwzględnij przestrzeń nazw rozszerzenia w zarządzaniu zasadami sieciowymi.

Umowa SLA serwera interfejsu API platformy Kubernetes

Usługę AKS można używać jako bezpłatnej usługi, ale ta warstwa nie zapewnia umowy SLA wspieranej finansowo. Aby uzyskać umowę SLA, musisz wybrać warstwę Standard. Zalecamy wszystkie klastry produkcyjne używać warstwy Standardowej. Zarezerwuj warstwę Bezpłatną dla klastrów przedprodukcyjnych oraz warstwę Premium tylko dla obciążeń o krytycznym znaczeniu. W przypadku korzystania ze stref dostępności Azure, umowa SLA serwera API 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 SLA dla usług online.

Kompromis

Istnieje kompromis między kosztem a dostępnością przy wdrażaniu architektury w różnych strefach i szczególnie w regionach. 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 należy spodziewać się niewielkiego opóźnienia sieci w komunikacji węzłów między strefami i większego opóźnienia komunikacji między regionami. Zmierz wpływ tej decyzji architektonicznej na obciążenie.

Testowanie z symulacjami i wymuszonym failover.

Przetestuj niezawodność rozwiązania za pomocą wymuszonego testowania trybu failover z symulowanymi awariami. Symulacje mogą obejmować zatrzymywanie węzła, wyłączanie wszystkich zasobów usługi AKS w określonej strefie w celu symulowania awarii strefy lub wywoływanie awarii zależności zewnętrznej. Można również użyć Azure Chaos Studio do symulowania różnych typów awarii w Azure i w klastrze.

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

Monitorowanie i zbieranie dzienników i metryk

Zalecamy usługi monitorowania Azure Monitor Kubernetes do monitorowania wydajności obciążeń kontenerów, ponieważ można wyświetlać zdarzenia w czasie rzeczywistym. Azure Monitor przechwytuje dzienniki kontenerów z uruchomionych podów i agreguje je w celu wyświetlenia. 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żna również użyć Azure Monitor do monitorowania wydajności w miarę skalowania zasobników. Obejmuje ona dane telemetryczne, które mają kluczowe znaczenie dla monitorowania, analizy i wizualizacji zebranych danych.

Włącz zbieranie dzienników z podów

Schemat dziennika ContainerLogV2 jest przeznaczony do przechwytywania dzienników kontenerów z zasobników Kubernetes w sposób usprawniony. Wpisy dziennika są konsolidowane w tabeli ContainerLogV2 w obszarze roboczym Azure Log Analytics.

W klastrze AKS istnieją dwie podstawowe metody konfigurowania zbierania logów podów. Obie metody umożliwiają dostosowanie ustawień. Przestrzenie nazw można filtrować, dostosowywać interwały kolekcji, włączać lub uniemożliwiać korzystanie z określonych funkcji (takich jak ContainerLogV2 lub ContainerLogV2-HighScale) i określić, które strumienie danych mają być zbierane.

• Jeśli potrzebujesz scentralizowanych konfiguracji monitorowania wielokrotnego wykorzystania w wielu klastrach lub wolisz, aby konfiguracja klastra została przeniesiona na natywne zasoby Azure, użyj reguł zbierania danych (DCR). DCR to zasoby Azure, którymi płaszczyzna sterowania w Azure Resource Manager zarządza natywnie. Można je uwzględnić w plikach Bicep. Implementacja referencyjna używa DCR.

• Możesz też zdefiniować monitorowanie przy użyciu obiektów ConfigMap, które są niekonfidentalnymi obiektami YAML platformy Kubernetes skonfigurowanymi za pomocą płaszczyzny sterowania interfejsu API Kubernetes. Agent Azure Monitor uruchomiony na monitorach klastra dla obiektów ConfigMap. Używa wstępnie zdefiniowanych ustawień, aby określić, które dane mają być zbierane.

Gdy obie metody są włączone, ustawienia ConfigMap mają pierwszeństwo przed Regułami Zbierania Danych (DCR). Unikaj mieszania konfiguracji ConfigMap i DCR na potrzeby zbierania dzienników kontenerów, ponieważ może to spowodować trudne do rozwiązania problemów z rejestrowaniem.

Alerty i metryki rozwiązania Prometheus

Awarie i usterki stanowią znaczne zagrożenie dla aplikacji związanych z obciążeniem, co sprawia, że niezbędne jest proaktywne identyfikowanie problemów związanych z kondycją i wydajnością infrastruktury. Monitorując swoje środowisko i działając korzystając z nabytej wiedzy, zmniejszasz zakłócenia i zwiększasz niezawodność rozwiązania. Aby przewidzieć potencjalne warunki awarii w klastrze, włącz zalecane reguły alertów Rozwiązania Prometheus dla platformy Kubernetes.

Większość obciążeń hostowanych w zasobnikach emituje metryki Prometheus. Azure Monitor można zintegrować z rozwiązaniem Prometheus. Możesz zobaczyć metryki aplikacji i obciążenia zbierane z kontenerów, zasobników, węzłów i klastra.

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

Azure infrastruktura i dzienniki płaszczyzny sterowania Kubernetes

Dzięki usłudze AKS Azure zarządza niektórymi podstawowymi usługami Kubernetes. Azure implementuje dzienniki składników warstwy kontrolnej usługi AKS w postaci resource logs. Funkcje te mogą pomóc w diagnostyce problemów z klastrem i charakteryzują się stosunkowo niską gęstością logów. Zalecamy włączenie następujących opcji w większości klastrów:

• ClusterAutoscaler: Uzyskaj wgląd w operacje skalowania za pomocą rejestrowania. Aby uzyskać więcej informacji, zobacz Pobierz logi i stan skalera automatycznego klastra.

• KubeControllerManager: Uzyskaj wgląd w interakcję między platformą Kubernetes a płaszczyzną sterowania Azure.

• kube-audit-admin: Zyskaj wgląd w działania modyfikujące klaster. Nie ma potrzeby włączania jednocześnie kube-audit i kube-audit-admin, ponieważ kube-audit jest nadzbiorem, który obejmuje również operacje niemodyfikowane (odczyt).

• guard: Przechwytywanie audytów Microsoft Entra ID i Azure RBAC.

Przydatne może być włączenie innych kategorii dzienników, takich jak KubeScheduler lub kube-audit, na wczesnym etapie opracowywania 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. Jeśli jednak dzienniki rozszerzonego rozwiązywania problemów będą przechowywane w pełnym wymiarze czasu po zakończeniu rozwiązywania problemów, może to spowodować poniesienie niepotrzebnych kosztów pozyskiwania i przechowywania danych w Azure Monitor.

Azure Monitor zawiera zestaw istniejących zapytań dzienników, które mogą posłużyć jako punkt wyjścia, a także mogą być podstawą do tworzenia własnych zapytań. W miarę rozwoju biblioteki można zapisywać i ponownie używać zapytań dziennika przy użyciu co najmniej jednego pakietu query. Twoja niestandardowa biblioteka zapytań zapewnia lepszą widoczność kondycji i wydajności klastrów usługi AKS. Obsługuje ona osiąganie celów SLO.

Aby uzyskać więcej informacji na temat monitorowania najlepszych rozwiązań dotyczących usługi AKS, zobacz Monitorowanie usługi AKS przy użyciu Azure Monitor.

Metryki sieci

Podstawowe metryki sieci na poziomie klastra są dostępne za pośrednictwem metryk natywnych platform i Prometheus. Aby uwidocznić metryki sieciowe węzłów AKS, można użyć metryk Prometheusa do prezentacji metryk sieciowych na poziomie węzła. 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 używa Azure Monitor, która również zbiera niektóre metryki związane z siecią. Implementacja referencyjna uniemożliwia bezpośrednie zbieranie niektórych metryk sieci z Azure Monitor, a zamiast tego zbiera metryki obserwacji sieci przy użyciu obszaru roboczego Azure Monitor z zarządzanym prometheusem.

** 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 obciążenia DNS, metryki sieci na poziomie pod są ważne. W usłudze AKS można uzyskać dostęp do tych szczegółowych metryk przy użyciu funkcji Advanced Container Networking Services. Większość obciążeń nie wymaga tej głębokości wglądu w sieć. Nie należy włączać zaawansowanej obserwowalności sieci, chyba że pody wymagają wysoce zoptymalizowanej sieci z czułości na poziomie pakietów.

Optymalizacja kosztów logowania

Implementacja referencyjna konfiguruje tabelę ContainerLogV2 do używania planu podstawowego jako punktu początkowego. Microsoft Defender dla kontenerów oraz 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 gromadzenia.

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. Podczas monitorowania wzorców użycia i dostosowywania planów tabel w razie potrzeby można osiągnąć równowagę między kosztami i funkcjami rozwiązania do monitorowania.

Aby uzyskać więcej informacji, zobacz Wybierz plan tabeli na podstawie użycia danych w obszarze roboczym Log Analytics.

Włącz samonaprawianie

Monitoruj kondycję zasobników, ustawiając sondy żywotności i gotowości. Jeśli platforma Kubernetes wykryje brak odpowiedzi zasobnika, uruchomi ponownie zasobnik. Sonda stanu żywotności określa, czy zasobnik jest zdrowy. Jeśli platforma Kubernetes wykryje brak odpowiedzi zasobnika, uruchomi ponownie zasobnik. Sonda gotowości określa, czy pod jest gotowy do przetwarzania żądań i obsługi ruchu.

Note

Usługa AKS ma funkcję automatycznej naprawy węzłów, która zapewnia wbudowane samonaprawianie węzłów infrastruktury.

Rutynowe aktualizacje klastrów AKS

Częścią codziennych operacji dla klastrów Kubernetes jest wykonywanie rutynowych aktualizacji platformy i systemu operacyjnego. Należy zająć się trzema warstwami aktualizacji na każdym klastrze usługi AKS.

• Wersja Kubernetes (na przykład Kubernetes 1.32.3 do 1.32.7 lub Kubernetes 1.32.7 do 1.33.1), która może zawierać zmiany i wycofania 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 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 są testowane względem wersji 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, jak często mają być aktualizowane poszczególne klastry usługi AKS, pule węzłów lub węzły (częstotliwość). Ponadto wybierz dni lub godziny stosowania aktualizacji ( okno obsługi). Wybierz, czy aktualizacje mają być instalowane ręcznie, automatycznie, czy wcale. 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 AKS patch and upgrade guidance in the AKS day-2 operations guide. 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 node na none i automatyczne uaktualnianie klastra na none. W tej konfiguracji ponosisz wyłączną odpowiedzialność za wszystkie uaktualnienia we wszystkich warstwach.

Po udostępnieniu żądanej aktualizacji należy wykonać następujące czynności:

1. Przetestuj aktualizację w środowisku przedprodukcyjnym i oceń jego zgodność w nowym klastrze.

2. Wdróż projekt produkcyjny, który zawiera zaktualizowaną wersję AKS i zaktualizowane VHD puli węzłów.

3. Gdy nowy klaster produkcyjny jest gotowy, opróżnij stary klaster i w końcu go zlikwidować.

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

Uaktualnienia na bieżąco

Obciążenia, które nie obsługują klastrów usługi AKS jako niezmienialnej 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 planowaną konserwację 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 pod disruption budgets, tak aby aplikacja pozostała stabilna podczas aktualizacji progresywnych. Nie należy jednak konfigurować budżetów w taki sposób, aby blokowały aktualizacje węzłów, ponieważ większość aktualizacji wymaga procesu wyłączenia i opróżnienia w każdym węźle.

• Potwierdź limit przydziału i dostępność zasobów Azure. Aktualizacje w miejscu wdrażają nowe instancje węzłów, zwane węzłami przepięcia, zanim stare węzły zostaną usunięte. Oznacza to, że limit przydziału w Azure oraz przestrzeń adresowa IP powinny być dostępne na nowe węzły. Wartość przeciążenia o 33% jest dobrym punktem wyjścia dla większości obciążeń.

• Przetestuj zgodność z narzędziami, takimi jak siatki usług lub agenty bezpieczeństwa, które dodałeś do klastra. Ponadto przetestuj składniki obciążenia, takie jak kontrolery wejściowe, siatki usług i zasobniki obciążenia. Uruchamianie testów w środowisku przedprodukcyjnym.

Aktualizacje na miejscu dla węzłów

Użyj kanału automatycznych aktualizacji 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. Microsoft przeprowadza testy aktualizacji na Twojej wersji AKS. W przypadku węzłów Windows aktualizacje są aktualizowane co miesiąc. W przypadku węzłów systemu Linux 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 zaplanowane okno konserwacyjne, które należy ustawić przynajmniej raz w tygodniu. Ustaw to niezależnie od tego, jakiego systemu operacyjnego obrazu węzła używasz, aby zagwarantować szybkie stosowanie aktualizacji.

• Te aktualizacje obejmują zabezpieczenia na poziomie systemu operacyjnego, zgodność i aktualizacje funkcjonalne, ustawienia konfiguracji systemu operacyjnego i aktualizacje składników usługi AKS.

• Wydania obrazów i dołączone numery wersji komponentów są śledzone przy użyciu śledzenia wydania 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. Microsoft również testuje te aktualizacje. Aktualizacje są publikowane tylko wtedy, gdy istnieją uaktualnienia zabezpieczeń, które Microsoft uznają 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 uwzględnia Twoje okna konserwacyjne, więc upewnij się, że okna konserwacyjne mają częstsze przerwy (takie jak codziennie lub co drugi dzień), aby wspierać te niespodziewane aktualizacje zabezpieczeń.

Większość klastrów, które wykonują bezpośrednie aktualizacje, powinna unikać opcji kanału uaktualniania obrazu węzła None 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ć przy dwóch najnowszych wersjach (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 AKS na miejscu z należytym zachowaniem ostrożności i rygoru. 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żda aktualizacja na miejscu może spowodować nieoczekiwane zachowanie. Jeśli aktualizacje w miejscu są uznawane za zbyt ryzykowne dla Twojego obciążenia, zalecamy użycie wdrożenia blue-green klastrów AKS zamiast stosowania pozostałych zaleceń.

Zalecamy unikanie automatycznej aktualizacji 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ąć nastawienie na „bycie na bieżąco” niż podejście na długoterminowe wsparcie.

Warning

Nie zalecamy automatycznego stosowania poprawek ani aktualizowania produkcyjnego klastra usługi AKS, nawet w przypadku aktualizacji wersji pomocniczej, chyba że najpierw przetestujesz te aktualizacje w niższych środowiskach. Aby uzyskać więcej informacji, zobacz Regularnie aktualizuj do najnowszej wersji Kubernetes i Zaktualizuj klaster AKS.

Powiadomienia o dostępności nowej wersji usługi AKS dla klastra można otrzymywać przy użyciu systemu AKS dla systemu Azure Event Grid. Implementacja referencyjna wdraża ten system usługi Event Grid, dzięki czemu można subskrybować zdarzenie Microsoft.ContainerService.NewKubernetesVersionAvailable z Twojego rozwiązania do powiadomień o strumieniu zdarzeń. Przejrzyj informacje o wersji AKS pod kątem konkretnych problemów ze zgodnością, zmian zachowania lub wycofywania funkcji.

Choćby po jakimś czasie nabrać pewności co do wydań Kubernetes, wydań AKS, swojego klastra, jego komponentów na poziomie klastra i obciążeń, aby móc zbadać funkcję automatycznej aktualizacji. W przypadku systemów produkcyjnych rzadko zdarza się wykraczać poza patch. Ponadto po automatycznym uaktualnieniu wersji usługi AKS sprawdź ustawienie wersji usługi AKS w infrastrukturze jako kod (IaC), aby te dwie wersje nie wyszły z synchronizacji. 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. Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Microsoft Defender for Containers identyfikuje i koryguje zalecenia Defender dla Chmury dotyczące obrazów kontenerów.
• Defender kontenerów regularnie skanuje obrazy kontenerów pod kątem luk w zabezpieczeniach.
• Defender dla kontenerów generuje również alerty zabezpieczeń w czasie rzeczywistym dotyczące podejrzanych działań.
• Zabezpieczenia dla aplikacji i klastrów w usłudze AKS zawiera szczegółowe informacje o tym, jak zabezpieczenia kontenerowe chronią cały kompleksowy potok end-to-end, od kompilacji do momentu uruchomienia 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), zapoznaj się z filarem zasad projektowania doskonałości operacyjnej.

Uruchamianie klastra

Po skonfigurowaniu klastra staje się on działającym klastrem, ale możesz mieć do wykonania dodatkowe kroki przed wdrożeniem zadań. Proces przygotowywania klastra nosi nazwę bootstrapping. Bootstrapping często polega na wdrażaniu wymaganych uprzednio obrazów na węzłach klastra, tworzeniu przestrzeni nazw i wykonywaniu innych zadań, które spełniają wymagania przypadku użycia organizacji.

Aby przyspieszyć przejście z nowo skonfigurowanego klastra do prawidłowo skonfigurowanego, należy zdefiniować unikatowy proces uruchamiania i przygotować odpowiednie zasoby z wyprzedzeniem. Jeśli na przykład używasz siatki usług, takiej jak Linkerd lub Consul Connect, zazwyczaj wdrażasz siatkę przed zaplanowaniem obciążeń aplikacji. Przed skonfigurowaniem klastra należy sprawdzić, czy obrazy usługi Service Mesh istnieją w wcześniej utworzonym rejestrze kontenerów. Ta walidacja pomaga zapobiegać opóźnieniom lub niepowodzeniom wdrażania.

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

• rozszerzenie klastra GitOps Flux v2
• Pipelines
• Autokonfiguracja za pomocą Flux lub Argo CD, na przykład

Note

Każda z tych metod działa z dowolną topologią klastra, ale zalecamy rozszerzenie klastra GitOps Flux v2 dla flot dla zapewnienia jednolitości i łatwiejszego zarządzania na dużą skalę. Po uruchomieniu tylko kilku klastrów usługa GitOps może być nadmiernie złożona. Zamiast tego możesz zdecydować się na zintegrowanie procesu z jedną lub większą liczbą linii potoków wdrożeniowych, aby upewnić się, że uruchomienie ma miejsce. Użyj metody, która najlepiej pasuje do celów organizacji i zespołu.

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, stawiając solidne fundamenty zarządzania na przyszłość, a także wspiera włączanie bootstrappingu jako szablonów zasobów w celu dostosowania do strategii IaC.

Gdy bootstrapped manifesty wymagają wartości, które są znane tylko w czasie wdrażania, takie jak adres URL rejestru kontenerów, nazwa Key Vault lub identyfikator klienta tożsamości, należy użyć podstawienia zmiennej Flux w konfiguracji kustomization. Kustomization określa, która ścieżka w repozytorium Git ma być synchronizowana oraz które podstawienia zmiennych po kompilacji należy zastosować. Konfigurację kustomizations można skonfigurować w ramach wdrożenia rozszerzenia Flux w szablonie IaC, w którym definiuje się zmienne podstawienia, aby wartości zostały rozpoznane z wdrożonych zasobów w czasie tworzenia klastra. Takie podejście eliminuje problemy wynikające z kolejności wykonywania, które pojawiają się, gdy obiekt ConfigMap musi istnieć przed pierwszą rekonsyliacją, a także pozwala uniknąć konieczności forkowania repozytorium wyłącznie po to, aby dostosować wartości właściwe dla danego środowiska. Agent rozszerzenia Flux tłumaczy tę konfigurację IaC na zasoby niestandardowe kubernetes, które kontroler Flux Kustomize uzgadnia, stosując zamiany zmiennych podczas przetwarzania każdej ścieżki.

Na koniec, jeśli używasz rozszerzenia klastra GitOps Flux v2, narzędzie kubectl nie jest wymagane w żadnej części procesu uruchamiania. Można zarezerwować dostęp kubectl na czas awaryjnych przypadków naprawczych. Między szablonami definicji zasobów Azure a uruchamianiem manifestów przez rozszerzenie GitOps można wykonywać wszystkie normalne działania konfiguracyjne bez konieczności używania narzędzia wiersza poleceń 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, które zawiera fundamentalne składniki, i rozwijaj je dalej. Początkowym zadaniem jest skonfigurowanie sieci. Skonfiguruj sieci wirtualne typu "hub and spoke" oraz podsieci w tych sieciach. Na przykład gałąź ma oddzielne podsieci dla pul węzłów systemowych i użytkowych, zasobów przychodzących i prywatnego serwera interfejsu API dla AKS. Wdróż podsieć dla Azure Firewall w centrum.

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

Korzystanie z IaC

W miarę możliwości wybierz idempotentną metodę deklaratywną zamiast 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. Implementacja referencyjna używa Bicep, ale zamiast tego można użyć Terraform lub szablonów Azure Resource Manager (szablonów ARM).

Pamiętaj, aby skonfigurować 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ć Azure Policy, aby wymusić zasady organizacji dotyczące tych decyzji.

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

Przechowuj i wersjonuj swoje skrypty oraz pliki szablonów w systemie kontroli wersji.

CI/CD dla obciążeń

Pipelines na potrzeby 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 oraz wycofywane 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 roboczych w klastrze.

W tej architekturze GitHub Actions zarządza przepływem pracy i wdrażaniem. Inne popularne opcje to Azure DevOps Services i Jenkins.

CI/CD klastra

Diagram przedstawia proces CI/CD od lewej do prawej. Po lewej stronie ikona Infrastruktura jako kod reprezentuje konfigurację deklaracyjną przechowywaną w kontroli źródła. Strzałka pozioma oznaczona etykietą Wdróż punkty z infrastruktury jako kod do centralnego pola z etykietą GitOps. To pole zawiera Azure Pipelines, GitHub Actions i Jenkins Pipelines. W polu GitOps strzałka z etykietą Synchronizuj wskazuje ikonę usługi AKS.

Pobierz plik Visio tej architektury.

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/CD jest rozpoczynanie 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 Flux, 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ą bieżącą konfigurację na podstawie tych zmian

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

Na poniższym przykładowym diagramie pokazano, jak zautomatyzować konfigurację klastra przy użyciu usług GitOps i Flux.

Diagram ilustruje przepływ pracy GitOps z czterema krokami ponumerowanym od lewej do prawej. Po lewej stronie ikona dewelopera z laptopem jest wyświetlana w kroku 1, gdzie użytkownik wypycha zmiany IaC do repozytorium Git. Krok 2 przedstawia repozytorium Git łączące się za pomocą strzałki z etykietą git clone --mirror z ikoną Flux wewnątrz granicy klastra usługi AKS. Krok 3 przedstawia strzałkę z etykietą kubectl apply, która wskazuje z ikony Flux na ikonę serwera API Kubernetes w klastrze. Krok 4 wyświetla czerwony okrąg z ukośną linią między deweloperem a serwerem API Kubernetes z przekreśloną etykietą kubectl.

Pobierz plik Visio tej architektury.

1. Deweloper zatwierdza zmiany w kodzie źródłowym, takie jak konfiguracyjne pliki YAML, które są przechowywane w repozytorium w 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 Flux stosuje zmiany tylko na żądanie 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ć polityki gałęzi na serwerze Git, aby wielu deweloperów mogło następnie zatwierdzać zmiany za pośrednictwem pull request 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óż jakiekolwiek zmiany, takie jak składniki architektury, obciążenie i konfiguracja klastra, do co najmniej jednego klastra przedprodukcyjnego AKS. Ten proces 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 etapu. Pomaga to zapewnić możliwość wdrażania aktualizacji do środowiska produkcyjnego w wysoce kontrolowany sposób i minimalizowania zakłóceń z powodu nieprzewidzianych problemów z wdrażaniem. Wdrożenie powinno podążać podobnym wzorcem jak produkcja, przy użyciu tego samego pipeline'u GitHub Actions lub operatorów Flux.

Zaawansowane techniki wdrażania, takie jak wdrożenie niebiesko-zielone, testowanie A/B i wydania kanaryjne, wymagają dodatkowych procesów i potencjalnie dodatkowych narzędzi. Flagger to popularne rozwiązanie typu open source ułatwiające rozwiązywanie zaawansowanych scenariuszy wdrażania.

Zarządzanie kosztami

Zacznij od przejrzenia listy kontrolnej projektu optymalizacji kosztów i listy zaleceń opisanych w Well-Architected Framework for AKS. Aby uzyskać ogólne zalecenia dotyczące obciążeń, zobacz listę kontrolną projektowania dotyczącą optymalizacji kosztów.

Szacowanie kosztów składników używanych w tej architekturze bazowej można znaleźć w kalkulatorze cen Azure. Zmodyfikuj szacowanie, aby uwzględnić składniki wymagane do użycia. To oszacowanie obejmuje zasoby na poziomie szprych, które są bezpośrednio skojarzone z klastrem. Współużytkowana infrastruktura centrum, taka jak Azure Firewall, wirtualne sieci centrum i strefy Azure Prywatna strefa DNS, nie jest uwzględniona, ponieważ zasoby te są zwykle własnością centralnego zespołu platformowego i są przez niego zarządzane.

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

Provision

• 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. Na koszty wpływają wystąpienia maszyn wirtualnych, pamięć masowa, dane dzienników oraz zasoby sieciowe wykorzystywane przez klaster. Rozważ wybranie tańszych maszyn wirtualnych dla pul węzłów systemowych. Seria Ddv50 to typowy typ maszyny wirtualnej dla puli węzłów systemu, a implementacja referencyjna używa jednostki SKU Standard_D2d_v5.

• Nie używaj tej samej konfiguracji w środowiskach 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 dostępności dla obciążeń produkcyjnych. Jednak istnieją oszczędności w przypadku klastrów przeznaczonych do prac deweloperskich/testowych lub do zastosowań eksperymentalnych, w których dostępności nie trzeba gwarantować. Na przykład, Twoje SLO może być wystarczające. Ponadto, jeśli obciążenie na to pozwala, 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ą Azure SQL Database lub Azure App Service w ramach architektury obciążeń AKS, oceń, czy kwalifikujesz się do korzystania z subskrypcji Azure Dev/Test aby otrzymać rabaty 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 zasobów i limity, aby umożliwić Kubernetes przydzielanie zasobów węzłów o większej gęstości, co pozwala na pełne wykorzystanie pojemności węzłów.

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

• Zawieraj umowy na jeden lub trzy lata na wystąpienia zarezerwowanych maszyn wirtualnych Azure, aby zmniejszyć koszty węzłów, jeśli Twoje obciążenie musi działać przez dłuższy czas. Aby uzyskać więcej informacji, zobacz Oszczędzaj koszty dzięki zarezerwowanym instancjom maszyn wirtualnych 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ół. Jeśli klaster jest współużytkowany między zespołami, twórz raporty rozliczenia kosztów dla każdego odbiorcy w celu zidentyfikowania taryfowych kosztów współużytkowanych usług w chmurze. Aby uzyskać więcej informacji, zobacz Określić taint, etykietę lub tag 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 Bandwidth.

• Utwórz budżety, aby pozostać w granicach ograniczeń kosztów zidentyfikowanych przez organizację. Budżety można tworzyć za pomocą 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ń, przechowywania, przepustowość, dzienniki i zapory. Azure udostępnia następujące opcje monitorowania i analizowania kosztów:

• Azure Advisor
• Zarządzanie kosztami

Monitoruj koszty w czasie rzeczywistym lub zgodnie z regularnym harmonogramem, aby można było podjąć działania przed końcem miesiąca, gdy koszty są już obliczane. Monitoruj miesięczne trendy w miarę upływu czasu, aby pozostać w budżecie.

Aby podejmować decyzje oparte na danych, należy wskazać, który zasób na poziomie szczegółowym wiąże się z największymi kosztami. Warto mieć dobrą znajomość liczników, które obliczają użycie zasobów. Na przykład analizując metryki, można określić, czy platforma jest zbyt duża. Mierniki użycia są widoczne w metrykach Azure Monitor.

Optimize

Postępuj zgodnie z zaleceniami z Azure Advisor. Zapoznaj się z innymi sposobami optymalizacji:

• Włącz narzędzie do automatycznego skalowania klastra, aby wykrywać i usuwać niewykorzystane węzły w puli węzłów.

  Important

  Wprowadzanie szybkich lub częstych zmian w ustawieniach automatycznego skalowania klastra, takich jak minimalna i maksymalna liczba węzłów dla puli węzłów, w celu kontrolowania kosztów może prowadzić do niezamierzonych lub niepożądanych wyników. Jeśli na przykład scale-down-unneeded-time ustawiono wartość 10 minut, a minimalne i maksymalne ustawienia węzła są modyfikowane co 5 minut w oparciu o charakterystykę obciążenia, liczba węzłów nigdy nie zmniejsza się. Wynika to z faktu, że obliczenie niepotrzebnego czasu dla każdego węzła jest resetowane po odświeżeniu ustawień automatycznego skalowania klastra.

• Wybierz niższą wartość SKU dla pul węzłów, jeśli obciążenie na to pozwala.

• Jeśli aplikacja nie wymaga skalowania impulsowego, rozważ odpowiednie dostosowanie wielkości klastra, analizując metryki wydajności w czasie.

• Jeśli obciążenie to umożliwia, skaluj pule węzłów użytkownika do zera gdy nie jest oczekiwane ich uruchomienie. Jeśli nie ma żadnych obciążeń, które nie zostały zaplanowane do uruchomienia w klastrze, 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ć więcej informacji, zobacz cennik AKS.

Dalsze kroki

• AKS — harmonogram działania GitHub

Powiązane zasoby

• Zaawansowana architektura mikrousług AKS
• architektura mikroserwisów na AKS
• Użyj Azure Firewall, aby chronić klaster usługi AKS
• GitOps dla AKS
• Przesyłanie strumieniowe danych przy użyciu usługi AKS

Ten artykuł zawiera zalecaną architekturę infrastruktury bazowej w celu wdrożenia klastra Azure Kubernetes Service (AKS). Są zgodne z naszymi zasadami projektowania oraz z najlepszymi praktykami architektonicznymi z ram architektonicznych Azure Well-Architected Framework. Artykuł prowadzi wiele różnych wyodrębnionych grup międzydyscyplinarnych, takich jak zespoły sieci, zabezpieczeń i tożsamości, podczas wdrażania tej infrastruktury ogólnego przeznaczenia.

Ta architektura nie koncentruje się na obciążeniu. Skupia się wyłącznie na klastrze AKS. Ten zakres informacji stanowi minimalną zalecaną podstawę dla większości klastrów AKS. Integruje się z usługami Azure, które zapewniają wgląd, zapewniają topologię sieci, która obsługuje rozwój wielu regionów i bezpieczny ruch w klastrze.

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

Tip

W tym artykule omówiono szeroki zakres kwestii związanych z projektowaniem klastrów AKS. Usługa AKS Automatic implementuje wiele decyzji projektowych, aby zmniejszyć liczbę zagadnień, które należy ocenić i zoptymalizować pod kątem typowych przypadków użycia. Na przykład usługa AKS Automatic automatycznie udostępnia i zarządza zarządzaną pulą węzłów systemowych, dlatego opisane w tym artykule decyzje dotyczące doboru rozmiaru, izolacji i uaktualniania puli węzłów systemowych nie mają zastosowania na tej platformie.

Nawet jeśli Twoje obciążenie robocze będzie hostowane w środowisku AKS Automatic, znajomość podstaw samodzielnie zarządzanego klastra AKS może pomóc Ci w dokonywaniu właściwych wyborów, gdy wymagania obciążenia roboczego się zmieniają.

Kubernetes to szeroki ekosystem, który wykracza poza technologie Azure i Microsoft. Podczas wdrażania klastra usługi AKS odpowiadasz za wiele decyzji dotyczących projektowania i obsługi klastra. Uruchomienie klastra usługi AKS obejmuje składniki zamkniętego źródła od różnych dostawców, w tym Microsoft, wraz ze składnikami typu open source z ekosystemu Kubernetes. Krajobraz zmienia się często, więc regularnie ponownie przemyśl decyzje. Podczas wdrażania platformy 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 na GitHub: implementacja referencyjna punktu odniesienia usługi AKS jako alternatywny punkt początkowy i skonfigurować ją zgodnie z potrzebami.

Note

Architektura referencyjna wymaga znajomości platformy Kubernetes i jej pojęć. Jeśli potrzebujesz odświeżenia, zobacz Wprowadzenie do Kubernetes oraz Opracowywanie i wdrażanie aplikacji na Kubernetes ścieżki szkoleniowe.

Konfiguracja sieci

Topologia sieci
Planowanie adresów IP
Routing aplikacji

Obliczenia klastra

Obliczenia dla klastra podstawowego
Odwołanie do obrazu kontenera
Zarządzanie zasadami

Zarządzanie tożsamościami

Integrate Microsoft Entra ID do klastra
Zintegrować Microsoft Entra ID z obciążeniem

Zabezpieczanie przepływu danych

Zabezpieczanie przepływu sieci
Dodawanie zarządzania tajnymi

Ciągłość biznesowa

Skalowalność węzłów i podów
Decyzje dotyczące ciągłości działania
Strefy dostępnościWiele regionów

Operations

Operacje klastra i obciążenia roboczego
Monitorowanie i zbieranie dzienników i metryk
Zarządzanie kosztami

Architecture

Na diagramie przedstawiono dwie połączone sieci wirtualne. Sieć wirtualna koncentratora zawiera Azure Firewall, Azure Bastion oraz podsieć bramy połączoną ze środowiskiem lokalnym. Sieć wirtualna 'spoke' zawiera kilka podsieci, klaster AKS i pule węzłów. Komunikacja równorzędna sieci wirtualnych łączy wirtualne sieci centralne (hub) i peryferyjne (spoke) za pośrednictwem linku dwukierunkowego. Strzałki wskazują z Key Vault i Container Registry w stronę podsieci punktów końcowych sieci Private Link. Strzałka wskazuje z podsieci Azure Bastion (zarządzanie) do wewnętrznego równoważnika obciążenia w sieci wirtualnej typu szprychowego. Strzałka wskazuje z sieci lokalnej do bramy lokalnej. Dwukierunkowa strzałka, oznaczona jako komunikacja równorzędna wirtualnej sieci, wskazuje z centralnej sieci wirtualnej hub do wirtualnej sieci odgałęzień w biurze zdalnym. Strzałka wskazuje z Internetu do podsieci Azure Application Gateway. Strzałka wskazuje z klastra usługi AKS do sekcji obszaru roboczego Azure Monitor, która zawiera metryki i zarządzaną aplikację Prometheus.

Pobierz plik Visio tej architektury.

Aby uzyskać więcej informacji, zobacz topologia sieci Hub-spoke w Azure.

Topologia sieci

Ta architektura korzysta z topologii sieci piasty i szprych. Wdróż piastę i szprychy w oddzielnych sieciach wirtualnych połączonych za pośrednictwem komunikacji równorzędnej virtual network. Ta topologia ma kilka zalet:

• Włącz zarządzanie segregowane. Możesz zastosować ład i przestrzegać zasady najniższych uprawnień (PoLP). Obsługuje również koncepcję strefy bazowej Azure z podziałem obowiązków.

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

• Zapewnij regionalne topologie typu hub-and-spoke. W przyszłości można rozszerzyć topologie sieci typu hub-and-spoke oraz zapewnić izolację zadań.

• Zastosowanie usługi web application firewall w celu sprawdzenia 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.

• Dostosuj się do strefy docelowej w skali przedsiębiorstwa Azure.

Wirtualna sieć węzła

Wirtualna sieć centralna jest centralnym punktem łączności i monitorowania. W tej architekturze centrum zawiera następujące składniki:

• Azure Firewall z globalnymi zasadami zapory zdefiniowanymi przez centralne zespoły IT w celu egzekwowania reguł w całej organizacji

• Azure Bastion, która ustanawia bezpieczny tunel do obwodu sieci prywatnej, dzięki czemu można wykonywać operacje zarządzania klastrem

• Podsieć bramy dla VPN

• Azure Monitor na potrzeby obserwacji sieci

W sieci architektura ma trzy podsieci.

Podsieć obsługująca Azure Firewall

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

Podsieć do hostowania bramy sieciowej

Ta podsieć jest symbolem zastępczym bramy sieci VPN lub bramy Azure ExpressRoute. Brama sieciowa zapewnia łączność między routerami w twojej sieci lokalnej a siecią wirtualną.

Podsieć przeznaczona na hostowanie Azure Bastion

Ta podsieć jest używana dla Azure Bastion. Za pomocą Azure Bastion można bezpiecznie uzyskiwać dostęp do zasobów Azure bez uwidaczniania zasobów w Internecie. Ta architektura używa Azure Bastion do bezpiecznego łączenia się z serwerem interfejsu API klastra usługi AKS na potrzeby operacji zarządzania. Podsieć dotyczy tylko operacji zarządzania.

Sieć wirtualna szprychowy

Ta sieć wirtualna typu szprychowego zawiera klaster usługi AKS i inne powiązane zasoby. Szprycha ma następujące podsieci.

Podsieć do obsługi Azure Application Gateway

Azure Application Gateway to internetowy moduł równoważenia obciążenia ruchu, który działa w warstwie 7. Implementacja referencyjna używa SKU Application Gateway w wersji v2, która umożliwia Azure Web Application Firewall. Web Application Firewall zabezpiecza ruch przychodzący z typowych ataków na ruch internetowy, w tym botów. Instancja ma publiczną konfigurację adresu IP frontonu, która odbiera żądania użytkowników. Zgodnie z projektem Application Gateway wymaga dedykowanej podsieci.

Podsieć dla wewnętrznych adresów IP modułu równoważenia obciążenia

Ta podsieć zapewnia przestrzeń adresową dla wewnętrznych adresów IP frontonu modułu równoważenia obciążenia. Usługa Application Gateway wysyła ruch do przypisanego prywatnego wewnętrznego adresu IP modułu równoważenia obciążenia, a moduł równoważenia obciążenia dystrybuuje ruch do dowolnego węzła w klastrze.

Agent kube-proxy w węźle odbierającego przekazuje pakiet do zasobnika serwera proxy bramy w puli węzłów systemu, co potencjalnie powoduje dodanie dodatkowego przeskoku sieciowego. Serwer proxy kończy protokół Transport Layer Security (TLS) i przekazuje żądania do zasobników obciążeń za pośrednictwem protokołu HTTP.

Korzystając z dedykowanej podsieci dla adresów IP modułu równoważenia obciążenia frontonu, można zastosować reguły sieciowej grupy zabezpieczeń, które mają zakres ruchu przychodzącego do modułu równoważenia obciążenia bez wpływu na podsieć węzła. Aby uzyskać więcej informacji, zobacz Jak użyć wewnętrznego równoważnika obciążenia z AKS.

Podsieć do hostowania węzłów klastra

Ta architektura używa dwóch pul węzłów, które są oddzielnymi grupami węzłów. Pula węzłów systemowych obsługuje zasobniki uruchamiające podstawowe usługi klastra, w tym proxy bramy, które kieruje ruch do obciążeń. Pula węzłów użytkownika uruchamia obciążenie.

Podsieć do hostowania punktów końcowych Azure Private Link

Utwórz połączenia Azure Private Link dla Azure Container Registry i Azure Key Vault, aby użytkownicy mogli uzyskiwać dostęp do tych usług za pośrednictwem prywatnego punktu końcowego w sieci wirtualnej typu szprycha. Prywatne punkty końcowe nie wymagają dedykowanej podsieci. Prywatne punkty końcowe można również umieścić w virtual network centrum. W implementacji wersji podstawowej punkty końcowe są wdrażane w dedykowanej podsieci w sieci wirtualnej szprychy. Takie podejście zmniejsza ruch przechodzący przez równorzędne połączenie sieciowe i utrzymuje 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 Private Link.

Podsieć serwera API AKS

Możesz skonfigurować klaster AKS do wykorzystania integracji z siecią wirtualną serwera API, co projektuje punkt końcowy serwera API klastra do delegowanej podsieci w sieci wirtualnej. Ta konfiguracja jest nazywana klastrem prywatnym , ponieważ gwarantuje, że cały ruch między serwerem interfejsu API, pulami węzłów i połączonymi klientami pozostaje całkowicie w sieci prywatnej.

Cała komunikacja między serwerem interfejsu API Kubernetes zarządzanym przez usługę AKS i klientami wewnętrznymi i zewnętrznymi jest ograniczona do zaufanej sieci.

Dzięki klastrowi prywatnemu można zabezpieczyć środowisko za pomocą sieciowych grup zabezpieczeń i innych wbudowanych narzędzi kontroli sieci. Ta konfiguracja uniemożliwia wszelkie nieautoryzowane publiczne dostępy między internetem a środowiskiem. Aby uzyskać więcej informacji, zobacz sekcję Tworzenie prywatnego klastra AKS.

Planowanie adresów IP

Diagram przedstawia prostą topologię sieci typu hub-and-spoke AKS. Sieć wirtualna piasty ma Azure Firewall, Azure Bastion i podsieć bramy. Sieć wirtualna będącej szprychą ma podsieci dla usługi Application Gateway, ruchu przychodzącego, węzłów, prywatnych punktów końcowych i klastra prywatnego. Strzałki pokazują połączenia komunikacji równorzędnej z sieci szprych do sieci piasty.

Pobierz plik Visio tej architektury.

Ta architektura referencyjna używa następujących metod sieciowych, z których każda wymaga oddzielnej przestrzeni adresowej IP.

• Twoja Azure sieci wirtualnej używanej dla zasobów, takich jak węzły klastra, serwer interfejsu API klastra, prywatne punkty końcowe dla usług Azure i Application Gateway.

• Nakładka Azure Container Networking Interface (CNI), która jest używana przez klaster do przydzielania adresów IP zasobnikom z przestrzeni adresowej oddzielonej od sieci wirtualnej Azure.

przestrzeń adresowa IP sieci wirtualnej

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

• Uaktualnienie: Usługa AKS regularnie aktualizuje węzły, aby upewnić się, że podstawowe maszyny wirtualne są aktualne pod względem zabezpieczeń i innych poprawek systemowych. Podczas procesu uaktualniania usługa AKS tworzy węzeł, który tymczasowo hostuje zasobniki, podczas gdy węzeł uaktualniania jest odgrodzony i opróżniony. Ten węzeł tymczasowy odbiera adres IP z podsieci klastra. Upewnij się, że masz wystarczającą przestrzeń adresową dla tymczasowych adresów IP węzła.

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

• Skalowalność: Rozważ łączną liczbę węzłów systemu i użytkownika oraz ich maksymalne limity skalowalności. Na przykład, jeśli chcesz rozszerzyć o 400%, potrzebujesz czterokrotnie więcej adresów dla wszystkich rozszerzonych węzłów.

  Ponieważ ta architektura używa Azure CNI Overlay, skalowalność podów nie ma wpływu na przestrzeń adresową sieci wirtualnej.

• Adresy Private Link: Uwzględnij adresy niezbędne do komunikacji z innymi usługami Azure za pośrednictwem Private Link. Ta architektura ma dwa adresy przypisane do linków do usługi Container Registry i Key Vault.

• Prywatne adresy serwerów API klastra: integracja serwera API z siecią wirtualną pomaga przedstawiać serwer API usługi AKS jako punkt końcowy wewnątrz sieci wirtualnej. Ta funkcja wymaga minimum rozmiaru podsieci więc upewnij się, że spełnisz te wymagania wstępne podczas planowania sieci.

• Zastrzeżone adresy IP: Azure rezerwuje określone adresy do własnych celów. 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żna również odizolować pule węzłów użytkownika od siebie. Ta izolacja skutkuje większą mniejszą podsiecią. Topologia bramy może również zostać rozwinięta, ponieważ każdy zasób bramy generuje własne wdrożenie serwera proxy bramy i adres IP frontonu modułu równoważenia obciążenia. Zaplanuj odpowiednio przestrzeń adresową podsieci.

Przestrzeń adresowa IP Pod

Nakładka Azure CNI przypisuje adresy IP do podsów przez dedykowaną przestrzeń adresową, która jest oddzielona od przestrzeni adresowej używanej w sieci wirtualnej. Użyj przestrzeni adresów IP, która nie nakłada się na sieć wirtualną ani na żadną równorzędną sieć wirtualną. Jeśli jednak utworzysz wiele klastrów usługi AKS, możesz bezpiecznie użyć tej samej przestrzeni adresowej zasobnika w każdym klastrze.

Nakładka Azure CNI przypisuje każdemu węzłowi przestrzeń adresową /24 dla jego podów. Ważne jest, aby przestrzeń adresowa poda była wystarczająco duża. Zezwalaj na tyle bloków /24, ile jest potrzebnych dla liczby węzłów w klastrze. Pamiętaj, aby uwzględnić wszystkie tymczasowe węzły utworzone podczas aktualizacji lub operacji skalowania w poziomie. Jeśli na przykład używasz przestrzeni adresowej /16 dla zakresu usługi Classless Inter-Domain Routing (CIDR), klaster może wzrosnąć do maksymalnie 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, zapoznaj się z wskazówkami dotyczącymi planowania adresów IP dla Azure CNI Overlay.

Inne zagadnienia dotyczące przestrzeni adresów IP

Aby zapoznać się z pełnym zestawem zagadnień dotyczących sieci dla tej architektury, zobacz topologię sieci bazowej AKS. Aby uzyskać więcej informacji na temat planowania adresowania IP dla klastra usługi AKS, zobacz Konfigurowanie sieci Azure CNI 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 punktu odniesienia zależy od określonych funkcji usługi AKS w wersji zapoznawczej i dodatków usługi AKS. Rozważ następujące różnice między funkcjami w wersji zapoznawczej i dodatkami:

• Zespół AKS opisuje funkcje w wersji zapoznawczej jako dostarczane i ulepszane, ponieważ wiele funkcji w wersji zapoznawczej pozostaje w tym stanie tylko przez kilka miesięcy, zanim przejdą do fazy ogólnej dostępności.

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

Architektura punktu odniesienia nie obejmuje każdej funkcji lub dodatku w wersji zapoznawczej, ale tylko te, które dodają znaczącą wartość do klastra ogólnego przeznaczenia. W miarę jak te funkcje wychodzą z wersji zapoznawczej, ta architektura bazowa jest odpowiednio zmieniana.

Możesz ocenić inne funkcje w wersji zapoznawczej lub dodatki usługi AKS w klastrach przedprodukcyjnych. Te funkcje mogą zwiększyć bezpieczeństwo, możliwości zarządzania lub inne wymagania. Należy zainstalować i obsługiwać wszelkie dodatki inne niż Microsoft, które obejmują śledzenie dostępnych wersji i instalowanie aktualizacji po uaktualnieniu wersji rozwiązania Kubernetes klastra.

Odwołanie do obrazu kontenera

Klaster może zawierać obciążenie i kilka innych obrazów, takich jak infrastruktura bramy zarządzanej samodzielnie lub kontener narzędzi, który synchronizuje certyfikaty TLS z Key Vault. Niektóre z tych obrazów mogą znajdować się w rejestrach publicznych, ale dobrym rozwiązaniem jest ich skanowanie, inspekcja i przechowywanie w dedykowanym rejestrze prywatnym, na przykład Azure Container Registry. Podczas ściągania obrazów do klastra należy wziąć pod uwagę następujące kwestie:

• Uwierzytelnij klaster, aby pobrać obraz.

• Jeśli używasz obrazu publicznego, zaimportuj obraz do rejestru kontenerów, który jest zgodny z celem poziomu usługi (SLO). W przeciwnym razie obraz może podlegać nieoczekiwanym problemom z dostępnością. Jeśli obraz jest niedostępny, gdy jest potrzebny, mogą wystąpić problemy operacyjne. Rozważ następujące korzyści wynikające z używania prywatnego rejestru kontenerów, takiego jak Azure Container Registry, zamiast rejestru publicznego:

  • Możesz zablokować nieautoryzowany dostęp do obrazów.
  • Nie masz zależności publicznych.
  • Można uzyskać dostęp do dzienników pobierania obrazów w celu monitorowania działań i klasyfikacji 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ą Azure Policy. W implementacji referencyjnej klaster pobiera obrazy tylko z dedykowanego wystąpienia Azure Container Registry wdrażanego w klastrze.

Konfigurowanie zasobów obliczeniowych dla klastra podstawowego

W usłudze AKS, zwykle każda pula węzłów jest mapowana na zestaw skalowania maszyn wirtualnych. Węzły są virtual machines (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. Implementacja referencyjna wdraża pulę węzłów systemowych z trzema węzłami D2dv5. Ten rozmiar jest wystarczający do spełnienia oczekiwanego obciążenia systemowych podów. Efemeryczny dysk systemu operacyjnego to 64 GB.

Podczas planowania pojemności puli węzłów użytkownika należy wziąć pod uwagę następujące zalecenia:

• Wybierz większe rozmiary węzłów, aby umieścić maksymalną liczbę podów na węźle. Duże węzły minimalizują ślad usług uruchamianych na wszystkich węzłach, takich jak monitorowanie i logowanie.

• 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, aby obciążenie działało zgodnie z wzorcem wysokiej dostępności z dwoma replikami. Usługa AKS umożliwia zmianę liczby węzłów bez ponownego tworzenia klastra.

• Zaplanuj właściwe rozmiary węzłów dla obciążenia na podstawie wymagań, które określa zespół projektowy. Na podstawie wymagań biznesowych ta architektura używa jednostki SKU D4dv5 dla obciążenia produkcyjnego.

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

• Ustaw maksymalne pody dla każdego węzła na podstawie planowania pojemności. Jeśli spró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. Implementacja referencyjna używa Azure Linux, która jest uproszczoną, wzmocnioną dystrybucją systemu Linux dostosowaną do Azure. Możesz wybrać inną dystrybucję systemu Linux, na przykład Ubuntu, jeśli wolisz lub jeśli Azure Linux nie spełnia Twoich wymagań. Jeśli wybierzesz inny system operacyjny, upewnij się, że rozmiar dysku systemu operacyjnego jest odpowiedni dla tego obrazu. Niektóre dystrybucje wymagają więcej miejsca niż Azure Linux, więc może być konieczne zwiększenie rozmiaru dysku, aby uniknąć problemów z wdrożeniem lub środowiskiem uruchomieniowym.

Jeśli obciążenie składa się z technologii mieszanych, możesz użyć różnych systemów operacyjnych w różnych pulach węzłów. Jeśli nie potrzebujesz różnych systemów operacyjnych, zalecamy użycie jednego systemu operacyjnego dla wszystkich pul węzłów obciążenia w celu zmniejszenia złożoności operacyjnej.

Integrowanie Microsoft Entra ID dla klastra

Zabezpieczenie dostępu do klastra i z klastra ma kluczowe znaczenie. Skorzystaj z perspektywy klastra, aby zrozumieć różnicę między ruchem wewnątrz i na zewnątrz .

• Dostęp wewnętrzny: Rozważ dostęp AKS do składników Azure, takich jak infrastruktura sieciowa, Container Registry i Key Vault. Autoryzuj tylko te zasoby, do których klastry powinny mieć dostęp.

• Dostęp poza dostępem: Podaj tożsamości z dostępem do klastra Kubernetes. Autoryzuj tylko te jednostki zewnętrzne, które mogą uzyskiwać dostęp do serwera interfejsu API Kubernetes i Azure Resource Manager.

Dostęp usługi AKS do składników Azure

Istnieją dwa sposoby zarządzania dostępem AKS do Azure za pośrednictwem Microsoft Entra ID: podmioty zabezpieczeń usługi lub zarządzane tożsamości dla zasobów Azure.

Z dwóch metod zarządzania dostępem usługi AKS do 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. W przypadku tożsamości zarządzanych Microsoft Entra ID zarządza uwierzytelnianiem i terminowym rotacją wpisów tajnych.

Zalecamy włączenie i użycie tożsamości zarządzanych w usłudze AKS aby klaster mógł wchodzić w interakcje z zasobami zewnętrznymi Azure za pośrednictwem Microsoft Entra ID. Jeśli nie używasz integracji Microsoft Entra ID natychmiast, możesz dodać ją później.

Domyślnie klaster używa dwóch podstawowych tożsamości: tożsamości klastra i tożsamości 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 i 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.

Należy użyć tożsamości zarządzanej, gdy klaster musi ściągać obrazy z rejestru kontenerów. Ta akcja wymaga, aby klaster pobierał poświadczenia rejestru, które można zezwolić, udzielając tożsamości AcrPull zarządzanej kubelet klastra dostępu do rejestru. Jeśli nie używasz tożsamości zarządzanej, możesz przechowywać te informacje w kluczu tajnym kubernetes i używać imagePullSecrets ich do ich pobierania. Nie zalecamy tego podejścia, ponieważ wprowadza on złożoność zabezpieczeń, takie jak konieczność wcześniejszego poznania wpisu tajnego i przechowywania go w potoku DevOps. Dodaje również nakład pracy operacyjnej, ponieważ należy zmienić tajny klucz.

W tej architekturze klaster uzyskuje dostęp do Azure zasobów, które Microsoft Entra ID zabezpieczają, a klaster wykonuje operacje obsługujące tożsamości zarządzane. Przypisz Azure role kontroli dostępu opartej na rolach (Azure RBAC) i uprawnienia do tożsamości zarządzanych klastra, w zależności od operacji wykonywanych przez klaster. Klaster uwierzytelnia się w Microsoft Entra ID i jest dozwolony lub blokowany dostęp na podstawie przypisanych do niego ról. W poniższych przykładach z implementacji referencyjnej przedstawiono Azure wbudowanych ról przypisanych do klastra:

• Rola współautora sieci zarządza zdolnością klastra do kontrolowania wirtualnej sieci opartej na szprychach. Dzięki temu przypisaniu roli tożsamość przypisana przez system klastra usługi AKS może wchodzić w interakcje z dedykowaną podsiecią wewnętrznego modułu równoważenia obciążenia, który kieruje serwerem proxy bramy i prywatnym serwerem interfejsu API usługi AKS.

• Rola Wkładowca strefy Prywatna strefa DNS zarządza możliwością łączenia strefy bezpośrednio z podsiecią wirtualną typu 'spoke', która hostuje klaster. Klaster prywatny przechowuje rekordy DNS poza publicznym Internetem przy użyciu prywatnej strefy DNS, ale nadal istnieje możliwość utworzenia prywatnego klastra usługi AKS z publicznym adresem DNS. Zalecamy jawne zablokowanie tej funkcji przez ustawienie enablePrivateClusterPublicFQDN , aby false zapobiec ujawnieniu prywatnego adresu IP płaszczyzny sterowania. Rozważ użycie Azure Policy, aby wymusić użycie klastrów prywatnych bez publicznych rekordów DNS.

• Rola Publisher metryk monitorujących zarządza możliwością klastra do wysyłania metryk do usługi Azure Monitor.

• Rola AcrPull zarządza zdolnością klastra do ściągania obrazów z wymienionych wystąpień usługi Container Registry.

Dwa dodatki usługi AKS udostępniają dodatkowe tożsamości zarządzane, które wymagają przypisań ról. Dodatek sterownika CSI magazynu wpisów tajnych pobiera certyfikaty TLS z Key Vault. Tożsamość dodatku routingu aplikacji zarządza rekordami DNS i uzgadnianiem bramy.

Przyznaj tym dwóm tożsamościom następujący dostęp do zasobów, z którymi korzystają:

• Dodatek sterownik CSI magazynu wpisów tajnych wymaga roli użytkownika certyfikatu Key Vault w key vault, aby sterownik mógł pobrać certyfikaty TLS.

  Note

  Alternatywnie możesz zamienić tożsamość zarządzaną sterownika CSI na tożsamość zarządzaną Microsoft Entra obciążenia na potrzeby dostępu Key Vault. W przypadku korzystania z tożsamości obciążenia należy powiązać tożsamość zarządzaną przypisaną przez użytkownika z usługą Kubernetes ServiceAccount przy użyciu poświadczeń federacyjnych i odwołać się do konta usługi ServiceAccount w opcjach protokołu TLS odbiornika bramy. Dodatek routingu aplikacji następnie automatycznie tworzy element SecretProviderClass.

  Zazwyczaj wybiera się tożsamość zarządzaną dodatku albo Workload Identity w celu uzyskania dostępu do usługi Key Vault za pośrednictwem sterownika CSI. Tożsamość obciążenia zapewnia izolację tożsamości w zakresie przestrzeni nazw i zmniejsza ręczne zarządzanie zasobami kosztem dodatkowego wzmacniania zabezpieczeń tożsamości za pośrednictwem poświadczeń federacyjnych.

• Tożsamość zarządzana dotycząca routingu aplikacji wymaga ról użytkownika Key Vault Secrets i Key Vault Reader w key vault. W przypadku wbudowanego składnika DNS do uzgadniania zasobów bramy ta tożsamość wymaga również roli współautora strefy Prywatna strefa DNS w strefie ruchu przychodzącego private DNS.

  Note

  Wbudowany składnik DNS wdrożony z dodatkiem nie uzgadnia automatycznie rekordów DNS. W przypadku rekordów interfejsu API bramy użyj podejścia Do obsługi tożsamości obciążenia.

Aby uzyskać więcej informacji, zobacz Konfigurowanie Azure DNS i protokołu TLS przy użyciu implementacji interfejsu API routingu aplikacji.

Dostęp do klastra

Integracja z Microsoft Entra upraszcza również zabezpieczenia dostępu od zewnątrz do wewnątrz. Na przykład możesz chcieć użyć narzędzia kubectl. Na początek możesz uruchomić polecenie az aks get-credentials, aby pobrać poświadczenia klastra. Microsoft Entra ID uwierzytelnia Twoją tożsamość na podstawie ról Azure, które mogą uzyskać poświadczenia klastra. Aby uzyskać więcej informacji, zobacz Uprawnienia dostępnych ról klastra.

Usługa AKS obsługuje dostęp do platformy Kubernetes za pośrednictwem Microsoft Entra ID, wykorzystując Microsoft Entra ID jako dostawcę tożsamości zintegrowanego z wbudowanym RBAC Kubernetes lub korzystając z wbudowanego RBAC Azure do zarządzania dostępem do klastra. W poniższych sekcjach opisano oba podejścia.

Kojarzenie Kubernetes RBAC z usługą Microsoft Entra ID

Kubernetes obsługuje RBAC poprzez następujące obiekty interfejsu API:

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

• Powiązania, które przypisują użytkownikom i grupom 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 Microsoft Entra, aby zarządzać dostępem za pomocą katalogu przedsiębiorstwa. Aby uzyskać więcej informacji, zobacz Użyj Kubernetes RBAC z integracją Microsoft Entra.

Upewnij się, że grupy Microsoft Entra dla dostępu do klastra i przestrzeni nazw znajdują się w przeglądach dostępu Microsoft Entra.

Użyj kontroli dostępu opartej na rolach Azure do autoryzacji w Kubernetes

Zalecamy użycie Azure RBAC i przypisań ról Azure w celu egzekwowania autoryzacji w klastrze. Takie podejście autoryzacji integruje się z uwierzytelnianiem Microsoft Entra. Role można przypisywać w różnych zakresach, takich jak grupa zarządzania, subskrypcja lub grupa zasobów. Wszystkie klastry objęte zakresem dziedziczą następnie spójny zestaw przypisań ról w kontekście osób z uprawnieniami do dostępu do obiektów w klastrze Kubernetes.

Nie zalecamy używania natywnej kontroli dostępu opartej na rolach (RBAC) platformy Kubernetes z ClusterRoleBindings i RoleBindings.

Aby uzyskać więcej informacji, zobacz Azure RBAC for Kubernetes authorization.

Konta lokalne

Usługa AKS obsługuje natywne uwierzytelnianie użytkowników Kubernetes. Nie zalecamy używania tej metody do zapewniania dostępu użytkownika klastrom. Ta metoda jest oparta na certyfikacie i wykonywana zewnętrznie względem podstawowego dostawcy tożsamości, co sprawia, że scentralizowana kontrola dostępu i zarządzanie dostępem są trudne. Zawsze zarządzaj dostępem do klastra przy użyciu Microsoft Entra ID i skonfiguruj klaster, aby jawnie uniemożliwić dostęp do konta lokalnego.

W implementacji referencyjnej dostęp kont klastrów lokalnych jest jawnie zabroniony, gdy system wdraża klaster.

Zintegruj Microsoft Entra ID dla obciążenia roboczego

Podobnie jak w przypadku systemowo przypisanej tożsamości zarządzanej Azure dla całego klastra, można przypisać tożsamości zarządzane na poziomie podu. Tożsamość zadania umożliwia hostowanemu zadaniu dostęp do zasobów za pośrednictwem Microsoft Entra ID. Na przykład obciążenie może przechowywać pliki w Azure Storage. Gdy zasobnik musi uzyskać dostęp do tych plików, uwierzytelnia się względem zasobu jako Azure tożsamości zarządzanej.

W 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, zobacz Federacja tożsamości obciążeń roboczych.

Wybieranie modelu sieci

Usługa AKS udostępnia wtyczki CNI w dwóch modelach sieciowych: nakładki i płaskie. Oba modele obsługują zasady sieciowe dla kontroli ruchu w klastrze.

W przypadku płaskiej wtyczki sieciowej, takiej jak Azure CNI Pod Subnet, każdy zasobnik otrzymuje adres IP z podsieci sieci wirtualnej. Zasoby w tej samej sieci lub równorzędnych sieciach mogą uzyskiwać dostęp do zasobników bezpośrednio przez ich adresy IP bez translatora adresów sieciowych (NAT). Użyj modelu płaskiej sieci, gdy obciążenie wymaga, aby zasobniki były bezpośrednio routowane do sieci wirtualnej.

Ta implementacja używa Azure nakładki CNI, wtyczki sieci nakładki, która przydziela adresy IP sieci wirtualnej tylko do węzłów i przypisuje adresy IP zasobników z oddzielnego zakresu CIDR. Dlatego, że Nakładka Azure CNI zużywa znacznie mniej adresów IP sieci wirtualnej niż modele płaskie, zalecamy ją dla większości wdrożeń.

Aby uzyskać więcej informacji na temat modeli, zobacz Omówienie sieci usługi AKS CNI i Najlepsze rozwiązania dotyczące łączności sieciowej i zabezpieczeń w usłudze AKS.

Marszruta zgłoszenia

Ta architektura korzysta z dodatku routingu aplikacji z interfejsem API Kubernetes Gateway. Dodatek trasowania aplikacji to konfiguracja klastra AKS, która określa, że klaster ma obejmować zarządzaną infrastrukturę bramy. Gateway API to zestaw niestandardowych definicji zasobów Kubernetes (CRD), w tym GatewayClass, Gateway, HTTPRoute i innych. Społeczność platformy Kubernetes wyznaczyła interfejs API bramy jako następcę poprzedniego interfejsu API ruchu przychodzącego. Interfejs API bramy zapewnia ustandaryzowaną, zorientowaną na rolę i rozszerzalną platformę do zarządzania ruchem.

Składniki interfejsu API bramy są wdrażane na następujących etapach cyklu życia:

• Projekt klastra. Zespół aplikacji decyduje, który kontroler bramy powinien zarządzać ruchem przychodzącym i jak zarządzać cyklem życia tego kontrolera. Kontrolery bramy zwykle łączą swoje serwery proxy płaszczyzny danych, dlatego ta decyzja określa również, który serwer proxy obsługuje ścieżkę ruchu. Ta architektura umożliwia zarządzanie obiektami CRD interfejsu Gateway API. Konfiguruje dodatek tak, aby używał zarządzanego Istio jako kontrolera bramy, który współpracuje z Envoy jako proxy bramy. Mimo że można również użyć istio jako siatki usług, ta architektura używa istio tylko jako kontrolera bramy i nie włącza jej możliwości siatki usług.

  Jeśli zespół potrzebuje innej implementacji, może użyć innych kontrolerów Gateway API, takich jak NGINX Gateway Fabric, Envoy Gateway i Traefik. Samodzielne zarządzanie tymi kontrolerami wymaga posiadania manifestów, ochrony przed koligacją, umieszczania węzłów, sond, określania zakresu kontroli dostępu opartej na rolach, zasad skalowania, ograniczeń źródłowych adresów IP i cyklu życia wersji. W zamian zespoły uzyskują pełny nadzór nad zachowaniem serwera proxy, przypinaniem wersji niezależnie od uaktualnień klastra i nieprzyciągniętymi konfiguracjami.

• Inicjowanie obsługi administracyjnej klastra. Na tym etapie nie są podejmowane żadne decyzje projektowe. Usługa AKS instaluje identyfikatory CRD interfejsu API bramy, zasobniki kontrolera bramy Istio w aks-istio-system przestrzeni nazw i approuting-istio gatewayClass. Na tym etapie nie istnieją zasobniki płaszczyzny danych dla serwera proxy bramy.

• Uruchamianie klastra. Zespół obciążenia określa, czy serwer proxy bramy jest uwidoczniony za pośrednictwem wewnętrznego lub zewnętrznego modułu równoważenia obciążenia, który podsieć hostuje adres IP frontonu modułu równoważenia obciążenia i w której przestrzeni nazw działa serwer proxy bramy. W tej architekturze serwer proxy bramy jest uwidaczniony w wewnętrznym module równoważenia obciążenia. Istnieje dedykowana podsieć adresów IP modułua0008 równoważenia obciążenia, a serwer proxy bramy jest wdrażany w przestrzeni nazw obciążenia.

  Zasób Gateway odwołujący się do klasy GatewayClass approuting-istio odzwierciedla te decyzje. Kontroler bramy uzgadnia zasób z wdrożeniami serwera proxy bramy envoy, usługą LoadBalancer, elementem HorizontalPodAutoscaler i zasobem PodDisruptionBudget w tej samej przestrzeni nazw co zasób bramy.

  Gdy prywatna strefa DNS jest dołączona do dodatku, składnik DNS dodatku może zarządzać rekordami DNS A, dzięki czemu nie trzeba utrzymywać rekordów statycznych w infrastrukturze jako szablonów kodu (IaC). Bootstrapping wdraża również zasoby synchronizacji certyfikatów TLS opisane w temacie Access cluster secrets (Uzyskiwanie dostępu do wpisów tajnych klastra).

  Note

  Wbudowany składnik DNS wdrożony wraz z dodatkiem nie synchronizuje automatycznie rekordów DNS w przypadku korzystania z zasobów Gateway API. Aby włączyć automatyczne uzgadnianie prywatnych rekordów DNS, wdróż zasób niestandardowy ClusterExternalDNS lub ExternalDNS . Składnik operatora routingu aplikacji wdraża następnie wystąpienie zarządzane external-dns , które obserwuje zasoby usługi Gateway i HTTPRoute, a następnie publikuje rekordy A w dołączonej strefie DNS.

  Ponieważ zapisywanie w strefie DNS wymaga uprawnień RBAC, ta integracja wymaga Microsoft Entra tożsamości obciążenia, w tym tożsamości zarządzanej przypisanej przez użytkownika z współautorem strefy DNS w strefie docelowej, poświadczenia tożsamości federacyjnej, które ufają wystawcy OpenID Connect (OIDC) klastra i dedykowanemu usłudze Kubernetes ServiceAccount. Oceń dodatkowe wymagania dotyczące infrastruktury tożsamości pod kątem zabezpieczeń i potrzeb operacyjnych.

• Wdrożenie obciążenia roboczego. Zespół aplikacji definiuje, które nazwy hostów, ścieżki i zaplecza powinny odbierać ruch. Zasoby usługi HTTPRoute powiązane z bramą wyrażają te decyzje dotyczące routingu. Kontroler bramy przekazuje zadeklarowane reguły routingu do podów Envoy.

• Ciągła konserwacja: Dodatek wiąże wersję kontrolera bramy Istio z wersją klastra usługi AKS, dlatego uaktualnienia odbywają się wraz z uaktualnieniami klastra, a nie wymaga niezależnego zarządzania cyklem życia. Ten dodatek używa Istio wyłącznie do zarządzania proxy bramy. Nie włącza wstrzykiwania sidecara ani pełnej siatki usług Istio, która stanowi oddzielny dodatek.

Note

Wybierz opcję samodzielnego zarządzania, gdy obciążenie wymaga możliwości, których dodatek jeszcze nie obsługuje, takich jak TLSRoute for Server Name Indication (SNI), zaawansowane przekształcenia ruchu za pośrednictwem niestandardowych wtyczek Lua lub Wasm albo gdy zgodność wymusza określony produkt proxy. Wybierz również opcję samodzielnego zarządzania, jeśli musisz uruchomić wersję serwera proxy niezależnie od uaktualnień klastra lub jeśli klaster korzysta już z dodatku siatki usługi Istio, ponieważ dwa dodatki nie mogą współistnieć.

Zastosowanie zasobów Gateway i HTTPRoute

Ta architektura korzysta z dodatku routingu aplikacji z interfejsem API Kubernetes Gateway do zarządzania ruchem przychodzącym. W tej sekcji opisano etapy uruchamiania klastra i wdrażania obciążenia opisane w poprzedniej sekcji. W tym momencie kontroler bramy jest uruchomiony i oczekuje na uzgadnianie zasobów interfejsu API bramy.

Interfejs API bramy jest neutralnym dla dostawcy standardem, który wyraża zasady protokołu TLS, routing oparty na nagłówkach i podział ruchu jako pola natywnego interfejsu API, a nie adnotacje specyficzne dla implementacji. Ponieważ konfiguracja routingu nie zależy od żadnej konkretnej technologii serwera proxy, możesz zmienić podstawową implementację później bez ponownego zapisywania. Dodatek routingu aplikacji determinuje cykl życia kontrolera bramy i proxy, co eliminuje konieczność zarządzania aktualizacjami, poprawkami zabezpieczeń, konfiguracją skalowania i zakresami uprawnień RBAC.

Interfejs API bramy oddziela ruch przychodzący na dwa zasoby, które zmieniają się niezależnie:

• Zasób bramy deklaruje powierzchnię sieci, w tym porty i protokoły do uwidocznienia, certyfikatów TLS i podsieci wewnętrznego modułu równoważenia obciążenia. Ten zasób zmienia się rzadko i wpływa na wszystkie dołączone do niego trasy.

• Zasób HTTPRoute deklaruje logikę routingu lub hosty, ścieżki i nagłówki mapują usługi zaplecza. Ten zasób zmienia się wraz z każdym wdrożeniem i ma zakres dla poszczególnych usług.

Ta architektura zmniejsza ryzyko zmiany routingu zakłócającej konfigurację sieci lub odwrotnie, ponieważ każdy zasób ma inny cykl zmian i promień wybuchu. Usuwa również kilka zależności.

• Konfiguracja routingu nie jest powiązana z określoną technologią serwera proxy.
• Wersja serwera proxy jest przenosina z wersją klastra usługi AKS, a nie wymaga niezależnego śledzenia.
• Każdy zasób bramy pobiera własne wdrożenie serwera proxy, a nie współużytkuje pojedynczy kontroler we wszystkich trasach.

Zgodnie z opisem w sekcji etapy cyklu życia po zastosowaniu zasobu bramy, który odwołuje się do skonfigurowanej klasy GatewayClass, kontroler bramy uzgadnia go z zasobami wdrażania serwera proxy bramy i zasobami pomocniczymi. Rozmieszczenie podsieci kontrolujesz za pomocą adnotacji infrastrukturalnych w zasobie Gateway.

Ten model deklaratywny eliminuje konieczność zarządzania chartami Helm, obrazami kontenerów lub manifestami wdrożeniowymi serwera proxy. Określasz zamierzony stan za pomocą konfiguracji zasobów Gateway API, a kontroler bramy doprowadza serwer proxy do pożądanego stanu.

Zazwyczaj kontroler bramy zarządzanej aprowizuje serwer proxy bramy z ustawieniami domyślnymi zorientowanymi na środowisko produkcyjne, w tym sondami gotowości i dostępnością, uprawnieniami RBAC, skalowaniem replik przy użyciu skalowania automatycznego opartego na procesorze CPU i zasobnikem Zasobniku, który utrzymuje co najmniej jeden dostępny zasobnik podczas dobrowolnych zakłóceń.

Topologia planowania dodatków

Dodatki AKS umieszczają zarządzane komponenty w pulach węzłów na podstawie decyzji harmonogramowania, nad którymi zespół aplikacji nie ma kontroli. Przed ustalaniem rozmiaru pul węzłów systemu i użytkownika określ, gdzie każdy z włączonych dodatków planuje jego zasobniki. Niektóre dodatki tolerują defekty puli węzłów systemowych i dlatego są uruchamiane tylko w puli systemu. Inne dodatki są przeznaczone dla pul użytkowników. Ta topologia ma bezpośredni wpływ na pojemność wymaganą w każdej puli.

Zarządzany serwer proxy bramy usługi Envoy działa w puli węzłów systemu zgodnie z projektem, a nie w puli węzłów użytkownika. Dostosuj rozmiar puli systemowej, aby uwzględnić dodatkowe zapotrzebowanie proxy na zasoby. Jeśli ta domyślna topologia nie spełnia wymagań organizacji, na przykład jeśli potrzebujesz serwera proxy w pulach użytkowników na potrzeby izolacji kosztów, segmentacji sieci lub powodów zgodności, przejdź do kontrolera bramy zarządzanej samodzielnie, w którym można podejmować decyzje dotyczące umieszczania węzłów.

Nawet w przypadku zarządzanego kontrolera bramy, zespół aplikacji może skonfigurować antykoligację podów, aby rozłożyć repliki serwera proxy między węzłami. Te ustawienia można skonfigurować za pomocą ustawień dostosowywania bramy dozwolonych. Aby uzyskać więcej informacji, zobacz Dostosowywanie zasobów bramy.

Ponieważ proxy bramy działa w puli węzłów systemowych, a obciążenie robocze działa w puli węzłów użytkownika, harmonogramista traktuje je jako niezależne domeny harmonogramowania. Usługi serwera proxy i obciążenia bramy często komunikują się, ponieważ każde żądanie przychodzące przepływa przez serwer proxy przed dotarciem do obciążenia. Żaden wbudowany mechanizm nie koreluje rozmieszczenia podów w strefach między różnymi pulami węzłów. Bez wyraźnych wskazówek harmonogram może umieszczać zasobniki obciążenia w strefach, w których nie istnieje żadna replika serwera proxy, wymuszając ruch do przekraczania granicy strefy dostępności i dodawania opóźnień i kosztów transferu danych między strefami.

Aby ograniczyć ten ruch między strefami, skonfiguruj dla swojego obciążenia preferowane powinowactwo podów, aby umieścić je wspólnie z replikami proxy w obrębie strefy. Ta wspólna lokalizacja jest najbliższa, gdy serwer proxy i obciążenie działają w oddzielnych pulach węzłów, ponieważ koligacja na poziomie węzła nie ma wpływu na pule. Należy pamiętać, że koligacja międzypodów dodaje obciążenie przetwarzania do harmonogramu i może spowolnić planowanie w dużych klastrach.

Wymagania dotyczące zasobów dodatków w zasadach ładu

Dodatki usługi AKS wdrażają składniki zarządzane, których wymagania dotyczące zasobów są definiowane i kontrolowane przez usługę AKS, a nie przez zespół aplikacji. Gdy klaster wymusza zasady limitu zasobów kontenera w trybie odmowy za pomocą Azure Policy i Open Policy Agent (OPA) Gatekeeper, zasady muszą być zgodne z każdym włączonym dodatkiem. W przeciwnym razie program Gatekeeper dyskretnie blokuje tworzenie zarządzanych zasobników, co wyłącza możliwości platformy, takie jak ruch przychodzący, synchronizacja wpisów tajnych i możliwość obserwacji bez wyświetlania żadnych oczywistych błędów wdrażania.

Traktuj profilowanie zasobów dodatku jako wymaganie wstępne dotyczące tworzenia zasad. Przed zdefiniowaniem ograniczeń procesora CPU kontenera, pamięci, typu woluminu lub kontekstu zabezpieczeń należy spisać każdy włączony dodatek i określić wymagania dotyczące zasobów środowiska uruchomieniowego. Użyj testów obciążeniowych lub kontrolowanych wdrożeń w środowisku przedprodukcyjnym, aby przechwycić rzeczywiste zużycie zasobów w realistycznych warunkach ruchu. Następnie ustaw limity zasad tak, aby uwzględniały zarówno komponenty dodatków, jak i kontenery obciążeń roboczych. Takie podejście gwarantuje, że zabezpieczenia ładu chronią klaster bez zakłócania infrastruktury zarządzanej przez platformę.

Na przykład zarządzany serwer proxy bramy Envoy wymaga do 2 rdzeni CPU i 1 GiB pamięci na replikę. Te wartości prawdopodobnie przekraczają potrzeby małego lub niskiego obciążenia zasobów. Ustaw limity zasad, aby uwzględnić serwer proxy bramy wraz z kontenerami aplikacji. Bez tego dostosowania program Gatekeeper odrzuca zasobniki serwera proxy bramy, a cały potok ruchu przychodzącego nie zmaterializuje się.

Kończenie żądań protokołu TLS bramy w klastrze i wymuszanie protokołu HTTPS

Ta architektura umożliwia skonfigurowanie bramy przy użyciu protokołu HTTPS na porcie 443 przy użyciu certyfikatu TLS zsynchronizowanego z Key Vault oraz odbiornika HTTP na porcie 80 na potrzeby przekierowania. Adnotacje infrastruktury w bramie umieszczają moduł równoważenia obciążenia w podsieci ruchu przychodzącego i sprawiają, że jest on wewnętrzny. Przekierowanie usługi HTTPRoute powiązanej z odbiornikiem HTTP powraca 301 Moved Permanently w celu uaktualnienia wszystkich żądań HTTP do protokołu HTTPS. Aplikacja HTTPRoute wiąże się z odbiornikiem HTTPS i kieruje ruch do usługi obciążenia za pośrednictwem protokołu HTTP. Ponieważ serwer proxy bramy wykonuje zakończenie szyfrowania TLS, komunikacja z usługami zaplecza jest niezaszyfrowana.

Zabezpieczanie przepływu sieci

W tej architekturze przepływ sieci obejmuje następujące typy ruchu:

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

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

• Ruch między zasobnikami, który obejmuje komunikację między serwerem proxy bramy 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.

Na diagramie przedstawiono cztery odrębne wzorce ruchu w architekturze. Jedno pole zawiera sieć koncentratora z polem podsieci zawierającym Azure Firewall. Oddzielne pole zawiera sieć szprychy i ma pola podsieci dla Web Application Firewall (WAF), wewnętrznego modułu równoważenia obciążenia zarządzanego przez usługę AKS i usługi AKS. Dwukierunkowa strzałka przedstawia komunikację równorzędną sieci wirtualnych między dwiema sieciami. Stałe zielone strzałki pokazują ruch żądań inicjowany przez użytkownika z publicznego Internetu do zapory aplikacji internetowej w sieci szprychy, z podsieci zapory aplikacji internetowej do wewnętrznej podsieci modułu równoważenia obciążenia i stamtąd do podsieci usługi AKS. Stałe pomarańczowe strzałki pokazują ruch żądania zainicjowanego przez klaster z podsieci AKS sieci szprychy do sieci piasty i wychodzący z podsieci Azure Firewall sieci koncentratora do publicznego Internetu. Kropkowane pomarańczowe strzałki pokazują zwracany ruch odpowiedzi z publicznego Internetu do podsieci Azure Firewall sieci piasty i z sieci piasty do podsieci AKS sieci szprychy. Zielone kropkowane strzałki pokazują ruch odpowiedzi z podsieci AKS do podsieci modułu równoważenia obciążenia, a następnie do podsieci zapory aplikacji internetowej sieci szprychy i z podsieci zapory aplikacji internetowej sieci szprychy z powrotem do publicznego Internetu.

Pobierz plik Visio tej architektury.

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

Przepływ ruchu przychodzącego

Architektura akceptuje tylko żądania szyfrowane protokołem TLS od klienta. Protokół TLS w wersji 1.2 jest minimalną dozwoloną wersją i umożliwia ograniczony zestaw szyfrów. SNI ścisłe dopasowywanie jest włączone. Kompleksowa konfiguracja protokołu TLS odbywa się za pośrednictwem Application Gateway przy użyciu dwóch różnych certyfikatów TLS, jak pokazano na poniższym diagramie.

Na diagramie przedstawiono pełny przepływ ruchu TLS z klienta do obciążenia. Krok 1 przedstawia użytkownika wysyłającego ruch HTTPS do usługi Application Gateway. W kroku 2 strzałka przechodzi z usługi Application Gateway do serwera proxy usługi Envoy w klastrze usługi AKS. Krok 3 przedstawia strzałkę wskazującą z serwera proxy usługi Envoy do obciążenia w klastrze usługi AKS. Krok 4 przedstawia wiersze przechodzące z usługi Application Gateway i serwera proxy usługi Envoy do Key Vault, które zawierają dwa certyfikaty, bicycle.contoso.com i *.aks-ingress.contoso.com. Każdy punkt zakończenia protokołu TLS jest oznaczony ikoną blokady.

Pobierz plik Visio tej architektury.

1. Klient wysyła żądanie HTTPS do nazwy domeny: bicycle.contoso.com, nazwa skojarzona z rekordem DNS A do publicznego adresu 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. Application Gateway ma zintegrowaną zaporę aplikacji internetowej i obsługuje procedurę uzgadniania TLS dla bicycle.contoso.com, zezwalając tylko na bezpieczne szyfry.

   Application Gateway jest punktem zakończenia protokołu TLS, który jest ważny, ponieważ Application Gateway web application firewall musi sprawdzić żądanie i odpowiedź w postaci zwykłego tekstu.

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

   W miarę jak ruch przechodzi z Application Gateway do backendu, jest ponownie szyfrowany za pomocą innego certyfikatu TLS, który jest symbolem wieloznacznym dla *.aks-ingress.contoso.com, ponieważ przekazuje go do wewnętrznego load balancera. To ponowne szyfrowanie pomaga zagwarantować, że niezabezpieczony ruch nie przepływa do podsieci klastra.

3. Serwer proxy bramy odbiera zaszyfrowany ruch za pośrednictwem modułu równoważenia obciążenia. Proxy to kolejny punkt terminacji TLS dla *.aks-ingress.contoso.com i przekazuje ruch do podów obciążenia przez protokół HTTP.

4. Oba certyfikaty TLS są przechowywane w Key Vault.

   Klaster uzyskuje dostęp do certyfikatu bicycle.contoso.com przy użyciu tożsamości zarządzanej przypisanej przez użytkownika, która integruje się z usługą Application Gateway. Aby uzyskać więcej informacji, zobacz terminacja TLS z certyfikatami Key Vault. Certyfikat TLS dla programu *.aks-ingress.contoso.com jest synchronizowany z klastrem jako wpis tajny Kubernetes, do którego odwołuje się zasób bramy. Aby uzyskać więcej informacji, zobacz Dodawanie zarządzania tajnymi danymi.

Możesz zaimplementować pełny ruch TLS na każdym przeskoku. Pamiętaj, aby wziąć pod uwagę wydajność, opóźnienie i skutki operacyjne wszelkich decyzji dotyczących zabezpieczania ruchu między zasobnikami. W przypadku większości klastrów z jedną dzierżawą, które mają odpowiednią kontrolę dostępu opartą na rolach płaszczyzny sterowania i dojrzałych praktyk cyklu życia tworzenia oprogramowania, wystarczy zaszyfrować protokół TLS do serwera proxy bramy i chronić go przy użyciu Web Application Firewall. Takie podejście minimalizuje obciążenie związane z zarządzaniem obciążeniami i niską wydajnością sieci. Wymagania dotyczące obciążenia i zgodności określają, gdzie wykonujesz terminację TLS.

Przepływ ruchu wychodzącego

W tej architekturze zalecamy, aby cały ruch wychodzący z klastra przechodził przez Azure Firewall. Możesz również użyć własnego podobnego wirtualnego urządzenia sieciowego. Nie zalecamy innych opcji ruchu wychodzącego, takich jak Azure NAT Gateway lub HTTP proxy ponieważ nie zapewniają inspekcji ruchu sieciowego. Dla kontroli Zero Trust i możliwości inspekcji ruchu, wyślij cały ruch wychodzący przez Azure Firewall. Zaimplementuj tę konfigurację przy użyciu tras zdefiniowanych przez użytkownika (UDR). Następnym przeskokiem trasy jest prywatny adres IP Azure Firewall. Azure Firewall decyduje, czy blokować lub zezwalać na ruch wychodzący na podstawie zdefiniowanych reguł, czy wbudowanych reguł analizy zagrożeń.

Alternatywą dla Azure Firewall jest użycie funkcji serwera proxy HTTP AKS. Cały ruch opuszczający klaster jest kierowany do adresu IP serwera proxy HTTP, który następnie przekazuje ruch lub go odrzuca.

W przypadku każdej metody przejrzyj wymagane reguły ruchu sieciowego wyjściowego dla usługi AKS.

Note

Jeśli używasz publicznego modułu równoważenia obciążenia jako publicznego punktu dla ruchu przychodzącego i wychodzącego przez Azure Firewall przy użyciu tras zdefiniowanych przez użytkownika, może wystąpić scenariusz routingu asymetrycznego. Ta architektura używa wewnętrznych modułów równoważenia obciążenia w dedykowanej podsieci wejściowej za Application Gateway. Ten wybór projektu zwiększa bezpieczeństwo, a także eliminuje problemy z routingiem asymetrycznym. Możesz też kierować ruch przychodzący przez zaporę przed lub po Application Gateway, ale takie podejście nie jest konieczne w przypadku większości sytuacji i nie zalecamy go. Aby uzyskać więcej informacji na temat routingu asymetrycznego, zobacz Integrate Firewall with an Azure standard load balancer.

Wyjątkiem od kontrolki Zero Trust jest to, że klaster musi komunikować się z innymi zasobami Azure. Na przykład klaster może wymagać ściągnięcia zaktualizowanego obrazu z rejestru kontenerów lub wpisów tajnych z Key Vault. W tych scenariuszach zalecamy użycie Private Link.

Zaletą korzystania z Private Link 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 Private Link wymaga dodatkowej konfiguracji zamiast używania usługi docelowej za pośrednictwem publicznego punktu końcowego. Ponadto nie wszystkie usługi Azure lub produkty obsługują Private Link. W takich przypadkach rozważ włączenie punktu końcowego usługi sieci wirtualnej w podsieci, aby uzyskać dostęp do usługi.

W przypadku usługi Container Registry należy używać dedykowanych punktów końcowych danych. Bez nich pobieranie warstw obrazu jest przekierowywane do punktu końcowego *.blob.core.windows.net, a nie do prywatnego punktu końcowego rejestru, a reguły zapory dla ruchu wychodzącego musiałyby zezwalać na niebezpieczny wzorzec wieloznaczny usługi Blob Storage. Ta reguła zezwalałaby na ruch wychodzący z węzłów do dowolnego konta usługi Azure Storage. Dedykowane punkty końcowe danych zastępują symbol wieloznaczny nazwami FQDN specyficznymi dla rejestru (<registry>.<region>.data.azurecr.io), które są rozpoznawane za pośrednictwem Private Link do prywatnego punktu końcowego, zachowując ruch w warstwie obrazu na ścieżce prywatnej i umożliwiając określanie zakresu reguł ruchu wychodzącego do rejestru klastra.

Jeśli 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ł Azure Firewall i zapory wbudowanej w usługę docelową. Zapora stosuje translowanie źródłowych adresów sieciowych (SNAT) do przepływów wychodzących, zastępując adres IP zasobnika jednym z dołączonych publicznych adresów IP na przepływ, a wybór nie jest deterministyczny. Dodaj cały zestaw dołączonych publicznych adresów IP do listy dozwolonych adresów IP usługi docelowej lub użyj prefiksu publicznego adresu IP , aby wyrazić ten zestaw jako ciągły zakres.

Jednym z wad nawiązywania połączenia z usługami Azure za pośrednictwem publicznych punktów końcowych jest to, że Azure Firewall następnie potrzebuje więcej reguł, aby upewnić się, że zezwala tylko na ruch z określonej podsieci. Liczba przypisanych publicznych adresów IP również ogranicza pulę portów SNAT i dlatego maksymalny jednoczesny limit połączeń wychodzących klastra. Zaplanuj wiele adresów IP na Azure Firewall zanim wyczerpią się porty. W przypadku klastrów, które otwierają dużą liczbę współbieżnych połączeń wychodzących, dołącz Azure NAT Gateway do AzureFirewallSubnetsieci wirtualnej, aby znacznie rozszerzyć pulę portów SNAT przy jednoczesnym zachowaniu całego ruchu wychodzącego pod kontrolą zapory.

Ruch między zasobnikami

Domyślnie pod może akceptować ruch z dowolnego innego podu w klastrze. Użyj platformy Kubernetes NetworkPolicy, aby ograniczyć ruch sieciowy między podami. Ostrożnie stosuj zasady, aby zapobiec blokowaniu krytycznych przepływów sieci. Zezwalaj tylko na określone ścieżki komunikacyjne, takie jak ruch między serwerem proxy bramy a obciążeniem zgodnie z potrzebami. Ponieważ serwer proxy bramy działa w tej samej przestrzeni nazw co obciążenie, należy go kierować według etykiety zasobnika, a nie selektora przestrzeni nazw. Aby uzyskać więcej informacji, zobacz Network policies.

Włącz zasady sieciowe podczas konfigurowania klastra, ponieważ nie można go dodać później. Masz kilka możliwości technologii do implementacji NetworkPolicy. Azure zasady sieciowe wymagają Azure CNI. 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ęta standardowym wsparciem Azure.

Aby uzyskać więcej informacji, zobacz Differences between Azure network policy engines.

Ruch zarządzania siecią

W ramach uruchamiania klastra serwer interfejsu API Kubernetes otrzymuje ruch od zasobów, które chcą przeprowadzać operacje zarządzania w klastrze, takie jak żądania utworzenia zasobów w celu zwiększenia skali klastra. Przykładami takich zasobów są pula agentów kompilacji w potoku DevOps, instancja Azure Bastion w podsieci Azure Bastion oraz same pule węzłów. Zamiast akceptować ten ruch zarządzania ze wszystkich adresów IP, zalecamy skonfigurowanie prywatnego klastra AKS.

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

Proponujemy wdrożenie klastra AKS jako klaster prywatny. Cały ruch płaszczyzny sterowania i puli węzłów pozostaje w sieci prywatnej i nie jest udostępniany publicznemu Internetowi. Implementacja referencyjna konfiguruje klaster prywatny przy użyciu integracji sieci wirtualnej serwera interfejsu API. Niższe środowiska mogą rozważyć złagodzenie tego zalecenia dotyczącego klastra prywatnego dla wygody, ale produkcyjne klastry usługi AKS powinny być zawsze wdrażane jako klastry prywatne na potrzeby bezpiecznego punktu odniesienia wdrożenia.

Ruch prywatny do prywatnego klastra usługi AKS może pochodzić z sieci wirtualnej odgałęzień, sieci połączonych równorzędnie lub prywatnych punktów końcowych w sieciach zdalnych. Chociaż węzły usługi AKS znajdują się naturalnie w sieci szprychy, operatorzy wykonujący zadania administracyjne potrzebują dedykowanego połączenia sieciowego, aby w sposób prywatny uzyskać dostęp do serwera interfejsu API usługi AKS. Tę łączność można ustanowić na następujące sposoby:

• Tunelowanie: Użyj Azure Bastion, aby otworzyć tunel bezpośrednio do serwera API klastra.
• Pole skoku: Aprowizuj maszynę wirtualną przesiadkową i użyj Azure Bastion, aby nawiązać z nią połączenie za pośrednictwem protokołu SSH lub RDP. Z tego miejsca operator wysyła żądania do serwera interfejsu API klastra za pośrednictwem jego prywatnego adresu IP.

Ta architektura wykorzystuje natywne tunelowanie klienta w usłudze Azure Bastion, aby połączyć komputer lokalny operatora z prywatnym serwerem interfejsu API platformy AKS za pomocą poleceń Azure CLI. Tunel obsługuje bezpośrednie przepływy pracy narzędzia kubectl i Helm bez pola przesiadkowego. To podejście jest zalecane, ponieważ zachowuje prywatny punkt końcowy interfejsu API usługi AKS, a jednocześnie pozostaje prostszy i mniej kosztowny do działania niż serwer przesiadkowy. Jest również mniej złożony do koordynowania między wieloma operatorami.

Możesz jednak użyć pola przesiadkowego, jeśli masz jakiekolwiek z następujących wymagań:

• Operatorzy używają niezabezpieczonych urządzeń. Serwer przesiadkowy może zapewnić silniejsze wzmocnienie zabezpieczeń, jeśli urządzenia klienckie nie są zaufane.

• Operatorzy łączą się za pośrednictwem niestabilnych sieci. Serwer przesiadkowy może zapewnić bardziej stabilne połączenie z klastrem, szczególnie w przypadku długotrwałych lub wsadowych operacji zarządzania.

• Operatory używają zaawansowanych narzędzi diagnostycznych. Niektóre typy narzędzi diagnostycznych, takie jak przechwytywanie pakietów, mogą nie działać prawidłowo w przypadku metod tunelowania.

Dodawanie funkcji zarządzania wpisami tajnymi

Przechowywanie wpisów tajnych w zarządzanym magazynie kluczy, takich jak Key Vault. Zaletą jest to, że zarządzany magazyn kluczy obsługuje rotację wpisów tajnych, zapewnia silne szyfrowanie i dziennik inspekcji dostępu oraz przechowuje podstawowe wpisy tajne z potoku wdrażania. W tej architekturze zapora Key Vault jest włączona i skonfigurowana, a Private Link służy do nawiązywania połączenia z zasobami Azure, takimi jak uzyskiwanie dostępu do wpisów tajnych i certyfikatów.

Key Vault jest dobrze zintegrowana z innymi usługami Azure. Użyj wbudowanej funkcji tych usług, aby uzyskać dostęp do sekretów. Aby uzyskać więcej informacji na temat tego, jak Application Gateway uzyskuje dostęp do certyfikatów TLS dla przepływu ruchu przychodzącego, zobacz sekcję Przepływ ruchu przychodzącego.

Model uprawnień RBAC Azure dla Key Vault umożliwia przypisanie tożsamości obciążeń Key Vault Secrets User lub Key Vault Reader w celu uzyskania dostępu do wpisów tajnych. Aby uzyskać więcej informacji, zobacz Access Key Vault using Azure RBAC.

Access sekrety klastra

Należy użyć tożsamości obciążeń, aby umożliwić zasobnikowi uzyskanie dostępu do tajemnic z określonego magazynu. Aby ułatwić proces pobierania, należy użyć secrets przechowywać sterownik CSI. 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 Key Vault ze sterownikiem CSI magazynu wpisów tajnych z ręcznym podejściem do konfiguracji protokołu TLS. Zasób SecretProviderClass definiuje, które certyfikaty z usługi Key Vault mają być synchronizowane do klastra jako obiekty Secret platformy Kubernetes. Sterownik CSI wymaga co najmniej jednego poda, który zamontuje odpowiedni wolumin CSI, aby utworzyć i utrzymywać zsynchronizowany Secret. Jeśli usuniesz wszystkie zainstalowane zasobniki, sterownik odśmieca wpis tajny, co oznacza, że brama utraci certyfikat TLS. Aby temu zapobiec, należy wdrożyć dedykowany, zawsze uruchomiony zasobnik, który utrzymuje wolumin CSI zainstalowany niezależnie od cykli życia zasobników obciążenia.

Ta architektura wykorzystuje obraz kontenera BusyBox, w którym działa lekki kontener z pozornym zadaniem. Zaimportuj obraz kontenera do Azure Container Registry przed utworzeniem klastra, ponieważ platforma Flux wdraża go podczas uruchamiania. Włącz rotację wpisów tajnych i ustaw interwał sondowania rotacji, taki jak dwie minuty dodatku CSI, dzięki czemu Key Vault odnawianie certyfikatów jest propagowane automatycznie. Zasób Gateway odwołuje się do zsynchronizowanego obiektu Secret TLS na potrzeby terminacji HTTPS. Aby uzyskać więcej informacji, zobacz Zabezpieczanie ruchu przychodzącego przy użyciu implementacji interfejsu API routingu aplikacji.

Jak wspomniano w artykule Dostęp usługi AKS do Azure składników, tę konfigurację ręczną można zastąpić podejściem TLS zarządzanym przez operator. W tym podejściu należy zadeklarować identyfikator URI certyfikatu Key Vault i konto Usługi tożsamości obciążenia bezpośrednio na odbiorniku bramy. Operator routingu aplikacji tworzy klasę SecretProviderClass i automatycznie stosuje poprawki do odwołania certyfikatu bramy, co eliminuje konieczność tworzenia tych zasobów podczas uruchamiania klastra lub tworzenia dedykowanego zasobnika synchronizacji tls. Oba podejścia polegają na mechanizmie rotacji sterownika CSI w celu pobrania odnawiania certyfikatów z Key Vault.

Przechowywanie obciążenia roboczego

Obciążenie robocze 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, zapoznaj się z opcje magazynowania dla aplikacji w AKS.

Zarządzanie zasadami

Skutecznym sposobem zarządzania klastrem usługi AKS jest wymuszanie ładu za pomocą zasad. Platforma Kubernetes implementuje zasady za pośrednictwem usługi OPA Gatekeeper. W przypadku usługi AKS dostarczaj zasady za pośrednictwem 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żna użyć Azure Policy na kilka sposobów:

• Uniemożliwiaj 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ą Azure Policy dla platformy Kubernetes.

Typowym przykładem, w którym zasady mogą być przydatne, jest zarządzanie i walidacja obrazów kontenerowych. Obrazy kontenerów mogą być źródłem luk w zabezpieczeniach, a niektóre organizacje wymagają, aby niezaufane obrazy kontenerów były najpierw weryfikowane przy użyciu narzędzia do skanowania obrazów, a następnie zatwierdzane, zanim będą mogły być używane w klastrze produkcyjnym. Ten proces można wymusić przy użyciu Azure Policy i zablokować rozmieszczenie niezaufanych obrazów kontenerów w klastrze. Aby uzyskać więcej informacji, zobacz wzorzec Quarantine.

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

• Zdecyduj, czy ustawić kolekcję zasad, znaną jako inicjatywy, czy wybrać poszczególne zasady. Azure Policy oferuje dwie wbudowane inicjatywy: podstawowe i ograniczone. Każda inicjatywa to zbiór wbudowanych zasad stosowanych do klastra 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.

• Zdecyduj, czy chcesz przeprowadzić inspekcję lub odmówić akcji. W trybie inspekcji akcja jest dozwolona, ale oznaczona jako niezgodna. Posiadanie procesów do sprawdzania niezgodnych stanów w regularnych odstępach czasu i podejmowania niezbędnych działań. W trybie odmowy akcja jest blokowana, ponieważ narusza zasady. Podczas wybierania trybu odmowy należy zachować ostrożność, ponieważ może to być zbyt restrykcyjne, aby obciążenie działało.

• Zdecyduj, czy masz obszary w obciążeniu, które nie powinny być zgodne z projektem. Azure Policy określa przestrzenie nazw Kubernetes, które są wykluczone z wymuszania zasad. Zalecamy stosowanie zasad w trybie inspekcji, aby pamiętać o tych wystąpieniach.

• Zdecyduj, czy masz wymagania, które nie są objęte wbudowanymi zasadami. Możesz utworzyć niestandardową definicję 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.

• Zdecyduj, 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.

• Zdecyduj, czy musisz przypisać zasady 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 zostały uwzględnione w przedprodukcji.

Implementacja referencyjna umożliwia Azure Policy podczas tworzenia 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 sprawdzić, jak działa Azure Policy w Twoim klastrze, możesz uzyskać dostęp do logów podów dla wszystkich podów w przestrzeni nazw gatekeeper-system oraz logów dla podów azure-policy i azure-policy-webhook w przestrzeni nazw kube-system.

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

Wraz z rosnącym zapotrzebowaniem, Kubernetes może się skalować poprzez dodanie większej liczby zasobników do istniejących węzłów, dzięki poziomemu automatycznemu skalowaniu zasobników. Gdy Kubernetes nie może już zaplanować większej liczby zasobników, liczba węzłów musi zostać zwiększona za pomocą automatycznego skalowania klastra AKS. Kompletne rozwiązanie skalowania musi mieć metody skalowania zarówno replik podó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 podów z biegiem czasu. Liczbę węzłów można dostosować za pomocą Azure CLI lub portalu Azure.

Zalecamy użycie podejścia do skalowania automatycznego, ponieważ niektóre mechanizmy ręczne 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ściowych i ręcznego skalowania, aby zlokalizować wąskie gardła i zrozumieć, jak aplikacja reaguje na skalowanie. Na koniec użyj tych danych, aby ustawić parametry skalowania automatycznego.

Narzędzie do automatycznego skalowania zasobników w poziomie

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

W zasobie HPA zalecamy ustawienie minimalnej i maksymalnej liczby replik. Wartości ograniczają ograniczenia skalowania automatycznego.

HPA może być skalowane na podstawie użycia CPU, użycia pamięci i metryk niestandardowych. Tylko użycie procesora CPU jest udostępniane natywnie. 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 niedostatecznie alokowane. 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 wystąpić stan wyścigu, na przykład kiedy HPA sprawdza coś przed zakończeniem operacji skalowania. W związku z tym wynik może być niepoprawnym obliczeniem współczynnika. Więcej informacji znajdziesz w sekcji Okres oczekiwania wydarzeń skalowania.

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 skalery. Użyj listy źródeł zdarzeń, które usługa KEDA może skalować w narzędziach skalowania KEDA. Lista zawiera Azure Monitor scaler, który jest wygodnym sposobem skalowania obciążeń KEDA opartych na metrykach Azure Monitor.

Automatyczny skalownik klastra

cluster autoscaler to składnik dodatku usługi AKS, który skaluje liczbę węzłów w puli węzłów. Dodaj go podczas tworzenia 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 harmonogramator platformy Kubernetes nie może zaplanować podu z powodu ograniczeń zasobów, narzędzie do automatycznego skalowania automatycznie konfiguruje 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 działa 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 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.

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

Aby zachować ciągłość działalności biznesowej, zdefiniuj poziom SLO dla infrastruktury i aplikacji. Aby uzyskać więcej informacji, zobacz Poleceń dotyczące definiowania celów niezawodności. Zapoznaj się z postanowieniami umowy dotyczącej poziomu usług (SLA) dla usługi AKS w najnowszym artykule SLA dla usług online.

Węzły klastra

Aby zapewnić minimalną dostępność dla zadań roboczych, konieczne jest posiadanie 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 lub pojemności, rozszerz skalę, aby dodać 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 znamion w celu zidentyfikowania puli węzłów i zaplanowania obciążenia roboczego. Upewnij się, że pula węzłów systemu jest oznaczona CriticalAddonsOnly taint, aby zapobiec zaplanowaniu zasobników aplikacji w pulach węzłów systemu.

Regularne zadania utrzymania w klastrze, takie jak aktualizacje terminowe, mają kluczowe znaczenie dla niezawodności. Zalecamy również, aby monitorować kondycję podów za pomocą sond.

Dostępność zasobnika

• Określ wymagania dotyczące zasobów podu: Zalecamy określenie wymagań dotyczących zasobów podu w ramach wdrożeń. Harmonogram może następnie odpowiednio zaplanować zasobnik. Niezawodność jest znacznie ograniczona, jeśli nie można zaplanować podó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ń Podów.

  Skonfiguruj wiele replik we wdrożeniu, aby obsługiwać zakłócenia, takie jak awarie sprzętowe. W przypadku planowanych zdarzeń, takich jak aktualizacje i uaktualnienia, budżet przerw może pomóc w zapewnieniu, że istnieje wymagana liczba replik podów do obsługi przewidywanego obciążenia aplikacji.

• Ustaw limity zasobów w obszarach nazw obciążenia: Limit zasobów w obszarze nazw pomaga upewnić się, że żądania podów i limity są prawidłowo ustawione we wdrożeniu. Aby uzyskać więcej informacji, zobacz Wdrażanie limitów zasobów.

  Note

  Jeśli ustawisz limity przydziału zasobów na poziomie klastra, problemy mogą wystąpić w przypadku wdrażania obciążeń zewnętrznych, które nie mają odpowiednich żądań i limitów. Ustawienie limitów przydziału na poziomie przestrzeni nazw zapewnia, że mają zastosowanie tylko do składników obciążenia.

• Ustaw żądania i limity podów: Ustaw żądania i limity, aby umożliwić platformie Kubernetes efektywne przydzielanie zasobów CPU i pamięci do podów. Zapewnia większą gęstość kontenerów 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 powoduje niestabilność klastra.

  Żądania i limity można określić w manifestach wdrożenia. Aby uzyskać więcej informacji, zobacz Podstawowe ustawienia żądań i limitów poda.

Strefy dostępności

Aby chronić przed niektórymi typami awarii, użyj availability zones jeśli region je obsługuje. Zarówno składniki płaszczyzny sterowania, jak i węzły w pulach węzłów są następnie strefowo nadmiarowe, co oznacza, że są one rozmieszczone w wielu strefach. 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 mapowana na oddzielny skalowalny zestaw maszyn wirtualnych, który zarządza instancjami 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 Limitations. Aby uzyskać umowę SLA czasu pracy, musisz wybrać poziom Standardowy lub Premium. SLA dotycząca dostępności jest wyższa, gdy używasz 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.

  Nadmiarowość strefy ma zastosowanie nie tylko do pul węzłów, ale także do 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, komponenty płaszczyzny kontrolnej nie mają gwarancji rozproszenia pomiędzy strefami dostępności.

• Zależne zasoby: Aby osiągnąć korzyść z odporności dzięki użyciu stref dostępności, wszystkie zależności usługowe 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.

  Załóżmy na przykład, że obciążenie używa bazy danych, która nie jest odporna na strefy. Jeśli wystąpi awaria, węzeł usługi AKS może przejść do innej strefy, ale baza danych nie zostanie przeniesiona z węzłem do tej strefy, więc obciążenie zostanie przerwane.

Dla uproszczenia tej architektury, usługa AKS jest wdrożona w jednym regionie, a pule węzłów obejmują trzy strefy dostępności. 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 gwarantuje się wystarczającej ochrony w mało prawdopodobnym przypadku awarii całego regionu. Aby uzyskać większą dostępność, uruchom wiele klastrów usługi AKS w różnych regionach.

• Preferuj sparowane regiony, kiedy są dostępne. Zaletą korzystania z sparowanych regionów jest niezawodność podczas aktualizacji platformy. Azure upewnia się, ż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 skonfigurujesz do zarządzania procesem odzyskiwania po awarii regionu. Określone 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 Azure obsługuje nadmiarowość geograficzną. Na przykład włączenie replikacji geograficznej dla usługi Container Registry powoduje automatyczne replikowanie obrazów do wybranych regionów Azure. Zapewnia również dalszy dostęp do obrazów, nawet jeśli główny region 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 Load Balancer, ponieważ może dystrybuować ruch niezwiązany z siecią w różnych strefach. Jeśli musisz dystrybuować ruch między regionami, rozważ Azure Front Door. Aby zobaczyć inne opcje, przejdź do Wybierz równoważenie obciążenia.

Note

Przykładowy scenariusz AKS dla klastrów wieloregionowych rozszerza architekturę w tym artykule, aby uwzględnić wiele regionów w konfiguracji aktywne-aktywne i wysokiej dostępności.

Odzyskiwanie po awarii

Najlepiej, jeśli wystąpi awaria w regionie głównym, możesz szybko przełączyć się do wystąpienia w innym regionie. Możesz wstępnie utworzyć klaster lub poczekać na jego utworzenie, dopóki nie będzie to wymagane. Rozważmy następujące zalecenia:

• Użyj wielu regionów. Jeśli region podstawowy ma sparowany region, skorzystaj z 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, na przykład replikowanie do innego regionu w ramach potoku DevOps, w celu spełnienia SLO.

• Skonfiguruj każdą usługę 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, mechanizm automatycznego przełączania awaryjnego ACR uwzględniający kondycję usługi automatycznie przekierowuje żądania pobierania do sprawnej repliki za pośrednictwem globalnego punktu końcowego bez konieczności zmiany konfiguracji klastra.

• 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.

Kopia zapasowa klastra

W przypadku wielu architektur można skonfigurować nowy klaster i zwrócić go do stanu operacyjnego za pomocą uruchamiania klastra opartego na metodyce GitOps, a następnie wdrożenia aplikacji. Jeśli jednak chodzi o krytyczny stan zasobów, takich jak mapy konfiguracji, zadania i sekrety, których nie można przechwycić w procesie uruchamiania, rozważ swoją 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 kopia zapasowa klastra musi być częścią strategii odzyskiwania, musisz zainstalować rozwiązanie zgodne z wymaganiami biznesowymi w klastrze. Ten agent jest odpowiedzialny za wypychanie stanu zasobu klastra do wybranego miejsca docelowego i koordynowanie Azure migawek woluminów trwałych opartych na dyskach.

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 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, przy czym harmonogramy i zakres kopii zapasowej są określane jako konfiguracja magazynu w Azure Backup.

Implementacja referencyjna nie implementuje kopii zapasowej, która obejmuje dodatkowe zasoby Azure do zarządzania, monitorowania, kupowania i zabezpieczania. Te zasoby mogą obejmować konto Azure Storage, magazyn Azure Backup i konfigurację oraz funkcję trusted access. Zamiast tego usługa GitOps połączona z zamiarem uruchamiania obciążenia bezstanowego jest rozwiązaniem odzyskiwania.

Wybierz i zweryfikuj rozwiązanie do tworzenia kopii zapasowej spełniające cel biznesowy, który obejmuje zdefiniowany cel punktu odzyskiwania i cel czasu odzyskiwania. Zdefiniuj proces odzyskiwania w elemencie runbooku zespołowego i przećwicz go dla wszystkich obciążeń krytycznych dla działania biznesu.

Jeśli musisz obsługiwać obciążenia stanowe i wdrażać AKS Backup, użyj Azure Policy, aby wymusić skonfigurowanie tej kopii zapasowej w klastrze. Azure Monitor przedstawia kondycję zadania tworzenia kopii zapasowej za pomocą tego samego stosu możliwości obserwowania, który został już utworzony w tej architekturze. Oprócz tych zasad ładu w projekcie należy uwzględnić następujące kwestie architektoniczne:

• Zakres kopii zapasowej. Zdecyduj, czy tworzysz kopię zapasową całego klastra, czy określonych przestrzeni nazw. AKS Backup przechowuje dane w kontenerze obiektów blob oraz w postaci migawek dysków lub plików. Zdefiniuj ten zakres na wczesnym etapie, ponieważ determinuje on rozmiar konta magazynowego, zasady przechowywania i poziom szczegółowości odzyskiwania w scenariuszach takich jak odzyskiwanie operacyjne, klonowanie środowiska i aktualizacje klastra.
• Zaufany dostęp. Usługa AKS Backup wymaga zaufanego dostępu między magazynem kopii zapasowych a klastrem usługi AKS, niezależnie od tego, czy klaster jest publiczny, prywatny, czy ograniczony przez adres IP.
• Uprawnienia RBAC. Tożsamość zarządzana magazynu kopii zapasowych wymaga zestawu uprawnień w klastrze usługi AKS do konfigurowania i wykonywania kopii zapasowych. Rozszerzenie kopii zapasowej tworzy również tożsamość użytkownika z uprawnieniami na koncie magazynu, na którym są przechowywane kopie zapasowe.
• Ruch wychodzący sieci. Rozszerzenie kopii zapasowej komunikuje się z usługami Azure Backup z poziomu klastra. Uwzględnij wymagane wychodzące punkty końcowe w regułach usługi Azure Firewall i NSG.
• Zajętość zasobów w klastrze. Rozszerzenie wdraża zasobniki na Twoich węzłach. Uwzględnij dodatkowe zużycie zasobów obliczeniowych i pamięci w limitach zasobów węzłów oraz uwzględnij przestrzeń nazw rozszerzenia w zarządzaniu zasadami sieciowymi.

Umowa SLA serwera interfejsu API platformy Kubernetes

Usługę AKS można używać jako bezpłatnej usługi, ale ta warstwa nie zapewnia umowy SLA wspieranej finansowo. Aby uzyskać umowę SLA, musisz wybrać warstwę Standard. Zalecamy wszystkie klastry produkcyjne używać warstwy Standardowej. Zarezerwuj warstwę Bezpłatną dla klastrów przedprodukcyjnych oraz warstwę Premium tylko dla obciążeń o krytycznym znaczeniu. W przypadku korzystania ze stref dostępności Azure, umowa SLA serwera API 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 SLA dla usług online.

Kompromis

Istnieje kompromis między kosztem a dostępnością przy wdrażaniu architektury w różnych strefach i szczególnie w regionach. 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 należy spodziewać się niewielkiego opóźnienia sieci w komunikacji węzłów między strefami i większego opóźnienia komunikacji między regionami. Zmierz wpływ tej decyzji architektonicznej na obciążenie.

Testowanie z symulacjami i wymuszonym failover.

Przetestuj niezawodność rozwiązania za pomocą wymuszonego testowania trybu failover z symulowanymi awariami. Symulacje mogą obejmować zatrzymywanie węzła, wyłączanie wszystkich zasobów usługi AKS w określonej strefie w celu symulowania awarii strefy lub wywoływanie awarii zależności zewnętrznej. Można również użyć Azure Chaos Studio do symulowania różnych typów awarii w Azure i w klastrze.

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

Monitorowanie i zbieranie dzienników i metryk

Zalecamy usługi monitorowania Azure Monitor Kubernetes do monitorowania wydajności obciążeń kontenerów, ponieważ można wyświetlać zdarzenia w czasie rzeczywistym. Azure Monitor przechwytuje dzienniki kontenerów z uruchomionych podów i agreguje je w celu wyświetlenia. 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żna również użyć Azure Monitor do monitorowania wydajności w miarę skalowania zasobników. Obejmuje ona dane telemetryczne, które mają kluczowe znaczenie dla monitorowania, analizy i wizualizacji zebranych danych.

Włącz zbieranie dzienników z podów

Schemat dziennika ContainerLogV2 jest przeznaczony do przechwytywania dzienników kontenerów z zasobników Kubernetes w sposób usprawniony. Wpisy dziennika są konsolidowane w tabeli ContainerLogV2 w obszarze roboczym Azure Log Analytics.

W klastrze AKS istnieją dwie podstawowe metody konfigurowania zbierania logów podów. Obie metody umożliwiają dostosowanie ustawień. Przestrzenie nazw można filtrować, dostosowywać interwały kolekcji, włączać lub uniemożliwiać korzystanie z określonych funkcji (takich jak ContainerLogV2 lub ContainerLogV2-HighScale) i określić, które strumienie danych mają być zbierane.

• Jeśli potrzebujesz scentralizowanych konfiguracji monitorowania wielokrotnego wykorzystania w wielu klastrach lub wolisz, aby konfiguracja klastra została przeniesiona na natywne zasoby Azure, użyj reguł zbierania danych (DCR). DCR to zasoby Azure, którymi płaszczyzna sterowania w Azure Resource Manager zarządza natywnie. Można je uwzględnić w plikach Bicep. Implementacja referencyjna używa DCR.

• Możesz też zdefiniować monitorowanie przy użyciu obiektów ConfigMap, które są niekonfidentalnymi obiektami YAML platformy Kubernetes skonfigurowanymi za pomocą płaszczyzny sterowania interfejsu API Kubernetes. Agent Azure Monitor uruchomiony na monitorach klastra dla obiektów ConfigMap. Używa wstępnie zdefiniowanych ustawień, aby określić, które dane mają być zbierane.

Gdy obie metody są włączone, ustawienia ConfigMap mają pierwszeństwo przed Regułami Zbierania Danych (DCR). Unikaj mieszania konfiguracji ConfigMap i DCR na potrzeby zbierania dzienników kontenerów, ponieważ może to spowodować trudne do rozwiązania problemów z rejestrowaniem.

Alerty i metryki rozwiązania Prometheus

Awarie i usterki stanowią znaczne zagrożenie dla aplikacji związanych z obciążeniem, co sprawia, że niezbędne jest proaktywne identyfikowanie problemów związanych z kondycją i wydajnością infrastruktury. Monitorując swoje środowisko i działając korzystając z nabytej wiedzy, zmniejszasz zakłócenia i zwiększasz niezawodność rozwiązania. Aby przewidzieć potencjalne warunki awarii w klastrze, włącz zalecane reguły alertów Rozwiązania Prometheus dla platformy Kubernetes.

Większość obciążeń hostowanych w zasobnikach emituje metryki Prometheus. Azure Monitor można zintegrować z rozwiązaniem Prometheus. Możesz zobaczyć metryki aplikacji i obciążenia zbierane z kontenerów, zasobników, węzłów i klastra.

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

Azure infrastruktura i dzienniki płaszczyzny sterowania Kubernetes

Dzięki usłudze AKS Azure zarządza niektórymi podstawowymi usługami Kubernetes. Azure implementuje dzienniki składników warstwy kontrolnej usługi AKS w postaci resource logs. Funkcje te mogą pomóc w diagnostyce problemów z klastrem i charakteryzują się stosunkowo niską gęstością logów. Zalecamy włączenie następujących opcji w większości klastrów:

• ClusterAutoscaler: Uzyskaj wgląd w operacje skalowania za pomocą rejestrowania. Aby uzyskać więcej informacji, zobacz Pobierz logi i stan skalera automatycznego klastra.

• KubeControllerManager: Uzyskaj wgląd w interakcję między platformą Kubernetes a płaszczyzną sterowania Azure.

• kube-audit-admin: Zyskaj wgląd w działania modyfikujące klaster. Nie ma potrzeby włączania jednocześnie kube-audit i kube-audit-admin, ponieważ kube-audit jest nadzbiorem, który obejmuje również operacje niemodyfikowane (odczyt).

• guard: Przechwytywanie audytów Microsoft Entra ID i Azure RBAC.

Przydatne może być włączenie innych kategorii dzienników, takich jak KubeScheduler lub kube-audit, na wczesnym etapie opracowywania 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. Jeśli jednak dzienniki rozszerzonego rozwiązywania problemów będą przechowywane w pełnym wymiarze czasu po zakończeniu rozwiązywania problemów, może to spowodować poniesienie niepotrzebnych kosztów pozyskiwania i przechowywania danych w Azure Monitor.

Azure Monitor zawiera zestaw istniejących zapytań dzienników, które mogą posłużyć jako punkt wyjścia, a także mogą być podstawą do tworzenia własnych zapytań. W miarę rozwoju biblioteki można zapisywać i ponownie używać zapytań dziennika przy użyciu co najmniej jednego pakietu query. Twoja niestandardowa biblioteka zapytań zapewnia lepszą widoczność kondycji i wydajności klastrów usługi AKS. Obsługuje ona osiąganie celów SLO.

Aby uzyskać więcej informacji na temat monitorowania najlepszych rozwiązań dotyczących usługi AKS, zobacz Monitorowanie usługi AKS przy użyciu Azure Monitor.

Metryki sieci

Podstawowe metryki sieci na poziomie klastra są dostępne za pośrednictwem metryk natywnych platform i Prometheus. Aby uwidocznić metryki sieciowe węzłów AKS, można użyć metryk Prometheusa do prezentacji metryk sieciowych na poziomie węzła. 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 używa Azure Monitor, która również zbiera niektóre metryki związane z siecią. Implementacja referencyjna uniemożliwia bezpośrednie zbieranie niektórych metryk sieci z Azure Monitor, a zamiast tego zbiera metryki obserwacji sieci przy użyciu obszaru roboczego Azure Monitor z zarządzanym prometheusem.

** 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 obciążenia DNS, metryki sieci na poziomie pod są ważne. W usłudze AKS można uzyskać dostęp do tych szczegółowych metryk przy użyciu funkcji Advanced Container Networking Services. Większość obciążeń nie wymaga tej głębokości wglądu w sieć. Nie należy włączać zaawansowanej obserwowalności sieci, chyba że pody wymagają wysoce zoptymalizowanej sieci z czułości na poziomie pakietów.

Optymalizacja kosztów logowania

Implementacja referencyjna konfiguruje tabelę ContainerLogV2 do używania planu podstawowego jako punktu początkowego. Microsoft Defender dla kontenerów oraz 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 gromadzenia.

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. Podczas monitorowania wzorców użycia i dostosowywania planów tabel w razie potrzeby można osiągnąć równowagę między kosztami i funkcjami rozwiązania do monitorowania.

Aby uzyskać więcej informacji, zobacz Wybierz plan tabeli na podstawie użycia danych w obszarze roboczym Log Analytics.

Włącz samonaprawianie

Monitoruj kondycję zasobników, ustawiając sondy żywotności i gotowości. Jeśli platforma Kubernetes wykryje brak odpowiedzi zasobnika, uruchomi ponownie zasobnik. Sonda stanu żywotności określa, czy zasobnik jest zdrowy. Jeśli platforma Kubernetes wykryje brak odpowiedzi zasobnika, uruchomi ponownie zasobnik. Sonda gotowości określa, czy pod jest gotowy do przetwarzania żądań i obsługi ruchu.

Note

Usługa AKS ma funkcję automatycznej naprawy węzłów, która zapewnia wbudowane samonaprawianie węzłów infrastruktury.

Rutynowe aktualizacje klastrów AKS

Częścią codziennych operacji dla klastrów Kubernetes jest wykonywanie rutynowych aktualizacji platformy i systemu operacyjnego. Należy zająć się trzema warstwami aktualizacji na każdym klastrze usługi AKS.

• Wersja Kubernetes (na przykład Kubernetes 1.32.3 do 1.32.7 lub Kubernetes 1.32.7 do 1.33.1), która może zawierać zmiany i wycofania 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 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 są testowane względem wersji 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, jak często mają być aktualizowane poszczególne klastry usługi AKS, pule węzłów lub węzły (częstotliwość). Ponadto wybierz dni lub godziny stosowania aktualizacji ( okno obsługi). Wybierz, czy aktualizacje mają być instalowane ręcznie, automatycznie, czy wcale. 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 AKS patch and upgrade guidance in the AKS day-2 operations guide. 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 node na none i automatyczne uaktualnianie klastra na none. W tej konfiguracji ponosisz wyłączną odpowiedzialność za wszystkie uaktualnienia we wszystkich warstwach.

Po udostępnieniu żądanej aktualizacji należy wykonać następujące czynności:

1. Przetestuj aktualizację w środowisku przedprodukcyjnym i oceń jego zgodność w nowym klastrze.

2. Wdróż projekt produkcyjny, który zawiera zaktualizowaną wersję AKS i zaktualizowane VHD puli węzłów.

3. Gdy nowy klaster produkcyjny jest gotowy, opróżnij stary klaster i w końcu go zlikwidować.

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

Uaktualnienia na bieżąco

Obciążenia, które nie obsługują klastrów usługi AKS jako niezmienialnej 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 planowaną konserwację 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 pod disruption budgets, tak aby aplikacja pozostała stabilna podczas aktualizacji progresywnych. Nie należy jednak konfigurować budżetów w taki sposób, aby blokowały aktualizacje węzłów, ponieważ większość aktualizacji wymaga procesu wyłączenia i opróżnienia w każdym węźle.

• Potwierdź limit przydziału i dostępność zasobów Azure. Aktualizacje w miejscu wdrażają nowe instancje węzłów, zwane węzłami przepięcia, zanim stare węzły zostaną usunięte. Oznacza to, że limit przydziału w Azure oraz przestrzeń adresowa IP powinny być dostępne na nowe węzły. Wartość przeciążenia o 33% jest dobrym punktem wyjścia dla większości obciążeń.

• Przetestuj zgodność z narzędziami, takimi jak siatki usług lub agenty bezpieczeństwa, które dodałeś do klastra. Ponadto przetestuj składniki obciążenia, takie jak kontrolery wejściowe, siatki usług i zasobniki obciążenia. Uruchamianie testów w środowisku przedprodukcyjnym.

Aktualizacje na miejscu dla węzłów

Użyj kanału automatycznych aktualizacji 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. Microsoft przeprowadza testy aktualizacji na Twojej wersji AKS. W przypadku węzłów Windows aktualizacje są aktualizowane co miesiąc. W przypadku węzłów systemu Linux 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 zaplanowane okno konserwacyjne, które należy ustawić przynajmniej raz w tygodniu. Ustaw to niezależnie od tego, jakiego systemu operacyjnego obrazu węzła używasz, aby zagwarantować szybkie stosowanie aktualizacji.

• Te aktualizacje obejmują zabezpieczenia na poziomie systemu operacyjnego, zgodność i aktualizacje funkcjonalne, ustawienia konfiguracji systemu operacyjnego i aktualizacje składników usługi AKS.

• Wydania obrazów i dołączone numery wersji komponentów są śledzone przy użyciu śledzenia wydania 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. Microsoft również testuje te aktualizacje. Aktualizacje są publikowane tylko wtedy, gdy istnieją uaktualnienia zabezpieczeń, które Microsoft uznają 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 uwzględnia Twoje okna konserwacyjne, więc upewnij się, że okna konserwacyjne mają częstsze przerwy (takie jak codziennie lub co drugi dzień), aby wspierać te niespodziewane aktualizacje zabezpieczeń.

Większość klastrów, które wykonują bezpośrednie aktualizacje, powinna unikać opcji kanału uaktualniania obrazu węzła None 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ć przy dwóch najnowszych wersjach (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 AKS na miejscu z należytym zachowaniem ostrożności i rygoru. 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żda aktualizacja na miejscu może spowodować nieoczekiwane zachowanie. Jeśli aktualizacje w miejscu są uznawane za zbyt ryzykowne dla Twojego obciążenia, zalecamy użycie wdrożenia blue-green klastrów AKS zamiast stosowania pozostałych zaleceń.

Zalecamy unikanie automatycznej aktualizacji 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ąć nastawienie na „bycie na bieżąco” niż podejście na długoterminowe wsparcie.

Warning

Nie zalecamy automatycznego stosowania poprawek ani aktualizowania produkcyjnego klastra usługi AKS, nawet w przypadku aktualizacji wersji pomocniczej, chyba że najpierw przetestujesz te aktualizacje w niższych środowiskach. Aby uzyskać więcej informacji, zobacz Regularnie aktualizuj do najnowszej wersji Kubernetes i Zaktualizuj klaster AKS.

Powiadomienia o dostępności nowej wersji usługi AKS dla klastra można otrzymywać przy użyciu systemu AKS dla systemu Azure Event Grid. Implementacja referencyjna wdraża ten system usługi Event Grid, dzięki czemu można subskrybować zdarzenie Microsoft.ContainerService.NewKubernetesVersionAvailable z Twojego rozwiązania do powiadomień o strumieniu zdarzeń. Przejrzyj informacje o wersji AKS pod kątem konkretnych problemów ze zgodnością, zmian zachowania lub wycofywania funkcji.

Choćby po jakimś czasie nabrać pewności co do wydań Kubernetes, wydań AKS, swojego klastra, jego komponentów na poziomie klastra i obciążeń, aby móc zbadać funkcję automatycznej aktualizacji. W przypadku systemów produkcyjnych rzadko zdarza się wykraczać poza patch. Ponadto po automatycznym uaktualnieniu wersji usługi AKS sprawdź ustawienie wersji usługi AKS w infrastrukturze jako kod (IaC), aby te dwie wersje nie wyszły z synchronizacji. 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. Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Microsoft Defender for Containers identyfikuje i koryguje zalecenia Defender dla Chmury dotyczące obrazów kontenerów.
• Defender kontenerów regularnie skanuje obrazy kontenerów pod kątem luk w zabezpieczeniach.
• Defender dla kontenerów generuje również alerty zabezpieczeń w czasie rzeczywistym dotyczące podejrzanych działań.
• Zabezpieczenia dla aplikacji i klastrów w usłudze AKS zawiera szczegółowe informacje o tym, jak zabezpieczenia kontenerowe chronią cały kompleksowy potok end-to-end, od kompilacji do momentu uruchomienia 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), zapoznaj się z filarem zasad projektowania doskonałości operacyjnej.

Uruchamianie klastra

Po skonfigurowaniu klastra staje się on działającym klastrem, ale możesz mieć do wykonania dodatkowe kroki przed wdrożeniem zadań. Proces przygotowywania klastra nosi nazwę bootstrapping. Bootstrapping często polega na wdrażaniu wymaganych uprzednio obrazów na węzłach klastra, tworzeniu przestrzeni nazw i wykonywaniu innych zadań, które spełniają wymagania przypadku użycia organizacji.

Aby przyspieszyć przejście z nowo skonfigurowanego klastra do prawidłowo skonfigurowanego, należy zdefiniować unikatowy proces uruchamiania i przygotować odpowiednie zasoby z wyprzedzeniem. Jeśli na przykład używasz siatki usług, takiej jak Linkerd lub Consul Connect, zazwyczaj wdrażasz siatkę przed zaplanowaniem obciążeń aplikacji. Przed skonfigurowaniem klastra należy sprawdzić, czy obrazy usługi Service Mesh istnieją w wcześniej utworzonym rejestrze kontenerów. Ta walidacja pomaga zapobiegać opóźnieniom lub niepowodzeniom wdrażania.

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

• rozszerzenie klastra GitOps Flux v2
• Pipelines
• Autokonfiguracja za pomocą Flux lub Argo CD, na przykład

Note

Każda z tych metod działa z dowolną topologią klastra, ale zalecamy rozszerzenie klastra GitOps Flux v2 dla flot dla zapewnienia jednolitości i łatwiejszego zarządzania na dużą skalę. Po uruchomieniu tylko kilku klastrów usługa GitOps może być nadmiernie złożona. Zamiast tego możesz zdecydować się na zintegrowanie procesu z jedną lub większą liczbą linii potoków wdrożeniowych, aby upewnić się, że uruchomienie ma miejsce. Użyj metody, która najlepiej pasuje do celów organizacji i zespołu.

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, stawiając solidne fundamenty zarządzania na przyszłość, a także wspiera włączanie bootstrappingu jako szablonów zasobów w celu dostosowania do strategii IaC.

Gdy bootstrapped manifesty wymagają wartości, które są znane tylko w czasie wdrażania, takie jak adres URL rejestru kontenerów, nazwa Key Vault lub identyfikator klienta tożsamości, należy użyć podstawienia zmiennej Flux w konfiguracji kustomization. Kustomization określa, która ścieżka w repozytorium Git ma być synchronizowana oraz które podstawienia zmiennych po kompilacji należy zastosować. Konfigurację kustomizations można skonfigurować w ramach wdrożenia rozszerzenia Flux w szablonie IaC, w którym definiuje się zmienne podstawienia, aby wartości zostały rozpoznane z wdrożonych zasobów w czasie tworzenia klastra. Takie podejście eliminuje problemy wynikające z kolejności wykonywania, które pojawiają się, gdy obiekt ConfigMap musi istnieć przed pierwszą rekonsyliacją, a także pozwala uniknąć konieczności forkowania repozytorium wyłącznie po to, aby dostosować wartości właściwe dla danego środowiska. Agent rozszerzenia Flux tłumaczy tę konfigurację IaC na zasoby niestandardowe kubernetes, które kontroler Flux Kustomize uzgadnia, stosując zamiany zmiennych podczas przetwarzania każdej ścieżki.

Na koniec, jeśli używasz rozszerzenia klastra GitOps Flux v2, narzędzie kubectl nie jest wymagane w żadnej części procesu uruchamiania. Można zarezerwować dostęp kubectl na czas awaryjnych przypadków naprawczych. Między szablonami definicji zasobów Azure a uruchamianiem manifestów przez rozszerzenie GitOps można wykonywać wszystkie normalne działania konfiguracyjne bez konieczności używania narzędzia wiersza poleceń 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, które zawiera fundamentalne składniki, i rozwijaj je dalej. Początkowym zadaniem jest skonfigurowanie sieci. Skonfiguruj sieci wirtualne typu "hub and spoke" oraz podsieci w tych sieciach. Na przykład gałąź ma oddzielne podsieci dla pul węzłów systemowych i użytkowych, zasobów przychodzących i prywatnego serwera interfejsu API dla AKS. Wdróż podsieć dla Azure Firewall w centrum.

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

Korzystanie z IaC

W miarę możliwości wybierz idempotentną metodę deklaratywną zamiast 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. Implementacja referencyjna używa Bicep, ale zamiast tego można użyć Terraform lub szablonów Azure Resource Manager (szablonów ARM).

Pamiętaj, aby skonfigurować 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ć Azure Policy, aby wymusić zasady organizacji dotyczące tych decyzji.

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

Przechowuj i wersjonuj swoje skrypty oraz pliki szablonów w systemie kontroli wersji.

CI/CD dla obciążeń

Pipelines na potrzeby 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 oraz wycofywane 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 roboczych w klastrze.

W tej architekturze GitHub Actions zarządza przepływem pracy i wdrażaniem. Inne popularne opcje to Azure DevOps Services i Jenkins.

CI/CD klastra

Diagram przedstawia proces CI/CD od lewej do prawej. Po lewej stronie ikona Infrastruktura jako kod reprezentuje konfigurację deklaracyjną przechowywaną w kontroli źródła. Strzałka pozioma oznaczona etykietą Wdróż punkty z infrastruktury jako kod do centralnego pola z etykietą GitOps. To pole zawiera Azure Pipelines, GitHub Actions i Jenkins Pipelines. W polu GitOps strzałka z etykietą Synchronizuj wskazuje ikonę usługi AKS.

Pobierz plik Visio tej architektury.

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/CD jest rozpoczynanie 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 Flux, 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ą bieżącą konfigurację na podstawie tych zmian

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

Na poniższym przykładowym diagramie pokazano, jak zautomatyzować konfigurację klastra przy użyciu usług GitOps i Flux.

Diagram ilustruje przepływ pracy GitOps z czterema krokami ponumerowanym od lewej do prawej. Po lewej stronie ikona dewelopera z laptopem jest wyświetlana w kroku 1, gdzie użytkownik wypycha zmiany IaC do repozytorium Git. Krok 2 przedstawia repozytorium Git łączące się za pomocą strzałki z etykietą git clone --mirror z ikoną Flux wewnątrz granicy klastra usługi AKS. Krok 3 przedstawia strzałkę z etykietą kubectl apply, która wskazuje z ikony Flux na ikonę serwera API Kubernetes w klastrze. Krok 4 wyświetla czerwony okrąg z ukośną linią między deweloperem a serwerem API Kubernetes z przekreśloną etykietą kubectl.

Pobierz plik Visio tej architektury.

1. Deweloper zatwierdza zmiany w kodzie źródłowym, takie jak konfiguracyjne pliki YAML, które są przechowywane w repozytorium w 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 Flux stosuje zmiany tylko na żądanie 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ć polityki gałęzi na serwerze Git, aby wielu deweloperów mogło następnie zatwierdzać zmiany za pośrednictwem pull request 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óż jakiekolwiek zmiany, takie jak składniki architektury, obciążenie i konfiguracja klastra, do co najmniej jednego klastra przedprodukcyjnego AKS. Ten proces 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 etapu. Pomaga to zapewnić możliwość wdrażania aktualizacji do środowiska produkcyjnego w wysoce kontrolowany sposób i minimalizowania zakłóceń z powodu nieprzewidzianych problemów z wdrażaniem. Wdrożenie powinno podążać podobnym wzorcem jak produkcja, przy użyciu tego samego pipeline'u GitHub Actions lub operatorów Flux.

Zaawansowane techniki wdrażania, takie jak wdrożenie niebiesko-zielone, testowanie A/B i wydania kanaryjne, wymagają dodatkowych procesów i potencjalnie dodatkowych narzędzi. Flagger to popularne rozwiązanie typu open source ułatwiające rozwiązywanie zaawansowanych scenariuszy wdrażania.

Zarządzanie kosztami

Zacznij od przejrzenia listy kontrolnej projektu optymalizacji kosztów i listy zaleceń opisanych w Well-Architected Framework for AKS. Aby uzyskać ogólne zalecenia dotyczące obciążeń, zobacz listę kontrolną projektowania dotyczącą optymalizacji kosztów.

Szacowanie kosztów składników używanych w tej architekturze bazowej można znaleźć w kalkulatorze cen Azure. Zmodyfikuj szacowanie, aby uwzględnić składniki wymagane do użycia. To oszacowanie obejmuje zasoby na poziomie szprych, które są bezpośrednio skojarzone z klastrem. Współużytkowana infrastruktura centrum, taka jak Azure Firewall, wirtualne sieci centrum i strefy Azure Prywatna strefa DNS, nie jest uwzględniona, ponieważ zasoby te są zwykle własnością centralnego zespołu platformowego i są przez niego zarządzane.

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

Provision

• 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. Na koszty wpływają wystąpienia maszyn wirtualnych, pamięć masowa, dane dzienników oraz zasoby sieciowe wykorzystywane przez klaster. Rozważ wybranie tańszych maszyn wirtualnych dla pul węzłów systemowych. Seria Ddv50 to typowy typ maszyny wirtualnej dla puli węzłów systemu, a implementacja referencyjna używa jednostki SKU Standard_D2d_v5.

• Nie używaj tej samej konfiguracji w środowiskach 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 dostępności dla obciążeń produkcyjnych. Jednak istnieją oszczędności w przypadku klastrów przeznaczonych do prac deweloperskich/testowych lub do zastosowań eksperymentalnych, w których dostępności nie trzeba gwarantować. Na przykład, Twoje SLO może być wystarczające. Ponadto, jeśli obciążenie na to pozwala, 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ą Azure SQL Database lub Azure App Service w ramach architektury obciążeń AKS, oceń, czy kwalifikujesz się do korzystania z subskrypcji Azure Dev/Test aby otrzymać rabaty 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 zasobów i limity, aby umożliwić Kubernetes przydzielanie zasobów węzłów o większej gęstości, co pozwala na pełne wykorzystanie pojemności węzłów.

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

• Zawieraj umowy na jeden lub trzy lata na wystąpienia zarezerwowanych maszyn wirtualnych Azure, aby zmniejszyć koszty węzłów, jeśli Twoje obciążenie musi działać przez dłuższy czas. Aby uzyskać więcej informacji, zobacz Oszczędzaj koszty dzięki zarezerwowanym instancjom maszyn wirtualnych 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ół. Jeśli klaster jest współużytkowany między zespołami, twórz raporty rozliczenia kosztów dla każdego odbiorcy w celu zidentyfikowania taryfowych kosztów współużytkowanych usług w chmurze. Aby uzyskać więcej informacji, zobacz Określić taint, etykietę lub tag 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 Bandwidth.

• Utwórz budżety, aby pozostać w granicach ograniczeń kosztów zidentyfikowanych przez organizację. Budżety można tworzyć za pomocą 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ń, przechowywania, przepustowość, dzienniki i zapory. Azure udostępnia następujące opcje monitorowania i analizowania kosztów:

• Azure Advisor
• Zarządzanie kosztami

Monitoruj koszty w czasie rzeczywistym lub zgodnie z regularnym harmonogramem, aby można było podjąć działania przed końcem miesiąca, gdy koszty są już obliczane. Monitoruj miesięczne trendy w miarę upływu czasu, aby pozostać w budżecie.

Aby podejmować decyzje oparte na danych, należy wskazać, który zasób na poziomie szczegółowym wiąże się z największymi kosztami. Warto mieć dobrą znajomość liczników, które obliczają użycie zasobów. Na przykład analizując metryki, można określić, czy platforma jest zbyt duża. Mierniki użycia są widoczne w metrykach Azure Monitor.

Optimize

Postępuj zgodnie z zaleceniami z Azure Advisor. Zapoznaj się z innymi sposobami optymalizacji:

• Włącz narzędzie do automatycznego skalowania klastra, aby wykrywać i usuwać niewykorzystane węzły w puli węzłów.

  Important

  Wprowadzanie szybkich lub częstych zmian w ustawieniach automatycznego skalowania klastra, takich jak minimalna i maksymalna liczba węzłów dla puli węzłów, w celu kontrolowania kosztów może prowadzić do niezamierzonych lub niepożądanych wyników. Jeśli na przykład scale-down-unneeded-time ustawiono wartość 10 minut, a minimalne i maksymalne ustawienia węzła są modyfikowane co 5 minut w oparciu o charakterystykę obciążenia, liczba węzłów nigdy nie zmniejsza się. Wynika to z faktu, że obliczenie niepotrzebnego czasu dla każdego węzła jest resetowane po odświeżeniu ustawień automatycznego skalowania klastra.

• Wybierz niższą wartość SKU dla pul węzłów, jeśli obciążenie na to pozwala.

• Jeśli aplikacja nie wymaga skalowania impulsowego, rozważ odpowiednie dostosowanie wielkości klastra, analizując metryki wydajności w czasie.

• Jeśli obciążenie to umożliwia, skaluj pule węzłów użytkownika do zera gdy nie jest oczekiwane ich uruchomienie. Jeśli nie ma żadnych obciążeń, które nie zostały zaplanowane do uruchomienia w klastrze, 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ć więcej informacji, zobacz cennik AKS.

Dalsze kroki

• AKS — harmonogram działania GitHub

Powiązane zasoby

• Zaawansowana architektura mikrousług AKS
• architektura mikroserwisów na AKS
• Użyj Azure Firewall, aby chronić klaster usługi AKS
• GitOps dla AKS
• Przesyłanie strumieniowe danych przy użyciu usługi AKS