Przegląd platformy Azure Well-Architected Framework — Azure Kubernetes Service (AKS)

  • Artykuł

Ten artykuł zawiera najlepsze rozwiązania dotyczące architektury dla Azure Kubernetes Service (AKS). Wytyczne opierają się na pięciu filarach doskonałości architektury:

  • Niezawodność
  • Bezpieczeństwo
  • Optymalizacja kosztów
  • Efektywność operacyjna
  • Zapewnianie wydajności

Zakładamy, że rozumiesz zasady projektowania systemu, masz działającą wiedzę na temat Azure Kubernetes Service i dobrze znasz jej funkcje. Aby uzyskać więcej informacji, zobacz Azure Kubernetes Service.

Wymagania wstępne

Zrozumienie filarów platformy Well-Architected Framework może pomóc w utworzeniu wysokiej jakości, stabilnej i wydajnej architektury chmury. Zalecamy przejrzenie obciążenia przy użyciu oceny przeglądu platformy Azure Well-Architected Framework .

W kontekście rozważ przejrzenie architektury referencyjnej, która odzwierciedla te zagadnienia w projekcie. Zalecamy rozpoczęcie od architektury linii bazowej dla klastra Azure Kubernetes Service (AKS) i architektury mikrousług w Azure Kubernetes Service. Zapoznaj się również z akceleratorem strefy docelowej usługi AKS, który zapewnia podejście architektoniczne i implementację referencyjną w celu przygotowania subskrypcji strefy docelowej do skalowalnego klastra Azure Kubernetes Service (AKS).

Niezawodność

W chmurze potwierdzamy, że występują błędy. Zamiast zapobiegać wszystkim awariom, dąży się do minimalizacji wpływu awarii pojedynczego składnika. Użyj poniższych informacji, aby zminimalizować liczbę wystąpień, które zakończyły się niepowodzeniem.

Podczas omawiania niezawodności z Azure Kubernetes Service ważne jest rozróżnienie między niezawodnością klastra a niezawodnością obciążeń. Niezawodność klastra jest wspólną odpowiedzialnością administratora klastra i dostawcy zasobów, podczas gdy niezawodność obciążenia jest domeną dewelopera. Azure Kubernetes Service ma uwagi i zalecenia dotyczące obu tych ról.

Na poniższej liście kontrolnej projektu i liście zaleceń objaśnienia są wykonywane, aby wskazać, czy każdy wybór ma zastosowanie do architektury klastra, architektury obciążenia, czy obu tych elementów.

Lista kontrolna projektu

  • Architektura klastra: W przypadku obciążeń krytycznych użyj stref dostępności dla klastrów usługi AKS.
  • Architektura klastra: Zaplanuj przestrzeń adresów IP, aby zapewnić niezawodne skalowanie klastra, w tym obsługę ruchu w trybie failover w topologii wielu klastrów.
  • Architektura klastra: Włącz usługę Container Insights , aby monitorować klaster i konfigurować alerty dotyczące zdarzeń wpływających na niezawodność.
  • Architektura obciążenia: Upewnij się, że obciążenia są tworzone w celu obsługi skalowania w poziomie oraz gotowości i kondycji aplikacji raportów.
  • Architektury klastrów i obciążeń: Upewnij się, że obciążenie jest uruchomione w pulach węzłów użytkownika i wybierz jednostkę SKU o odpowiednim rozmiarze. Co najmniej uwzględnij dwa węzły dla pul węzłów użytkownika i trzy węzły dla puli węzłów systemowych.
  • Architektura klastra: Użyj umowy SLA czasu działania usługi AKS, aby spełnić cele dostępności dla obciążeń produkcyjnych.

Zalecenia dotyczące konfiguracji usługi AKS

Zapoznaj się z poniższą tabelą zaleceń, aby zoptymalizować konfigurację usługi AKS pod kątem niezawodności.

