Uppdatera orkestrering mellan flera medlemskluster

Plattformsadministratörer som hanterar ett stort antal kluster har ofta problem med att mellanlagring av uppdateringar av flera kluster (till exempel uppgradering av nod os-avbildningsversioner, uppgradering av Kubernetes-versioner) på ett säkert och förutsägbart sätt. För att hantera den här smärtpunkten kan du med Azure Kubernetes Fleet Manager (Fleet) samordna uppdateringar över flera kluster med hjälp av uppdateringskörningar, steg, grupper och strategier.

• Uppdateringskörning: En uppdateringskörning representerar en uppdatering som tillämpas på en samling AKS-kluster, som består av uppdateringsmålet och sekvensen. Uppdateringsmålet beskriver önskade uppdateringar (till exempel uppgradering till Kubernetes version 1.28.3). Uppdateringssekvensen beskriver den exakta ordningen för att tillämpa uppdateringarna på flera medlemskluster, uttryckta med hjälp av faser och grupper. Om de är ospecificerade uppdateras alla medlemskluster en efter en sekventiellt. En uppdateringskörning kan stoppas och startas.
• Uppdateringssteg: Uppdateringskörningar är indelade i faser som tillämpas sekventiellt. En första uppdateringsfas kan till exempel uppdatera medlemskluster för testmiljön, och ett andra uppdateringssteg skulle sedan senare uppdatera medlemskluster för produktionsmiljön. En väntetid kan anges för att fördröja tillämpningen av efterföljande uppdateringssteg.
• Uppdateringsgrupp: Varje uppdateringssteg innehåller en eller flera uppdateringsgrupper som används för att välja de medlemskluster som ska uppdateras. Uppdateringsgrupper används också för att beställa program för uppdateringar till medlemskluster. I en uppdateringsfas tillämpas uppdateringar på alla olika uppdateringsgrupper parallellt. i en uppdateringsgrupp uppdateras medlemskluster sekventiellt. Varje medlemskluster i flottan kan bara ingå i en uppdateringsgrupp.
• Uppdateringsstrategi: En uppdateringsstrategi beskriver uppdateringssekvensen med steg och grupper. Du kan återanvända en strategi i dina uppdateringskörningar i stället för att definiera sekvensen upprepade gånger i varje körning.

För närvarande är de uppdateringsåtgärder som stöds i klustret uppgraderingar. Det finns tre typer av uppgraderingar som du kan välja mellan:

• Uppgradera Kubernetes-versioner för Kubernetes-kontrollplanet och noderna (vilket inkluderar uppgradering av nodbilderna).
• Uppgradera Kubernetes-versioner för endast kontrollplan för klustren
• Uppgradera endast nodbilderna.

Du kan ange kubernetes-målversionen att uppgradera till, men du kan inte ange de exakta målnodavbildningsversionerna eftersom de senaste tillgängliga nodavbildningsversionerna kan variera beroende på klustrets region (kontrollera versionsspåraren för mer information). Avbildningsversionerna för målnoden väljs automatiskt för dig baserat på dina inställningar:

• Latest: Använd de senaste nodavbildningarna som är tillgängliga i en klusterregion när uppgraderingen av klustret startar. Därför kan olika avbildningsversioner användas beroende på vilken region ett kluster finns i och när uppgraderingen faktiskt startar.
• Consistent: När uppdateringskörningen startar väljer den de senaste vanliga avbildningsversionerna i regionerna i medlemskluster i den här körningen, så att samma, konsekventa avbildningsversioner används mellan kluster.

Du bör välja Latest att använda nyare avbildningsversioner och minimera säkerhetsrisker och välja Consistent att förbättra tillförlitligheten genom att använda och verifiera dessa avbildningar i kluster i tidigare steg innan du använder dem i senare kluster.

Planerat underhåll

Uppdateringskörningar respekterar planerade underhållsperioder som du anger på klusternivån Azure Kubernetes Service (AKS).

I en uppdateringskörning (för uppdateringskörningar av typen One by one eller Faser ) prioriterar uppdateringskörningen uppgraderingen av klustren i följande ordning:

