Definieren von wiederverwendbaren Updatestrategien mithilfe von Azure Kubernetes Fleet Manager

1. Navigieren Sie im Azure-Portal zu Ihrer Azure Kubernetes Fleet Manager-Ressource.

2. Wählen Sie im Dienstmenü unter EinstellungenMitgliedscluster>Hinzufügen aus.

   

3. Wählen Sie den Cluster aus, den Sie hinzufügen möchten, und wählen Sie dann Weiter: Überprüfen + Hinzufügen aus.

4. Geben Sie den Namen der Updategruppe ein, der Sie den Cluster zuweisen möchten, und wählen Sie dann Hinzufügen aus.

   

Weisen Sie einem Mitgliedercluster eine Updategruppe zu, wenn Sie den Mitgliedscluster zur Flotte hinzufügen, indem Sie den Befehl az fleet member create verwenden, wobei der Parameter --update-group auf den Namen der Updategruppe festgelegt ist.

az fleet member create \
    --resource-group $GROUP \
    --fleet-name $FLEET \
    --name member1 \
    --member-cluster-id $CLUSTERID \
    --update-group group-1a

1. Navigieren Sie im Azure-Portal zu Ihrer Azure Kubernetes Fleet Manager-Ressource.

2. Wählen Sie im Dienstmenü unter Einstellungen die Option Mitgliedscluster aus.

3. Wählen Sie die Cluster aus, den/die Sie einer Updategruppe zuweisen möchten, und wählen Sie dann Updategruppe zuweisen aus.

   

4. Geben Sie den Namen der Updategruppe ein, der Sie den Cluster zuweisen möchten, und wählen Sie dann Zuweisen aus.

   

Weisen Sie ein vorhandenes Flottenmitglied einer Updategruppe mithilfe des Befehls az fleet member update zu, wobei das --update-group Flag auf den Namen der Updategruppe festgelegt ist.

az fleet member update \
 --resource-group $GROUP \
 --fleet-name $FLEET \
 --name member1 \
 --update-group group-1

1. Navigieren Sie im Azure-Portal zu Ihrer Azure Kubernetes Fleet Manager-Ressource.

2. Wählen Sie im Dienstmenü unter EinstellungenMulticlusterupdate>Strategien und dann Erstellen aus.

3. Geben Sie einen Namen für den Server ein.

4. Wenn Sie die Seite zum ersten Mal anzeigen, wird ein Erklärungsdiagramm zur Updatestrategie angezeigt, das ihnen dabei helfen kann, zu visualisieren, wie Strategien funktionieren.

   

5. Wählen Sie Phase erstellen aus, und geben Sie Folgendes ein:

   • Der Phasenname - die Stufe benennen - muss für alle Phasennamen in der Strategie eindeutig sein.
   • (Optional) Phasengenehmigungen – Wählen Sie diese Option aus, wenn Sie vor dem Start dieser Phase oder nach Abschluss einer Genehmigung auf eine Genehmigung warten möchten. Weitere Informationen finden Sie unter Hinzufügen von Genehmigungen zum Aktualisieren von Gruppen und Phasen.
   • (Optional) Nach der Phase anhalten: Wählen Sie diese Option aus, wenn Sie eine Pause definieren möchten, bevor Sie zur nächsten Phase wechseln.
   • (Optional) Pausedauer – Wählen Sie eine vordefinierte Dauer aus, oder geben Sie einen benutzerdefinierten Wert in Sekunden ein.

   

6. Weisen Sie der Phase eine oder mehrere Aktualisierungsgruppe zu, und wählen Sie dann Erstellen aus.

   Hinweis

   Die maximale Anzahl von Updategruppen in jeder Updatephase beträgt 50.

   

In diesem Szenario erstellen wir Phasen und Gruppen, um die Details zuzuordnen, die für den Azure-Portalprozess verwendet werden.