Zalecenie Korzyść
Architektury klastrów i obciążeń: Kontrolowanie planowania zasobników przy użyciu selektorów węzłów i koligacji. Umożliwia harmonogramowi Kubernetes logiczne izolowanie obciążeń przez sprzęt w węźle. W przeciwieństwie do tolerancji zasobniki bez pasującego selektora węzłów można zaplanować w węzłach oznaczonych etykietami, co umożliwia korzystanie z nieużywanych zasobów w węzłach, ale daje priorytet zasobnikom definiującym pasujący selektor węzłów. Użyj koligacji węzła, aby uzyskać większą elastyczność, co pozwala zdefiniować, co się stanie, jeśli zasobnik nie może być dopasowany do węzła.
Architektura klastra: Upewnij się, że wybór wtyczki sieciowej zależy od wymagań sieciowych i rozmiaru klastra. Usługa Azure CNI jest wymagana w określonych scenariuszach, na przykład w pulach węzłów opartych na systemie Windows, specyficznych wymaganiach sieciowych i zasadach sieci kubernetes. Aby uzyskać więcej informacji , zobacz Kubenet i Azure CNI .
Architektury klastrów i obciążeń: Użyj umowy SLA czasu działania usługi AKS dla klastrów klasy produkcyjnej. Umowa SLA dotycząca czasu działania usługi AKS gwarantuje:
- 99.95%dostępność punktu końcowego serwera interfejsu API Kubernetes dla klastrów usługi AKS korzystających z usługi Azure Strefy dostępności lub
- 99.9%dostępność klastrów usługi AKS, które nie korzystają z usługi Azure Strefy dostępności.
Architektury klastrów i obciążeń: Konfigurowanie monitorowania klastra za pomocą usługi Container Insights. Szczegółowe informacje o kontenerach pomagają monitorować kondycję i wydajność kontrolerów, węzłów i kontenerów, które są dostępne na platformie Kubernetes za pośrednictwem interfejsu API metryk. Integracja z rozwiązaniem Prometheus umożliwia zbieranie metryk aplikacji i obciążeń.
Architektura klastra: Strefy dostępności umożliwiają zmaksymalizowanie odporności w regionie świadczenia usługi Azure przez dystrybucję węzłów agenta usługi AKS w fizycznie oddzielnych centrach danych. Rozdzielając pule węzłów w wielu strefach, węzły w jednej puli węzłów będą nadal działać, nawet jeśli inna strefa nie działa. Jeśli istnieją wymagania dotyczące współlokalności, można użyć zwykłego wdrożenia usługi AKS opartego na zestawie skalowania maszyn wirtualnych do jednej strefy lub grup umieszczania w pobliżu , aby zminimalizować opóźnienie międzywęźle.
Architektura klastra: Wdrożenie strategii wieloregionowej przez wdrożenie klastrów usługi AKS wdrożonych w różnych regionach świadczenia usługi Azure w celu zmaksymalizowania dostępności i zapewnienia ciągłości działania. Obciążenia połączone z Internetem powinny wykorzystywać usługę Azure Front Door lub Azure Traffic Manager do kierowania ruchu globalnego między klastrami usługi AKS.
Architektury klastrów i obciążeń: Zdefiniuj żądania zasobów zasobnika i limity w manifestach wdrażania aplikacji i wymuś je za pomocą Azure Policy. Limity zasobów procesora CPU i pamięci kontenera są niezbędne, aby zapobiec wyczerpaniu zasobów w klastrze Kubernetes.
Architektury klastrów i obciążeń: Zachowaj pulę węzłów systemowych odizolowaną od obciążeń aplikacji. Pule węzłów systemowych wymagają jednostki SKU maszyny wirtualnej co najmniej 2 procesorów wirtualnych i 4 GB pamięci, ale zalecane jest użycie co najmniej 4 procesorów wirtualnych. Dokumentacja pul węzłów systemu i użytkownika w celu uzyskania szczegółowych wymagań.
Architektury klastrów i obciążeń: Oddzielne aplikacje do dedykowanych pul węzłów na podstawie określonych wymagań. Aplikacje mogą współużytkować tę samą konfigurację i wymagać maszyn wirtualnych z obsługą procesora GPU, procesora CPU lub pamięci zoptymalizowanych pod kątem pamięci lub możliwości skalowania do zera. Unikaj dużej liczby pul węzłów, aby zmniejszyć dodatkowe obciążenie związane z zarządzaniem.
Architektura klastra: Użyj bramy translatora adresów sieciowych dla klastrów, które uruchamiają obciążenia, które tworzą wiele współbieżnych połączeń wychodzących. Aby uniknąć problemów z niezawodnością związanych z Azure Load Balancer ograniczeniami dotyczącymi dużego ruchu wychodzącego o dużej godzinie współbieżnej, brama translatora adresów sieciowych obsługuje niezawodny ruch wychodzący na dużą skalę.

Aby uzyskać więcej sugestii, zobacz Zasady filaru niezawodności.

Azure Policy

Azure Kubernetes Service oferuje szeroką gamę wbudowanych zasad platformy Azure, które dotyczą zarówno zasobu platformy Azure, jak typowe zasady platformy Azure, jak i przy użyciu dodatku Azure Policy dla platformy Kubernetes również w klastrze. Istnieje wiele zasad, a najważniejsze zasady związane z tym filarem zostały tutaj podsumowane. Aby uzyskać bardziej szczegółowy widok, zobacz wbudowane definicje zasad dla platformy Kubernetes.

Architektura klastra i obciążenia

  • Klastry mają sondy kondycji gotowości lub aktualności skonfigurowane dla specyfikacji zasobnika.

Oprócz wbudowanych definicji Azure Policy można tworzyć zasady niestandardowe zarówno dla zasobu usługi AKS, jak i dodatku Azure Policy dla platformy Kubernetes. Dzięki temu można dodać dodatkowe ograniczenia dotyczące niezawodności, które chcesz wymusić w architekturze klastra i obciążenia.

Zabezpieczenia

Bezpieczeństwo to jeden z najważniejszych aspektów każdej architektury. Aby dowiedzieć się, w jaki sposób usługa AKS może zwiększyć bezpieczeństwo obciążenia aplikacji, zalecamy zapoznanie się z zasadami projektowania zabezpieczeń. Jeśli klaster Azure Kubernetes Service musi być zaprojektowany pod kątem uruchamiania wrażliwego obciążenia spełniającego wymagania prawne standardu PCI-DSS 3.2.1 (Payment Card Industry Data Security Standard), zapoznaj się z klastrem regulowanym usługi AKS dla standardu PCI-DSS 3.2.1.

Aby dowiedzieć się więcej o obsłudze i wymaganiach dotyczących poziomu DoD Impact Level 5 (IL5) w usłudze AKS, zapoznaj się z wymaganiami dotyczącymi izolacji Azure Government IL5.