1. Medlem med en öppen löpande underhållsperiod.
2. Medlem med underhållsperiod som öppnas inom de närmaste fyra timmarna.
3. Medlem utan underhållsperiod.
4. Medlem med en stängd underhållsperiod.

Uppdatera körningstillstånd

En uppdateringskörning kan vara i något av följande tillstånd:

• NotStarted: Status för uppdateringskörningen innan den startas.

• Körs: Uppgradering pågår för minst ett av klustren i uppdateringskörningen.

• Väntar:

  • Medlemskluster: Ett medlemskluster kan vara i väntande tillstånd av någon av följande orsaker och visas under meddelandefältet.
    • Underhållsfönstret är inte öppet. Meddelandet anger nästa öppningstid.
    • Kubernetes-målversionen är ännu inte tillgänglig i medlemmens region. Meddelandelänkar till versionsspåraren så att du kan kontrollera versionens status i olika regioner.
    • Målnodens avbildningsversion är ännu inte tillgänglig i medlemmens region. Meddelandelänkar till versionsspåraren så att du kan kontrollera versionens status i olika regioner.
  • Grupp: En grupp är i Pending tillstånd om alla medlemmar i grupperna är i Pending tillstånd eller inte startas. När en medlem flyttas till Pendingförsöker uppdateringskörningen uppgradera nästa medlem i gruppen. Om alla medlemmar är i Pending status flyttas gruppen till Pending tillstånd. Alla grupper måste vara i terminaltillstånd innan de flyttas till nästa steg. Det vill säga om en grupp är i Pending tillstånd väntar uppdateringskörningen på att den ska slutföras innan den går vidare till nästa steg för körning.
  • Steg: En fas är i Pending om alla grupper under den fasen är i Pending tillstånd eller inte startas.
  • Kör: En körning är i Pending tillstånd om den aktuella fasen som ska köras är i Pending tillstånd.

• Överhoppad: Alla nivåer av en uppdateringskörning kan hoppas över och detta kan antingen vara systemdefinierad eller användarinitierad.

  • Medlem:
    • Du har hoppat över uppgraderingen för en medlem eller en av dess föräldrar.
    • Medlemsklustret finns redan i kubernetes-målversionen (om uppdateringskörningsläget är Full eller ControlPlaneOnly).
    • Medlemsklustret finns redan i kubernetes-målversionen och alla nodpooler finns i målnodens avbildningsversion.
    • När konsekvent nodavbildning väljs för en uppgraderingskörning, om det inte går att hitta målavbildningsversionen för en av nodpoolerna, hoppas uppgraderingen över för klustret. Ett exempel på detta är när en ny nodpool med en ny SKU för virtuella datorer läggs till efter att en uppdateringskörning har startats.
  • Grupp:
    • Alla medlemskluster identifierades som Skipped av systemet.
    • Du initierade ett hopp på gruppnivå.
  • Steg:
    • Alla grupper i fasen identifierades som Skipped av systemet.
    • Du initierade ett hopp på stegnivå.
  • Kör:
    • Alla steg identifierades som Skipped av systemet.

• Stoppad: Alla nivåer av en uppdateringskörning kan stoppas. Det finns två möjligheter att ange ett stoppat tillstånd:

  • Du stoppar uppdateringskörningen, då uppdateringskörningen slutar spåra alla åtgärder. Om en åtgärd redan har initierats av en uppdateringskörning (till exempel en klusteruppgradering pågår) avbryts inte den åtgärden för det enskilda klustret.
  • Om ett fel påträffas under uppdateringskörningen (till exempel om uppgraderingar misslyckades i ett av klustren) hamnar hela uppdateringskörningen i ett stopptillstånd och körs inte för något efterföljande kluster i uppdateringskörningen.

• Misslyckades: Ett fel vid uppgradering av ett kluster resulterar i följande åtgärder:

  • MemberUpdateStatus Markerar som Failed i medlemsklustret.
  • Markerar alla överordnade (grupp –> fas –> körning) som Failed med ett sammanfattningsfelmeddelande.
  • Hindrar uppdateringskörningen från att fortsätta.

Nästa steg

• Samordna uppdateringar över flera medlemskluster.