Overwegingen voor zonetolerantie voor AKS (Azure Kubernetes Service)

In dit artikel vindt u informatie over de verschillende overwegingen voor zonetolerantie in Azure Kubernetes Service (AKS), waaronder het volgende:

• Uw AKS-clusteronderdelen zone tolerant maken
• Een stateless toepassing ontwerpen
• Uw opslagschijf beslissen
• Testen op tolerantie van beschikbaarheidszone (AZ)

Overzicht

AZ-tolerantie is een belangrijk onderdeel van het uitvoeren van Kubernetes-clusters op productieniveau. Kubernetes profiteert optimaal van onafhankelijke infrastructuur in datacenters zonder dat er extra kosten in rekening worden gebracht door nieuwe knooppunten alleen in te richten wanneer dat nodig is.

Uw AKS-clusteronderdelen zone tolerant maken

De volgende secties bevatten richtlijnen voor belangrijke beslissingspunten voor het maken van de zone voor AKS-clusteronderdelen, maar ze zijn niet volledig. Houd rekening met andere factoren op basis van uw specifieke vereisten en beperkingen en controleer uw andere afhankelijkheden om ervoor te zorgen dat ze zijn geconfigureerd voor zonetolerantie.

Zoneredundante clusters en knooppuntgroepen maken

Met AKS kunt u meerdere AZ's selecteren tijdens het maken van clusters en knooppuntgroepen. Wanneer u een cluster met meerdere AZ's maakt, wordt het besturingsvlak verspreid over de geselecteerde AZ's. De knooppunten in de knooppuntgroep worden ook verspreid over de geselecteerde AZ's. Deze aanpak zorgt ervoor dat het besturingsvlak en de knooppunten worden verdeeld over meerdere AZ's, waardoor tolerantie wordt geboden in het geval van een AZ-fout. U kunt AZ's configureren met behulp van Azure Portal, Azure CLI of Azure Resource Manager-sjablonen.

In het volgende voorbeeld ziet u hoe u een cluster maakt met drie knooppunten verspreid over drie AZ's met behulp van de Azure CLI:

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

Zodra het cluster is gemaakt, kunt u de volgende opdracht gebruiken om de regio en beschikbaarheidszone voor elk agentknooppunt op te halen uit de labels:

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

In de volgende voorbeelduitvoer ziet u de regio en beschikbaarheidszone voor elk agentknooppunt:

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

Zie Beschikbaarheidszones gebruiken in Azure Kubernetes Service (AKS) voor meer informatie.

Zorg ervoor dat pods verspreid zijn over AZ's

U kunt beperkingen voor podtopologiespreiding gebruiken op basis van de zone en hostname labels om pods over AZ's binnen een regio en over knooppunten binnen AZ's te verdelen.

Stel dat u een cluster met vier knooppunten hebt waarin drie pods met het label foo:bar zich bevinden, node1node2en node3 respectievelijk. Als u wilt dat een binnenkomende pod gelijkmatig wordt verdeeld met bestaande pods in verschillende zones, kunt u een manifest gebruiken dat vergelijkbaar is met het volgende voorbeeld:

kind: Pod
apiVersion: v1
metadata:
  name: mypod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

Zie Kubernetes Pod Topology Spread Constraints voor meer informatie.

AZ-bewuste netwerken configureren

Als u pods hebt die netwerkverkeer bedienen, moet u het verkeer over meerdere AZ's verdelen om ervoor te zorgen dat uw toepassing maximaal beschikbaar is en bestand is tegen fouten. U kunt Azure Load Balancer gebruiken om binnenkomend verkeer over de knooppunten in uw AKS-cluster te verdelen.

Azure Load Balancer ondersteunt zowel interne als externe taakverdeling en u kunt deze configureren voor het gebruik van een standard-SKU voor zone-redundante taakverdeling. De Standard-SKU is de standaard-SKU in AKS en ondersteunt regionale tolerantie met beschikbaarheidszones om ervoor te zorgen dat uw toepassing niet wordt beïnvloed door een regiofout. In het geval van een zonefoutscenario wordt een zone-redundante Standard SKU-load balancer niet beïnvloed door de fout en kunnen uw implementaties het verkeer van de resterende zones blijven verwerken. U kunt een globale load balancer gebruiken, zoals Front Door of Traffic Manager, of u kunt load balancers in meerdere regio's voor uw regionale AKS-clusters gebruiken om ervoor te zorgen dat uw toepassing niet wordt beïnvloed door regionale storingen. Zie Een standard load balancer gebruiken in Azure Kubernetes Service (AKS) als u een Standard SKU-load balancer in AKS wilt maken.

