Strefy dostępności w usłudze Azure Kubernetes Service (AKS)

2025-05-09

Strefy dostępności pomagają chronić aplikacje i dane przed awariami centrum danych. Strefy to unikatowe lokalizacje fizyczne w regionie świadczenia usługi Azure. Każda strefa obejmuje co najmniej jedno centrum danych wyposażone w niezależne zasilanie, chłodzenie i sieć.

Użycie usługi Azure Kubernetes Service (AKS) ze strefami dostępności fizycznie dystrybuuje zasoby w różnych strefach dostępności w jednym regionie, co zwiększa niezawodność. Wdrażanie węzłów w wielu strefach nie wiąże się z dodatkowymi kosztami.

W tym artykule pokazano, jak skonfigurować zasoby usługi AKS do korzystania ze stref dostępności.

Zasoby AKS

Na tym diagramie przedstawiono zasoby platformy Azure tworzone podczas tworzenia klastra usługi AKS:

Płaszczyzna sterowania usługi AKS

Firma Microsoft hostuje płaszczyznę sterowania usługi AKS, serwer interfejsu API Kubernetes oraz usługi, takie jak scheduler i etcd jako usługa zarządzana. Firma Microsoft replikuje płaszczyznę sterowania w wielu strefach.

Inne zasoby klastra są wdrażane w zarządzanej grupie zasobów w ramach subskrypcji platformy Azure. Domyślnie ta grupa zasobów ma prefiks MC_ dla klastra zarządzanego i zawiera zasoby wymienione w poniższych sekcjach.

Grupy węzłów

Grupy węzłów są tworzone jako zestawy skalowalne maszyn wirtualnych w ramach subskrypcji Azure.

Podczas tworzenia klastra usługi AKS wymagana jest jedna pula węzłów systemowych i jest tworzona automatycznie. Hostuje krytyczne zasobniki systemowe, takie jak CoreDNS i metrics-server. Możesz dodać więcej pul węzłów użytkownika do klastra usługi AKS w celu hostowania aplikacji.

Istnieją trzy sposoby, w jaki można wdrożyć pule węzłów:

Przekraczanie stref
Wyrównane do strefy
Regionalne

Strefy puli węzłów systemowych są konfigurowane podczas tworzenia klastra lub puli węzłów.

Rozciąganie się na strefy

W tej konfiguracji węzły są rozmieszczone we wszystkich wybranych strefach. Te strefy są określane przy użyciu parametru --zones .

# Create an AKS cluster, and create a zone-spanning system node pool in all three AZs, one node in each AZ
az aks create --resource-group example-rg --name example-cluster --node-count 3 --zones 1 2 3
# Add one new zone-spanning user node pool, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-a  --node-count 6 --zones 1 2 3

Usługa AKS automatycznie równoważy liczbę węzłów między strefami.

W przypadku awarii strefowej węzły w dotkniętej strefie mogą zostać dotknięte, ale węzły w innych strefach dostępności pozostają bez wpływu.

Aby zweryfikować lokalizacje węzłów, uruchom następujące polecenie:

kubectl get nodes -o custom-columns='NAME:metadata.name, REGION:metadata.labels.topology\.kubernetes\.io/region, ZONE:metadata.labels.topology\.kubernetes\.io/zone'

NAME                                REGION   ZONE
aks-nodepool1-34917322-vmss000000   eastus   eastus-1
aks-nodepool1-34917322-vmss000001   eastus   eastus-2
aks-nodepool1-34917322-vmss000002   eastus   eastus-3

Dostosowane do strefy

W tej konfiguracji każdy węzeł jest dopasowany (przypięty) do określonej strefy. Aby utworzyć trzy pule węzłów dla regionu z trzema strefami dostępności:

# # Add three new zone-aligned user node pools, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-x  --node-count 2 --zones 1
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-y  --node-count 2 --zones 2
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-z  --node-count 2 --zones 3

Ta konfiguracja może być używana, gdy potrzebujesz mniejszego opóźnienia między węzłami. Zapewnia również bardziej szczegółową kontrolę nad operacjami skalowania lub w przypadku korzystania z narzędzia do automatycznego skalowania klastra.

Uwaga / Notatka

Jeśli pojedyncze obciążenie jest wdrażane w pulach węzłów, zalecamy ustawienie --balance-similar-node-groups na true, aby zachować zrównoważoną dystrybucję węzłów między strefami dla obciążeń podczas operacji skalowania w górę.

Regionalne (bez używania stref dostępności)

Tryb regionalny jest używany, gdy przypisanie strefy nie jest ustawione w szablonie wdrożenia (na przykład "zones"=[] lub "zones"=null).

W tej konfiguracji pula węzłów tworzy wystąpienia regionalne (nie przypięte do strefy) i niejawnie umieszcza wystąpienia w całym regionie. Nie ma gwarancji, że wystąpienia są zrównoważone lub rozłożone w różnych strefach lub że wystąpienia znajdują się w tej samej strefie dostępności.