Podczas omawiania zabezpieczeń z Azure Kubernetes Service ważne jest rozróżnienie między zabezpieczeniami klastra i zabezpieczeniami obciążeń. Zabezpieczenia klastra są wspólną odpowiedzialnością między administratorem klastra a ich dostawcą zasobów, podczas gdy zabezpieczenia obciążenia są domeną dewelopera. Azure Kubernetes Service ma uwagi i zalecenia dotyczące obu tych ról.

Na poniższej liście kontrolnej projektu i liście zaleceń objaśnienia są wykonywane, aby wskazać, czy każdy wybór ma zastosowanie do architektury klastra, architektury obciążenia, czy obu tych elementów.

Lista kontrolna projektu

  • Architektura klastra: Użyj tożsamości zarządzanych , aby uniknąć zarządzania i rotacji zasad usługi.
  • Architektura klastra: Użyj kontroli dostępu opartej na rolach (RBAC) platformy Kubernetes z Tożsamość Microsoft Entra, aby uzyskać dostęp z najmniejszymi uprawnieniami i zminimalizować przyznawanie uprawnień administratora w celu ochrony konfiguracji i dostępu do wpisów tajnych.
  • Architektura klastra: Użyj Microsoft Defender dla kontenerów w usłudze Azure Sentinel, aby wykrywać i szybko reagować na zagrożenia w klastrze i obciążeniach uruchomionych na nich.
  • Architektura klastra: Wdróż prywatny klaster usługi AKS, aby zapewnić, że ruch związany z zarządzaniem klastrem na serwerze interfejsu API pozostanie w sieci prywatnej. Możesz też użyć listy dozwolonych serwerów interfejsu API dla klastrów innych niż prywatne.
  • Architektura obciążenia: Zabezpieczanie ruchu HTTP za pomocą Web Application Firewall.
  • Architektura obciążenia: Upewnij się, że potok ciągłej integracji/ciągłej integracji jest wzmocniony dzięki skanowaniu obsługującym kontenery.

Zalecenia

Zapoznaj się z poniższą tabelą zaleceń, aby zoptymalizować konfigurację usługi AKS pod kątem zabezpieczeń.

Zalecenie Korzyść
Architektura klastra: Użyj integracji Microsoft Entra. Użycie Tożsamość Microsoft Entra centralizuje składnik zarządzania tożsamościami. Każda zmiana stanu konta użytkownika lub grupy jest automatycznie aktualizowana w dostępie do klastra usługi AKS. Deweloperzy i właściciele aplikacji klastra Kubernetes muszą mieć dostęp do różnych zasobów.
Architektura klastra: Uwierzytelnij się przy użyciu Tożsamość Microsoft Entra w celu Azure Container Registry. Usługa AKS i Tożsamość Microsoft Entra umożliwiają uwierzytelnianie przy użyciu Azure Container Registry bez używania wpisów tajnychimagePullSecrets. Aby uzyskać więcej informacji, zobacz Uwierzytelnianie przy użyciu Azure Container Registry z Azure Kubernetes Service.
Architektura klastra: Zabezpieczanie ruchu sieciowego do serwera interfejsu API za pomocą prywatnego klastra usługi AKS. Domyślnie ruch sieciowy między pulami węzłów a serwerem interfejsu API jest kierowany do sieci szkieletowej firmy Microsoft; przy użyciu klastra prywatnego można zapewnić, że ruch sieciowy do serwera interfejsu API pozostaje tylko w sieci prywatnej.
Architektura klastra: W przypadku klastrów innych niż prywatne usługi AKS użyj autoryzowanych zakresów adresów IP serwera interfejsu API. W przypadku korzystania z klastrów publicznych nadal można ograniczyć ruch, który może docierać do serwera interfejsu API klastrów przy użyciu funkcji autoryzowanego zakresu adresów IP. Uwzględnij źródła, takie jak publiczne adresy IP agentów kompilacji wdrożenia, zarządzanie operacjami i punkt ruchu wychodzącego pul węzłów (na przykład Azure Firewall).
Architektura klastra: Ochrona serwera interfejsu API przy użyciu kontroli dostępu opartej na rolach Microsoft Entra. Zabezpieczanie dostępu do serwera interfejsu API Kubernetes jest jedną z najważniejszych czynności, które można wykonać w celu zabezpieczenia klastra. Zintegruj kontrolę dostępu opartą na rolach (RBAC) platformy Kubernetes z Tożsamość Microsoft Entra w celu kontrolowania dostępu do serwera interfejsu API. Wyłącz konta lokalne, aby wymusić cały dostęp do klastra przy użyciu tożsamości opartych na Tożsamość Microsoft Entra.
Architektura klastra: Użyj zasad sieciowych platformy Azure lub Calico. Zabezpieczanie i kontrolowanie ruchu sieciowego między zasobnikami w klastrze.
Architektura klastra: Zabezpieczanie klastrów i zasobników za pomocą Azure Policy. Azure Policy może pomóc w zastosowaniu wymuszania na dużą skalę i zabezpieczeń w klastrach w sposób scentralizowany, spójny. Może również kontrolować, jakie zasobniki funkcji są przyznawane, i jeśli coś działa względem zasad firmy.
Architektura klastra: Zabezpieczanie dostępu kontenera do zasobów. Ogranicz dostęp do akcji, które mogą wykonywać kontenery. Podaj najmniejszą liczbę uprawnień i unikaj używania eskalacji uprawnień głównych lub uprzywilejowanych.
Architektura obciążenia: Zabezpieczanie ruchu HTTP za pomocą Web Application Firewall. Aby skanować ruch przychodzący pod kątem potencjalnych ataków, użyj zapory aplikacji internetowej, takiej jak zapora aplikacji internetowej (WAF) platformy Azure Web Application Firewall w usłudze Azure Application Gateway lub Azure Front Door.
Architektura klastra: Sterowanie ruchem wychodzącym klastra. Upewnij się, że ruch wychodzący klastra przechodzi przez punkt zabezpieczeń sieci, taki jak Azure Firewall lub serwer proxy HTTP.
Architektura klastra: Użyj sterownika CSI magazynu kluczy tajnych Tożsamość obciążeń Microsoft Entra open source i magazynu wpisów tajnych w usłudze Azure Key Vault. Chroń i wymieniaj wpisy tajne, certyfikaty i parametry połączenia na platformie Azure Key Vault przy użyciu silnego szyfrowania. Udostępnia dziennik inspekcji dostępu i przechowuje podstawowe wpisy tajne z potoku wdrażania.
Architektura klastra: Użyj Microsoft Defender dla kontenerów. Monitorowanie i utrzymywanie zabezpieczeń klastrów, kontenerów i ich aplikacji.

