Kontrolle der Clusterreihenfolge für die Ressourcenplatzierung

az fleet member update \
    --resource-group $GROUP \
    --fleet-name $FLEET_NAME \
    --name member2 \
    --labels environment=staging

Vorbereiten von Kubernetes-Workloads für die Platzierung

Veröffentlichen Sie Kubernetes-Workloads im Hubcluster, damit sie in Mitgliedscluster platziert werden können.

Erstellen Sie einen Namespace und eine ConfigMap für die Workload im Hub-Cluster:

kubectl create namespace test-namespace
kubectl create configmap test-cm --from-literal=key=value1 -n test-namespace

Um die Ressourcen bereitzustellen, erstellen Sie folgendes ClusterResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: example-placement
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-namespace
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: External

Alle drei Cluster sollten geplant werden, da die PickAll-Richtlinie angewendet wird. Es sollten jedoch noch keine Ressourcen in den Mitgliedsclustern bereitgestellt werden, da Sie noch keinen ClusterStagedUpdateRun erstellt haben.

Überprüfen Sie, ob die Platzierung geplant ist:

kubectl get clusterresourceplacement example-placement

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                GEN   SCHEDULED   SCHEDULED-GEN   AVAILABLE   AVAILABLE-GEN   AGE
example-placement   1     True        1                                           51s

Erstellen einer mehrstufigen Updatestrategie

A ClusterStagedUpdateStrategy definiert das Orchestrierungsmuster, das Cluster in Phasen gruppiert und die Rolloutsequenz angibt. Sie wählt Mitgliedscluster nach Bezeichnungen aus. In dieser Demo erstellen Sie eine Strategie mit den beiden Phasen Staging und Canary:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterStagedUpdateStrategy
metadata:
  name: example-strategy
spec:
  stages:
    - name: staging
      labelSelector:
        matchLabels:
          environment: staging
      afterStageTasks:
        - type: TimedWait
          waitTime: 1m
      maxConcurrency: 1
    - name: canary
      labelSelector:
        matchLabels:
          environment: canary
      sortingLabelKey: order
      beforeStageTasks:
        - type: Approval
      maxConcurrency: 50%

Arbeiten mit Ressourcensnapshots

Fleet Manager erstellt Ressourcen-Snapshots, wenn sich Ressourcen ändern, wenn die Platzierung eine Rollout-Strategie von RollingUpdate hat. Jede Momentaufnahme verfügt über einen eindeutigen Index, den Sie verwenden können, um auf bestimmte Versionen Ihrer Ressourcen zu verweisen.

Wenn eine Platzierung die Rollout-Strategie External verwendet, werden Ressourcen-Snapshots nicht automatisch erstellt. Stattdessen werden sie erstellt, wenn Sie eine mehrstufige Updateausführung ausführen. Dies bedeutet, dass beim ersten Erstellen einer Platzierung mit einer External Rolloutstrategie keine Ressourcenschnappschüsse vorhanden sind, bis der erste mehrstufige Update-Lauf ausgeführt wird.

Überprüfung der aktuellen Ressourcenschnappschüsse

Da die ClusterResourcePlacementExternal-Strategie verwendet wird, sind noch keine Ressourcenschnappschüsse vorhanden. Überprüfen wir Folgendes:

kubectl get clusterresourcesnapshots --show-labels

Ihre Ausgabe sollte keine Ressourcen anzeigen:

No resources found

Erstellen Sie den ersten Ressourcenschnappschuss

Um den ersten Ressourcen Snapshot zu erstellen, müssen Sie einen ClusterStagedUpdateRun erstellen, wobei das Feld resourceSnapshotIndex weggelassen wird. Der Updateausführungscontroller erkennt, dass keine Momentaufnahmen vorhanden sind, und erstellt automatisch eine.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterStagedUpdateRun
metadata:
  name: example-initial-run
spec:
  placementName: example-placement
  stagedRolloutStrategyName: example-strategy
  state: Run

Überprüfen Sie die Ressourcenschnappschüsse, nachdem der Updatevorgang abgeschlossen ist.

kubectl get clusterresourcesnapshots --show-labels

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                           GEN   AGE   LABELS
example-placement-0-snapshot   1     60s   kubernetes-fleet.io/is-latest-snapshot=true,kubernetes-fleet.io/parent-CRP=example-placement,kubernetes-fleet.io/resource-index=0

Sie verfügen jetzt über eine Version der Momentaufnahme. Dies ist das aktuellste (kubernetes-fleet.io/is-latest-snapshot=true) und hat den Ressourcenindex 0 (kubernetes-fleet.io/resource-index=0).

Neue Ressourcen-Snapshot erstellen

Ändern Sie nun die ConfigMap mit einem neuen Wert:

kubectl edit configmap test-cm -n test-namespace

Ändern Sie den Wert von value1 in value2:

kubectl get configmap test-cm -n test-namespace -o yaml

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

apiVersion: v1
data:
  key: value2 # value updated here, old value: value1
kind: ConfigMap
metadata:
  creationTimestamp: ...
  name: test-cm
  namespace: test-namespace
  resourceVersion: ...
  uid: ...

Da die Platzierung die Strategie External verwendet, wird der neue Ressourcen-Snapshot nicht automatisch erstellt. Erstellen Sie ein weiteres ClusterStagedUpdateRun Feld, bei dem das resourceSnapshotIndex Feld weggelassen wird, um die Erstellung einer neuen Momentaufnahme auszulösen:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterStagedUpdateRun
metadata:
  name: example-snapshot-run
