Indeling bijwerken in meerdere lidclusters

Platformbeheerders die een groot aantal clusters beheren, hebben vaak problemen met het faseren van de updates van meerdere clusters (bijvoorbeeld het upgraden van installatiekopieversies van het knooppuntbesturingssysteem, het upgraden van Kubernetes-versies) op een veilige en voorspelbare manier. Om dit pijnpunt te verhelpen, kunt u met Azure Kubernetes Fleet Manager (Fleet) updates in meerdere clusters organiseren met behulp van updateuitvoeringen, fasen, groepen en strategieën.

• Updateuitvoering: Een updateuitvoering vertegenwoordigt een update die wordt toegepast op een verzameling AKS-clusters, bestaande uit het updatedoel en de volgorde. Het updatedoel beschrijft de gewenste updates (bijvoorbeeld upgraden naar Kubernetes versie 1.28.3). De updatereeks beschrijft de exacte volgorde om de updates toe te passen op meerdere lidclusters, uitgedrukt in fasen en groepen. Indien niet opgegeven, worden alle lidclusters één voor één bijgewerkt. Een updateuitvoering kan worden gestopt en gestart.
• Updatefase: Updateuitvoeringen zijn onderverdeeld in fasen, die opeenvolgend worden toegepast. Een eerste updatefase kan bijvoorbeeld testomgevinglidclusters bijwerken en vervolgens een tweede updatefase de clusters van leden van de productieomgeving bijwerken. Er kan een wachttijd worden opgegeven om te vertragen tussen de toepassing van volgende updatefasen.
• Updategroep: Elke updatefase bevat een of meer updategroepen, die worden gebruikt om de lidclusters te selecteren die moeten worden bijgewerkt. Updategroepen worden ook gebruikt om de toepassing van updates voor lidclusters te orden. Binnen een updatefase worden updates parallel toegepast op alle verschillende updategroepen; binnen een updategroep worden lidclusters opeenvolgend bijgewerkt. Elk lidcluster van de vloot kan slechts deel uitmaken van één updategroep.
• Updatestrategie: Een updatestrategie beschrijft de updatevolgorde met fasen en groepen. U kunt een strategie in uw updateuitvoeringen opnieuw gebruiken in plaats van de volgorde herhaaldelijk in elke uitvoering te definiëren.

Momenteel zijn de ondersteunde updatebewerkingen op het cluster upgrades. Er zijn drie soorten upgrades waaruit u kunt kiezen:

• Voer een upgrade uit van Kubernetes-versies voor het Kubernetes-besturingsvlak en de knooppunten (waaronder het upgraden van de installatiekopieën van knooppunten).
• Kubernetes-versies upgraden voor alleen de besturingsvlakken van de clusters
• Alleen de knooppuntinstallatiekopieën bijwerken.

U kunt de Kubernetes-doelversie opgeven waarnaar u een upgrade wilt uitvoeren, maar u kunt niet de exacte versies van de doelknooppuntinstallatiekopieën opgeven omdat de meest recente versies van de beschikbare knooppuntinstallatiekopieën kunnen variëren, afhankelijk van de regio van het cluster (raadpleeg releasetracker voor meer informatie). De versies van de doelknooppuntinstallatiekopieën worden automatisch voor u geselecteerd op basis van uw voorkeuren:

• Latest: Gebruik de meest recente knooppuntinstallatiekopieën die beschikbaar zijn in de regio van een cluster wanneer de upgrade van het cluster wordt gestart. Als gevolg hiervan kunnen verschillende versies van installatiekopieën worden gebruikt, afhankelijk van de regio waarin een cluster zich bevindt en wanneer de upgrade daadwerkelijk wordt gestart.
• Consistent: Wanneer de updateuitvoering wordt gestart, worden de meest recente algemene installatiekopieversies gekozen in de regio's van de lidclusters in deze uitvoering, zodat dezelfde, consistente installatiekopieversies in clusters worden gebruikt.

U moet ervoor kiezen Latest om nieuwere versies van installatiekopieën te gebruiken en beveiligingsrisico's te minimaliseren en ervoor te kiezen Consistent om de betrouwbaarheid te verbeteren door deze installatiekopieën in clusters in eerdere fasen te gebruiken voordat u deze in latere clusters gebruikt.

Gepland onderhoud

Update voert geplande onderhoudsvensters uit die u hebt ingesteld op het niveau van het AKS-cluster (Azure Kubernetes Service).

Binnen een updateuitvoering (voor updateuitvoeringen van het type One voor één of Fasen ) geeft de updateuitvoering prioriteit aan het bijwerken van de clusters in de volgende volgorde:

1. Lid met een open doorlopend onderhoudsvenster.
2. Lid met onderhoudsvenster openen in de komende vier uur.
3. Lid zonder onderhoudsvenster.
4. Lid met een gesloten onderhoudsvenster.

Uitvoeringsstatussen bijwerken

Een updateuitvoering kan een van de volgende statussen hebben:

• NotStarted: Status van de updateuitvoering voordat deze wordt gestart.

• Wordt uitgevoerd: Er wordt een upgrade uitgevoerd voor ten minste één van de clusters in de updateuitvoering.

• In behandeling:

  • Lidcluster: Een lidcluster kan om een van de volgende redenen in behandeling zijn en worden weergegeven onder het berichtveld.
    • Het onderhoudsvenster is niet geopend. Bericht geeft de volgende openingstijd aan.
    • De doelversie van Kubernetes is nog niet beschikbaar in de regio van het lid. Berichtkoppelingen naar de releasetracker, zodat u de status van de release in verschillende regio's kunt controleren.
    • Versie van doelknooppuntinstallatiekopieën is nog niet beschikbaar in de regio van het lid. Berichtkoppelingen naar de releasetracker, zodat u de status van de release in verschillende regio's kunt controleren.
  • Groep: Een groep heeft Pending de status als alle leden in de groepen de status hebben of niet zijn Pending gestart. Wanneer een lid naartoe Pendingwordt verplaatst, probeert de updateuitvoering het volgende lid in de groep bij te werken. Als alle leden de Pending status hebben, wordt de groep verplaatst naar Pending de status. Alle groepen moeten de terminalstatus hebben voordat ze naar de volgende fase gaan. Als een groep de Pending status heeft, wacht de updateuitvoering totdat deze is voltooid voordat deze naar de volgende fase voor uitvoering gaat.
  • Fase: Een fase bevindt zich als Pending alle groepen in die fase de status hebben of niet zijn Pending gestart.
  • Uitvoeren: Een uitvoering heeft Pending de status als de huidige fase die moet worden uitgevoerd, de Pending status heeft.

• Overgeslagen: alle niveaus van een updateuitvoering kunnen worden overgeslagen en dit kan door het systeem worden gedetecteerd of door de gebruiker geïnitieerd.

  • Lid:
    • U hebt de upgrade voor een lid of een van de ouders overgeslagen.
    • Lidcluster bevindt zich al in de kubernetes-doelversie (als de update-uitvoeringsmodus is Full of ControlPlaneOnly).
    • Het lidcluster bevindt zich al in de kubernetes-doelversie en alle knooppuntgroepen bevinden zich in de versie van de doelknooppuntinstallatiekopieën.
    • Wanneer er een consistente knooppuntinstallatiekopieën worden gekozen voor een upgradeuitvoering, als het niet mogelijk is om de versie van de doelinstallatiekopieën voor een van de knooppuntgroepen te vinden, wordt de upgrade voor dat cluster overgeslagen. Een voorbeeld hiervan is wanneer een nieuwe knooppuntgroep met een nieuwe VM-SKU wordt toegevoegd nadat een update-uitvoering is gestart.
  • Groep:
    • Alle lidclusters zijn gedetecteerd als Skipped door het systeem.
    • U hebt een skip gestart op groepsniveau.
  • Fase:
    • Alle groepen in de fase zijn gedetecteerd als Skipped door het systeem.
    • U hebt een skip gestart op faseniveau.
  • Uitvoeren:
    • Alle fasen zijn gedetecteerd zoals Skipped door het systeem.

• Gestopt: alle niveaus van een updateuitvoering kunnen worden gestopt. Er zijn twee mogelijkheden voor het invoeren van een gestopte status:

  • U stopt de updateuitvoering, waarna de updateuitvoering stopt met het bijhouden van alle bewerkingen. Als een bewerking al is gestart door de updateuitvoering (bijvoorbeeld een clusterupgrade wordt uitgevoerd), wordt die bewerking niet afgebroken voor dat afzonderlijke cluster.
  • Als er een fout optreedt tijdens de updateuitvoering (bijvoorbeeld upgrades die zijn mislukt op een van de clusters), wordt de volledige updateuitvoering uitgevoerd in een stopstatus en wordt er geen poging uitgevoerd voor een volgend cluster in de updateuitvoering.

• Mislukt: een mislukte upgrade van een cluster leidt tot de volgende acties:

  • Hiermee markeert u de MemberUpdateStatus status Failed op het lidcluster.
  • Markeert alle ouders (groep -> fase -> uitvoeren) als Failed met een samenvattingsfoutbericht.
  • Hiermee wordt de updateuitvoering niet verder uitgevoerd.

Volgende stappen

• Updates in meerdere lidclusters indelen.