Aby uzyskać więcej sugestii, zobacz Zasady filaru zabezpieczeń.

Usługa Azure Advisor pomaga zapewnić i ulepszyć usługę Azure Kubernetes. Udostępnia ona zalecenia dotyczące podzestawu elementów wymienionych w poniższej sekcji zasad, takich jak klastry bez skonfigurowanej kontroli dostępu opartej na rolach, brak konfiguracji Microsoft Defender, nieograniczony dostęp sieciowy do serwera interfejsu API. Podobnie udostępnia rekomendacje dotyczące obciążeń dla niektórych elementów inicjatywy zabezpieczeń zasobnika. Zapoznaj się z zaleceniami.

Definicje zasad

Azure Policy oferuje różne wbudowane definicje zasad, które dotyczą zarówno zasobu platformy Azure, jak i usługi AKS, takich jak standardowe definicje zasad, oraz korzystanie z dodatku Azure Policy dla platformy Kubernetes, również w klastrze. Wiele zasad zasobów platformy Azure jest dostępnych zarówno w wersji Audit/Deny, jak i w wariancie Wdróż, jeśli nie istnieje .

Istnieje wiele zasad, a najważniejsze zasady związane z tym filarem zostały tutaj podsumowane. Aby uzyskać bardziej szczegółowy widok, zobacz wbudowane definicje zasad dla platformy Kubernetes.

Architektura klastra

  • Microsoft Defender zasad opartych na chmurze
  • Tryb uwierzytelniania i zasady konfiguracji (Tożsamość Microsoft Entra, kontrola dostępu oparta na rolach, wyłączanie uwierzytelniania lokalnego)
  • Zasady dostępu do sieci serwera API, w tym klaster prywatny

Architektura klastra i obciążenia

  • Inicjatywy zabezpieczeń zasobników klastra Kubernetes oparte na systemie Linux
  • Uwzględnij zasady możliwości zasobnika i kontenera, takie jak AppArmor, sysctl, limity zabezpieczeń, SELinux, seccomp, kontenery uprzywilejowane, poświadczenia interfejsu API klastra
  • Instalowanie, sterowniki woluminów i zasady systemu plików
  • Zasady sieciowe zasobnika/kontenera, takie jak sieć hosta, port, dozwolone zewnętrzne adresy IP, protokoły HTTPs i wewnętrzne moduły równoważenia obciążenia

Azure Kubernetes Service wdrożenia często używają również Azure Container Registry dla wykresów programu Helm i obrazów kontenerów. Azure Container Registry obsługuje również szeroką gamę zasad platformy Azure, które obejmują ograniczenia sieci, kontrolę dostępu i Microsoft Defender dla chmury, które uzupełniają bezpieczną architekturę usługi AKS.

Oprócz wbudowanych zasad można tworzyć zasady niestandardowe zarówno dla zasobu usługi AKS, jak i dodatku Azure Policy dla platformy Kubernetes. Dzięki temu można dodać dodatkowe ograniczenia zabezpieczeń, które chcesz wymusić w architekturze klastra i obciążenia.

Aby uzyskać więcej sugestii, zobacz Pojęcia dotyczące zabezpieczeń usługi AKS i oceń nasze zalecenia dotyczące wzmacniania zabezpieczeń na podstawie testu porównawczego CIS Kubernetes.

Optymalizacja kosztów

Optymalizacja kosztów polega na zrozumieniu różnych opcji konfiguracji i zalecanych najlepszych rozwiązań w celu zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Przed wykonaniem wskazówek zawartych w tym artykule zalecamy zapoznanie się z następującymi zasobami:

Podczas omawiania optymalizacji kosztów za pomocą Azure Kubernetes Service ważne jest rozróżnienie kosztów zasobów klastra i kosztów zasobów obciążenia. Zasoby klastra są wspólną odpowiedzialnością między administratorem klastra a ich dostawcą zasobów, podczas gdy zasoby obciążenia są domeną dewelopera. Azure Kubernetes Service ma uwagi i zalecenia dotyczące obu tych ról.

Na liście kontrolnej projektu i liście zaleceń objaśnienia są wykonywane, aby wskazać, czy każdy wybór ma zastosowanie do architektury klastra, architektury obciążenia, czy obu tych elementów.