1. Erstellen Sie eine JSON-Datei, um die Phasen und Gruppen für die Updateausführung zu definieren. Phasen werden sequenziell in der Reihenfolge ausgeführt, in der sie in der JSON-Datei angezeigt werden. Gruppen werden innerhalb jeder Phase parallel ausgeführt, daher ist die Sortierung nicht wichtig. Die folgende Beispieldatei (example-stages.json) definiert eine Strategie mit zwei Stufen und enthält optionale maxConcurrency und maxAllowedFailures Einstellungen:

   {
       "stages": [
           {
               "name": "stage-1",
               "maxConcurrency": "7",
               "maxAllowedFailures": "2",
               "groups": [
                   {
                       "name": "group-1",
                       "maxConcurrency": "3",
                       "maxAllowedFailures": "1"
                   },
                   {
                       "name": "group-2",
                       "maxConcurrency": "50%",
                       "maxAllowedFailures": "25%"
                   }
               ],
               "afterStageWaitInSeconds": 300
           },
           {
               "name": "stage-2",
               "maxConcurrency": "100%",
               "maxAllowedFailures": "0",
               "groups": [
                   {
                       "name": "group-3",
                       "maxConcurrency": "2",
                       "maxAllowedFailures": "0"
                   }
               ]
           }
       ]
   }
   

   maxConcurrency

   Das maxConcurrency Feld ist optional und steuert, wie viele Cluster gleichzeitig auf Stufe oder Gruppenebene aktualisiert werden können. Verwenden Sie einen größeren Wert, um Cluster schneller in Ihrer Flotte zu aktualisieren, oder einen kleineren Wert für einen kontrollierten Rollout, der den Strahlradius begrenzt, wenn Probleme auftreten.

   In diesem Beispiel setzt stage-1maxConcurrency auf "7", wodurch bis zu "7" Cluster in dieser Phase gleichzeitig aktualisiert werden können. Innerhalb von stage-1 und group-1 wird die Gleichzeitigkeit auf "3" Cluster begrenzt, was bedeutet, dass bis zu "3" innerhalb dieser Gruppe gleichzeitig aktualisiert werden können. group-2 ermöglicht bis zu "50%" seinen Clustern gleichzeitig ein Upgrade (z. B. wenn die Gruppe vier Cluster enthält, kann bis zu 2 gleichzeitig aktualisiert werden).

   Werte können eine feste ganze Zahl (z "3". B. ) oder ein Prozentsatz (z. B "100%". ) sein. Wenn diese Angabe weggelassen wird, wendet das System Standardwerte an. Ausführliche Informationen zur Auflösung dieser Werte und deren Obergrenzen finden Sie unter "Maximale Parallelität (Vorschau)".

   maxAllowedFailures

   Das Feld maxAllowedFailures ist optional und steuert, wie viele Fehlschläge bei der Aktualisierung von Memberclustern toleriert werden, bevor die Gruppe oder Stufe als fehlgeschlagen markiert wird. Standardmäßig (wenn nicht festgelegt oder "0") ein einzelner Fehler die gesamte Updateausführung beendet.

   Diese Einstellung wertet die Fehleranzahl nur aus. Sie erzwingt keine minimale Erfolgsquote. Eine Gruppe oder Phase kann daher auch mit Completed enden, selbst wenn einige oder alle Mitglieder ausgefallen sind, solange der Fehlerschwellenwert nicht überschritten war, als Fleet seine Planungsentscheidungen getroffen hat.

   In diesem Beispiel setzt stage-1maxAllowedFailures auf "2" und toleriert dabei bis zu zwei Ausfälle von Mitgliedern in der gesamten Phase. Innerhalb stage-1 toleriert group-1 den Ausfall von "1" und group-2 toleriert den Ausfall von "25%" seiner Mitglieder (z. B. wenn die Gruppe 4 Cluster enthält, wird der Ausfall von bis zu 1 Cluster toleriert). stage-2 legt maxAllowedFailures auf "0" fest, was bedeutet, dass jeder Fehler den Lauf sofort stoppt und dies häufig für Produktionsphasen nützlich ist.

   Bevorzugen Sie für die meisten Rollouts prozentbasierte Werte, da sie auf unterschiedlichen Gruppengrößen besser skaliert werden. Vermeiden Sie es, den Wert auf die Gesamtzahl der Mitglieder festzulegen, es sei denn, Sie möchten für dieses Segment absichtlich ein Verhalten, bei dem es praktisch „nie fehlschlägt“.

   Werte können eine feste ganze Zahl (z "3". B. ) oder ein Prozentsatz (z. B "25%". ) sein. Ausführliche Informationen dazu, wie diese Werte behoben werden, finden Sie unter Maximal zulässige Fehler (Vorschau).

2. Erstellen Sie eine neue Updatestrategie mithilfe des Befehls az fleet updatestrategy create, wobei das --stages Flag auf den Namen Ihrer JSON-Datei festgelegt ist.

   az fleet updatestrategy create \
    --resource-group $GROUP \
    --fleet-name $FLEET \
    --name $STRATEGY \
    --stages example-stages.json