Rekommendationer för zonåterhämtning för Azure Kubernetes Service (AKS)

Gäller för: ✔️ AKS Automatic ✔️ AKS Standard

Zonåterhämtning är en viktig del av körningen av Kubernetes-kluster i produktionsklass. Med skalbarhet i grunden drar Kubernetes full nytta av oberoende infrastruktur i datacenter utan att medföra ytterligare kostnader genom att etablera nya noder endast när det behövs.

I den här artikeln får du lära dig rekommendationer för zonåterhämtning i AKS, inklusive hur du:

• Gör AKS-klusterkomponenterna zonsäkra.
• Utforma tillståndslösa applikationer för scenarier med zonbortfall.
• Välj alternativ för lagringsredundans.
• Testa program- och plattformsbeteende vid zonfel.

AKS-klusterlägen och zonåterhämtning

AKS stöder två klusterlägen:

• AKS Automatic, som ger mer förkonfigurerade plattformsstandarder.
• AKS Standard, som ger bredare direktoperatörskontroll.

Zonåterhämtningsprinciper i den här artikeln gäller för båda klusterlägena. Den största skillnaden är ägarskapet för plattformsåtgärder.

En fullständig jämförelse av funktioner per läge finns i funktionsjämförelsen mellan AKS Automatic och AKS Standard.

Gör dina AKS-klusterkomponenter zon-resistenta

I följande avsnitt beskrivs viktiga beslutspunkter för zonåterhämtning i AKS. De är inte uttömmande. Du bör också verifiera zonåterhämtning för beroenden som datalager, identitetssystem och externa tjänster.

Skapa zonredundanta kluster och nodpooler

Med AKS kan du välja flera AZ under skapandet av kluster- och nodpoolen. I regioner som stöder flera AZs sprids kontrollplanet automatiskt över zoner. Nodpoolnoder är spridda över de valda zonerna. Den här metoden säkerställer att kontrollplanet och noderna distribueras över flera AZ:er, vilket ger återhämtning i händelse av ett AZ-fel.

Vägledning för klusterläge:

• AKS Automatic: Många plattformsstandarder är förkonfigurerade. Du bör fortfarande kontrollera att affärskritiska arbetsbelastningar avsiktligt distribueras mellan zoner och att felbeteendet uppfyller kraven.
• AKS Standard: Utforma nodpooltopologi, skalningsinställningar och beteende för feldomän explicit.

I följande exempel visas hur du skapar ett kluster med tre noder fördelade på tre AZ:er med hjälp av 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

När klustret har skapats kan du använda följande kommando för att hämta regionen och tillgänglighetszonen för varje agentnod från etiketterna:

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

Följande exempelutdata visar regionen och tillgänglighetszonen för varje agentnod:

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

Mer information finns i Använda tillgänglighetszoner i Azure Kubernetes Service (AKS).

Se till att poddar är spridda över AZs

Strategin för poddplacering är en fråga på arbetsbelastningsnivå i både AKS Automatic och AKS Standard. Plattformsstandarder ersätter inte topologikrav på arbetsbelastningsnivå.

Från och med Kubernetes version 1.33 konfigureras standard Kube-Scheduler i AKS att använda MaxSkew värdet 1 för topology.kubernetes.io/zone:

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

Den här konfigurationen syftar till att ha högst en pods skillnad mellan zoner, vilket minskar risken för att ett fel i en zon orsakar ett avbrott i distributionen.

Om distributionen har specifika topologibehov åsidosätter du dessa standardvärden i poddspecifikationen. Du kan använda begränsningar för poddtopologispridning baserat på etiketterna zone och hostname för att sprida poddar över AZs inom en region och mellan värdar i AZs.

Anta till exempel att du har ett kluster med fyra noder där tre poddar som är märkta app: mypod-app finns i node1, node2respektive node3 . Om du vill att den inkommande distributionen ska finnas på distinkta noder så mycket som möjligt kan du använda ett manifest som liknar följande exempel:

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