Om ervoor te zorgen dat het netwerkverkeer van uw toepassing bestand is tegen fouten, moet u AZ-bewuste netwerken configureren voor uw AKS-workloads. Azure biedt verschillende netwerkservices die AZ's ondersteunen:

• Azure VPN Gateway: u kunt VPN- en ExpressRoute-gateways implementeren in Azure AZ's om betere tolerantie, schaalbaarheid en beschikbaarheid voor virtuele netwerkgateways mogelijk te maken. Zie Een zoneredundante virtuele netwerkgateway maken in beschikbaarheidszones voor meer informatie.
• Azure-toepassing Gateway v2: Azure-toepassing Gateway biedt een regionale L7-load balancer met ondersteuning voor beschikbaarheidszones. Zie Webverkeer omleiden met Azure-toepassing Gateway voor meer informatie.
• Azure Front Door: Azure Front Door biedt een wereldwijde L7-load balancer en maakt gebruik van aanwezigheidspunten (POP's) of Azure Content Delivery Network (CDN). Zie Azure Front Door POP-locaties voor meer informatie.

Een zone-redundant, geografisch gerepliceerd containerregister instellen

Om ervoor te zorgen dat uw containerinstallatiekopieën maximaal beschikbaar zijn en bestand zijn tegen fouten, moet u een zone-redundant containerregister instellen. De Premium SKU van Azure Container Registry (ACR) ondersteunt geo-replicatie en optionele zoneredundantie. Deze functies bieden beschikbaarheid en verminderen latentie voor regionale bewerkingen.

Beschikbaarheid en redundantie voor sleutels en geheimen garanderen

Azure Key Vault biedt meerdere lagen redundantie om ervoor te zorgen dat uw sleutels en geheimen beschikbaar blijven voor uw toepassing, zelfs als afzonderlijke onderdelen van de service mislukken of als Azure-regio's of AZ's niet beschikbaar zijn. Zie Beschikbaarheid en redundantie in Azure Key Vault voor meer informatie.

Functies voor automatisch schalen gebruiken

U kunt de beschikbaarheid en tolerantie van toepassingen in AKS verbeteren met behulp van functies voor automatisch schalen, waarmee u de volgende doelen kunt bereiken:

• Optimaliseer het resourcegebruik en de kostenefficiëntie door omhoog of omlaag te schalen op basis van het CPU- en geheugengebruik van uw pods.
• Verbeter fouttolerantie en herstel door meer knooppunten of pods toe te voegen wanneer er een zonefout optreedt.

U kunt de automatische schaalaanpassing van horizontale pods (HPA) en cluster automatisch schalen gebruiken om automatisch schalen in AKS te implementeren. De HPA schaalt automatisch het aantal pods in een implementatie op basis van waargenomen CPU-gebruik, geheugengebruik, aangepaste metrische gegevens en metrische gegevens van andere services. De automatische schaalaanpassing van clusters past automatisch het aantal knooppunten in een knooppuntgroep aan op basis van de resourceaanvragen van de pods die op de knooppunten worden uitgevoerd. Als u beide automatische schaalaanpassingen samen wilt gebruiken, moet u ervoor zorgen dat de knooppuntgroepen waarvoor automatische schaalaanpassing is ingeschakeld meerdere zones omvatten. Als de knooppuntgroep zich in één zone bevindt en die zone uitvalt, kan de automatische schaalaanpassing het cluster niet schalen tussen zones.

Met de preview-functie van AKS Karpenter Provider kunt u knooppunten automatisch inrichten met behulp van Karpenter op uw AKS-cluster. Zie het overzicht van de functie AKS Karpenter Provider voor meer informatie.

De KEDA-invoegtoepassing (Kubernetes Event Driven AutoScaling) voor AKS past automatisch schalen op basis van gebeurtenissen toe om uw toepassing te schalen op basis van metrische gegevens van externe services om aan de vraag te voldoen. Zie De KEDA-invoegtoepassing installeren in Azure Kubernetes Service (AKS) voor meer informatie.

Een stateless toepassing ontwerpen

Wanneer een toepassing staatloos is, worden de toepassingslogica en gegevens losgekoppeld en slaan de pods geen permanente gegevens of sessiegegevens op hun lokale schijven op. Met dit ontwerp kan de toepassing eenvoudig omhoog of omlaag worden geschaald zonder dat u zich zorgen hoeft te maken over gegevensverlies. Staatloze toepassingen zijn toleranter voor fouten, omdat ze eenvoudig kunnen worden vervangen of opnieuw kunnen worden gepland op een ander knooppunt in het geval van een knooppuntfout.

Bij het ontwerpen van een staatloze toepassing met AKS moet u beheerde Azure-services, zoals Azure Databases, Azure Cache voor Redis of Azure Storage, gebruiken om de toepassingsgegevens op te slaan. Door deze services te gebruiken, zorgt u ervoor dat uw verkeer kan worden verplaatst tussen knooppunten en zones zonder risico op gegevensverlies of gevolgen voor de gebruikerservaring. U kunt Kubernetes Deployments, Services en Health Probes gebruiken om staatloze pods te beheren en zelfs distributie tussen zones te garanderen.

Uw opslagschijf beslissen

Het juiste schijftype kiezen op basis van toepassingsbehoeften

Azure biedt twee typen schijven voor permanente opslag: lokaal redundante opslag (LRS) en zone-redundante opslag (ZRS). LRS repliceert uw gegevens binnen één AZ. ZRS repliceert uw gegevens over meerdere AZ's binnen een regio. Vanaf AKS versie 1.29 gebruikt de standaardopslagklasse ZRS-schijven voor permanente opslag. Zie ingebouwde AKS-opslagklassen voor meer informatie.

De manier waarop uw toepassing gegevens repliceert, kan invloed hebben op uw keuze van de schijf. Als uw toepassing zich in meerdere zones bevindt en de gegevens vanuit de toepassing repliceert, kunt u tolerantie bereiken met een LRS-schijf in elke AZ, omdat als de ene AZ uitvalt, de andere AZ's de meest recente gegevens beschikbaar zouden hebben. Als uw toepassingslaag deze replicatie niet afhandelt, zijn ZRS-schijven een betere keuze, omdat Azure de replicatie in de opslaglaag afhandelt.

De volgende tabel bevat een overzicht van voor- en nadelen van elk schijftype:

Zie Azure Storage-redundantie voor meer informatie over de typen LRS- en ZRS-schijven. Zie Azure Disks Storage inrichten in Azure Kubernetes Service (AKS) als u opslagschijven in AKS (Azure Disks) wilt inrichten.

Schijfprestaties bewaken

Om optimale prestaties en beschikbaarheid van uw opslagschijven in AKS te garanderen, moet u belangrijke metrische gegevens bewaken, zoals IOPS, doorvoer en latentie. Deze metrische gegevens kunnen u helpen bij het identificeren van eventuele problemen of knelpunten die van invloed kunnen zijn op de prestaties van uw toepassing. Als u consistente prestatieproblemen ondervindt, kunt u het beste het type of de grootte van de opslagschijf herzien. U kunt Azure Monitor gebruiken om deze metrische gegevens te verzamelen en te visualiseren en waarschuwingen in te stellen om u op de hoogte te stellen van eventuele prestatieproblemen.

Zie AKS (Azure Kubernetes Service) bewaken met Azure Monitor voor meer informatie.

Testen op AZ-tolerantie

Methode 1: Cordon- en afvoerknooppunten in één AZ

Een manier om uw AKS-cluster voor AZ-tolerantie te testen, is door een knooppunt in één zone leeg te maken en te zien hoe dit van invloed is op verkeer totdat er een failover naar een andere zone wordt uitgevoerd. Met deze methode wordt een praktijkscenario gesimuleerd waarbij een hele zone niet beschikbaar is vanwege een noodgeval of storing. Als u dit scenario wilt testen, kunt u de kubectl drain opdracht gebruiken om alle pods van een knooppunt correct te verwijderen en deze als niet-gepland te markeren. Vervolgens kunt u clusterverkeer en prestaties bewaken met behulp van hulpprogramma's zoals Azure Monitor of Prometheus.

De volgende tabel bevat een overzicht van voor- en nadelen van deze methode:

Methode 2: Een AZ-fout simuleren met behulp van Azure Chaos Studio

Een andere manier om uw AKS-cluster voor AZ-tolerantie te testen, is door fouten in uw cluster te injecteren en de impact op uw toepassing te observeren met behulp van Azure Chaos Studio. Azure Chaos Studio is een service waarmee u chaosexperimenten kunt maken en beheren op Azure-resources en -services. U kunt Chaos Studio gebruiken om een AZ-fout te simuleren door een foutinjectieexperiment te maken dat gericht is op een specifieke zone en de virtuele machines (VM's) in die zone stopt of opnieuw opstart. Vervolgens kunt u de beschikbaarheid, latentie en foutsnelheid van uw toepassing meten met behulp van metrische gegevens en logboeken.

De volgende tabel bevat een overzicht van voor- en nadelen van deze methode:

Zie Wat is Azure Chaos Studio? voor meer informatie.

Volgende stappen

Zie de handleiding voor zone-redundante AKS-clusters en -opslag voor meer implementatiedetails.