Uppdatera Kubernetes- och nodavbildningar i 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 nodoperativsystemavbildning eller Kubernetes-versioner) på ett säkert och förutsägbart sätt. För att hantera den här utmaningen kan du med Azure Kubernetes Fleet Manager (Fleet) samordna uppdateringar över flera kluster med hjälp av uppdateringskörningar.

Uppdateringskörningar består av steg, grupper och strategier och kan tillämpas antingen manuellt, för engångsuppdateringar eller automatiskt för pågående regelbundna uppdateringar med hjälp av profiler för automatisk uppgradering. Alla uppdateringskörningar (manuella eller automatiserade) respekterar underhållsperioder för medlemskluster.

Förstå uppdateringskörningar

Följande bild visualiserar en uppgraderingskörning som innehåller två uppdateringssteg, som var och en innehåller två uppdateringsgrupper med två medlemskluster. En väntetid konfigureras mellan den första och den andra etappen.

• 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 uppdateringen på flera medlemskluster, uttryckt 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 och gör att du kan återanvända en uppdateringskörningskonfiguration i stället för att definiera sekvensen upprepade gånger i varje körning. En uppdateringsstrategi innehåller inte önskade Kubernetes- eller nodbildversioner.

För närvarande är uppdateringsåtgärder som stöds i medlemskluster 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 kontrollplanet i klustren.
• Uppgradera endast nodbilderna.

Du kan ange kubernetes-målversionen att uppgradera till, men du kan inte ange den exakta målnodens avbildningsversion. Det beror på att den senaste tillgängliga nodavbildningsversionen kan variera beroende på Azure-regionen i klustret (mer information finns i AKS-versionsspåraren).

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 Azure-regionen i ett kluster när uppgraderingen av klustret startar. Därför kan olika avbildningsversioner användas beroende på vilken Azure-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 Azure-regionerna i medlemskluster i den här körningen, så att samma, konsekventa avbildningsversioner används i 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: Uppdateringskörningen har inte startats.
• Körs: Uppgradering pågår för minst ett av medlemsklusteren i uppdateringskörningen.
• Väntar:
  • Medlemskluster: Ett medlemskluster kan vara i väntande tillstånd av någon av följande orsaker som kan visas i meddelandefältet.
    • Underhållsfönstret är inte öppet. Meddelandet anger nästa öppningstid.
    • Kubernetes-målversionen är ännu inte tillgänglig i Azure-regionen för medlemmen. Meddelandelänkar till versionsspåraren så att du kan kontrollera versionens status i olika regioner.
    • Målnodens avbildningsversion är ännu inte tillgänglig i Azure-regionen för medlemmen. 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 gruppen ä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 Pendingflyttas gruppen till Pending tillstånd. Om en grupp är i Pending tillstånd väntar uppdateringskörningen på att gruppen ska slutföras innan den går vidare till nästa steg för körning.
  • Steg: En fas är i Pending tillstånd 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.
• Hoppades över: Alla nivåer i en uppdateringskörning kan hoppas över. Hoppar över kan vara system- eller användarinitierade.
  • Medlem:
    • Du hoppades över uppgraderingen för en medlem, grupp eller fas.
    • 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. Detta kan till exempel inträffa när en ny nodpool med en ny SKU för virtuell dator läggs till när 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 stoppat tillstånd. Åtgärder görs inte för 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.

Kommentar

Du kan köra en uppdateringskörning igen när som helst för att tillämpa uppgraderingar som kan ha hoppat över eller misslyckats.

Förstå profiler för automatisk uppgradering (förhandsversion)

Profiler för automatisk uppgradering används för att automatiskt utlösa uppdateringskörningar när nya Kubernetes- eller nodbildversioner görs tillgängliga för AKS.

Viktigt!

Förhandsversionsfunktionerna i Azure Kubernetes Fleet Manager är tillgängliga via självbetjäning och opt-in. Förhandsversioner tillhandahålls "som är" och "som tillgängliga", och de undantas från serviceavtalen och den begränsade garantin. Förhandsversioner av Azure Kubernetes Fleet Manager omfattas delvis av kundsupport på bästa sätt. Därför är dessa funktioner inte avsedda för produktionsanvändning.

I en profil för automatisk uppgradering kan du konfigurera:

