Zalecenia dotyczące odporności strefy dla usługi Azure Kubernetes Service (AKS)

Odporność strefy jest kluczową częścią uruchamiania klastrów Kubernetes klasy produkcyjnej. Dzięki skalowalności w jej rdzeniu platforma Kubernetes w pełni wykorzystuje niezależną infrastrukturę w centrach danych bez ponoszenia dodatkowych kosztów przez aprowizowanie nowych węzłów tylko w razie potrzeby.

W tym artykule przedstawiono różne zalecenia dotyczące odporności strefy w usłudze Azure Kubernetes Service (AKS), w tym instrukcje:

• Uodpornij strefę składników klastra usługi AKS
• Projektowanie aplikacji bezstanowej
• Wybierz dysk do przechowywania danych
• Testowanie odporności strefy dostępności (AZ)

Uodpornij strefę składników klastra usługi AKS

Poniższe sekcje zawierają wskazówki dotyczące głównych punktów decyzyjnych związanych z zapewnieniem odporności strefowej składników klastra AKS, ale nie są one wyczerpujące. Należy wziąć pod uwagę inne czynniki na podstawie określonych wymagań i ograniczeń oraz sprawdzić inne zależności, aby upewnić się, że są skonfigurowane pod kątem odporności strefy.

Twórz strefowo redundantne klastry i pule węzłów

Usługa AKS umożliwia wybranie wielu stref AZ podczas tworzenia puli klastrów i węzłów. Podczas tworzenia klastra w regionie, w którym znajduje się wiele stref AZ, płaszczyzna sterowania jest automatycznie rozłożona na wszystkie strefy AZ w tym regionie. Jednak węzły w puli węzłów są rozmieszczone tylko w wybranych strefach dostępności (AZ). Takie podejście gwarantuje, że warstwa kontrolna i węzły są rozproszone w wielu strefach dostępności (AZ), zapewniając wysoką dostępność w przypadku awarii AZ. Strefę AZ można skonfigurować przy użyciu witryny Azure Portal, interfejsu wiersza polecenia platformy Azure lub szablonów usługi Azure Resource Manager.

Poniższy przykład pokazuje, jak utworzyć klaster z trzema węzłami rozłożonymi na trzy strefy dostępności za pomocą Azure CLI.

az aks create --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --generate-ssh-keys --vm-set-type VirtualMachineScaleSets --load-balancer-sku standard --node-count 3 --zones 1 2 3

Po utworzeniu klastra można użyć następującego polecenia, aby pobrać region i strefę dostępności dla każdego węzła agenta z etykiet:

kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone"

Następujące przykładowe dane wyjściowe pokazują region i strefę dostępności dla każdego węzła agenta:

Name:       aks-nodepool1-28993262-vmss000000
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            topology.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            topology.kubernetes.io/zone=eastus2-3

Aby uzyskać więcej informacji, zobacz Używanie stref dostępności w usłudze Azure Kubernetes Service (AKS).

Upewnij się, że zasobniki są rozłożone na strefę AZ

Począwszy od Kubernetes w wersji 1.33, domyślna Kube-Scheduler w usłudze AKS jest skonfigurowana do użycia wartości 1 dla MaxSkew, jak opisano poniżej:

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: "topology.kubernetes.io/zone"
  whenUnsatisfiable: ScheduleAnyway

Ta konfiguracja różni się od domyślnej w wersji bazowej, celując w nie więcej niż jedną różnicę w liczbie podów między strefami. W rezultacie zasobniki są bardziej równomiernie dystrybuowane między strefami, co zmniejsza prawdopodobieństwo, że awaria strefowa spowoduje przestój odpowiedniego wdrożenia.

Jeśli jednak twoje wdrożenie ma określone potrzeby topologii, możesz zastąpić powyższe wartości domyślne, dodając własne wartości w specyfikacji zasobnika. Za pomocą ograniczeń rozprzestrzeniania topologii zasobników na podstawie etykiet zone i hostname można dystrybuować zasobniki między strefami AZ w regionie oraz na hostach w ramach stref AZ.

