Een AKS-cluster (Azure Kubernetes Service) maken dat gebruikmaakt van beschikbaarheidszones

Artikel
04/27/2024

In dit artikel leest u hoe u een AKS-cluster maakt en de knooppuntonderdelen over beschikbaarheidszones distribueert.

Voordat u begint

U moet Azure CLI versie 2.0.76 of hoger hebben geïnstalleerd en geconfigureerd. Voer az --version uit om de versie te bekijken. Als u Azure CLI 2.0 wilt installeren of upgraden, raadpleegt u Azure CLI 2.0 installeren.
Lees het overzicht van beschikbaarheidszones in AKS voor meer informatie over de voordelen en beperkingen van het gebruik van beschikbaarheidszones in AKS.

Azure Resource Manager-sjablonen en -beschikbaarheidszones

Houd rekening met de volgende details bij het maken van een AKS-cluster met beschikbaarheidszones met behulp van een Azure Resource Manager-sjabloon:

Als u bijvoorbeeld expliciet een null-waarde in een sjabloon definieert, "availabilityZones": nullbehandelt de sjabloon de eigenschap alsof deze niet bestaat. Dit betekent dat uw cluster niet wordt geïmplementeerd in een beschikbaarheidszone.
Als u de "availabilityZones": eigenschap niet in de sjabloon opneemt, wordt uw cluster niet geïmplementeerd in een beschikbaarheidszone.
U kunt instellingen voor beschikbaarheidszones in een bestaand cluster niet bijwerken, omdat het gedrag verschilt wanneer u een AKS-cluster bijwerkt met Azure Resource Manager-sjablonen. Als u expliciet een null-waarde in uw sjabloon instelt voor beschikbaarheidszones en uw cluster bijwerkt, wordt uw cluster niet bijgewerkt voor beschikbaarheidszones. Als u echter de eigenschap beschikbaarheidszones weglaat met syntaxis, zoals "availabilityZones": [], probeert de implementatie beschikbaarheidszones op uw bestaande AKS-cluster uit te schakelen en mislukt.

Een AKS-cluster maken in verschillende beschikbaarheidszones

Wanneer u een cluster maakt met behulp van de az aks create opdracht, geeft de --zones parameter de beschikbaarheidszones op waarin agentknooppunten moeten worden geïmplementeerd. De beschikbaarheidszones waar de onderdelen van het beheerde besturingsvlak in worden geïmplementeerd, worden niet beheerd door deze parameter. Ze worden automatisch verspreid over alle beschikbaarheidszones (indien aanwezig) in de regio tijdens de clusterimplementatie.

In de volgende voorbeeldopdrachten ziet u hoe u een resourcegroep en een AKS-cluster maakt met in totaal drie knooppunten. Eén agentknooppunt in zone 1, één in 2 en vervolgens één in 3.

Maak een resourcegroep met behulp van de az group create opdracht.
```
az group create --name $RESOURCE_GROUP --location $LOCATION
```
Maak een AKS-cluster met behulp van de az aks create opdracht met de --zones parameter.
```
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
```
Het duurt enkele minuten om het AKS-cluster te maken.

Bij het bepalen van de zone waartoe een nieuw knooppunt moet behoren, gebruikt een opgegeven AKS-knooppuntgroep een best effort zone balancing die wordt aangeboden door onderliggende Virtuele-machineschaalsets van Azure. De AKS-knooppuntgroep is 'evenwichtig' wanneer elke zone hetzelfde aantal VM's of +- één VM in alle andere zones voor de schaalset heeft.

Knooppuntdistributie tussen zones controleren

Wanneer het cluster gereed is, vermeldt u in welke beschikbaarheidszone de agentknooppunten in de schaalset zich bevinden.

Haal de AKS-clusterreferenties op met behulp van de az aks get-credentials opdracht:
```
az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME
```

Vermeld de knooppunten in het cluster met behulp van de kubectl describe opdracht en filter op de topology.kubernetes.io/zone waarde.

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

In de volgende voorbeelduitvoer ziet u de drie knooppunten die zijn verdeeld over de opgegeven regio en beschikbaarheidszones, zoals eastus2-1 voor de eerste beschikbaarheidszone en eastus2-2 voor de tweede beschikbaarheidszone:

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

Wanneer u meer knooppunten toevoegt aan een agentgroep, distribueert het Azure-platform automatisch de onderliggende VM's over de opgegeven beschikbaarheidszones.

Met Kubernetes-versies 1.17.0 en hoger gebruikt AKS het topology.kubernetes.io/zone label en het afgeschafte failure-domain.beta.kubernetes.io/zonelabel. U kunt hetzelfde resultaat krijgen van het uitvoeren van de kubectl describe nodes opdracht in het vorige voorbeeld met behulp van de volgende opdracht:

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

Het volgende voorbeeld lijkt op de uitvoer met uitgebreidere details:

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

Poddistributie tussen zones controleren

Zoals beschreven in bekende labels, aantekeningen en Taints, gebruikt Kubernetes het topology.kubernetes.io/zone label om pods automatisch te distribueren in een replicatiecontroller of service in de verschillende beschikbare zones. In dit voorbeeld test u het label en schaalt u het cluster van 3 tot 5 knooppunten om te controleren of de pod correct wordt verdeeld.

Schaal uw AKS-cluster van 3 tot 5 knooppunten met behulp van de az aks scale opdracht met de --node-count set op 5.
```
az aks scale \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --node-count 5
```

Wanneer de schaalbewerking is voltooid, controleert u de poddistributie tussen de zones met behulp van de volgende kubectl describe opdracht:

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

In de volgende voorbeelduitvoer ziet u de vijf knooppunten die zijn verdeeld over de opgegeven regio en beschikbaarheidszones, zoals eastus2-1 voor de eerste beschikbaarheidszone en eastus2-2 voor de tweede beschikbaarheidszone:

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

Implementeer een NGINX-toepassing met drie replica's met behulp van de volgende kubectl create deployment en kubectl scale opdrachten:

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

Controleer de poddistributie tussen de zones met behulp van de volgende kubectl describe opdracht:
```
kubectl describe pod | grep -e "^Name:" -e "^Node:"
```
In de volgende voorbeelduitvoer ziet u de drie pods die zijn verdeeld over de opgegeven regio en beschikbaarheidszones, zoals eastus2-1 voor de eerste beschikbaarheidszone en eastus2-2 voor de tweede beschikbaarheidszone:
```
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
```
Zoals u in de vorige uitvoer kunt zien, wordt de eerste pod uitgevoerd op knooppunt 0 in de beschikbaarheidszone eastus2-1. De tweede pod wordt uitgevoerd op knooppunt 2, die overeenkomt met eastus2-3en de derde in knooppunt 4, in eastus2-2. Zonder extra configuratie verspreidt Kubernetes de pods correct over alle drie de beschikbaarheidszones.

Volgende stappen

In dit artikel wordt beschreven hoe u een AKS-cluster maakt met behulp van beschikbaarheidszones. Zie Best practices voor bedrijfscontinuïteit en herstel na noodgevallen in AKS voor meer overwegingen over maximaal beschikbare clusters.

Share via