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:
- Medlem med en öppen löpande underhållsperiod.
- Medlem med underhållsperiod som öppnas inom de närmaste fyra timmarna.
- Medlem utan underhållsperiod.
- 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 iPending
tillstånd eller inte startas. När en medlem flyttas tillPending
försöker uppdateringskörningen uppgradera nästa medlem i gruppen. Om alla medlemmar är iPending
status flyttas gruppen tillPending
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 iPending
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 iPending
tillstånd eller inte startas. - Kör: En körning är i
Pending
tillstånd om den aktuella fasen som ska köras är iPending
tillstånd.
- Medlemskluster: Ett medlemskluster kan vara i väntande tillstånd av någon av följande orsaker och visas under meddelandefältet.
Ö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
ellerControlPlaneOnly
). - 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å.
- Alla medlemskluster identifierades som
- Steg:
- Alla grupper i fasen identifierades som
Skipped
av systemet. - Du initierade ett hopp på stegnivå.
- Alla grupper i fasen identifierades som
- Kör:
- Alla steg identifierades som
Skipped
av systemet.
- Alla steg identifierades som
- Medlem:
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 somFailed
i medlemsklustret.- Markerar alla överordnade (grupp –> fas –> körning) som
Failed
med ett sammanfattningsfelmeddelande. - Hindrar uppdateringskörningen från att fortsätta.