Aanbevelingen voor zonetolerantie voor Azure Kubernetes Service (AKS)

Van toepassing op: ✔️ AKS Automatic ✔️ AKS Standard

Zonetolerantie is een belangrijk onderdeel van het uitvoeren van Kubernetes-clusters op productieniveau. Met schaalbaarheid als kern profiteert Kubernetes optimaal van onafhankelijke infrastructuur in datacenters, zonder extra kosten te maken door nieuwe knooppunten alleen in te richten wanneer dat nodig is.

In dit artikel leert u aanbevelingen voor zonetolerantie in AKS, waaronder het volgende:

• AKS-clusteronderdelen zone tolerant maken.
• Ontwerp statusloze toepassingen voor scenario's met zone-uitval.
• Kies opties voor opslagredundantie.
• Test het gedrag van toepassingen en platformen tijdens zonegebonden fouten.

AKS-clustermodi en zonetolerantie

AKS ondersteunt twee clustermodi:

• AKS Automatic, dat meer vooraf geconfigureerde platformstandaarden biedt.
• AKS Standard, dat operators meer directe controle biedt.

Beginselen voor zonetolerantie in dit artikel zijn van toepassing op beide clustermodi. Het belangrijkste verschil is wie het platform beheert.

Zie AKS Automatic en AKS Standard-functievergelijking voor volledig functiegedrag per modus.

Uw AKS-clusteronderdelen zone tolerant maken

In de volgende secties worden de belangrijkste beslissingspunten voor zonetolerantie in AKS beschreven. Ze zijn niet volledig. U moet ook zonetolerantie valideren voor afhankelijkheden, zoals gegevensarchieven, identiteitssystemen en externe services.

Zoneredundante clusters en knooppuntgroepen maken

Met AKS kunt u meerdere AZ's selecteren tijdens het maken van clusters en knooppuntgroepen. In regio’s waar meerdere AZ’s beschikbaar zijn, wordt de control plane automatisch verdeeld over zones. De knooppunten in de nodepool zijn verspreid over de geselecteerde zones. 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.

Richtlijnen voor de clustermodus:

• AKS Automatisch: veel platformstandaarden zijn vooraf geconfigureerd. U moet nog steeds valideren dat bedrijfskritieke workloads opzettelijk zijn verdeeld over zones en dat foutgedrag voldoet aan de vereisten.
• AKS Standard: Ontwerp de topologie van de knooppuntgroepen, de schaalinstellingen en het gedrag van foutdomeinen expliciet.

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

De plaatsingsstrategie voor pods is in zowel AKS Automatic als AKS Standard een aandachtspunt op workloadniveau. Platformstandaarden vervangen geen topologievereisten op workloadniveau.

Vanaf Kubernetes versie 1.33 is de standaard-Kube-Scheduler in AKS geconfigureerd voor het gebruik van een MaxSkew waarde van 1 voor topology.kubernetes.io/zone:

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: "topology.kubernetes.io/zone"
  whenUnsatisfiable: ScheduleAnyway

Deze configuratie streeft naar niet meer dan één pod verschil tussen zones, waardoor de kans afneemt dat uitval van een zone leidt tot uitval van een implementatie.

Als uw implementatie specifieke topologiebehoeften heeft, moet u deze standaardinstellingen in uw podspecificatie overschrijven. U kunt beperkingen voor podtopologiespreiding gebruiken op basis van de zone en hostname labels om pods over AZ's binnen een regio en over hosts binnen AZ's te verdelen.

Stel dat u een cluster met vier knooppunten hebt waarin drie pods met het label app: mypod-app zich bevinden, node1node2en node3 respectievelijk. Als u wilt dat de binnenkomende implementatie zoveel mogelijk op afzonderlijke knooppunten wordt gehost, kunt u een manifest gebruiken dat vergelijkbaar is met het volgende voorbeeld:

apiVersion: v1
kind: Deployment
metadata:
  name: mypod-deployment
  labels:
    app: mypod-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mypod-app
  template:
    metadata:
      labels:
        app: mypod-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "kubernetes.io/hostname"
        whenUnsatisfiable: ScheduleAnyway
      containers:
      - name: pause
        image: registry.k8s.io/pause

