Dela via


Uppgraderingsalternativ och rekommendationer för AKS-kluster (Azure Kubernetes Service)

Den här artikeln beskriver uppgraderingsalternativ för AKS-kluster och ger scenariobaserade rekommendationer för vanliga uppgraderingsutmaningar.

Uppgraderingsalternativ

Utföra manuella uppgraderingar

Med manuella uppgraderingar kan du styra när klustret uppgraderas till en ny Kubernetes-version. Användbart för att testa eller rikta in sig på en viss version.

Konfigurera automatiska uppgraderingar

Automatiska uppgraderingar håller klustret på en version som stöds och är uppdaterat. Då vill du ställa in och sedan glömma bort det.

Särskilda överväganden för nodpooler som sträcker sig över flera tillgänglighetszoner

AKS använder zonutjämning med bästa prestanda i nodgrupper. Under en uppgraderingsökning är zonerna för uppgraderingsnoder i Virtuella Maskinskalningsuppsättningar okända i förväg, vilket tillfälligt kan orsaka en obalanserad zonskonfiguration. AKS tar bort överspänningsnoder efter uppgraderingen och återställer det ursprungliga zonsaldot. För att hålla zonerna balanserade anger du överspänning till en multipel av tre noder. Datorer som använder Azure LRS-diskar är zonbundna och kan orsaka stilleståndstid om överspänningsnoder finns i en annan zon. Använd en Poddavbrottsbudget för att upprätthålla hög tillgänglighet under dräneringar.

Optimera uppgraderingar för att förbättra prestanda och minimera störningar

Kombinera fönstret Planerat underhåll, Maximal ökning av belastning, Poddavbrottsbudget, tidsgräns för noddränering och nods blötläggningstid för att öka sannolikheten för lyckade uppgraderingar med få avbrott.

Uppgraderingsinställningar Så här används extra noder Förväntat beteende
maxSurge=5, maxUnavailable=0 5 överspänningsnoder 5 noder valdes för uppgradering
maxSurge=5, maxUnavailable=0 0–4 överspänningsnoder Uppgraderingen misslyckas på grund av otillräckliga överspänningsnoder
maxSurge=0, maxUnavailable=5 Inte tillgänglig 5 befintliga noder tömda för uppgradering

Anmärkning

Innan du uppgraderar, kontrollera API-förändringar som bryter kompatibilitet och granska AKS versionsanteckningar för att undvika störningar.

Valideringar som används i uppgraderingsprocessen

AKS utför valideringar före uppgraderingen för att säkerställa klusterhälsa:

  • API-förändringar som bryter bakåtkompatibilitet: Identifierar föråldrade API:er.
  • Kubernetes-uppgraderingsversion: Säkerställer en giltig uppgraderingssökväg.
  • PDB-konfiguration: Kontrollerar felkonfigurerade PDB:er (t.ex. maxUnavailable=0).
  • Kvot: Bekräftar tillräckligt med kvot för överspänningsnoder.
  • Undernät: Verifierar tillräckligt med IP-adresser.
  • Certifikat/tjänstens huvudnamn: Identifierar utgångna autentiseringsuppgifter.

Dessa kontroller hjälper till att minimera uppgraderingsfel och ge tidig insyn i problem.

Vanliga uppgraderingsscenarier och rekommendationer

Scenario 1: Kapacitetsbegränsningar

Om klustret begränsas av SKU eller regional kapacitet kan uppgraderingar misslyckas när överbelastningsnoder inte kan etableras. Detta är vanligt med specialiserade SKU:er (t.ex. GPU-noder) eller i regioner med begränsade resurser. Fel som SKUNotAvailable, AllocationFailed, eller OverconstrainedAllocationRequest kan inträffa om maxSurge ställs in för högt för tillgänglig kapacitet.

Rekommendationer för att förhindra eller lösa

  • Använd maxUnavailable för att uppgradera med befintliga noder i stället för att använda nya. Läs mer.
  • Lägre maxSurge för att minska behovet av extra kapacitet. Läs mer.
  • För säkerhetsuppdateringar använder du säkerhetskorrigeringsåterskapningar som inte kräver överspänningsnoder. Läs mer.

Scenario 2: Nodavloppsfel och PDB:er

Uppgraderingar kräver tömning av noder (avlägsna poddar). Avlopp kan misslyckas om:

  • Poddar tar lång tid att avsluta (långa stopparkrokar eller beständiga anslutningar).
  • Strikta poddavbrottsbudgetar (PDB) blockerar borttagning av poddar.

Exempel på felmeddelande:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... failed with Too Many Requests error. This is often caused by a restrictive Pod Disruption Budget (PDB) policy. See https://aka.ms/aks/debugdrainfailures. Original error: Cannot evict pod as it would violate the pod's disruption budget. PDB debug info: ... blocked by pdb ... with 0 unready pods.