spec:
  placementName: example-placement
  stagedRolloutStrategyName: example-strategy
  state: Run

Nach Abschluss der Aktualisierung sollten zwei Versionen von Ressourcensnapshots mit den Indizes 0 und 1 angezeigt werden, wobei die neueste die Indexnummer 1 hat.

kubectl get clusterresourcesnapshots --show-labels

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                           GEN   AGE    LABELS
example-placement-0-snapshot   1     2m6s   kubernetes-fleet.io/is-latest-snapshot=false,kubernetes-fleet.io/parent-CRP=example-placement,kubernetes-fleet.io/resource-index=0
example-placement-1-snapshot   1     10s    kubernetes-fleet.io/is-latest-snapshot=true,kubernetes-fleet.io/parent-CRP=example-placement,kubernetes-fleet.io/resource-index=1

Die neueste Label lautet example-placement-1-snapshot, das die neuesten ConfigMap-Daten enthält.

kubectl get clusterresourcesnapshots example-placement-1-snapshot -o yaml

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourceSnapshot
metadata:
  annotations:
    kubernetes-fleet.io/number-of-enveloped-object: "0"
    kubernetes-fleet.io/number-of-resource-snapshots: "1"
    kubernetes-fleet.io/resource-hash: 10dd7a3d1e5f9849afe956cfbac080a60671ad771e9bda7dd34415f867c75648
  creationTimestamp: "2025-07-22T21:26:54Z"
  generation: 1
  labels:
    kubernetes-fleet.io/is-latest-snapshot: "true"
    kubernetes-fleet.io/parent-CRP: example-placement
    kubernetes-fleet.io/resource-index: "1"
  name: example-placement-1-snapshot
  ownerReferences:
  - apiVersion: placement.kubernetes-fleet.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: ClusterResourcePlacement
    name: example-placement
    uid: e7d59513-b3b6-4904-864a-c70678fd6f65
  resourceVersion: "19994"
  uid: 79ca0bdc-0b0a-4c40-b136-7f701e85cdb6
spec:
  selectedResources:
  - apiVersion: v1
    kind: Namespace
    metadata:
      labels:
        kubernetes.io/metadata.name: test-namespace
      name: test-namespace
    spec:
      finalizers:
      - kubernetes
  - apiVersion: v1
    data:
      key: value2 # latest value: value2, old value: value1
    kind: ConfigMap
    metadata:
      name: test-cm
      namespace: test-namespace

Vorbereitung eines gestaffelten Update-Laufs zur Einführung von Änderungen

Ein ClusterStagedUpdateRun führt den Rollout eines ClusterResourcePlacement gefolgt von einer ClusterStagedUpdateStrategy durch. Um den gestuften Aktualisierungsdurchlauf für unser ClusterResourcePlacement (CRP) auszulösen, erstellen wir einen ClusterStagedUpdateRun, in dem wir den CRP-Namen, den Namen der updateRun-Strategie, den Index des neuesten Ressourcen-Snapshot („1“) sowie den Status „Initialize“ angeben.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterStagedUpdateRun
metadata:
  name: example-run
spec:
  placementName: example-placement
  resourceSnapshotIndex: "1"
  stagedRolloutStrategyName: example-strategy
  state: Initialize

Die mehrstufige Update-Ausführung wird initialisiert, aber nicht ausgeführt.

kubectl get clusterstagedupdaterrun example-run

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME          PLACEMENT           RESOURCE-SNAPSHOT-INDEX   POLICY-SNAPSHOT-INDEX   INITIALIZED   SUCCEEDED   AGE
example-run   example-placement   1                         0                       True                      7s

Starten einer mehrstufigen Updateausführung

Um die Ausführung eines mehrstufigen Updates zu starten, müssen Sie das state Feld in der Spezifikation Runauf Folgendes patchen:

kubectl patch clusterstagedupdaterrun example-run --type merge -p '{"spec":{"state":"Run"}}'

Der gestaffelte Updatevorgang wird initialisiert und ausgeführt:

kubectl get clusterstagedupdaterrun example-run

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME          PLACEMENT           RESOURCE-SNAPSHOT-INDEX   POLICY-SNAPSHOT-INDEX   INITIALIZED   SUCCEEDED   AGE
example-run   example-placement   1                         0                       True                      7s

Ein detaillierterer Blick auf den Status nach ablaufen einer Minute TimedWait :

kubectl get clusterstagedupdaterrun example-run -o yaml

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterStagedUpdateRun
metadata:
  ...
  name: example-run
  ...
spec:
  placementName: example-placement
  resourceSnapshotIndex: "1"
  stagedRolloutStrategyName: example-strategy
  state: Run