Mer information om hur du konfigurerar podddistribution och förstår konsekvenserna av MaxSkewfinns i dokumentationen om Kubernetes Pod Topology. Till exempel hur nodeTaintsPolicy: Honor påverkar podddistribution.

Konfigurera AZ-medvetna nätverk

Om du har poddar som hanterar nätverkstrafik bör du belastningsutjämna trafik över flera tillgänglighetszoner för att säkerställa att din applikation är mycket tillgänglig och motståndskraftig mot fel. Du kan använda Azure Load Balancer för att distribuera inkommande trafik över noderna i AKS-klustret.

Azure Load Balancer stöder både intern och extern belastningsutjämning, och du kan konfigurera den så att den använder en standard-SKU för zonredundant belastningsutjämning. Standard-SKU:n är standard-SKU:n i AKS och stöder regional återhämtning med tillgänglighetszoner för att säkerställa att ditt program inte påverkas av ett regionfel. I händelse av ett zonfel påverkas inte en zonredundant Standard SKU-lastbalanserare av felet och gör att dina distributioner kan fortsätta att betjäna trafik från de återstående zonerna. Du kan använda en global lastbalanserare, till exempel Front Door eller Traffic Manager, eller så kan du använda lastbalanserare mellan regioner framför dina regionala AKS-kluster för att säkerställa att programmet inte påverkas av regionala fel. Information om hur du skapar en Standard SKU-lastbalanserare i AKS finns i Använda en standardlastbalanserare i Azure Kubernetes Service (AKS).

För att säkerställa att programmets nätverkstrafik är motståndskraftig mot fel bör du konfigurera AZ-medvetna nätverk för dina AKS-arbetsbelastningar. Azure erbjuder olika nätverkstjänster som stöder AZs:

• Azure VPN Gateway: Du kan distribuera VPN- och ExpressRoute-gatewayer i Azure AZs för att ge bättre återhämtning, skalbarhet och tillgänglighet för virtuella nätverksgatewayer. Mer information finns i Skapa en zonredundant virtuell nätverksgateway i tillgänglighetszoner.
• Azure Application Gateway v2: Azure Application Gateway tillhandahåller en regional L7-lastbalanserare med stöd för tillgänglighetszoner. Mer information finns i Direct Web Traffic with Azure Application Gateway (Direkt webbtrafik med Azure Application Gateway).
• Azure Front Door: Azure Front Door tillhandahåller en global L7-lastbalanserare och utnyttjar närvaropunkter (POPs) eller Azure Content Delivery Network (CDN). Mer information finns i Azure Front Door POP-platser.

Konfigurera ett zonredundant, geo-replikerat containerregister

För att säkerställa att dina containeravbildningar är mycket tillgängliga och motståndskraftiga mot fel bör du konfigurera ett zonredundant containerregister. Azure Container Registry (ACR) Premium SKU stöder geo-replikering och valfri zonredundans. De här funktionerna ger tillgänglighet och kortare svarstid för regionala åtgärder.

Säkerställa tillgänglighet och redundans för nycklar och hemligheter

Azure Key Vault innehåller flera lager av redundans för att se till att dina nycklar och hemligheter förblir tillgängliga för ditt program även om enskilda komponenter i tjänsten misslyckas, eller om Azure-regioner eller AZs inte är tillgängliga. Mer information finns i tillgänglighet och redundans för Azure Key Vault.

Använda funktioner för automatisk skalning

Du kan förbättra programmets tillgänglighet och återhämtning i AKS med hjälp av autoskalningsfunktioner, vilket hjälper dig att uppnå följande mål:

• Optimera resursutnyttjande och kostnadseffektivitet genom att skala upp eller ned baserat på processor- och minnesanvändningen för dina poddar.
• Förbättra feltoleransen och återställningen genom att lägga till fler noder eller poddar när ett zonfel inträffar.

