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

  • Artikel
  • 7 minuter för att läsa

Ett Azure Kubernetes Service (AKS) distribuerar resurser som noder och lagring över logiska delar av den underliggande Azure-infrastrukturen. Den här distributionsmodellen när du använder tillgänglighetszoner ser till att noder i en viss tillgänglighetszon är fysiskt åtskilda från de som definierats i en annan tillgänglighetszon. AKS-kluster som distribueras med flera tillgänglighetszoner som konfigurerats i ett kluster ger en högre tillgänglighetsnivå för att skydda mot ett maskinvarufel eller en planerad underhållshändelse.

Genom att definiera nodpooler i ett kluster för att sträcka sig över flera zoner kan noder i en viss nodpool fortsätta att fungera även om en enda zon har försvunnit. 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 på en delmängd av noderna.

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

Innan du börjar

Azure CLI version 2.0.76 eller senare måste vara installerat och konfigurerat. 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 regionstillgänglighet

AKS-kluster kan för närvarande skapas med hjälp av tillgänglighetszoner i följande regioner:

  • Australien, östra
  • Brasilien, södra
  • Kanada, centrala
  • Indien, centrala
  • Central US
  • Asien, östra
  • East US
  • USA, östra 2
  • Frankrike, centrala
  • Tyskland, västra centrala
  • Japan, östra
  • Sydkorea, centrala
  • Europa, norra
  • Mellanöstern
  • Sydostasien
  • USA, södra centrala
  • Central- och Central-Landet
  • Storbritannien, södra
  • US Gov, Virginia
  • Europa, västra
  • USA, västra 2
  • USA, västra 3

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 inställningarna för tillgänglighetszoner när klustret har skapats. Du kan inte heller uppdatera ett befintligt zonkluster utan tillgänglighet för att använda tillgänglighetszoner.
  • Den valda nodstorleken (VM SKU) måste vara tillgänglig för alla tillgänglighetszoner som valts.
  • Kluster med tillgänglighetszoner aktiverade kräver användning av Azure Standard Load Balancers för distribution mellan zoner. Den här typen av lastbalanserare kan bara definieras när klustret skapas. Mer information och begränsningar för standardlastbalanserare finns i Azure Load Balancer Standard SKU-begränsningar.

Begränsningar för Azure-diskar

Volymer som använder Hanterade Azure-diskar är för närvarande inte zonredundanta resurser. Volymer kan inte kopplas mellan zoner och måste finnas i samma zon som en viss nod som är värd för målpodden.

Kubernetes känner till 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 tar hand om schemaläggningen av alla poddar som gör anspråk på denna PV i rätt tillgänglighetszon.

Azure Resource Manager och tillgänglighetszoner

Om du uttryckligen definierar ett null-värde i en mall med syntax som när du skapar ett AKS-kluster behandlar Resource Manager-mallen egenskapen som om den inte finns, vilket innebär att tillgänglighetszonerna inte är aktiverade i "availabilityZones": null klustret. Om du skapar ett kluster med en Resource Manager som utelämnar egenskapen tillgänglighetszoner inaktiveras tillgänglighetszonerna.

Du kan inte uppdatera inställningarna för tillgänglighetszoner i ett befintligt kluster, så 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 görs inga ändringar i klustret för tillgänglighetszoner. Men om du utelämnar egenskapen tillgänglighetszoner med syntax som försöker distributionen inaktivera tillgänglighetszoner i ditt befintliga "availabilityZones": [] 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 mot datacenterfel. Zoner är unika fysiska platser i en Azure-region. Varje zon utgörs av ett eller flera datacenter som är utrustade med oberoende kraft, kylning och nätverk. För att säkerställa återhämtning finns det alltid fler ä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 distributionen av AKS-klusterresurser förbättrar klustertillgängligheten eftersom de är motståndskraftiga mot fel i en viss zon.

AKS-noddistribution mellan tillgänglighetszoner

Om en enskild zon blir otillgänglig fortsätter dina program att köras om klustret är fördelat över flera zoner.

Skapa ett AKS-kluster mellan tillgänglighetszoner

