Skapa ett AKS-kluster (Azure Kubernetes Service) som använder tillgänglighetszoner

  • Artikel

Ett AKS-kluster (Azure Kubernetes Service) distribuerar resurser som noder och lagring över logiska avsnitt i den underliggande Azure-infrastrukturen. Om du använder tillgänglighetszoner separeras noder fysiskt från andra noder som distribuerats till olika tillgänglighetszoner. AKS-kluster som distribueras med flera tillgänglighetszoner som konfigurerats i ett kluster ger en högre tillgänglighetsnivå för att skydda mot maskinvarufel eller en planerad underhållshändelse.

Genom att definiera nodpooler i ett kluster som sträcker sig över flera zoner kan noder i en viss nodpool fortsätta att fungera även om en enda zon har gått ned. Dina program kan fortsätta att vara tillgängliga även om det uppstår ett fysiskt fel i ett enda datacenter om de orkestreras för att tolerera fel i en delmängd av noder.

Den här artikeln visar hur du skapar ett AKS-kluster och distribuerar nodkomponenterna mellan tillgänglighetszoner.

Innan du börjar

Du behöver Azure CLI version 2.0.76 eller senare installerad och konfigurerad. Kör az --version för att hitta versionen. Om du behöver installera eller uppgradera kan du läsa Installera Azure CLI.

Begränsningar och regiontillgänglighet

AKS-kluster kan använda tillgänglighetszoner i alla Azure-regioner som har tillgänglighetszoner.

Följande begränsningar gäller när du skapar ett AKS-kluster med hjälp av tillgänglighetszoner:

  • Du kan bara definiera tillgänglighetszoner när klustret eller nodpoolen skapas.
  • Det går inte att uppdatera ett befintligt icke-tillgänglighetszonkluster för att använda tillgänglighetszoner när klustret har skapats.
  • Den valda nodstorleken (VM SKU) som valts måste vara tillgänglig i alla valda tillgänglighetszoner.
  • Kluster med tillgänglighetszoner som är aktiverade kräver användning av Azure Standard Load Balancers för distribution mellan zoner. Du kan bara definiera den här lastbalanserarens typ när klustret skapas. Mer information och begränsningarna för standardlastbalanseraren finns i Standard SKU-begränsningar för Azure Load Balancer.

Stöd för tillgänglighetszoner för Azure-diskar

  • Volymer som använder Azure-hanterade LRS-diskar är inte zonredundanta resurser. Det går inte att koppla mellan zoner. Du måste samlokalitera volymer i samma zon som den angivna noden som är värd för målpodden.
  • Volymer som använder Azure-hanterade ZRS-diskar är zonredundanta resurser. Du kan schemalägga dessa volymer på alla zon- och icke-zonagentnoder. Här är ett exempel på hur du skapar en lagringsklass med hjälp av StandardSSD_ZRS disk:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-csi-zrs
provisioner: disk.csi.azure.com
parameters:
  skuName: StandardSSD_ZRS  # or Premium_ZRS
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Kubernetes är medveten om Azure-tillgänglighetszoner sedan version 1.12. Du kan distribuera ett PersistentVolumeClaim-objekt som refererar till en Azure Managed Disk i ett AKS-kluster med flera zoner och Kubernetes sköter schemaläggningen av alla poddar som gör anspråk på denna PVC i rätt tillgänglighetszon.

Azure Resource Manager-mallar och tillgänglighetszoner

När du skapar ett AKS-kluster kan du förstå följande information om hur du anger tillgänglighetszoner i en mall:

  • Om du uttryckligen definierar ett null-värde i en mall, till exempel genom att "availabilityZones": nullange , behandlar Resource Manager-mallen egenskapen som om den inte finns. Det innebär att klustret inte distribueras i en tillgänglighetszon.
  • Om du inte inkluderar "availabilityZones": egenskapen i Resource Manager-mallen distribueras inte klustret i en tillgänglighetszon.
  • Du kan inte uppdatera inställningarna för tillgänglighetszoner i ett befintligt kluster. Beteendet är annorlunda när du uppdaterar ett AKS-kluster med Resource Manager-mallar. Om du uttryckligen anger ett null-värde i mallen för tillgänglighetszoner och uppdaterar klustret uppdateras inte klustret för tillgänglighetszoner. Men om du utelämnar egenskapen tillgänglighetszoner med syntax som "availabilityZones": [], försöker distributionen inaktivera tillgänglighetszoner i ditt befintliga AKS-kluster och misslyckas.

Översikt över tillgänglighetszoner för AKS-kluster

Tillgänglighetszoner är ett erbjudande med hög tillgänglighet som skyddar 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. För att säkerställa återhämtning finns det alltid mer än en zon i alla zonaktiverade regioner. Den fysiska avgränsningen av tillgänglighetszonerna inom en region skyddar program och data mot datacenterfel.

Mer information finns i Vad är tillgänglighetszoner i Azure?.

AKS-kluster som distribueras med hjälp av tillgänglighetszoner kan distribuera noder över flera zoner inom en enda region. Ett kluster i regionen USA, östra 2 kan till exempel skapa noder i alla tre tillgänglighetszonerna i USA, östra 2. Den här fördelningen av AKS-klusterresurser förbättrar klustertillgängligheten eftersom de är motståndskraftiga mot fel i en viss zon.