Rekommendationer för att förhindra eller lösa

  • Ange maxUnavailable i PDF-filer så att minst en podd kan avlägsnas.

  • Öka poddrepliker så att avbrottsbudgeten kan tolerera utvisningar.

  • Använd undrainableNodeBehavior för att tillåta uppgraderingar att fortsätta även om vissa noder inte kan tömmas:

    • Schema (standard): Nod- och överspänningsersättning kan tas bort, vilket minskar kapaciteten.
    • Avspärrning (rekommenderas): Noden är avspärrad och märkt som kubernetes.azure.com/upgrade-status=Quarantined.
      • Exempelkommando:

        az aks nodepool update \
          --resource-group <resource-group-name> \
          --cluster-name <cluster-name> \
          --name <node-pool-name> \
          --undrainable-node-behavior Cordon
        

        I följande exempelutdata visas det uppdaterade beteendet hos den odränerbara noden:

        "upgradeSettings": {
        "drainTimeoutInMinutes": null,
        "maxSurge": "1",
        "nodeSoakDurationInMinutes": null,
        "undrainableNodeBehavior": "Cordon"
        }
        
  • Utöka tidsgränsen för avlopp om arbetsbelastningar behöver mer tid (standardvärdet är 30 minuter).

  • Testa PDB:er i stagingmiljön, övervaka uppgraderingshändelser och använd blågröna distributioner för kritiska arbetslaster. Läs mer.

Verifiera icke-dränerbara noder

  • De blockerade noderna är inte schemalagda för poddar och markerade med etiketten "kubernetes.azure.com/upgrade-status: Quarantined".

  • Kontrollera etiketten på alla blockerade noder när det uppstår ett fel på dräneringsnoden vid uppgraderingen:

    kubectl get nodes --show-labels=true
    

Lösa oanvändbara noder

  1. Ta bort det ansvariga PDB:et:

    kubectl delete pdb <pdb-name>
    
  2. kubernetes.azure.com/upgrade-status: Quarantined Ta bort etiketten:

    kubectl label nodes <node-name> <label-name>
    
  3. Du kan också ta bort den blockerade noden:

    az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>
    
  4. När du har slutfört det här steget kan du stämma av klusterstatusen genom att utföra en uppdateringsåtgärd utan de valfria fälten enligt beskrivningen här. Du kan också skala nodpoolen till samma antal noder som antalet uppgraderade noder. Den här åtgärden säkerställer att nodpoolen når sin ursprungliga storlek. AKS prioriterar borttagningen av blockerade noder. Det här kommandot återställer även klusteretableringsstatusen till Succeeded. I det angivna 2 exemplet är det totala antalet uppgraderade noder.

    # Update the cluster to restore the provisioning status
    az aks update --resource-group <resource-group-name> --name <cluster-name>
    
    # Scale the node pool to restore the original size
    az aks nodepool scale --resource-group <resource-group-name> --cluster-name <cluster-name> --name <node-pool-name> --node-count 2
    

Scenario 3: Långsamma uppgraderingar

Uppgraderingar kan fördröjas av konservativa inställningar eller problem på nodnivå, vilket påverkar din förmåga att hålla dig uppdaterad med korrigeringar och förbättringar.

Vanliga orsaker till långsamma uppgraderingar är:

  • Låg maxSurge eller maxUnavailable värden (begränsar parallellitet).
  • Långa väntetider (långa pauser mellan noduppgraderingar).
  • Dräneringsfel (se Nodavloppsfel]).

Rekommendationer för att förhindra eller lösa

  • För produktion: maxSurge=33%, maxUnavailable=1.
  • För dev/test: maxSurge=50%, maxUnavailable=2.
  • Använd OS-säkerhetsuppdatering för snabb, riktad korrigering (undviker fullständig nodomavbildning).
  • Aktivera undrainableNodeBehavior för att undvika uppgraderingsblockerare.

Scenario 4: IP-överbelastning

Överspänningsnoder kräver ytterligare IP-adresser. Om undernätet är nära kapacitet kan nodetablering misslyckas (t.ex. Error: SubnetIsFull). Det här är vanligt med hög resursanvändning för Azure CNI eller vid stora mängder noder.

Rekommendationer för att förhindra eller lösa

  • Se till att ditt undernät har tillräckligt med IP-adresser för alla noder, överspänningsnoder och poddar:

    • Formel: Total IPs = (Number of nodes + maxSurge) * (1 + maxPods)
  • Frigör oanvända IP-adresser eller expandera undernätet (t.ex. från /24 till /22).

  • Lägre maxSurge om det inte går att utöka undernätet:

    az aks nodepool update \
      --resource-group <resource-group-name> \
      --cluster-name <cluster-name> \
      --name <node-pool-name> \
      --max-surge 10%
    
  • Övervaka IP-användning med Azure Monitor eller anpassade aviseringar.

  • Minska maxPods per nod, rensa överblivna ip-adresser för lastbalanserare och planera undernätsstorlek för storskaliga kluster.


Nästa steg

  • Läs AKS-korrigerings- och uppgraderingsvägledningen för bästa praxis och planeringstips innan du påbörjar en uppgradering.
  • Sök alltid efter API-brytande ändringar och kontrollera arbetsbelastningarnas kompatibilitet med den version av Kubernetes som ni siktar på att använda.
  • Testa uppgraderingsinställningar (till exempel maxSurge, maxUnavailableoch PDB) i en mellanlagringsmiljö för att minimera produktionsrisken.
  • Övervaka uppgraderingshändelser och klusterhälsa under hela processen.