När du skapar ett kluster med kommandot az aks create definierar --zones parametern vilka zonagentnoder som distribueras till. Kontrollplanskomponenterna, till exempel etcd eller API:et, sprids över de tillgängliga zonerna i regionen om du --zones definierar parametern när klustret skapas. De specifika zoner som kontrollplanskomponenterna är utspridda över är oberoende av vilka explicita zoner som väljs för den första nodpoolen.

Om du inte definierar några zoner för standardagentpoolen när du skapar ett AKS-kluster är det inte säkert att kontrollplanskomponenterna sprids över tillgänglighetszoner. Du kan lägga till ytterligare nodpooler med kommandot az aks nodepool add och ange för nya noder, men det ändrar inte hur kontrollplanet har --zones fördelats mellan zoner. Inställningar för tillgänglighetszoner kan bara definieras när klustret eller nodpoolen skapas.

I följande exempel skapas ett AKS-kluster med namnet myAKSCluster i resursgruppen med namnet myResourceGroup. Totalt skapas 3 noder – en agent 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 viss AKS-nodpool en zonbalansering med bästa möjliga resultat som erbjuds av underliggande Azure Virtual Machine Scale Sets. En aks-nodpool betraktas som "balanserad" om varje zon har samma antal virtuella datorer eller + 1 virtuell dator i alla andra - zoner för skalningsuppsättningen.

Verifiera noddistribution mellan zoner

När klustret är klart listar du agentnoderna i skalningsuppsättningen för att se vilken tillgänglighetszon de är distribuerade 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 en lista över noderna i klustret och filtrera failure-domain.beta.kubernetes.io/zone värdet. Följande exempel är för ett Bash-gränssnitt.

kubectl describe nodes | grep -e "Name:" -e "failure-domain.beta.kubernetes.io/zone"

Följande exempelutdata visar de tre noderna som är distribuerade i 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
            failure-domain.beta.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            failure-domain.beta.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            failure-domain.beta.kubernetes.io/zone=eastus2-3

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

Observera att I nyare Kubernetes-versioner (1.17.0 och senare) använder AKS den nyare etiketten utöver den topology.kubernetes.io/zone inaktuella failure-domain.beta.kubernetes.io/zone . Du kan få samma resultat som ovan 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}'

Vilket ger dig mer kortfattade utdata:

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 informationen i Välkända etiketter, Anteckningar och Taintsanvänder Kubernetes etiketten för att automatiskt distribuera poddar i en replikeringskontrollant eller -tjänst i de olika zoner som failure-domain.beta.kubernetes.io/zone är tillgängliga. För att testa detta kan du skala upp klustret från 3 till 5 noder för att verifiera korrekt poddspridning:

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

När skalningsåtgärden slutförs efter några minuter bör kommandot i kubectl describe nodes | grep -e "Name:" -e "failure-domain.beta.kubernetes.io/zone" ett Bash-gränssnitt ge utdata som liknar det här exemplet:

Name:       aks-nodepool1-28993262-vmss000000
            failure-domain.beta.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            failure-domain.beta.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            failure-domain.beta.kubernetes.io/zone=eastus2-3
Name:       aks-nodepool1-28993262-vmss000003
            failure-domain.beta.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000004
            failure-domain.beta.kubernetes.io/zone=eastus2-2

Nu har vi två ytterligare noder i zon 1 och 2. Du kan distribuera ett program som består av tre repliker. Vi använder NGINX som exempel:

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

När du visar noderna där poddarna körs ser du att poddar körs på noderna som motsvarar tre olika tillgänglighetszoner. Med kommandot i ett Bash-gränssnitt får du till kubectl describe pod | grep -e "^Name:" -e "^Node:" exempel utdata som liknar följande:

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 i tidigare utdata körs den första podden på nod 0, som finns i tillgänglighetszonen eastus2-1 . Den andra podden körs på nod 2, som motsvarar eastus2-3 och den tredje i nod 4, i eastus2-2 . Utan ytterligare konfiguration sprider Kubernetes poddarna korrekt över alla tre tillgänglighetszonerna.

Nästa steg

Den här artikeln beskriver hur du skapar ett AKS-kluster som använder tillgänglighetszoner. Mer information om kluster med hög tillgänglig finns i Metodtips för affärskontinui och haveriberedskap i AKS.