• a Channel (Stabil, Snabb, NodeImage) som avgör vilken typ av automatisk uppgradering som tillämpas på klustren.
• en UpdateStrategy som konfigurerar sekvensen där klustren uppgraderas. Om en strategi inte tillhandahålls uppdateras kluster en efter en sekventiellt.
• NodeImageSelectionType (Senaste, konsekventa) för att ange hur nodbilden väljs när du uppgraderar Kubernetes-versionen.

Stabil kanal

Stable-kanalen är alltid den senaste AKS-stödda Kubernetes-korrigeringsversionen på delversion N-1, där N är den senaste delversionen som stöds.

Exempel:

• Den senaste kubernetes-versionen som stöds är 1.30. Eventuella korrigeringsversioner i 1,29-mindre intervall skulle övervägas för uppdateringar av stabila kanaler.
• En ny kubernetes-delversion av 1.31 publiceras. Eventuella korrigeringsversioner i 1.30-mindre intervall skulle övervägas för uppdateringar av stabila kanaler. Alla kluster som tidigare tog emot uppdateringar från 1.29 skulle uppdateras till den senaste korrigeringen för 1.30.

Snabb kanal

Rapid-kanalen är alltid den senaste aks-stödda Kubernetes-versionen.

Exempel:

• Den senaste delversionen som stöds är 1.30. Eventuella korrigeringsversioner i 1.30-mindre intervall skulle övervägas för snabba kanaluppdateringar.
• En ny kubernetes-delversion av 1.31 publiceras. 1.30 skiftar till den stabila kanalen. Alla kluster som tidigare tog emot uppdateringar från 1.30 skulle uppdateras till den senaste korrigeringen för 1.31 , som nu är Rapid-kanalen.

NodeImage-kanal

Medlemsklusternoder uppdateras med en nyligen korrigerad virtuell hårddisk som innehåller säkerhetskorrigeringar och buggkorrigeringar i en veckovis takt. Uppdateringen av den nya virtuella hårddisken är störande, efter underhållsperioder och överspänningsinställningar. Ingen extra VHD-kostnad uppstår när du väljer det här alternativet.

Om du använder den här kanalen inaktiveras obevakade Linux-uppgraderingar som standard. Nodbilduppgraderingar stöder korrigeringsversioner som är inaktuella, så länge den mindre Kubernetes-versionen fortfarande stöds. Nodbilder är AKS-testade, fullständigt hanterade och tillämpas med säkra distributionsmetoder.

Noder på olika operativsystem uppdateras i enlighet med nodavbildningsversionerna som är anpassade till dessa operativsystem.

Exempel:

• Ett kluster har noder med NodeImage av AKSWindows-2022-containerd av version 20348.2582.240716. En ny NodeImage-version 20348.2582.240916 släpps och klusternoderna uppgraderas automatiskt till version 20348.2582.240916.

Beteende för att hoppa över delversion

Automatisk uppgradering flyttar inte kluster mellan mindre Kubernetes-versioner när det finns mer än en mindre Kubernetes-versionsskillnad (till exempel: 1.28 till 1.30). Om administratörer har en mängd olika Kubernetes-versioner rekommenderar vi att du först använder en eller flera uppdateringskörningar för att föra in medlemskluster i en uppsättning konsekvent versionsversioner så att konfigurerade Stable uppdateringar eller Rapid kanaluppdateringar säkerställer att konsekvensen upprätthålls i framtiden.

Kommentar

Tänk på följande när du använder automatisk uppgradering:

• Automatisk uppgradering kräver version 1.3.0 eller senare av Fleet Azure CLI-tillägget.

• Automatisk uppgradering uppdateras endast till GA-versioner av Kubernetes och uppdateras inte till förhandsversioner.

• Automatisk uppgradering kräver att klustrets Kubernetes-version finns i AKS-supportfönstret.

• Om ett kluster inte har något definierat planerat underhållsperiod uppgraderas det omedelbart när uppdateringskörningen når klustret.

• Om du vill uppgradera Kubernetes-versionen måste du skapa en autoupgradeprofile med Rapid eller Stable kanaler.

• Om du vill att NodeImage-versionen ska uppgraderas måste du skapa en autoupgradeprofile med NodeImage kanal.

• Du kan skapa flera profiler för automatisk uppgradering för samma flotta.

Nästa steg

• Anvisningar: Uppgradera flera kluster med azure Kubernetes Fleet Manager-uppdateringskörningar.
• Anvisningar: Uppgradera automatiskt flera kluster med Azure Kubernetes Fleet Manager.