Załóżmy na przykład, że masz klaster z czterema węzłami, w którym znajdują się trzy zasobniki oznaczone etykietą app: mypod-app w node1, node2 i node3 odpowiednio. Jeśli chcesz, aby wdrożenie przychodzące było hostowane w różnych węzłach, jak to możliwe, możesz użyć manifestu podobnego do następującego przykładu:

apiVersion: v1
kind: Deployment
metadata:
  name: mypod-deployment
  labels:
    app: mypod-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mypod-app
  template:
    metadata:
      labels:
        app: mypod-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "kubernetes.io/hostname"
        whenUnsatisfiable: ScheduleAnyway
      containers:
      - name: pause
        image: registry.k8s.io/pause

Aby uzyskać więcej informacji na temat konfigurowania dystrybucji podów i zrozumienia implikacji związanych z MaxSkew, zapoznaj się z dokumentacją topologii podów Kubernetes. Na przykład, jak nodeTaintsPolicy: Honor wpływa na rozmieszczenie zasobników.

Konfigurowanie sieci obsługującej moduł AZ

Jeśli masz zasobniki obsługujące ruch sieciowy, należy równoważyć obciążenie ruchu między wieloma strefami dostępności, aby upewnić się, że aplikacja jest wysoce dostępna i odporna na awarie. Za pomocą usługi Azure Load Balancer można dystrybuować ruch przychodzący między węzły w klastrze usługi AKS.

Usługa Azure Load Balancer obsługuje zarówno wewnętrzne, jak i zewnętrzne równoważenie obciążenia, i można skonfigurować ją do używania SKU w wersji Standard na potrzeby strefowo-redundantnego równoważenia obciążenia. Standardowa jednostka SKU jest domyślną jednostką SKU w usłudze AKS i obsługuje odporność regionalną ze strefami dostępności, aby zapewnić, że aplikacja nie zostanie dotknięta awarią regionu. W przypadku scenariusza awarii strefy strefowy moduł równoważenia obciążenia SKU Standard nie jest wpływany przez awarię i umożliwia twoim wdrożeniom dalsze obsługiwanie ruchu z pozostałych stref. Możesz użyć globalnego modułu równoważenia obciążenia, takiego jak usługa Front Door lub Traffic Manager, lub użyć modułów równoważenia obciążenia między regionami umieszczonych przed regionalnymi klastrami usługi AKS, aby upewnić się, że aplikacja nie ma wpływu na awarie regionalne. Aby utworzyć standardowy równoważnik obciążenia SKU w AKS, zobacz Użyj standardowego równoważnika obciążenia w Azure Kubernetes Service (AKS).

Aby upewnić się, że ruch sieciowy aplikacji jest odporny na awarie, należy skonfigurować sieć z obsługą az dla obciążeń usługi AKS. Platforma Azure oferuje różne usługi sieciowe, które obsługują strefy dostępności (AZs):

• Azure VPN Gateway: bramy sieci VPN i usługi ExpressRoute można wdrażać w usługach Azure AZ, aby umożliwić lepszą odporność, skalowalność i dostępność bram sieci wirtualnej. Aby uzyskać więcej informacji, zobacz Tworzenie strefowo nadmiarowych bram sieci wirtualnych w strefach dostępności.
• Azure Application Gateway w wersji 2: usługa Azure Application Gateway udostępnia regionalny moduł równoważenia obciążenia L7 z obsługą stref dostępności. Aby uzyskać więcej informacji, zobacz Direct web traffic with Azure Application Gateway (Bezpośredni ruch internetowy za pomocą usługi Azure Application Gateway).
• Azure Front Door: usługa Azure Front Door udostępnia globalny moduł równoważenia obciążenia L7 i wykorzystuje punkty obecności (POPS) lub Azure Content Delivery Network (CDN). Aby uzyskać więcej informacji, zobacz Lokalizacje POP usługi Azure Front Door.

Konfigurowanie strefowo nadmiarowego, zreplikowanego geograficznie rejestru kontenerów

Aby upewnić się, że obrazy kontenerów są wysoce dostępne i odporne na błędy, należy skonfigurować strefowo nadmiarowy rejestr kontenerów. Oferta Premium usługi Azure Container Registry (ACR) obsługuje replikację geograficzną oraz opcjonalną nadmiarowość strefową. Te funkcje zapewniają dostępność i zmniejszenie opóźnienia dla operacji regionalnych.