status:
  conditions:
  - lastTransitionTime: "2025-07-22T21:28:08Z"
    message: ClusterStagedUpdateRun initialized successfully
    observedGeneration: 2
    reason: UpdateRunInitializedSuccessfully
    status: "True" # the updateRun is initialized successfully
    type: Initialized
  - lastTransitionTime: "2025-07-22T21:29:53Z"
    message: The updateRun is waiting for after-stage tasks in stage canary to complete
    observedGeneration: 2
    reason: UpdateRunWaiting
    status: "False" # the updateRun is still progressing and waiting for approval
    type: Progressing
  deletionStageStatus:
    clusters: [] # no clusters need to be cleaned up
    stageName: kubernetes-fleet.io/deleteStage
  policyObservedClusterCount: 3 # number of clusters to be updated
  policySnapshotIndexUsed: "0"
  resourceSnapshotIndexUsed: "1"
  stagedUpdateStrategySnapshot: # snapshot of the strategy used for this update run
    stages:
    - afterStageTasks:
      - type: TimedWait
        waitTime: 1m0s
      labelSelector:
        matchLabels:
          environment: staging
      maxConcurrency: 1
      name: staging
    - beforeStageTasks:
      - type: Approval
      labelSelector:
        matchLabels:
          environment: canary
      maxConcurrency: 50%
      name: canary
      sortingLabelKey: order
  stagesStatus: # detailed status for each stage
  - afterStageTaskStatus:
    - conditions:
      - lastTransitionTime: "2025-07-22T21:29:23Z"
        message: Wait time elapsed
        observedGeneration: 2
        reason: StageTaskWaitTimeElapsed
        status: "True" # the wait after-stage task has completed
        type: WaitTimeElapsed
      type: TimedWait
    clusters:
    - clusterName: member2 # stage staging contains member2 cluster only
      conditions:
      - lastTransitionTime: "2025-07-22T21:28:08Z"
        message: Cluster update started
        observedGeneration: 2
        reason: ClusterUpdatingStarted
        status: "True"
        type: Started
      - lastTransitionTime: "2025-07-22T21:28:23Z"
        message: Cluster update completed successfully
        observedGeneration: 2
        reason: ClusterUpdatingSucceeded
        status: "True" # member2 is updated successfully
        type: Succeeded
    conditions:
    - lastTransitionTime: "2025-07-22T21:28:23Z"
      message: All clusters in the stage are updated and after-stage tasks are completed
      observedGeneration: 2
      reason: StageUpdatingSucceeded
      status: "False"
      type: Progressing
    - lastTransitionTime: "2025-07-22T21:29:23Z"
      message: Stage update completed successfully
      observedGeneration: 2
      reason: StageUpdatingSucceeded
      status: "True" # stage staging has completed successfully
      type: Succeeded
    endTime: "2025-07-22T21:29:23Z"
    stageName: staging
    startTime: "2025-07-22T21:28:08Z"
  - beforeStageTaskStatus:
    - approvalRequestName: example-run-before-canary # ClusterApprovalRequest name for this stage for before stage task
      conditions:
      - lastTransitionTime: "2025-07-22T21:29:53Z"
        message: ClusterApprovalRequest is created
        observedGeneration: 2
        reason: StageTaskApprovalRequestCreated
        status: "True"
        type: ApprovalRequestCreated
      type: Approval
    conditions:
    - lastTransitionTime: "2025-07-22T21:29:53Z"
      message: Not all before-stage tasks are completed, waiting for approval
      observedGeneration: 2
      reason: StageUpdatingWaiting
      status: "False" # stage canary is waiting for approval task completion
      type: Progressing
    stageName: canary
    startTime: "2025-07-22T21:29:23Z"

Wir können sehen, dass die TimedWait-Periode für die Staging Stage abläuft und dass das ClusterApprovalRequest-Objekt für die Genehmigungs-Aufgabe in der Canary Stage erstellt wurde. Wir können die generierte ClusterApprovalRequest überprüfen und feststellen, dass sie noch niemand genehmigt hat.

kubectl get clusterapprovalrequest

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                        UPDATE-RUN    STAGE    APPROVED   APPROVALACCEPTED   AGE
example-run-before-canary   example-run   canary                                 2m39s

Genehmigen Sie die Ausführung des mehrstufigen Updates

Wir können die ClusterApprovalRequest Datei genehmigen, indem wir eine JSON-Patchdatei erstellen und anwenden:

cat << EOF > approval.json
"status": {
    "conditions": [
        {
            "lastTransitionTime": "$(date -u +%Y-%m-%dT%H:%M:%SZ)",
            "message": "lgtm",
            "observedGeneration": 1,
            "reason": "testPassed",
            "status": "True",
            "type": "Approved"
        }
    ]
}
EOF

Hinweis: Stellen Sie sicher, dass observedGeneration mit der Generation des Genehmigungsobjekts übereinstimmt.

Senden Sie eine Patchanforderung, um sie mithilfe der erstellten JSON-Datei zu genehmigen.

kubectl patch clusterapprovalrequests example-run-before-canary --type='merge' --subresource=status --patch-file approval.json

Überprüfen Sie dann, ob Sie die Anforderung genehmigt haben:

kubectl get clusterapprovalrequest

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                        UPDATE-RUN    STAGE    APPROVED   APPROVALACCEPTED   AGE
example-run-before-canary   example-run   canary   True       True               3m35s

Der ClusterStagedUpdateRun kann jetzt fortgesetzt und abgeschlossen werden:

kubectl get clusterstagedupdaterrun example-run

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME          PLACEMENT           RESOURCE-SNAPSHOT-INDEX   POLICY-SNAPSHOT-INDEX   INITIALIZED   SUCCEEDED   AGE
example-run   example-placement   1                         0                       True          True        5m28s

Überprüfung des Abschlusses des Rollouts

Dies ClusterResourcePlacement zeigt auch, dass der Rollout abgeschlossen ist und Ressourcen in allen Mitgliedsclustern verfügbar sind:

kubectl get clusterresourceplacement example-placement

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                GEN   SCHEDULED   SCHEDULED-GEN   AVAILABLE   AVAILABLE-GEN   AGE
example-placement   1     True        1               True        1               8m55s

ConfigMap test-cm soll auf allen drei Member Clustern mit den neuesten Daten bereitgestellt werden.

apiVersion: v1
data:
  key: value2
kind: ConfigMap
metadata:
  ...
  name: test-cm
  namespace: test-namespace
  ...

Beenden einer mehrstufigen Updateausführung

Um die Ausführung eines laufenden gestuften Update-Durchlaufs zu beenden, müssen Sie das state-Feld in der Spezifikation auf Stop patchen. Diese Aktion sorgt für ein kontrolliertes Anhalten des Aktualisierungsdurchlaufs, sodass Cluster, die laufende Aktualisierungen durchführen, diese abschließen können, bevor der gesamte Ausrollvorgang gestoppt wird:

kubectl patch clusterstagedupdaterun example-run --type merge -p '{"spec":{"state":"Stop"}}'

Der gestufte Aktualisierungslauf ist initialisiert und wird nicht mehr ausgeführt:

kubectl get clusterstagedupdaterun example-run

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME          PLACEMENT           RESOURCE-SNAPSHOT-INDEX   POLICY-SNAPSHOT-INDEX   INITIALIZED   SUCCEEDED   AGE
example-run   example-placement   1                         0                       True                      7s

Ein detaillierterer Blick auf den Status, nachdem die Updateausführung beendet wurde:

kubectl get clusterstagedupdaterun example-run -o yaml

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterStagedUpdateRun
metadata:
  ...
  name: example-run
  ...
spec:
  placementName: example-placement
  resourceSnapshotIndex: "1"
  stagedRolloutStrategyName: example-strategy
  state: Stop
status:
  conditions:
  - lastTransitionTime: "2025-07-22T21:28:08Z"
    message: ClusterStagedUpdateRun initialized successfully
    observedGeneration: 3
    reason: UpdateRunInitializedSuccessfully
    status: "True" # the updateRun is initialized successfully
    type: Initialized
  - lastTransitionTime: "2025-07-22T21:28:23Z"
    message: The update run has been stopped
    observedGeneration: 3
    reason: UpdateRunStopped
    status: "False" # the updateRun has stopped progressing
    type: Progressing
  deletionStageStatus:
    clusters: [] # no clusters need to be cleaned up
    stageName: kubernetes-fleet.io/deleteStage
  policyObservedClusterCount: 3 # number of clusters to be updated
  policySnapshotIndexUsed: "0"
  resourceSnapshotIndexUsed: "1"
  stagedUpdateStrategySnapshot: # snapshot of the strategy used for this update run
    stages:
    - afterStageTasks:
      - type: TimedWait
        waitTime: 1m0s
      labelSelector:
        matchLabels:
          environment: staging
      maxConcurrency: 1
      name: staging
    - beforeStageTasks:
      - type: Approval
      labelSelector:
        matchLabels:
          environment: canary
      maxConcurrency: 50%
      name: canary
      sortingLabelKey: order
  stagesStatus: # detailed status for each stage
  - clusters:
    - clusterName: member2 # stage staging contains member2 cluster only
      conditions:
      - lastTransitionTime: "2025-07-22T21:28:08Z"
        message: Cluster update started
        observedGeneration: 3
        reason: ClusterUpdatingStarted
        status: "True"
        type: Started
      - lastTransitionTime: "2025-07-22T21:28:23Z"
        message: Cluster update completed successfully
        observedGeneration: 3
        reason: ClusterUpdatingSucceeded
        status: "True" # member2 is updated successfully
        type: Succeeded
    conditions:
    - lastTransitionTime: "2025-07-22T21:28:23Z"
      message: All the updating clusters have finished updating, the stage is now stopped, waiting to be resumed
      observedGeneration: 3
      reason: StageUpdatingStopped
      status: "False"
      type: Progressing
    stageName: staging
    startTime: "2025-07-22T21:28:08Z"

Bereitstellen einer zweiten mehrstufigen Updateausführung zum Zurücksetzen auf eine frühere Version

Angenommen, der Workload-Administrator möchte die Änderung der ConfigMap rückgängig machen und den Wert von value2 auf value1 zurücksetzen. Anstatt die ConfigMap manuell vom Hub zu aktualisieren, können sie einen neuen ClusterStagedUpdateRun mit einem vorherigen Ressourcensnapshot-Index, "0" in unserem Kontext, erstellen und dieselbe Strategie wiederverwenden.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterStagedUpdateRun
metadata:
  name: example-run-2
spec:
  placementName: example-placement
  resourceSnapshotIndex: "0"
  stagedRolloutStrategyName: example-strategy
  state: Run

Sehen wir uns das neue ClusterStagedUpdateRun an:

kubectl get clusterstagedupdaterun

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME            PLACEMENT           RESOURCE-SNAPSHOT-INDEX   POLICY-SNAPSHOT-INDEX   INITIALIZED   SUCCEEDED   AGE
example-run     example-placement   1                         0                       True          True        13m
example-run-2   example-placement   0                         0                       True                      9s

Nach Ablauf der Minute TimedWait sollten wir sehen, dass das ClusterApprovalRequest-Objekt für das neue ClusterStagedUpdateRun erstellt wurde:

kubectl get clusterapprovalrequest

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                          UPDATE-RUN      STAGE    APPROVED   APPROVALACCEPTED   AGE
example-run-2-before-canary   example-run-2   canary                                 75s
example-run-before-canary     example-run     canary   True       True               14m

Um das neue ClusterApprovalRequest Objekt zu genehmigen, verwenden wir die gleiche approval.json Datei, um es zu patchen:

kubectl patch clusterapprovalrequests example-run-2-before-canary --type='merge' --subresource=status --patch-file approval.json

Überprüfen Sie, ob das neue Objekt genehmigt wurde:

kubectl get clusterapprovalrequest                                                                            

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                          UPDATE-RUN      STAGE    APPROVED   APPROVALACCEPTED   AGE
example-run-2-before-canary   example-run-2   canary   True       True               2m7s
example-run-before-canary     example-run     canary   True       True               15m

Die ConfigMap test-cm sollte jetzt für alle drei Mitgliedscluster bereitgestellt sein, wobei die Daten auf value1 zurückgesetzt wurden:

apiVersion: v1
data:
  key: value1
kind: ConfigMap
metadata:
  ...
  name: test-cm
  namespace: test-namespace
  ...

Bereinigen von Ressourcen

Wenn Sie mit diesem Lernprogramm fertig sind, können Sie die von Ihnen erstellten Ressourcen bereinigen:

kubectl delete clusterstagedupdaterun example-run example-run-2
kubectl delete clusterstagedupdatestrategy example-strategy
kubectl delete clusterresourceplacement example-placement
kubectl delete namespace test-namespace

Vorbereiten von Kubernetes-Workloads für die Platzierung

Veröffentlichen Sie Kubernetes-Workloads im Hubcluster, damit sie in Mitgliedscluster platziert werden können.

Erstellen Sie einen Namespace und eine ConfigMap für die Workload im Hub-Cluster:

kubectl create namespace test-namespace
kubectl create configmap test-cm --from-literal=key=value1 -n test-namespace

Da ResourcePlacement im Namespacebereich liegt, sollten Sie zunächst den Namespace für alle Mitgliedscluster mithilfe von ClusterResourcePlacement bereitstellen und NamespaceOnly für den Auswahlbereich angeben:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: test-namespace-placement
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-namespace
      version: v1
      selectionScope: NamespaceOnly
  policy:
    placementType: PickAll

Überprüfen Sie, ob der Namespace für alle Membercluster bereitgestellt wird:

kubectl get clusterresourceplacement test-namespace-placement

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                       GEN   SCHEDULED   SCHEDULED-GEN   AVAILABLE   AVAILABLE-GEN   AGE
test-namespace-placement   1     True        1               True        1               30s

Um die ConfigMap bereitzustellen, erstellen Sie eine Namespace-begrenzte ResourcePlacement.

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ResourcePlacement
metadata:
  name: example-placement
  namespace: test-namespace
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      name: test-cm
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: External

Alle drei Cluster sollten geplant werden, da wir die Richtlinie PickAll verwenden. Die ConfigMap sollte jedoch noch nicht auf den Mitgliedsclustern bereitgestellt werden, da wir keine StagedUpdateRun erstellt haben.

Überprüfen Sie, ob die Platzierung geplant ist:

kubectl get resourceplacement example-placement -n test-namespace

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                GEN   SCHEDULED   SCHEDULED-GEN   AVAILABLE   AVAILABLE-GEN   AGE
example-placement   1     True        1                                           51s

Erstellen einer mehrstufigen Updatestrategie

A StagedUpdateStrategy definiert das Orchestrierungsmuster, das Cluster in Phasen gruppiert und die Rolloutsequenz angibt. Sie wählt Mitgliedscluster nach Bezeichnungen aus. In dieser Demo erstellen Sie eine Strategie mit den beiden Phasen Staging und Canary:

apiVersion: placement.kubernetes-fleet.io/v1
kind: StagedUpdateStrategy
metadata:
  name: example-strategy
  namespace: test-namespace
spec:
  stages:
    - name: staging
      labelSelector:
        matchLabels:
          environment: staging
      afterStageTasks:
        - type: TimedWait
          waitTime: 1m
      maxConcurrency: 1
    - name: canary
      labelSelector:
        matchLabels:
          environment: canary
      sortingLabelKey: order
      beforeStageTasks:
        - type: Approval
      maxConcurrency: 50%

Arbeiten mit Ressourcensnapshots

Fleet Manager erstellt Ressourcen-Snapshots, wenn sich Ressourcen ändern, wenn die Platzierung eine Rollout-Strategie von RollingUpdate hat. Jede Momentaufnahme verfügt über einen eindeutigen Index, den Sie verwenden können, um auf bestimmte Versionen Ihrer Ressourcen zu verweisen.

Wenn eine Platzierung die Rollout-Strategie External verwendet, werden Ressourcen-Snapshots nicht automatisch erstellt. Stattdessen werden sie erstellt, wenn Sie eine mehrstufige Updateausführung ausführen. Das bedeutet, dass bei der erstmaligen Erstellung einer Platzierung mit einer External Rollout-Strategie keine Ressourcen-Snapshots vorhanden sind, bis Sie den ersten Stage Update-Lauf ausführen.

Überprüfung der aktuellen Ressourcenschnappschüsse

