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

Dotyczy: ✔️ AKS Automatic AKS Standard ✔️

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 dowiesz się, jakie są zalecenia dotyczące odporności strefowej w usłudze AKS, w tym jak:

• Zapewnij odporność strefową komponentów klastra AKS.
• Projektowanie aplikacji bezstanowych dla scenariuszy awarii strefy.
• Wybierz opcje nadmiarowości magazynu.
• Przetestuj zachowanie aplikacji i platformy podczas błędów strefowych.

Tryby klastra usługi AKS i odporność strefy

Usługa AKS obsługuje dwa tryby klastra:

• Usługa AKS Automatic, która zapewnia więcej wstępnie skonfigurowanych ustawień domyślnych platformy.
• AKS Standard, który zapewnia szerszą kontrolę operatora bezpośredniego.

Zasady odporności strefy w tym artykule dotyczą obu trybów klastra. Kluczową różnicą jest własność operacji platformy.

Pełne informacje o działaniu funkcji w zależności od trybu można znaleźć w artykule Porównanie funkcji trybów AKS Automatic i AKS Standard.

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

W poniższych sekcjach opisano kluczowe kwestie decyzyjne dotyczące odporności między strefami w usłudze AKS. Nie są wyczerpujące. Należy również zweryfikować odporność strefy dla zależności, takich jak magazyny danych, systemy tożsamości i usługi zewnętrzne.

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

Usługa AKS umożliwia wybranie wielu stref dostępności (AZ) podczas tworzenia klastra i puli węzłów. W regionach obsługujących wiele stref kontroli płaszczyzna sterowania jest automatycznie rozłożona między strefy. Węzły puli węzłów są rozmieszczone w wybranych strefach. 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.

Wskazówki dotyczące trybu klastra:

• AKS Automatic: wiele domyślnych ustawień platformy jest wstępnie skonfigurowanych. Nadal należy zweryfikować, czy obciążenia o krytycznym znaczeniu dla działalności firmy są celowo rozłożone między strefami oraz czy system zachowuje się w przypadku awarii zgodnie z wymaganiami.
• AKS Standard: Jawnie zaprojektuj topologię puli węzłów, ustawienia skalowania i zachowanie w domenach awarii.

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

Strategia rozmieszczania zasobników jest kwestią na poziomie obciążenia roboczego zarówno w przypadku usługi AKS Automatic, jak i AKS Standard. Wartości domyślne platformy nie zastępują wymagań dotyczących topologii na poziomie obciążenia.

Począwszy od wersji 1.33 platformy Kubernetes domyślny harmonogram Kube-Scheduler w usłudze AKS jest skonfigurowany tak, aby używać wartości MaxSkew równej 1 dla topology.kubernetes.io/zone:

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

Ta konfiguracja zakłada różnicę nie większą niż jeden pod między strefami, co zmniejsza prawdopodobieństwo, że awaria strefowa spowoduje niedostępność wdrożenia.

Jeśli wdrożenie ma specyficzne wymagania dotyczące topologii, zastąp te ustawienia domyślne w specyfikacji zasobnika. Możesz użyć ograniczeń rozproszenia topologicznego podów opartych na etykietach zone i hostname, aby rozmieścić pody między strefami AZ w regionie oraz między hostami w obrębie 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 do automatycznego skalowania klastra automatycznie dostosowuje liczbę węzłów w puli węzłów na podstawie oczekujących zasobników i żądań zasobów na oczekujących zasobnikach.

Wskazówki dotyczące trybu klastra:

• Automatyczne usługi AKS: skoncentruj się na żądaniach obciążeń i limitach, zasadach dystrybucji zasobników i mechanizmach kontroli zakłóceń, dzięki czemu wstępnie skonfigurowane skalowanie platformy może odzyskać usługę podczas stresu strefowego.
• AKS Standard: Należy jasno określić granice puli węzłów, zasady skalowania i ustawienia automatycznego skalera, tak aby były zgodne z ograniczeniami planowania uwzględniającego strefy.

Funkcja AKS Karpenter Provider umożliwia automatyczne udostępnianie węzłów za pomocą Karpenter na klastrze 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).

Strategia skalowania strefowego w zależności od trybu klastra AKS

W przypadku skalowania w górę z uwzględnieniem stref dopasuj model puli węzłów do ograniczeń planisty i trybu klastra.

AKS Standard

W przypadku korzystania z narzędzia Do automatycznego skalowania klastra ze strefami dostępności najlepszym rozwiązaniem jest jedna pula węzłów na strefę. Można ustawić --balance-similar-node-groups na True, aby zachować zrównoważony rozkład węzłów między strefami podczas zwiększania skali.

Dlaczego ma to znaczenie:

• Narzędzie do automatycznego skalowania klastra symuluje planowanie według puli węzłów, a nie według rozmieszczenia określonych stref.
• W wielostrefowej puli węzłów skalowanie w górę może umieścić nowy węzeł w strefie, która nadal narusza rygorystyczne ograniczenia rozkładu topologicznego, przez co pody pozostają w stanie Pending.
• Virtual Machine Scale Sets stosuje równoważenie między strefami w miarę możliwości. Podczas ograniczeń pojemności w strefie lub awarii strefy alokacja może się nie powieść i spowodować przejście puli węzłów w stan opóźnienia ponownych prób.
• Użycie jednej puli węzłów na strefę zwiększa kontrolę nad zachowaniem skalowania specyficznego dla strefy.

Moduł Cluster Autoscaler nie uwzględnia stref, a przydział do stref jest obsługiwany przez bazowe zestawy skalowania maszyn wirtualnych (Virtual Machine Scale Sets), a nie przez usługę AKS. Ta najlepsza praktyka staje się jeszcze bardziej istotna w przypadku korzystania ze strefowych ograniczeń rozkładu topologicznego zasobników w pojedynczej, wielostrefowej puli węzłów, ponieważ restrykcyjne ograniczenia mogą pozostawić zasobniki w stanie Pending, zwłaszcza w regionach o ograniczonej dostępności zasobów lub w scenariuszach niedostępności strefy.

Automatyczne usługi AKS

AKS Automatic używa wstępnie skonfigurowanego zachowania zarządzanych węzłów oraz domyślnych ustawień automatycznego aprowizowania węzłów. Nie można założyć, że obciążenia krytyczne są odporne na strefy bez zasad na poziomie obciążenia.

W przypadku usług krytycznych sprawdź poprawność:

• Zachowanie rozmieszczania Podów w topologii między strefami.
• Zachowanie odzyskiwania podczas ciśnienia strefowego.
• Planowanie wyników, gdy są używane ścisłe ograniczenia.
• Zachowanie aplikacji, gdy jedna strefa stanie się niedostępna.

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 Managed 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?.

Treści powiązane

• Co to jest usługa AKS Automatic?
• Przewodnik po nadmiarowych strefowo klastrach AKS i magazynowaniu