Zapewnianie dostępności i nadmiarowości kluczy i sekretów

Usługa Azure Key Vault udostępnia wiele warstw nadmiarowości, aby upewnić się, że klucze i wpisy tajne pozostają dostępne dla aplikacji, nawet jeśli poszczególne składniki usługi kończą się niepowodzeniem, lub jeśli regiony platformy Azure lub stref dostępności są niedostępne. Aby uzyskać więcej informacji, zobacz Dostępność i nadmiarowość usługi Azure Key Vault.

Korzystanie z funkcji skalowania automatycznego

Możesz zwiększyć dostępność aplikacji i odporność w usłudze AKS przy użyciu funkcji skalowania automatycznego, które ułatwiają osiągnięcie następujących celów:

• Zoptymalizuj wykorzystanie zasobów i efektywność kosztową, skalując zasoby w górę lub w dół na podstawie użycia procesora i pamięci podów.
• Zwiększ tolerancję na błędy i możliwości odzyskiwania, dodając więcej węzłów lub podów w przypadku awarii strefy.

Aby zaimplementować skalowanie automatyczne w usłudze AKS, możesz użyć narzędzia Horizontal Pod Autoscaler (HPA) i cluster Autoscaler . Narzędzie HPA automatycznie skaluje liczbę podów w ramach wdrożenia na podstawie obserwowanego wykorzystania CPU, wykorzystania pamięci, metryk niestandardowych oraz metryk innych usług. Narzędzie Cluster Autoscaler automatycznie dostosowuje liczbę węzłów w puli węzłów na podstawie żądań zasobów od podów uruchomionych na węzłach. Jeśli chcesz używać obu autoskalatorów razem, upewnij się, że pule węzłów z włączonym autoskalerem obejmują wiele stref. Jeśli pula węzłów znajduje się w jednej strefie i ta strefa ulegnie awarii, narzędzie do automatycznego skalowania nie może skalować klastra między strefami.

Funkcja dostawcy usługi AKS Karpenter w wersji zapoznawczej umożliwia automatyczne aprowizowanie węzłów przy użyciu narzędzia Karpenter w klastrze usługi AKS. Aby uzyskać więcej informacji, zobacz omówienie funkcji dostawcy AKS Karpenter.

Dodatek do usługi AKS, skalowanie automatyczne oparte na zdarzeniach KEDA dla platformy Kubernetes, umożliwia skalowanie aplikacji na podstawie metryk usług zewnętrznych, aby sprostać zapotrzebowaniu. Aby uzyskać więcej informacji, zobacz Instalowanie dodatku KEDA w usłudze Azure Kubernetes Service (AKS).

Projektowanie aplikacji bezstanowej

Gdy aplikacja jest bezstanowa, logika aplikacji i dane są oddzielone, a pody nie przechowują żadnych trwałych ani danych sesyjnych na swoich lokalnych dyskach. Ten projekt umożliwia łatwe skalowanie aplikacji w górę lub w dół bez obaw o utratę danych. Aplikacje bezstanowe są bardziej odporne na awarie, ponieważ można je łatwo umieścić lub ponownie przypisać do innego węzła w przypadku awarii węzła.

Podczas projektowania aplikacji bezstanowej za pomocą usługi AKS należy używać zarządzanych usług platformy Azure, takich jak Azure Databases, Azure Cache for Redis lub Azure Storage do przechowywania danych aplikacji. Korzystanie z tych usług zapewnia, że ruch może być przenoszony między węzłami i strefami bez ryzyka utraty danych lub wpływu na środowisko użytkownika. Za pomocą wdrożeń, usług i sond kondycji platformy Kubernetes można zarządzać zasobnikami bezstanowymi, a nawet zapewnić równomierną dystrybucję między strefami.

Wybierz dysk do przechowywania danych

Wybieranie odpowiedniego typu dysku na podstawie potrzeb aplikacji

Platforma Azure oferuje dwa typy dysków dla magazynu trwałego: magazyn lokalnie nadmiarowy (LRS) i magazyn strefowo nadmiarowy (ZRS). Usługa LRS replikuje dane w obrębie pojedynczej strefy dostępności AZ. ZRS replikuje dane między wieloma strefami dostępności w regionie. Począwszy od AKS wersji 1.29, domyślna klasa pamięci masowej używa dysków ZRS do przechowywania trwałego. Aby uzyskać więcej informacji, zobacz wbudowane klasy przechowywania w usłudze AKS.