Du kan använda HPA (Horizontal Pod Autoscaler) och Cluster Autoscaler för att implementera autoskalning i AKS. HPA skalar automatiskt antalet poddar i en distribution baserat på observerad CPU-användning, minnesanvändning, anpassade mått och mått för andra tjänster. Cluster Autoscaler justerar automatiskt antalet noder i en nodpool baserat på väntande poddar och resursbegäranden för dessa poddar.

Vägledning för klusterläge:

• AKS Automatic: Fokusera på resursbegäranden och gränser för arbetsbelastningar, principer för poddfördelning och störningskontroller så att förkonfigurerad plattformsskalning kan återställa tjänsten vid belastning i en zon.
• AKS Standard: Utforma uttryckligen nodpoolsgränser, skalningsprincip och autoskalningsinställningar för att anpassa till zonmedvetna schemaläggningsbegränsningar.

Funktionen AKS Karpenter Provider möjliggör automatisk avetablering av noder med Karpenter i AKS-klustret. Mer information finns i funktionsöversikten för AKS Karpenter Provider.

Tillägget Kubernetes Händelsedriven autoskalning (KEDA) för AKS tillämpar händelsedriven autoskalning för att skala ditt program baserat på mått för externa tjänster för att möta efterfrågan. Mer information finns i Installera KEDA-tillägget i Azure Kubernetes Service (AKS).

Strategi för zonskalning efter AKS-klusterläge

För zonmedvetna uppskalningsbeteenden justerar du din nodpoolmodell med begränsningar för schemaläggaren och ditt klusterläge.

AKS Standard

När du använder Cluster Autoscaler med tillgänglighetszoner är en vedertagen bästa praxis att ha en nodpool per zon. Du kan ställa in --balance-similar-node-groups till True för att upprätthålla en balanserad fördelning av noder mellan zoner vid uppskalning.

Varför detta är viktigt:

• Autoskalning av kluster simulerar schemaläggning efter nodpool, inte efter specifik zonplacering.
• I en nodpool med flera zoner kan uppskalning placera en ny nod i en zon som fortfarande bryter mot strikta begränsningar för topologispridning, vilket lämnar poddar väntande.
• Virtual Machine Scale Sets använder zonutjämning i möjligaste mån. Under zonkapacitetsbegränsningar eller zonavstängningshändelser kan allokeringen misslyckas och placera nodpoolen i backoff.
• Om du använder en nodpool per zon förbättras kontrollen över zonspecifikt skalningsbeteende.

Autoskalning av kluster är inte zonmedveten och zonallokering hanteras av den underliggande Virtual Machine Scale Sets och inte av AKS. Den här bästa praxis blir ännu mer relevant när du använder zonbaserade spridningsbegränsningar för poddtopologi i en enda nodpool med flera zoner, eftersom restriktiva begränsningar kan göra att poddar förblir i väntande tillstånd, särskilt i kapacitetsbegränsade regioner eller vid zonbortfall.

AKS Automatisk

AKS Automatic använder förkonfigurerat hanterat nodbeteende och standardinställningar för automatisk avetablering av noder. Du kan inte utgå från att kritiska arbetsbelastningar är zonredundanta utan en policy på arbetsbelastningsnivå.

Verifiera för kritiska tjänster:

• Poddtopologi sprider beteende mellan zoner.
• Återställningsbeteende vid zontryck.
• Schemaläggningsresultat när strikta begränsningar används.
• Programbeteende när en zon blir otillgänglig.

Utforma ett tillståndslöst program

När ett program är tillståndslöst frikopplas programlogik och data och poddarna lagrar inte några beständiga data eller sessionsdata på sina lokala diskar. Med den här designen kan programmet enkelt skalas upp eller ned utan att behöva oroa sig för dataförlust. Tillståndslösa program är mer motståndskraftiga mot fel eftersom de enkelt kan ersättas eller schemaläggas om på en annan nod i händelse av ett nodfel.