Da die ResourcePlacementExternal-Strategie verwendet wird, sind noch keine Ressourcensnapshots vorhanden. Überprüfen wir Folgendes:

kubectl get resourcesnapshots -n test-namespace --show-labels

Ihre Ausgabe sollte keine Ressourcen anzeigen:

No resources found in test-namespace namespace.

Erstellen Sie den ersten Ressourcenschnappschuss

Um den ersten Ressourcen Snapshot zu erstellen, müssen Sie einen StagedUpdateRun erstellen, wobei das Feld resourceSnapshotIndex weggelassen wird. Der Updateausführungscontroller erkennt, dass keine Momentaufnahmen vorhanden sind, und erstellt automatisch eine.

apiVersion: placement.kubernetes-fleet.io/v1
kind: StagedUpdateRun
metadata:
  name: example-initial-run
  namespace: test-namespace
spec:
  placementName: example-placement
  stagedRolloutStrategyName: example-strategy
  state: Run

Überprüfen Sie die Ressourcenschnappschüsse, nachdem der Updatevorgang abgeschlossen ist.

kubectl get resourcesnapshots -n test-namespace --show-labels

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                           GEN   AGE   LABELS
example-placement-0-snapshot   1     60s   kubernetes-fleet.io/is-latest-snapshot=true,kubernetes-fleet.io/parent-CRP=example-placement,kubernetes-fleet.io/resource-index=0

Sie verfügen jetzt über eine Version der Momentaufnahme. Dies ist das aktuellste (kubernetes-fleet.io/is-latest-snapshot=true) und hat den Ressourcenindex 0 (kubernetes-fleet.io/resource-index=0).

Neue Ressourcen-Snapshot erstellen

Ändern Sie nun die ConfigMap mit einem neuen Wert:

kubectl edit configmap test-cm -n test-namespace

Ändern Sie den Wert von value1 in value2:

kubectl get configmap test-cm -n test-namespace -o yaml

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

apiVersion: v1
data:
  key: value2 # value updated here, old value: value1
kind: ConfigMap
metadata:
  creationTimestamp: ...
  name: test-cm
  namespace: test-namespace
  resourceVersion: ...
  uid: ...

Da die Platzierungsstrategie die External-Strategie verwendet, wird der neue Ressourcensnapshot nicht automatisch erstellt. Erstellen Sie ein weiteres StagedUpdateRun Feld, bei dem das resourceSnapshotIndex Feld weggelassen wird, um die Erstellung einer neuen Momentaufnahme auszulösen:

apiVersion: placement.kubernetes-fleet.io/v1
kind: StagedUpdateRun
metadata:
  name: example-snapshot-run
  namespace: test-namespace
spec:
  placementName: example-placement
  stagedRolloutStrategyName: example-strategy
  state: Run

Nach Abschluss des Update-Vorgangs sollten zwei Versionen von Snapshots der Ressourcen mit den Indizes 0 und 1 angezeigt werden.

kubectl get resourcesnapshots -n test-namespace --show-labels

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                           GEN   AGE    LABELS
example-placement-0-snapshot   1     2m6s   kubernetes-fleet.io/is-latest-snapshot=false,kubernetes-fleet.io/parent-CRP=example-placement,kubernetes-fleet.io/resource-index=0
example-placement-1-snapshot   1     10s    kubernetes-fleet.io/is-latest-snapshot=true,kubernetes-fleet.io/parent-CRP=example-placement,kubernetes-fleet.io/resource-index=1

Die neueste Label lautet example-placement-1-snapshot, das die neuesten ConfigMap-Daten enthält.

kubectl get resourcesnapshots example-placement-1-snapshot -n test-namespace -o yaml

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ResourceSnapshot
metadata:
  annotations:
    kubernetes-fleet.io/number-of-enveloped-object: "0"
    kubernetes-fleet.io/number-of-resource-snapshots: "1"
    kubernetes-fleet.io/resource-hash: 10dd7a3d1e5f9849afe956cfbac080a60671ad771e9bda7dd34415f867c75648
  creationTimestamp: "2025-07-22T21:26:54Z"
  generation: 1
  labels:
    kubernetes-fleet.io/is-latest-snapshot: "true"
    kubernetes-fleet.io/parent-CRP: example-placement
    kubernetes-fleet.io/resource-index: "1"
  name: example-placement-1-snapshot
  namespace: test-namespace
  ownerReferences:
  - apiVersion: placement.kubernetes-fleet.io/v1beta1
    blockOwnerDeletion: true
    controller: true
    kind: ResourcePlacement
    name: example-placement
    uid: e7d59513-b3b6-4904-864a-c70678fd6f65
  resourceVersion: "19994"
  uid: 79ca0bdc-0b0a-4c40-b136-7f701e85cdb6
spec:
  selectedResources:
  - apiVersion: v1
    data:
      key: value2 # latest value: value2, old value: value1
    kind: ConfigMap
    metadata:
      name: test-cm
      namespace: test-namespace

Vorbereitung eines gestaffelten Update-Laufs zur Einführung von Änderungen

Ein StagedUpdateRun führt den Rollout eines ResourcePlacement gefolgt von einer StagedUpdateStrategy durch. Um den gestuften Aktualisierungsdurchlauf für unser ResourcePlacement (RP) auszulösen, erstellen wir einen StagedUpdateRun, in dem wir den RP-Namen, den Namen der updateRun-Strategie, den neuesten Ressourcensnapshot-Index („1“) und dem Status „Initialize“ angeben.