Sposób replikowania danych przez aplikację może mieć wpływ na wybór dysku. Jeśli aplikacja znajduje się w wielu strefach dostępności i replikuje dane z poziomu aplikacji, możesz osiągnąć odporność przy użyciu dysku LRS w każdej strefie dostępności, ponieważ jeśli jedna z nich ulegnie awarii, pozostałe strefy będą miały dostęp do najnowszych danych. Jeśli warstwa aplikacji nie obsługuje takiej replikacji, dyski magazynu ZRS są lepszym wyborem, ponieważ platforma Azure obsługuje replikację w warstwie magazynu.

W poniższej tabeli przedstawiono zalety i wady poszczególnych typów dysków:

Aby uzyskać więcej informacji na temat typów dysków LRS i ZRS, zobacz Nadmiarowość usługi Azure Storage. pl-PL: Aby skonfigurować dyski magazynu w usłudze AKS, zobacz Konfigurowanie magazynu dysków Azure w usłudze Azure Kubernetes Service (AKS).

Monitorowanie wydajności dysku

Aby zapewnić optymalną wydajność i dostępność dysków pamięci masowej w usłudze AKS, powinieneś monitorować kluczowe metryki, takie jak IOPS, przepływność i opóźnienia. Te metryki mogą pomóc w zidentyfikowaniu wszelkich problemów lub wąskich gardeł, które mogą mieć wpływ na wydajność aplikacji. Jeśli zauważysz jakiekolwiek powtarzające się problemy z wydajnością, warto ponownie rozważyć typ lub rozmiar dysku pamięci masowej. Za pomocą usługi Azure Monitor można zbierać i wizualizować te metryki oraz konfigurować alerty w celu powiadamiania o wszelkich problemach z wydajnością.

Aby uzyskać więcej informacji, zobacz Monitorowanie usługi Azure Kubernetes Service (AKS) przy użyciu usługi Azure Monitor.

Testowanie odporności modułu AZ

Metoda 1. Węzły cordonu i opróżniania w jednym module AZ

Jednym ze sposobów testowania klastra usługi AKS pod kątem odporności az jest opróżnienie węzła w jednej strefie i sprawdzenie, jak wpływa na ruch, dopóki nie przełączy się w tryb failover do innej strefy. Ta metoda symuluje rzeczywisty scenariusz, w którym cała strefa jest niedostępna z powodu katastrofy lub awarii. Aby przetestować ten scenariusz, możesz użyć polecenia kubectl drain, aby bezpiecznie usunąć wszystkie pody z węzła i oznaczyć go jako nieplanowalny. Następnie można monitorować ruch i wydajność klastra przy użyciu narzędzi, takich jak Azure Monitor lub Prometheus.

W poniższej tabeli przedstawiono zalety i wady tej metody:

Metoda 2. Symulowanie błędu az przy użyciu programu Azure Chaos Studio

Innym sposobem przetestowania klastra usługi AKS pod kątem odporności na awarie AZ jest wstrzyknięcie błędów do klastra i obserwowanie wpływu na aplikację przy użyciu usługi Azure Chaos Studio. Azure Chaos Studio to usługa, która umożliwia tworzenie eksperymentów chaosu i zarządzanie nimi w zasobach i usługach platformy Azure. Za pomocą programu Chaos Studio można zasymulować awarię modułu AZ, tworząc eksperyment polegający na wstrzyknięciu błędów, który jest przeznaczony dla określonej strefy i zatrzymuje lub uruchamia ponownie maszyny wirtualne w tej strefie. Następnie można zmierzyć dostępność, opóźnienie i szybkość błędów aplikacji przy użyciu metryk i dzienników.

W poniższej tabeli przedstawiono zalety i wady tej metody:

Aby uzyskać więcej informacji, zobacz Co to jest usługa Azure Chaos Studio?.

Dalsze kroki

Aby uzyskać więcej szczegółów implementacji, zobacz Przewodnik po strefowo nadmiarowych klastrach i magazynie usługi AKS.