AKS node distribution across availability zones

Om en enskild zon blir otillgänglig fortsätter dina program att köras på kluster som är konfigurerade att spridas över flera zoner.

Kommentar

När du implementerar tillgänglighetszoner med autoskalning av kluster rekommenderar vi att du använder en enda nodpool för varje zon. Du kan ange parametern --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. När den här metoden inte implementeras kan nedskalningsåtgärder störa balansen mellan noder mellan zoner.

Skapa ett AKS-kluster mellan tillgänglighetszoner

När du skapar ett kluster med kommandot az aks create anger parametern --zones de tillgänglighetszoner som agentnoderna ska distribueras till. Tillgänglighetszonerna som komponenterna för det hanterade kontrollplanet distribueras till styrs inte av den här parametern. De sprids automatiskt över alla tillgänglighetszoner (om de finns) i regionen under klusterdistributionen.

I följande exempel skapas ett AKS-kluster med namnet myAKSCluster i resursgruppen myResourceGroup med totalt tre noder. En agentnod i zon 1, en i 2 och sedan en i 3.

az group create --name myResourceGroup --location eastus2

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

Det tar några minuter att skapa AKS-klustret.

När du bestämmer vilken zon en ny nod ska tillhöra använder en angiven AKS-nodpool en zonutjämning med bästa möjliga ansträngning som erbjuds av underliggande Skalningsuppsättningar för virtuella Azure-datorer. AKS-nodpoolen är "balanserad" när varje zon har samma antal virtuella datorer eller +- en virtuell dator i alla andra zoner för skalningsuppsättningen.

Verifiera noddistribution mellan zoner

När klustret är klart anger du vilken tillgänglighetszon agentnoderna i skalningsuppsättningen finns i.

Hämta först autentiseringsuppgifterna för AKS-klustret med kommandot az aks get-credentials :

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Använd sedan kommandot kubectl describe för att visa noderna i klustret och filtrera efter topology.kubernetes.io/zone värdet. Följande exempel är för ett Bash-gränssnitt.

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

Följande exempelutdata visar de tre noderna som distribueras över den angivna regionen och tillgänglighetszonerna, till exempel eastus2-1 för den första tillgänglighetszonen och eastus2-2 för den andra tillgänglighetszonen:

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

När du lägger till fler noder i en agentpool distribuerar Azure-plattformen automatiskt de underliggande virtuella datorerna över de angivna tillgänglighetszonerna.

Med Kubernetes version 1.17.0 och senare använder AKS den nyare etiketten topology.kubernetes.io/zone och den inaktuella failure-domain.beta.kubernetes.io/zone. Du kan få samma resultat från att köra kubelet describe nodes kommandot i föregående steg genom att köra följande skript:

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

Följande exempel liknar utdata med mer utförlig information:

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

Verifiera podddistribution mellan zoner

Enligt beskrivningen i Välkända etiketter, Anteckningar och Taints använder topology.kubernetes.io/zone Kubernetes etiketten för att automatiskt distribuera poddar i en replikeringskontrollant eller tjänst över de olika tillgängliga zonerna. Om du vill testa etiketten och skala klustret från 3 till 5 noder kör du följande kommando för att kontrollera att podden är korrekt spridd:

az aks scale \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 5

När skalningsåtgärden har slutförts efter några minuter kör du kommandot kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone" i ett Bash-gränssnitt. Följande utdata liknar resultatet:

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
Name:       aks-nodepool1-28993262-vmss000003
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000004
            topology.kubernetes.io/zone=eastus2-2

Nu har du ytterligare två noder i zonerna 1 och 2. Du kan distribuera ett program som består av tre repliker. I följande exempel används NGINX:

kubectl create deployment nginx --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
kubectl scale deployment nginx --replicas=3

Genom att visa noder där dina poddar körs ser du att poddar körs på noderna som motsvarar tre olika tillgänglighetszoner. Med kommandot kubectl describe pod | grep -e "^Name:" -e "^Node:" i ett Bash-gränssnitt kan du till exempel se följande exempelutdata:

Name:         nginx-6db489d4b7-ktdwg
Node:         aks-nodepool1-28993262-vmss000000/10.240.0.4
Name:         nginx-6db489d4b7-v7zvj
Node:         aks-nodepool1-28993262-vmss000002/10.240.0.6
Name:         nginx-6db489d4b7-xz6wj
Node:         aks-nodepool1-28993262-vmss000004/10.240.0.8

Som du ser från föregående utdata körs den första podden på nod 0 i tillgänglighetszonen eastus2-1. Den andra podden körs på nod 2, motsvarande eastus2-3, och den tredje i noden 4 i eastus2-2. Utan någon extra konfiguration sprider Kubernetes poddarna korrekt över alla tre tillgänglighetszonerna.

Nästa steg

I den här artikeln beskrivs hur du skapar ett AKS-kluster med hjälp av tillgänglighetszoner. Mer information om kluster med hög tillgänglighet finns i Metodtips för affärskontinuitet och haveriberedskap i AKS.