apiVersion: placement.kubernetes-fleet.io/v1
kind: StagedUpdateRun
metadata:
  name: example-run
  namespace: test-namespace
spec:
  placementName: example-placement
  resourceSnapshotIndex: "1"
  stagedRolloutStrategyName: example-strategy
  state: Initialize

Die mehrstufige Update-Ausführung wird initialisiert, aber nicht ausgeführt.

kubectl get stagedupdaterrun example-run -n test-namespace

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME          PLACEMENT           RESOURCE-SNAPSHOT-INDEX   POLICY-SNAPSHOT-INDEX   INITIALIZED   SUCCEEDED   AGE
example-run   example-placement   1                         0                       True                      7s

Starten einer mehrstufigen Updateausführung

Um die Ausführung eines mehrstufigen Updates zu starten, müssen Sie das state Feld in der Spezifikation Runauf Folgendes patchen:

kubectl patch stagedupdaterrun example-run -n test-namespace --type merge -p '{"spec":{"state":"Run"}}'

Der gestaffelte Updatevorgang wird initialisiert und ausgeführt:

kubectl get stagedupdaterrun example-run -n test-namespace

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME          PLACEMENT           RESOURCE-SNAPSHOT-INDEX   POLICY-SNAPSHOT-INDEX   INITIALIZED   SUCCEEDED   AGE
example-run   example-placement   1                         0                       True                      7s

Überprüfen Sie nach Ablauf einer Minute TimedWait, ob die Genehmigungsanforderung vorliegt:

kubectl get approvalrequests -n test-namespace

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                        STAGED-UPDATE-RUN   STAGE    APPROVED   APPROVALACCEPTED   AGE
example-run-before-canary   example-run         canary                                 2m39s

Genehmigen Sie die Ausführung des mehrstufigen Updates

Wir können die ApprovalRequest Datei genehmigen, indem wir eine JSON-Patchdatei erstellen und anwenden:

cat << EOF > approval.json
"status": {
    "conditions": [
        {
            "lastTransitionTime": "$(date -u +%Y-%m-%dT%H:%M:%SZ)",
            "message": "lgtm",
            "observedGeneration": 1,
            "reason": "testPassed",
            "status": "True",
            "type": "Approved"
        }
    ]
}
EOF

Senden Sie eine Patchanforderung, um sie mithilfe der erstellten JSON-Datei zu genehmigen.

kubectl patch approvalrequests example-run-before-canary -n test-namespace --type='merge' --subresource=status --patch-file approval.json

Überprüfen Sie dann, ob Sie die Anforderung genehmigt haben:

kubectl get approvalrequests -n test-namespace

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                        STAGED-UPDATE-RUN   STAGE    APPROVED   APPROVALACCEPTED   AGE
example-run-before-canary   example-run         canary   True       True               3m35s

Der StagedUpdateRun kann jetzt fortgesetzt und abgeschlossen werden:

kubectl get stagedupdaterrun example-run -n test-namespace

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME          PLACEMENT           RESOURCE-SNAPSHOT-INDEX   POLICY-SNAPSHOT-INDEX   INITIALIZED   SUCCEEDED   AGE
example-run   example-placement   1                         0                       True          True        5m28s

Überprüfung des Abschlusses des Rollouts

Dies ResourcePlacement zeigt auch, dass der Rollout abgeschlossen ist und Ressourcen in allen Mitgliedsclustern verfügbar sind:

kubectl get resourceplacement example-placement -n test-namespace

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                GEN   SCHEDULED   SCHEDULED-GEN   AVAILABLE   AVAILABLE-GEN   AGE
example-placement   1     True        1               True        1               8m55s

ConfigMap test-cm soll auf allen drei Member Clustern mit den neuesten Daten bereitgestellt werden.

apiVersion: v1
data:
  key: value2
kind: ConfigMap
metadata:
  ...
  name: test-cm
  namespace: test-namespace
  ...

Beenden einer mehrstufigen Updateausführung

Um die Ausführung eines laufenden mehrstufigen Updates zu beenden, müssen Sie das state-Feld im spec auf Stop patchen. Diese Aktion sorgt für ein kontrolliertes Anhalten des Aktualisierungsdurchlaufs, sodass Cluster, die laufende Aktualisierungen durchführen, diese abschließen können, bevor der gesamte Ausrollvorgang gestoppt wird:

kubectl patch stagedupdaterun example-run -n test-namespace --type merge -p '{"spec":{"state":"Stop"}}'

Der gestufte Aktualisierungslauf ist initialisiert und wird nicht mehr ausgeführt:

kubectl get stagedupdaterun example-run -n test-namespace

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME          PLACEMENT           RESOURCE-SNAPSHOT-INDEX   POLICY-SNAPSHOT-INDEX   INITIALIZED   SUCCEEDED   AGE
example-run   example-placement   1                         0                       True                      7s

Ein detaillierterer Blick auf den Status, nachdem die Updateausführung beendet wurde:

kubectl get stagedupdaterun example-run -n test-namespace -o yaml

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

apiVersion: placement.kubernetes-fleet.io/v1
kind: StagedUpdateRun
metadata:
  ...
  name: example-run
  namespace: test-namespace
  ...
spec:
  placementName: example-placement
  resourceSnapshotIndex: "1"
  stagedRolloutStrategyName: example-strategy
  state: Stop