W przypadku optymalizacji kosztów klastra przejdź do kalkulatora cen platformy Azure i wybierz pozycję Azure Kubernetes Service z dostępnych produktów. Różne konfiguracje i plany płatności można przetestować w kalkulatorze.

Lista kontrolna projektu

  • Architektura klastra: Użyj odpowiedniej jednostki SKU maszyny wirtualnej na pulę węzłów i wystąpień zarezerwowanych, w których oczekiwana jest długoterminowa pojemność.
  • Architektury klastrów i obciążeń: Użyj odpowiedniej warstwy i rozmiaru dysku zarządzanego.
  • Architektura klastra: Przejrzyj metryki wydajności, począwszy od procesora CPU, pamięci, magazynu i sieci, aby zidentyfikować możliwości optymalizacji kosztów według klastra, węzłów i przestrzeni nazw.
  • Architektura klastra i obciążenia: Użyj autoskalatorów, aby skalować w poziomie, gdy obciążenia są mniej aktywne.

Zalecenia

Zapoznaj się z poniższą tabelą zaleceń, aby zoptymalizować konfigurację usługi AKS pod kątem kosztów.

Zalecenie Korzyść
Architektury klastrów i obciążeń: Dopasuj wybór jednostki SKU i rozmiar dysku zarządzanego do wymagań dotyczących obciążenia. Dopasowanie wyboru do wymagań dotyczących obciążeń gwarantuje, że nie płacisz za niepotrzebne zasoby.
Architektura klastra: Wybierz odpowiedni typ wystąpienia maszyny wirtualnej. Wybranie odpowiedniego typu wystąpienia maszyny wirtualnej ma kluczowe znaczenie, ponieważ ma bezpośredni wpływ na koszt uruchamiania aplikacji w usłudze AKS. Wybranie wystąpienia o wysokiej wydajności bez odpowiedniego wykorzystania może prowadzić do marnujących wydatków, a wybranie zaawansowanego wystąpienia może prowadzić do problemów z wydajnością i zwiększonego przestoju. Aby określić właściwy typ wystąpienia maszyny wirtualnej, rozważ charakterystyki obciążeń, wymagania dotyczące zasobów i potrzeby dotyczące dostępności.
Architektura klastra: Wybierz maszyny wirtualne na podstawie architektury arm. Usługa AKS obsługuje tworzenie węzłów agenta arm64 Ubuntu, a także węzły architektury Intel i ARM w klastrze, które mogą zapewnić lepszą wydajność przy niższych kosztach.
Architektura klastra: Wybierz pozycję Azure Spot Virtual Machines. Maszyny wirtualne typu spot umożliwiają korzystanie z nie w pełni wykorzystywanej pojemności platformy Azure ze znacznymi rabatami (do 90% w porównaniu z cenami płatności zgodnie z rzeczywistym użyciem). Jeśli platforma Azure potrzebuje pojemności z powrotem, infrastruktura platformy Azure eksmituje węzły typu spot.
Architektura klastra: Wybierz odpowiedni region. Ze względu na wiele czynników koszt zasobów różni się w zależności od regionu na platformie Azure. Oceń koszty, opóźnienia i wymagania dotyczące zgodności, aby upewnić się, że obciążenie działa opłacalnie i nie ma to wpływu na użytkowników końcowych ani nie tworzy dodatkowych opłat za sieć.
Architektura obciążenia: Obsługa małych i zoptymalizowanych obrazów. Usprawnianie obrazów pomaga zmniejszyć koszty, ponieważ nowe węzły muszą pobrać te obrazy. Twórz obrazy w sposób, który umożliwia uruchamianie kontenera tak szybko, jak to możliwe, aby uniknąć niepowodzeń żądań użytkownika lub przekroczenia limitu czasu podczas uruchamiania aplikacji, co potencjalnie prowadzi do nadmiernej aprowizacji.
Architektura klastra: Włącz automatyczne skalowanie klastra , aby automatycznie zmniejszyć liczbę węzłów agenta w odpowiedzi na nadmiarową pojemność zasobów. Automatyczne skalowanie w dół liczby węzłów w klastrze usługi AKS umożliwia uruchamianie wydajnego klastra, gdy zapotrzebowanie jest niskie i skalowane w górę po powrocie zapotrzebowania.
Architektura klastra: Włącz automatyczne aprowizowanie węzła , aby zautomatyzować wybór jednostki SKU maszyny wirtualnej. Automatyczna aprowizacja węzła upraszcza proces wyboru jednostki SKU i decyduje w oparciu o oczekujące wymagania dotyczące zasobów zasobników optymalną konfigurację maszyny wirtualnej do uruchamiania obciążeń w najbardziej wydajny i ekonomiczny sposób.
Architektura obciążenia: Użyj narzędzia Horizontal Pod Autoscaler. Dostosuj liczbę zasobników we wdrożeniu w zależności od użycia procesora CPU lub innych metryk wyboru, które obsługują operacje skalowania klastra.
Architektura obciążenia: Użyj narzędzia Vertical Pod Autoscaler (wersja zapoznawcza). Ustawianie rozmiaru zasobników i dynamiczne ustawianie żądań i limitów na podstawie historycznego użycia.
Architektura obciążenia: Użyj skalowania automatycznego opartego na zdarzeniach Kubernetes (KEDA). Skaluj na podstawie liczby przetwarzanych zdarzeń. Wybierz z bogatego katalogu 50+ skalatorów KEDA.
Architektury klastrów i obciążeń: Przyjęcie dziedziny finansowej chmury i praktyki kulturowej w celu utrzymania własności użycia chmury. Podstawą włączania optymalizacji kosztów jest rozłożenie klastra oszczędności kosztów. Podejście do operacji finansowych (FinOps) jest często używane w celu ułatwienia organizacjom obniżenia kosztów chmury. Jest to praktyka obejmująca współpracę między zespołami finansowymi, operacyjnymi i inżynieryjnymi w celu dostosowania celów oszczędzania kosztów i zapewnienia przejrzystości kosztów w chmurze.
Architektura klastra: Zarejestruj się w celu uzyskania rezerwacji platformy Azure lub planu oszczędności platformy Azure. Jeśli pojemność jest prawidłowo planowana, obciążenie jest przewidywalne i istnieje przez dłuższy czas, zarejestruj się w celu uzyskania rezerwacji platformy Azure lub planu oszczędnościowego , aby jeszcze bardziej zmniejszyć koszty zasobów.
Architektura klastra: Konfigurowanie monitorowania klastra za pomocą szczegółowych informacji o kontenerze. Pomoc dotycząca szczegółowych informacji o kontenerach zapewnia praktyczny wgląd w bezczynne i nieprzydzielone zasoby klastrów. Usługa Container Insights obsługuje również zbieranie metryk Prometheus i integruje się z usługą Azure Managed Grafana w celu uzyskania całościowego widoku aplikacji i infrastruktury.
Architektura klastra: Skonfiguruj dodatek AKS Cost Analysis. Rozszerzenie klastra analizy kosztów umożliwia uzyskanie szczegółowego wglądu w koszty związane z różnymi zasobami Kubernetes w klastrach lub przestrzeniach nazw.