Zie de documentatie over de MaxSkew voor meer informatie over het configureren van poddistributie en het begrijpen van de implicaties hiervan. Bijvoorbeeld hoe nodeTaintsPolicy: Honor de distributie van pods beïnvloedt.

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 standaard load balancer gebruiken in Azure Kubernetes Service (AKS) voor instructies om een Standard SKU-load balancer in AKS te 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 Application Gateway v2: Azure Application Gateway biedt een regionale L7-load balancer met ondersteuning voor beschikbaarheidszones. Zie Webverkeer omleiden met Azure Application 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-netwerk voor contentlevering (CDN). Zie Azure Front Door POP-locaties voor meer informatie.

Een zone-redundant, geografisch gerepliceerd containerregister instellen

Om ervoor te zorgen dat uw containerafbeeldingen hoog beschikbaar en veerkrachtig tegen storingen zijn, 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 van Azure Key Vaultvoor 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 Horizontale Pod Autoscaler (HPA) en Cluster Autoscaler gebruiken voor het implementeren van autoscaling in AKS. 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 Cluster Autoscaler past automatisch het aantal knooppunten in een knooppuntgroep aan op basis van in behandeling zijnde pods en de resourceaanvragen van de in behandeling zijnde pods.

Richtlijnen voor de clustermodus:

• AKS Automatic: Focus op workloadvereisten en -limieten, beleid voor podverdeling en verstoringscontroles, zodat vooraf geconfigureerde platformschaling de service kan herstellen bij zonale belasting.
• AKS Standard: Ontwerp expliciet de grenzen van knooppuntgroepen, schaalbeleid en instellingen voor automatisch schalen om af te stemmen op zonebewuste planningsbeperkingen.

Met de functie AKS Karpenter Provider kunt u knooppunten automatisch inrichten met behulp van Karpenter in 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.

Zoneschaalstrategie op basis van AKS-clustermodus

Voor zonebewust opschalen kunt u het model van de knooppuntgroep uitlijnen met scheduler-beperkingen en de clustermodus.

AKS Standard

Wanneer u Automatische schaalaanpassing van clusters met beschikbaarheidszones gebruikt, is een veelvoorkomende best practice één knooppuntgroep per zone. U kunt --balance-similar-node-groups instellen op True om tijdens het opschalen een evenwichtige verdeling van knooppunten over zones te behouden.

Waarom dit belangrijk is:

• Cluster Autoscaler simuleert de planning per nodepool, niet op basis van plaatsing in een specifieke zone.
• In een nodepool met meerdere zones kan opschalen een nieuwe node in een zone plaatsen die nog steeds in strijd is met strikte topologieverspreidingsbeperkingen, waardoor pods in afwachting blijven.
• Virtual Machine Scale Sets maakt gebruik van zoneverdeling met best effort. Tijdens zonecapaciteitsbeperkingen of uitval van een zone kan de allocatie mislukken, waardoor de knooppuntgroep in back-off terechtkomt.
• Het gebruik van één knooppuntgroep per zone verbetert de controle over zonespecifiek schaalgedrag.

De automatische schaalaanpassing van clusters is niet zonebewust en zonetoewijzing wordt verwerkt door de onderliggende Virtual Machine Scale Sets en niet door AKS. Deze aanbevolen werkwijze wordt nog relevanter wanneer u zonegebaseerde constraints voor podtopologieverdeling gebruikt op één multizone-nodepool, omdat te strikte constraints ertoe kunnen leiden dat pods in de status Pending blijven, vooral in regio's met beperkte capaciteit of in scenario's waarin een zone uitvalt.

AKS Automatisch

AKS Automatic maakt gebruik van vooraf geconfigureerd gedrag van beheerde knooppunten en standaardinstellingen voor automatische inrichting van knooppunten. U kunt er niet van uitgaan dat kritieke workloads bestand zijn tegen zone-uitval zonder beleid op het niveau van de workload.

Valideer het volgende voor kritieke services:

• Podtopologie verspreidt gedrag over zones.
• Herstelgedrag tijdens zonegebonden druk.
• Planningsresultaten wanneer strikte beperkingen worden gebruikt.
• Toepassingsgedrag wanneer één zone niet beschikbaar is.

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 Managed 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.

Maak uw keuze voor een opslagschijf

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-opslag inrichten in Azure Kubernetes Service (AKS) voor instructies over het inrichten van opslagschijven in AKS.

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.

Test voor AZ-veerkrachtigheid

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.

Verwante inhoud

• Wat is AKS Automatic?
• Handleiding voor zoneredundante AKS-clusters en -opslag