W rzadkich przypadkach całkowitej awarii strefowej może mieć to wpływ na dowolne lub wszystkie wystąpienia w puli węzłów.

Aby zweryfikować lokalizacje węzłów, uruchom następujące polecenie:

kubectl get nodes -o custom-columns='NAME:metadata.name, REGION:metadata.labels.topology\.kubernetes\.io/region, ZONE:metadata.labels.topology\.kubernetes\.io/zone'

NAME                                REGION   ZONE
aks-nodepool1-34917322-vmss000000   eastus   0
aks-nodepool1-34917322-vmss000001   eastus   0
aks-nodepool1-34917322-vmss000002   eastus   0

Wdrożenia

Kapsuły

Platforma Kubernetes zna strefy dostępności platformy Azure i może równoważyć zasobniki między węzłami w różnych strefach. W przypadku, gdy strefa stanie się niedostępna, platforma Kubernetes automatycznie przenosi pody z dotkniętych węzłów.

Jak opisano w dokumentacji referencyjnej platformy Kubernetes Well-Known Labels, Adnotacje i Taints, platforma Kubernetes używa topology.kubernetes.io/zone etykiety do automatycznego dystrybuowania zasobników w kontrolerze replikacji lub usłudze w różnych dostępnych strefach.

Aby sprawdzić, które zasobniki i węzły są uruchomione, uruchom następujące polecenie:

  kubectl describe pod | grep -e "^Name:" -e "^Node:"

Parametr maxSkew opisuje stopień, w jakim pody mogą być nierównomiernie rozłożone. Przy założeniu, że trzy strefy i trzy repliki, należy ustawić tę wartość, aby zagwarantować 1 , że każda strefa ma uruchomiony co najmniej jeden zasobnik:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: my-app
      containers:
      - name: my-container
        image: my-image

Przechowywanie i woluminy

Domyślnie, wersje Kubernetes 1.29 i nowsze używają dysków zarządzanych na platformie Azure z wykorzystaniem magazynu strefowo nadmiarowego dla żądań trwałych woluminów.

Te dyski są replikowane między strefami, aby zwiększyć odporność aplikacji. Ta akcja pomaga chronić dane przed awariami centrum danych.

W poniższym przykładzie pokazano żądanie trwałego wolumenu, które używa Azure Standard SSD w przechowywaniu ze strefową nadmiarowością.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-csi
  #storageClassName: managed-csi-premium
  resources:
    requests:
      storage: 5Gi

W przypadku wdrożeń z wyrównaniem strefowym, można utworzyć nową klasę pamięci z parametrem skuname ustawionym na LRS (lokalnie nadmiarowa pamięć). Następnie możesz użyć nowej klasy pamięci masowej w Żądaniu Trwałego Wolumenu.

Chociaż lokalnie nadmiarowe dyski magazynowe są tańsze, nie są nadmiarowe strefowo, a dołączanie dysku do węzła w innej strefie nie jest obsługiwane.

W poniższym przykładzie przedstawiono lokalnie nadmiarową klasę magazynowania podstawowego SSD.

kind: StorageClass

metadata:
  name: azuredisk-csi-standard-lrs
provisioner: disk.csi.azure.com
parameters:
  skuname: StandardSSD_LRS
  #skuname: PremiumV2_LRS

Moduły równoważenia obciążenia

Platforma Kubernetes domyślnie wdraża Azure Standard Load Balancer, który równoważy ruch przychodzący we wszystkich strefach w regionie. Jeśli węzeł stanie się niedostępny, moduł równoważenia obciążenia przekierowuje ruch do węzłów w dobrej kondycji.

Przykładowa usługa korzystająca z usługi Azure Load Balancer:

apiVersion: v1
kind: Service
metadata:
  name: example
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 8080

Ważne

30 września 2025 r. usługa Load Balancer w warstwie podstawowej zostanie wycofana. Więcej informacji znajdziesz w oficjalnym ogłoszeniu. Jeśli używasz usługi Load Balancer w warstwie Podstawowej, pamiętaj o uaktualnieniu do usługi Load Balancer w warstwie Standardowej przed datą wycofania.

Ograniczenia

Podczas korzystania ze stref dostępności obowiązują następujące ograniczenia:

Zobacz Limity przydziału, ograniczenia dotyczące rozmiaru maszyny wirtualnej oraz dostępność regionu w AKS.
Nie można zmienić liczby używanych stref dostępności po utworzeniu puli węzłów.
Większość regionów obsługuje strefy dostępności. Zobacz listę regionów.

Dowiedz się więcej o pulach węzłów systemowych.
Dowiedz się więcej o pulach węzłów użytkownika.
Dowiedz się więcej o modułach równoważenia obciążenia.
Uzyskaj najlepsze praktyki zapewnienia ciągłości działania oraz odzyskiwania po awarii w usłudze AKS.