Aby uzyskać więcej sugestii, zobacz Zasady filaru optymalizacji kosztów i Optymalizowanie kosztów w Azure Kubernetes Service.

Definicje zasad

Chociaż nie ma wbudowanych zasad związanych z optymalizacją kosztów, zasady niestandardowe można tworzyć zarówno dla zasobu usługi AKS, jak i dodatku Azure Policy dla platformy Kubernetes. Dzięki temu można dodać dodatkowe ograniczenia optymalizacji kosztów, które chcesz wymusić w architekturze klastra i obciążenia.

Wydajność chmury

Zwiększenie wydajności obciążeń i chmury wymaga łączenia wysiłków związanych z optymalizacją kosztów, zmniejszeniem emisji dwutlenku węgla i optymalizacją zużycia energii. Optymalizacja kosztów aplikacji jest pierwszym krokiem w dokonaniu bardziej zrównoważonych obciążeń.

Dowiedz się, jak tworzyć zrównoważone i wydajne obciążenia usługi AKS w zasadach zrównoważonej inżynierii oprogramowania w usłudze Azure Kubernetes Service (AKS).

Efektywność operacyjna

Monitorowanie i diagnostyka są niezwykle istotne. Nie tylko możesz mierzyć statystyki wydajności, ale także szybko rozwiązywać problemy i rozwiązywać problemy. Zalecamy zapoznanie się z zasadami projektowania doskonałości operacyjnej i przewodnikiem po operacjach day-2.

Podczas omawiania doskonałości operacyjnej z Azure Kubernetes Service ważne jest rozróżnienie między doskonałością operacyjną klastra a doskonałością operacyjną obciążeń. Operacje klastra są współdzieloną odpowiedzialnością między administratorem klastra a ich dostawcą zasobów, podczas gdy operacje obciążenia są domeną dewelopera. Azure Kubernetes Service ma uwagi i zalecenia dotyczące obu tych ról.

Na poniższej liście kontrolnej projektu i liście zaleceń objaśnienia są wykonywane, aby wskazać, czy każdy wybór ma zastosowanie do architektury klastra, architektury obciążenia, czy obu tych elementów.

Lista kontrolna projektu

  • Architektura klastra: Użyj wdrożenia opartego na szablonach przy użyciu narzędzi Bicep, Terraform lub innych. Upewnij się, że wszystkie wdrożenia są powtarzalne, możliwe do śledzenia i przechowywane w repozytorium kodu źródłowego.
  • Architektura klastra: Utwórz zautomatyzowany proces, aby upewnić się, że klastry są uruchamiane przy użyciu niezbędnych konfiguracji i wdrożeń w całym klastrze. Jest to często wykonywane przy użyciu metodyki GitOps.
  • Architektura obciążenia: Użyj powtarzalnych i zautomatyzowanych procesów wdrażania dla obciążenia w ramach cyklu życia tworzenia oprogramowania.
  • Architektura klastra: Włącz ustawienia diagnostyczne, aby upewnić się, że interakcje z płaszczyzną sterowania lub podstawowym serwerem interfejsu API są rejestrowane.
  • Architektury klastrów i obciążeń: Włącz usługę Container Insights , aby zbierać metryki, dzienniki i diagnostykę, aby monitorować dostępność i wydajność klastra i obciążeń uruchomionych na nim.
  • Architektura obciążenia: Obciążenie powinno być zaprojektowane tak, aby emitować dane telemetryczne, które można zbierać, co powinno również obejmować linie na żywo i stan gotowości.
  • Architektury klastrów i obciążeń: Skorzystaj z praktyk inżynieryjnych chaosu, które dotyczą platformy Kubernetes, aby zidentyfikować problemy z niezawodnością aplikacji lub platformy.
  • Architektura obciążenia: Zoptymalizuj obciążenie, aby wydajnie obsługiwać i wdrażać w kontenerze.
  • Architektury klastrów i obciążeń: Wymuszanie ładu klastra i obciążenia przy użyciu Azure Policy.

