Azure Kubernetes Fleet Manager クラスター リソース配置のロールアウト戦略の定義

クラスター リソース配置 (CRP) の有効期間中に、CRP に変更が加えられる可能性があり、その結果、次のいずれかのシナリオが発生する可能性があります。

• 選択したすべてのクラスターに新しいワークロードを配置する必要がある場合があります
• 選択したクラスターに既に配置されているワークロードは、更新または削除される可能性があります
• 以前に選択した一部のクラスターは選択されなくなり、ワークロードはそのようなクラスターから削除する必要があります
• 一部のクラスターは新しく選択され、ワークロードを追加する必要があります。

Fleet Manager が更新されたリソースをディスパッチすると、メンバー クラスターで実行されているワークロードが一時的に使用できなくなる可能性があるため、ほとんどのシナリオでサービスが中断される可能性があります。 選択されなくなったクラスターは、配置されたすべてのリソースを失い、トラフィックが失われます。 選択されている新しいクラスターが多すぎて、Fleet Manager によってリソースが同時に配置されると、クラスターが過負荷になる可能性があります。 正確な中断パターンは、配置されたリソースによって異なる場合があります。

中断を最小限に抑えるために、Fleet Manager のクラスター リソースの配置により、ユーザーはネイティブ Kubernetes デプロイと同様にロールアウト戦略を構成して、変更間を可能な限りスムーズに切り替えることができます。

この記事では、クラスター リソースの配置に使用できるロールアウト戦略オプションについて説明します。

明示的な戦略のない既定の動作

クラスター リソースの配置では、ロールアウト戦略を定義する必要はありません。 指定しない場合、既定の動作では、RollingUpdateが 25%、maxSurgeが 25%、maxUnavailableが 10 秒のunavailablePeriodSeconds戦略が使用されます。

ローリング更新の戦略

明示的なローリング更新戦略を使うには、strategy の指定を CRP に追加します。 Fleet Manager リソースの配置の中断を制御するパラメーターを定義できます。

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-example
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-namespace
      version: v1
  policy:
    placementType: PickN
    numberOfClusters: 2
    affinity:
      clusterAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          clusterSelectorTerms:
            - labelSelector:
                matchLabels:
                  fleet.azure.com/___location: westus
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 50%

ローリング アップデート戦略は、次のパラメーターを使用して構成できます。

• maxUnavailable: リソースがクラスターに正常に適用されていない場合は、クラスターを使用不可と見なし、少 なくとも (N - maxUnavailable) 個のクラスターがいつでも使用可能であることを確認します。 絶対数またはパーセンテージとして設定できます。 既定値は 25% であり、ゼロは使用しないでください。 このパラメーターを小さい値に設定すると、変更中の中断が少なくなりますが、ロールアウトが遅くなります。

• maxSurge: いつでも、使用可能なクラスターの数が 最大 (N + maxSurge) であることを確認します。 絶対数またはパーセンテージとして設定できます。 既定値は 25% であり、ゼロは使用しないでください。 このパラメーターを小さい値に設定すると、Fleet Manager によるクラスターのリソース配置が少なくなり、ロールアウト プロセスが遅くなります。

• unavailablePeriodSeconds を使用すると、リソースを "準備完了" として評価する前の期間を定義できます。 既定値は 60 秒です。 Fleet Manager では、クラスターに新しく適用されたリソースは、そのクラスターにリソースが正常に適用されてから数秒後 unavailablePeriodSeconds "準備完了" と見なされます。 このパラメーターの値を小さく設定すると、ロールアウトが高速になります。 ただし、初期化/準備タスクを完了できる値をユーザーが設定することを強くお勧めします。

クラスター数の決定方法

Fleet Manager では、配置の種類を使用して、NまたはmaxUnavailableを計算するときに使用するクラスターのベースライン数 (maxSurge) を決定します。

• PickFixed: 指定された clusterNames の数
• PickAll: 選択されたクラスターの数
• PickN: numberOfClusters 値。

パラメーターにパーセンテージを使用すると、 N に対しても計算されます。

段階的な更新戦略 (プレビュー)