När du utformar ett tillståndslöst program med AKS bör du använda hanterade Azure-tjänster, till exempel Azure Databases, Azure Managed Redis eller Azure Storage för att lagra programdata. Genom att använda dessa tjänster säkerställer du att din trafik kan flyttas mellan noder och zoner utan att riskera dataförlust eller påverka användarupplevelsen. Du kan använda Kubernetes Deployments, tjänster och hälsoprober för att hantera tillståndslösa poddar och säkerställa jämn fördelning över zoner.

Fatta beslut om lagringsdisken

Välj rätt disktyp baserat på programbehov

Azure erbjuder två typer av diskar för beständig lagring: lokalt redundant lagring (LRS) och zonredundant lagring (ZRS). LRS replikerar dina data inom en enda AZ. ZRS replikerar dina data över flera AZs inom en region. Från och med AKS version 1.29 använder standardlagringsklassen ZRS-diskar för beständig lagring. Mer information finns i inbyggda AKS-lagringsklasser.

Hur ditt program replikerar data kan påverka ditt val av disk. Om ditt program finns i flera zoner och replikerar data från programmet kan du uppnå återhämtning med en LRS-disk i varje AZ, eftersom de andra AZ:erna skulle ha de senaste tillgängliga data om en AZ slutar fungera. Om programlagret inte hanterar sådan replikering är ZRS-diskar ett bättre val eftersom Azure hanterar replikeringen i lagringsskiktet.

I följande tabell beskrivs fördelar och nackdelar för varje disktyp:

Mer information om disktyperna LRS och ZRS finns i Azure Storage-redundans. Information om hur du etablerar lagringsdiskar i AKS finns i Etablera Azure Disks-lagring i Azure Kubernetes Service (AKS).

Övervaka diskprestanda

För att säkerställa optimal prestanda och tillgänglighet för dina lagringsdiskar i AKS bör du övervaka viktiga mått, till exempel IOPS, dataflöde och svarstid. Dessa mått kan hjälpa dig att identifiera eventuella problem eller flaskhalsar som kan påverka programmets prestanda. Om du märker några konsekventa prestandaproblem kanske du vill ompröva lagringsdiskens typ eller storlek. Du kan använda Azure Monitor för att samla in och visualisera dessa mått och konfigurera aviseringar för att meddela dig om eventuella prestandaproblem.

Mer information finns i Övervaka Azure Kubernetes Service (AKS) med Azure Monitor.

Test för AZ-motståndskraft

Metod 1: Avspärra och tömma noder i en enda AZ

Ett sätt att testa AKS-klustret för AZ-resiliens är att dränera en nod i en zon och se hur det påverkar trafiken tills den växlar över till en annan zon. Den här metoden simulerar ett verkligt scenario där en hel zon inte är tillgänglig på grund av ett haveri eller avbrott. Om du vill testa det här scenariot kan du använda kubectl drain kommandot för att korrekt avlägsna alla poddar från en nod och markera den som oplanerad. Du kan sedan övervaka klustertrafik och prestanda med hjälp av verktyg som Azure Monitor eller Prometheus.

I följande tabell beskrivs för- och nackdelar med den här metoden:

Metod 2: Simulera ett AZ-fel med Azure Chaos Studio

Ett annat sätt att testa AKS-klustrets AZ-resiliens är att införa fel i klustret och observera effekten på ditt program med hjälp av Azure Chaos Studio. Azure Chaos Studio är en tjänst som gör att du kan skapa och hantera kaosexperiment på Azure-resurser och -tjänster. Du kan använda Chaos Studio för att simulera ett AZ-fel genom att skapa ett felinmatningsexperiment som riktar sig mot en specifik zon och stoppar eller startar om de virtuella datorerna i den zonen. Du kan sedan mäta programmets tillgänglighet, svarstid och felfrekvens med hjälp av mått och loggar.

I följande tabell beskrivs för- och nackdelar med den här metoden:

Mer information finns i Vad är Azure Chaos Studio?.

Relaterat innehåll

• Vad är AKS Automatic?
• Guide till zonredundanta AKS-kluster och lagring