Zalecenia

Zapoznaj się z poniższą tabelą zaleceń, aby zoptymalizować konfigurację usługi AKS pod kątem operacji.

Zalecenie Korzyść
Architektury klastrów i obciążeń: Zapoznaj się z dokumentacją najlepszych rozwiązań usługi AKS . Aby pomyślnie skompilować i uruchomić aplikacje w usłudze AKS, należy wziąć pod uwagę kluczowe zagadnienia dotyczące zrozumienia i wdrożenia. Obszary te obejmują funkcje wielu dzierżaw i harmonogramów, klastry i zasobników oraz ciągłość działania i odzyskiwanie po awarii.
Architektury klastrów i obciążeń: Zapoznaj się z programem Azure Chaos Studio. Usługa Azure Chaos Studio może pomóc symulować błędy i wyzwalać sytuacje odzyskiwania po awarii.
Architektury klastrów i obciążeń: Konfigurowanie monitorowania klastra za pomocą szczegółowych informacji o kontenerze. Szczegółowe informacje o kontenerach ułatwiają monitorowanie wydajności kontenerów przez zbieranie metryk pamięci i procesora z kontrolerów, węzłów i kontenerów dostępnych w usłudze Kubernetes za pośrednictwem interfejsu API metryk i dzienników kontenerów.
Architektura obciążenia: Monitorowanie wydajności aplikacji za pomocą usługi Azure Monitor. Skonfiguruj usługę Application Insights na potrzeby monitorowania opartego na kodzie aplikacji działających w klastrze usługi AKS.
Architektura obciążenia: Skonfiguruj złomowanie metryk Rozwiązania Prometheus przy użyciu szczegółowych informacji o kontenerze. Szczegółowe informacje o kontenerach, które są częścią usługi Azure Monitor, zapewniają bezproblemowe środowisko dołączania do zbierania metryk rozwiązania Prometheus. Aby uzyskać więcej informacji, zobacz Konfigurowanie złomowania metryk Rozwiązania Prometheus .
Architektura klastra: Wdrożenie strategii wieloregionowej przez wdrożenie klastrów usługi AKS wdrożonych w różnych regionach świadczenia usługi Azure w celu zmaksymalizowania dostępności i zapewnienia ciągłości działania. Obciążenia połączone z Internetem powinny wykorzystywać usługę Azure Front Door lub Azure Traffic Manager do kierowania ruchu globalnie w klastrach usługi AKS.
Architektura klastra: Operacjonalizacja standardów konfiguracji klastrów i zasobników przy użyciu Azure Policy. Azure Policy może pomóc w zastosowaniu wymuszania na dużą skalę i zabezpieczeń w klastrach w sposób scentralizowany, spójny. Może również kontrolować, jakie zasobniki funkcji są przyznawane i jeśli coś działa względem zasad firmy.
Architektura obciążenia: Korzystanie z możliwości platformy w procesie inżynierii wersji. Kontrolery kubernetes i ruchu przychodzącego obsługują wiele zaawansowanych wzorców wdrażania w celu włączenia ich do procesu inżynierii wydania. Rozważ wzorce, takie jak wdrożenia niebieski-zielony lub wersje kanaarne.
Architektury klastrów i obciążeń: W przypadku obciążeń o znaczeniu krytycznym należy używać wdrożeń niebieskich/zielonych na poziomie sygnatury. Automatyzowanie obszarów projektowania o krytycznym znaczeniu, w tym wdrażania i testowania.

Aby uzyskać więcej sugestii, zobacz Zasady filaru doskonałości operacyjnej.

Usługa Azure Advisor udostępnia również zalecenia dotyczące podzestawu elementów wymienionych w poniższej sekcji zasad, takich nieobsługiwanych wersji usługi AKS i nieskonfigurowanych ustawień diagnostycznych. Podobnie, zalecenia dotyczące obciążenia dotyczące używania domyślnej przestrzeni nazw.

Definicje zasad

Azure Policy oferuje różne wbudowane definicje zasad, które mają zastosowanie zarówno do zasobu platformy Azure, jak i usługi AKS, takich jak standardowe definicje zasad, oraz przy użyciu dodatku Azure Policy dla platformy Kubernetes, również w klastrze. Wiele zasad zasobów platformy Azure jest dostępnych zarówno w wersji Audit/Deny, jak i w wariancie Wdróż, jeśli nie istnieje .

Istnieje wiele zasad, a kluczowe zasady związane z tym filarem zostały tu podsumowane. Aby uzyskać bardziej szczegółowy widok, zobacz wbudowane definicje zasad dla platformy Kubernetes.

Architektura klastra

  • Azure Policy dodatek dla platformy Kubernetes
  • Zasady konfiguracji usługi GitOps
  • Zasady ustawień diagnostycznych
  • Ograniczenia wersji usługi AKS
  • Zapobiegaj wywołaniu polecenia

Architektura klastra i obciążenia

  • Ograniczenia wdrażania przestrzeni nazw