段階的な更新戦略では、構成可能な進行ルールを使用してクラスターを順次ステージに編成することで、リソースのロールアウトをきめ細かく制御できます。 ローリング 更新戦略とは異なり、ステージングされた更新は、デプロイを調整するために連携する個別のカスタム リソースを使用して外部で定義されます。

段階的な更新のしくみ

段階的な更新では、次の 3 つのカスタム リソースが使用されます。

• ClusterResourcePlacement - 外部戦略管理を示すために strategy.type: External で構成
• ClusterStagedUpdateStrategy - ステージ、クラスターの選択、および進行ルールを定義します
• ClusterStagedUpdateRun - 特定の CRP およびリソース スナップショットに対して clusterStagedUpdateStrategy を実行します

ClusterResourcePlacement と外部戦略

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: my-app-placement
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: External  # Rollout is controlled by ClusterStagedUpdateRun, ClusterStagedUpdateStrategy.

ClusterStagedUpdateStrategy

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterStagedUpdateStrategy
metadata:
  name: three-stage-strategy
spec:
  stages:
    - name: staging
      labelSelector:
        matchLabels:
          environment: staging
      afterStageTasks:
        - type: TimedWait
          waitTime: 1h
    - name: canary
      labelSelector:
        matchLabels:
          environment: canary
      sortingLabelKey: name
      afterStageTasks:
        - type: Approval
    - name: production
      labelSelector:
        matchLabels:
          environment: production
      sortingLabelKey: order

戦略の各ステージでは、次の項目を指定できます。

• ステージに属するクラスターを決定するラベル セレクター
• sortingLabelKeyを使用したステージ内のクラスターの並べ替え順序 (省略可能 - クラスターは名前でアルファベット順に並べ替えられます (指定しない場合)
• ステージ後のタスク の待機時間または承認の要件 (省略可能、ステージあたり最大 2 つのタスク、各種類の最大 1 つ)

ClusterStagedUpdateRun

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterStagedUpdateRun
metadata:
  name: my-app-rollout
spec:
  placementName: my-app-placement # ClusterResourcePlacement name the update run is applied to.
  resourceSnapshotIndex: "0" # Resource snapshot index of the selected resources to be updated across clusters.
  stagedRolloutStrategyName: three-stage-strategy # The name of the update strategy to use.

Stage progression

Fleet Manager では、ステージが順番に処理されます。

1. ステージ内のすべてのクラスターは、並べ替え順序に従って更新プログラムを受け取ります
2. ステージ内のすべてのクラスターが正常に更新されると、構成されたすべてのステージ後タスクが実行されます。
3. 次のステージは、ステージ タスクが完了した後、前のすべてのステージの後にのみ開始されます

承認ベースの進行のために、Fleet Manager は、次のステージに進む前に承認する必要がある ClusterApprovalRequest リソースを作成します。

デプロイ パターンの例

次の図は、一般的な 3 段階デプロイ パターンを示しています。

このパターンを使用すると、次のことができます。

• 初期検証のために最初にステージング クラスターにデプロイする
• カナリア クラスターに進む前に、指定した時間待ちます
• 運用環境にロールアウトする前に手動承認を要求する
• カナリアステージと運用ステージ内の更新の順序を制御する

段階的な更新プログラムを使用する場合

段階的な更新戦略は、必要な場合に最適です。

• 環境ベースのロールアウト (開発→ステージング→運用環境)
• ステージ間の検証の遅延と承認ゲート
• ステージ内でのクラスター更新の確定的な順序付け
• 複数のクラスター リソース配置にわたる再利用可能なデプロイ パターン

パーセンテージベースのロールアウトで十分な単純なシナリオでは、代わりにインライン ローリング更新戦略を使用することを検討してください。

Next steps

• ClusterStagedUpdateRun を使用して段階的なロールアウトを調整する方法。
• クラスター リソースの配置に対する削除と中断の制御。
• クラスター リソース配置を使用して、複数のクラスターにワークロードをデプロイします。
• メンバー クラスターのプロパティに基づくインテリジェントなクラスター間 Kubernetes リソースの配置。