status:
  conditions:
  - lastTransitionTime: "2025-07-22T21:28:08Z"
    message: StagedUpdateRun initialized successfully
    observedGeneration: 3
    reason: UpdateRunInitializedSuccessfully
    status: "True" # the updateRun is initialized successfully
    type: Initialized
  - lastTransitionTime: "2025-07-22T21:28:23Z"
    message: The update run has been stopped
    observedGeneration: 3
    reason: UpdateRunStopped
    status: "False" # the updateRun has stopped progressing
    type: Progressing
  deletionStageStatus:
    clusters: [] # no clusters need to be cleaned up
    stageName: kubernetes-fleet.io/deleteStage
  policyObservedClusterCount: 3 # number of clusters to be updated
  policySnapshotIndexUsed: "0"
  resourceSnapshotIndexUsed: "1"
  stagedUpdateStrategySnapshot: # snapshot of the strategy used for this update run
    stages:
    - afterStageTasks:
      - type: TimedWait
        waitTime: 1m0s
      labelSelector:
        matchLabels:
          environment: staging
      maxConcurrency: 1
      name: staging
    - beforeStageTasks:
      - type: Approval
      labelSelector:
        matchLabels:
          environment: canary
      maxConcurrency: 50%
      name: canary
      sortingLabelKey: order
  stagesStatus: # detailed status for each stage
  - clusters:
    - clusterName: member2 # stage staging contains member2 cluster only
      conditions:
      - lastTransitionTime: "2025-07-22T21:28:08Z"
        message: Cluster update started
        observedGeneration: 3
        reason: ClusterUpdatingStarted
        status: "True"
        type: Started
      - lastTransitionTime: "2025-07-22T21:28:23Z"
        message: Cluster update completed successfully
        observedGeneration: 3
        reason: ClusterUpdatingSucceeded
        status: "True" # member2 is updated successfully
        type: Succeeded
    conditions:
    - lastTransitionTime: "2025-07-22T21:28:23Z"
      message: All the updating clusters have finished updating, the stage is now stopped, waiting to be resumed
      observedGeneration: 3
      reason: StageUpdatingStopped
      status: "False"
      type: Progressing
    stageName: staging
    startTime: "2025-07-22T21:28:08Z"

Bereitstellen einer zweiten mehrstufigen Updateausführung zum Zurücksetzen auf eine frühere Version

Angenommen, der Workload-Administrator möchte die Änderung der ConfigMap rückgängig machen und den Wert von value2 auf value1 zurücksetzen. Statt die Configmap manuell aus dem Hub heraus zu aktualisieren, kann ein neuer StagedUpdateRun mit einem früheren Ressourcensnapshot-Index erstellt werden, in unserem Kontext „0“, und dieselbe Strategie kann wiederverwendet werden:

apiVersion: placement.kubernetes-fleet.io/v1
kind: StagedUpdateRun
metadata:
  name: example-run-2
  namespace: test-namespace
spec:
  placementName: example-placement
  resourceSnapshotIndex: "0"
  stagedRolloutStrategyName: example-strategy
  state: Run

Sehen wir uns das neue StagedUpdateRun an:

kubectl get stagedupdaterun -n test-namespace

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME            PLACEMENT           RESOURCE-SNAPSHOT-INDEX   POLICY-SNAPSHOT-INDEX   INITIALIZED   SUCCEEDED   AGE
example-run     example-placement   1                         0                       True          True        13m
example-run-2   example-placement   0                         0                       True                      9s

Nach Ablauf der Minute TimedWait sollten wir sehen, dass das ApprovalRequest-Objekt für das neue StagedUpdateRun erstellt wurde:

kubectl get approvalrequests -n test-namespace

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                          STAGED-UPDATE-RUN   STAGE    APPROVED   APPROVALACCEPTED   AGE
example-run-2-before-canary   example-run-2       canary                                 75s
example-run-before-canary     example-run         canary   True       True               14m

Um das neue ApprovalRequest Objekt zu genehmigen, verwenden wir die gleiche approval.json Datei, um es zu patchen:

kubectl patch approvalrequests example-run-2-before-canary -n test-namespace --type='merge' --subresource=status --patch-file approval.json

Überprüfen Sie, ob das neue Objekt genehmigt wurde:

kubectl get approvalrequests -n test-namespace

Ihre Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAME                          STAGED-UPDATE-RUN   STAGE    APPROVED   APPROVALACCEPTED   AGE
example-run-2-before-canary   example-run-2       canary   True       True               2m7s
example-run-before-canary     example-run         canary   True       True               15m

Die ConfigMap test-cm sollte jetzt für alle drei Mitgliedscluster bereitgestellt sein, wobei die Daten auf value1 zurückgesetzt wurden:

apiVersion: v1
data:
  key: value1
kind: ConfigMap
metadata:
  ...
  name: test-cm
  namespace: test-namespace
  ...

Bereinigen von Ressourcen

Wenn Sie mit diesem Lernprogramm fertig sind, können Sie die von Ihnen erstellten Ressourcen bereinigen:

kubectl delete stagedupdaterun example-run example-run-2 -n test-namespace
kubectl delete stagedupdatestrategy example-strategy -n test-namespace
kubectl delete resourceplacement example-placement -n test-namespace
kubectl delete clusterresourceplacement test-namespace-placement
kubectl delete namespace test-namespace