Oprócz wbudowanych zasad można tworzyć zasady niestandardowe zarówno dla zasobu usługi AKS, jak i dodatku Azure Policy dla platformy Kubernetes. Umożliwia to dodanie dodatkowych ograniczeń zabezpieczeń, które chcesz wymusić w architekturze klastra i obciążenia.

Efektywność wydajności

Efektywność wydajności to możliwość skalowania obciążenia w celu zaspokojenia zapotrzebowania użytkowników w wydajny sposób. Zalecamy zapoznanie się z zasadami wydajności.

Podczas omawiania wydajności z Azure Kubernetes Service ważne jest rozróżnienie między wydajnością klastra a wydajnością obciążenia. Wydajność klastra jest współdzieloną odpowiedzialnością między administratorem klastra a ich dostawcą zasobów, podczas gdy wydajność obciążenia jest domeną dewelopera. Azure Kubernetes Service ma uwagi i zalecenia dotyczące obu tych ról.

Na poniższej liście kontrolnej projektu i liście zaleceń objaśnienia są wykonywane, aby wskazać, czy każdy wybór ma zastosowanie do architektury klastra, architektury obciążenia, czy obu tych elementów.

Lista kontrolna projektu

Podczas podejmowania decyzji projektowych dotyczących Azure Kubernetes Service zapoznaj się z zasadami wydajności.

  • Architektury klastrów i obciążeń: Wykonaj i iteruj szczegółowe ćwiczenie planu pojemności, które obejmuje jednostki SKU, ustawienia skalowania automatycznego, adresowanie IP i zagadnienia dotyczące trybu failover.
  • Architektura klastra: Włącz automatyczne skalowanie klastra , aby automatycznie dostosować liczbę węzłów agenta w zależności od zapotrzebowania na obciążenia.
  • Architektura klastra: Użyj narzędzia do automatycznego skalowania zasobnika poziomego , aby dostosować liczbę zasobników we wdrożeniu w zależności od użycia procesora CPU lub innych wybranych metryk.
  • Architektury klastrów i obciążeń: Wykonaj trwające działania testowania obciążenia, które wykonują zarówno narzędzie do automatycznego skalowania zasobnika, jak i klastra.
  • Architektury klastrów i obciążeń: Rozdziel obciążenia na różne pule węzłów, co umożliwia niezależne skalowanie.

Zalecenia

Zapoznaj się z poniższą tabelą zaleceń, aby zoptymalizować konfigurację Azure Kubernetes Service pod kątem wydajności.

Zalecenie Korzyść
Architektury klastrów i obciążeń: Opracuj szczegółowy plan pojemności i stale przeglądaj i popraw. Po sformalizacji planu pojemności należy go często aktualizować, stale obserwując wykorzystanie zasobów klastra.
Architektura klastra: Włącz automatyczne skalowanie klastra , aby automatycznie dostosować liczbę węzłów agenta w odpowiedzi na ograniczenia zasobów. Możliwość automatycznego skalowania w górę lub w dół liczby węzłów w klastrze usługi AKS umożliwia uruchamianie wydajnego, ekonomicznego klastra.
Architektury klastrów i obciążeń: Rozdziel obciążenia na różne pule węzłów i rozważ skalowanie pul węzłów użytkownika. W przeciwieństwie do pul węzłów systemu, które zawsze wymagają uruchomionych węzłów, pule węzłów użytkownika umożliwiają skalowanie w górę lub w dół.
Architektura obciążenia: Korzystanie z zaawansowanych funkcji harmonogramu usługi AKS. Pomaga kontrolować równoważenie zasobów dla obciążeń, które ich wymagają.
Architektura obciążenia: Użyj znaczących metryk skalowania obciążenia. Nie wszystkie decyzje dotyczące skalowania mogą pochodzić z metryk procesora CPU lub pamięci. Często zagadnienia dotyczące skalowania wynikają z bardziej złożonych, a nawet zewnętrznych punktów danych. Użyj narzędzia KEDA , aby utworzyć znaczący zestaw reguł skalowania automatycznego na podstawie sygnałów specyficznych dla obciążenia.

Aby uzyskać więcej sugestii, zobacz Zasady filaru wydajności.

Definicje zasad

Azure Policy oferuje różne wbudowane definicje zasad, które dotyczą zarówno zasobu platformy Azure, jak i usługi AKS, takich jak standardowe definicje zasad, oraz korzystanie z dodatku Azure Policy dla platformy Kubernetes, również w klastrze. Wiele zasad zasobów platformy Azure jest dostępnych zarówno w wersji Audit/Deny, jak i w wariancie Wdróż, jeśli nie istnieje .

Istnieje wiele zasad, a najważniejsze zasady związane z tym filarem zostały tutaj podsumowane. Aby uzyskać bardziej szczegółowy widok, zobacz wbudowane definicje zasad dla platformy Kubernetes.

Architektura klastra i obciążenia

  • Limity zasobów procesora CPU i pamięci

Oprócz wbudowanych zasad można tworzyć zasady niestandardowe zarówno dla zasobu usługi AKS, jak i dodatku Azure Policy dla platformy Kubernetes. Dzięki temu można dodać dodatkowe ograniczenia zabezpieczeń, które chcesz wymusić w architekturze klastra i obciążenia.

Dodatkowe zasoby

Wskazówki dotyczące Centrum architektury platformy Azure

Wytyczne w przewodniku Cloud Adoption Framework

Następne kroki