Dela via


Tillgänglighetszoner i Azure Kubernetes Service (AKS)

Tillgänglighetszoner hjälper till att skydda dina program och data från datacenterfel. Zoner är unika fysiska platser i en Azure-region. Varje zon innehåller ett eller flera datacenter som är utrustade med oberoende ström, kylning och nätverk.

Genom att använda Azure Kubernetes Service (AKS) med tillgänglighetszoner distribueras resurser fysiskt mellan olika tillgänglighetszoner i en enda region, vilket förbättrar tillförlitligheten. Att distribuera noder i flera zoner medför inte extra kostnader.

Den här artikeln visar hur du konfigurerar AKS-resurser för att använda tillgänglighetszoner.

AKS-resurser

Det här diagrammet visar de Azure-resurser som skapas när du skapar ett AKS-kluster:

Diagram som visar olika AKS-komponenter, inklusive AKS-komponenter som hanteras av Microsoft- och AKS-komponenter i din Azure-prenumeration.

AKS-kontrollplan

Microsoft är värd för AKS-kontrollplanet, Kubernetes API-servern och tjänster som scheduler och etcd som en hanterad tjänst. Microsoft replikerar kontrollplanet i flera zoner.

Andra resurser i klustret distribueras i en hanterad resursgrupp i din Azure-prenumeration. Som standardinställning är den här resursgruppen prefixad med MC_ för hanterat kluster och innehåller de resurser som nämns i följande avsnitt.

Nodgrupper

Nodpooler skapas som VM-skalningsuppsättningar i din Azure-prenumeration.

När du skapar ett AKS-kluster krävs en systemnodpool och skapas automatiskt. Den är värd för kritiska systempoddar som CoreDNS och metrics-server. Du kan lägga till fler användarnodpooler i AKS-klustret som värd för dina program.

Det finns tre sätt att distribuera nodpooler:

  • Zonöverskridande
  • Zonjusterad
  • Regionell

Diagram som visar AKS-noddistribution mellan tillgänglighetszoner i olika modeller.

Zonerna för systemnodpoolen konfigureras när klustret eller nodpoolen skapas.

Zonomfattande

I den här konfigurationen är noderna spridda över alla valda zoner. Dessa zoner anges med hjälp av parametern --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

AKS balanserar automatiskt antalet noder mellan zoner.

Om ett zonindelad avbrott inträffar kan noder i den berörda zonen påverkas, men noder i andra tillgänglighetszoner påverkas inte.

Kör följande kommando för att verifiera nodplatser:

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

Zonanpassad

I den här konfigurationen justeras varje nod (fäst) till en specifik zon. Så här skapar du tre nodpooler för en region med tre tillgänglighetszoner:

# # 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

Den här konfigurationen kan användas när du behöver kortare svarstid mellan noder. Det ger också mer detaljerad kontroll över skalningsåtgärder eller när du använder autoskalning av kluster.

Anmärkning

Om en enskild arbetsbelastning distribueras mellan nodpooler rekommenderar vi att du anger --balance-similar-node-groups till true för att upprätthålla en balanserad fördelning av noder mellan zoner för dina arbetsbelastningar under uppskalningsåtgärder.

Regional (använder inte tillgänglighetszoner)

Regionalt läge används när zontilldelningen inte anges i distributionsmallen (till exempel "zones"=[] eller "zones"=null).

I den här konfigurationen skapar nodpoolen regionala (inte zonfästa) instanser och placerar implicit instanser i hela regionen. Det finns ingen garanti för att instanser är balanserade eller spridda över zoner eller att instanser finns i samma tillgänglighetszon.

Vid sällsynta fall av ett fullständigt zonavbrott kan en, flera eller alla instanser i nodpoolen påverkas.

Kör följande kommando för att verifiera nodplatser:

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

Utrullningar

Kapslar

Kubernetes är medveten om Azure-tillgänglighetszoner och kan balansera poddar mellan noder i olika zoner. Om en zon blir otillgänglig flyttar Kubernetes poddar från berörda noder automatiskt.

Som dokumenterat i Kubernetes-referensen Well-Known Etiketter, Anteckningar och Taints använder Kubernetes topology.kubernetes.io/zone etiketten för att automatiskt sprida poddar i en replikeringskontrollant eller tjänst över de olika zonerna som finns tillgängliga.

Kör följande kommando för att se vilka poddar och noder som körs:

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

Parametern maxSkew beskriver i vilken grad poddar kan vara ojämnt fördelade. Om vi antar tre zoner och tre repliker kan du ange det här värdet så att 1 varje zon har minst en podd som körs:

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

Lagring och volymer

Standardmässigt använder Kubernetes version 1.29 och senare Azure Managed Disks med lagring med zonredundans för persistent volume-anspråk.

Dessa diskar replikeras mellan zoner för att förbättra återhämtningsförmågan för dina program. Den här åtgärden hjälper till att skydda dina data mot datacenterfel.

I följande exempel visas ett beständigt volymanspråk som använder Azure Standard SSD i zonredundant lagring:

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

För zonjusterade distributioner kan du skapa en ny lagringsklass med parametern inställd på skunameLRS (lokalt redundant lagring). Du kan sedan använda den nya lagringsklassen i din Persistent Volume Claim.

Även om lokalt redundanta lagringsdiskar är billigare är de inte zonredundanta och det går inte att ansluta en disk till en nod i en annan zon.

I följande exempel visas en lokalt redundant lagringsklass för Standard SSD-lagring:

kind: StorageClass

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

Lastbalanserare

Kubernetes distribuerar Azure Standard Load Balancer som standard, vilket balanserar inkommande trafik över alla zoner i en region. Om en nod blir otillgänglig omdirigerar lastbalanseraren trafiken till felfria noder.

En exempeltjänst som använder Azure Load Balancer:

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

Viktigt!

Den 30 september 2025 dras Basic Load Balancer tillbaka. Mer information finns i det officiella meddelandet. Om du använder Basic Load Balancer måste du uppgradera till Standard Load Balancer före slutdatumet.

Begränsningar

Följande begränsningar gäller när du använder tillgänglighetszoner: