複数のクラスター間で Kubernetes とノード イメージを安全に更新する

適用対象: ✔️ Fleet Manager ✔️ ハブ クラスターを持つFleet Manager

多くのクラスターを管理するプラットフォーム管理者は、多くの場合、ノード OS イメージまたは Kubernetes バージョンのアップグレードを安全かつ予測可能にステージングするのに苦労します。 Azure Kubernetes Fleet Manager では、更新実行を使用して、複数のクラスターにまたがるこれらのアップグレードを調整して実行できます。

更新プログラムの実行は、ステージ、グループ、および戦略で構成されます。 更新プログラムの実行は、1 回限り更新に対して手動で適用することも、自動アップグレード プロファイルを使用して継続的な定期的な更新に対して自動的に適用することもできます。 手動と自動のいずれの更新実行も、クラスターのメンテナンス ウィンドウに従います。

更新プログラムの実行について

更新プログラムの実行は、AKS クラスターのコレクションに適用される更新を表します。 これは、更新の目標とシーケンスで構成されます。 更新の目標は、必要な更新プログラムについて説明します。 たとえば、特定の Kubernetes バージョンにアップグレードしたり、すべてのクラスターに一貫性のあるノード イメージを適用したりします。

更新プログラムの実行を使用するときに最適な結果を得るには、次の概念を理解することが重要です。

• 更新戦略: クラスターのステージとグループで構成される再利用可能な更新シーケンスについて説明します。 クラスターは、割り当てられている更新グループまたはメンバー ラベルに基づいて、ステージ内のグループに表示されます。 詳細については、 更新戦略の理解を参照してください。

  • 更新ステージ: 更新戦略は、順番に適用される更新ステージに分割されます。 たとえば、テスト環境クラスターは最初の更新ステージに入り、運用環境クラスターは 2 番目の更新ステージに入ります。 更新ステージには、1 つ以上の更新グループが含まれています。 最大コンカレンシー、待機時間、承認ゲートなどの追加の制御を使用して、Update Stage の実行をより詳細に制御できます。

  • 更新グループ: 各更新ステージには、更新するクラスターを選択する 1 つ以上の更新グループが含まれています。 クラスターの Update Group プロパティ、または member labels を使用したプレビュー中のラベルベース照合を使用して、メンバー クラスターを Update Group に割り当てます。 更新ステージ内の更新グループは並列に更新されます。

  注意

  各更新ステージの更新グループの最大数は 50 です。

  • その他のフロー制御: より多くの制御を使用して、クラスターのフリートを更新する速度を柔軟に設定できます。

    • 最大コンカレンシー (プレビュー):最大コンカレンシー 構成を使用して、並列にアップグレードされるクラスターの数を変更します。 この動作は、ステージ レベルとグループ レベルの両方で構成できます。

    • 許容される最大エラー数 (プレビュー): 更新プログラムの実行を停止する前に許容されるメンバー クラスターのアップグレードエラーの数を制御するには、[ 許容される最大エラー 数] 構成を使用します。 この動作は、ステージ レベルとグループ レベルの両方で構成できます。

    • ゲート: 条件が満たされるまで更新プログラムの実行を一時停止します。

      • 承認ゲート (プレビュー):各ステージまたはグループの前または後に構成できます。 承認の際に更新プログラムの実行が一時停止されて、ユーザーまたはユーザーが設定した自動化は、処理を続けても問題ないかどうかを確認できます。 自分またはオートメーションが承認を付与すると、更新プログラムの実行が続行されます。

      • スケジュールされた開始ゲート (プレビュー): 各ステージまたはグループの前に構成できます。 スケジュールされた開始ゲートは、指定した日時まで更新プログラムの実行を一時停止します。 ゲートは、スケジュールされた時刻に達すると自動的に完了するか、手動で完了していつでも続行できます。

• 自動アップグレード プロファイル: 新しい Kubernetes またはノード イメージ のバージョンが AKS によって使用可能になったときに、更新プログラムの実行を自動的に作成して開始します。 詳細については、 自動アップグレード プロファイルについてを参照してください。

更新プログラムの実行オプション

更新プログラムの実行では、次の 3 種類のアップグレードを適用できます。

• コントロール プレーンとノードの Kubernetes バージョンをアップグレードします。 このアップグレードには、ノード イメージのアップグレードが含まれます。
• クラスターのコントロール プレーンの Kubernetes バージョンのみをアップグレードします。
• ノード イメージのみをアップグレードします。

アップグレード先の Kubernetes バージョンを指定できますが、ターゲット ノード イメージのバージョンを選択することはできません。 システムは、設定に基づいてターゲット ノード イメージのバージョンを自動的に選択します。

• 最新: そのクラスターのアップグレードの開始時に、各クラスターのAzure リージョンで使用可能な最新のノード イメージを使用します。 その結果、クラスターがどのリージョンに存在するか、アップグレードが実際に開始されるタイミング Azureに応じて、フリート全体で異なるイメージ バージョンが使用される可能性があります。
• 一貫性: 更新プログラムの実行が開始されたら、この実行のクラスターが配置されているすべてのAzureリージョンで現在使用可能なイメージ バージョンを選択します。 そのため、一貫性のあるイメージ バージョンはすべてのクラスターで使用されます。

最新のイメージ バージョンを使用し、セキュリティ リスクを最小限に抑えるには、[ 最新] を選択します。 後のクラスターで使用する前に、以前のステージのクラスターでこれらのイメージを使用して確認することで、信頼性を向上させるには、[ 一貫性] を選択します。

実行状態の更新

更新プログラムの実行のライフサイクルを理解するには、各状態、実行できるアクション、および状態の計算方法を把握する必要があります。

保留中

• Update Run: 現在のステージが Pending 状態の場合。
• 更新ステージ: ステージ内のすべての更新グループが Pending または開始されていない場合、または Pending ゲートがある場合。
• グループの更新: グループ内のすべてのクラスターが Pending または開始されていない場合、または Pending ゲートがある場合。 クラスターが Pendingに移動すると、更新プログラムの実行によって、グループ内の次のクラスターのアップグレードが試行されます。 すべてのメンバーが Pendingされると、グループは Pendingに移動します。 更新プログラムの実行は、ステージ内のすべてのグループが完了するまで待機してから、次のステージに進みます。
• メンバー クラスター: 次のいずれかの理由により、メッセージ フィールドに表示できます。
  • メンテナンス期間がオープンしていません。 メッセージに次回のオープン時刻が示されています。
  • ターゲット Kubernetes またはノード イメージのバージョンは、クラスターの Azure リージョンではまだ使用できません。 リリースの状態を確認するための AKS リリース トラッカーへのメッセージ リンク。

スキップされた状態

• 更新プログラムの実行: すべてのステージが Skippedされたことをシステムが検出しました。
• ステージの更新: ステージまたはステージ内のすべてのグループを Skippedとしてマークしたユーザー。
• グループの更新: グループまたはグループ内のすべてのクラスターを Skippedとしてマークしたユーザー。
• メンバー クラスター: 次のいずれかの理由により、メッセージ フィールドに表示できます。
  • ユーザーがクラスター、グループ、またはステージを明示的にスキップしました。
  • クラスターは既にターゲットの Kubernetes バージョンにあり (更新実行モードが Full または ControlPlaneOnlyの場合)、すべてのノード プールはターゲット ノード イメージ バージョンにあります。
  • 一貫性のあるノード イメージが選択されていて、いずれかのノード プールのターゲット イメージ バージョンを見つけることができない場合。 この状況は、更新プログラムの実行が開始された後に、新しい仮想マシン (VM) SKU を持つ新しいノード プールが追加されたときに発生する可能性があります。

失敗した状態

失敗した状態は、次のようにクラスターから連鎖します。 概要エラー メッセージに、クラスターのアップグレードに失敗した原因が表示されます。

• 更新プログラムの実行: 現在のグループ内の少なくとも 1 つのクラスターが失敗しました。
• ステージの更新: ステージ内のグループ内の少なくとも 1 つのクラスターが失敗しました。
• グループの更新: グループ内の少なくとも 1 つのクラスターが失敗しました。
• メンバー クラスター: アップグレードに失敗し、クラスターの状態が Failedとして設定されます。

許容される最大エラー数を構成すると、エラーのしきい値は、更新グループ、更新ステージ、および更新の実行の状態に影響します。 個々のメンバー クラスターの状態には影響しません。 メンバー クラスターのアップグレードが失敗した場合でも、その状態は Failed に設定されます。

• グループまたはステージのエラー数が構成された maxAllowedFailures しきい値を超えた場合、グループまたはステージは概要エラー メッセージで Failed としてマークされ、更新の実行は進行を停止します。 maxAllowedFailuresが構成されていない場合 (または0に設定されている場合)、1 回の失敗で実行全体が停止します。
• エラー数が maxAllowedFailures しきい値内にある場合、更新プログラムの実行は後続のメンバーのアップグレードを続行します。 詳細については、「 許容される最大エラー数」を参照してください。

完了した状態

Completed状態は、更新プログラムの実行がターミナル ライフサイクルの状態に達したことを意味します。 [許容最大エラー数] を使用する場合、Completedは、Fleet Manager がスケジュール作業を続行するかどうかを決定したときに、構成されたエラーのしきい値を超えていなかったことを意味します。 最小成功率や正常な結果は保証されません。 FailureCount、メンバーの状態、およびエラー メッセージを常に検査します。

計画メンテナンス期間

更新プログラムの実行では、AKS クラスター レベルで設定 した計画メンテナンス期間 が優先されます。

AKS クラスターでは、Kubernetes (コントロール プレーン) のアップグレード用とノード イメージのアップグレード用の 2 つの異なるメンテナンス期間がサポートされています。 メンテナンス期間は、更新プログラムをクラスターに適用できる期間を定義しますが、更新トリガーではありません。

Fleet Manager の更新プログラムの実行では、AKS メンテナンス期間が次のように優先されます。

更新プログラムの実行では、計画メンテナンスに基づいてクラスターのアップグレードが次の順序で優先されます。

1. 継続的なメンテナンス期間が開いているクラスター。
2. 次の 4 時間以内にメンテナンス期間が開くクラスター。
3. メンテナンス期間のないクラスター。
4. メンテナンス期間が閉じているクラスター。

AKS プラットフォーム主導のアップグレード

Fleet Manager は AKS サポート ウィンドウ内のメンバー クラスターのアップグレードを調整します。 クラスターの Kubernetes バージョンがサポート終了を迎えると、60 日間の プラットフォーム サポート猶予期間に入ります。 この期間が経過してもクラスターがサポートされていないバージョンのままである場合、AKS は 、プラットフォームによって開始されるアップグレード をメンバー クラスターに対して直接実行します。

AKS はこのアップグレードを直接開始するため、Fleet Manager の更新プログラムの実行、更新グループ、および更新戦略では、その順序付けは制御されません。 アップグレードは、クラスターの計画メンテナンス期間外にも発生する可能性があります。

Fleet オーケストレーション下でアップグレードを管理するには、更新実行と 自動アップグレード プロファイル を使用して、メンバー クラスターをサポート対象の Kubernetes バージョンに維持します。

自動アップグレード プロファイルの概要

自動アップグレード プロファイルを使用して、AKS で新しい Kubernetes またはノード イメージバージョンが使用可能になったときに更新プログラムの実行を自動的にトリガーします。

自動アップグレード プロファイルでは、次の構成を行います。

• クラスターに適用される更新プログラムの種類を決定するチャネル (Rapid、Stable、TargetKubernetesVersion、NodeImage、SecurityPatch (プレビュー))。
• クラスターをアップグレードするシーケンスを構成する UpdateStrategy 。 戦略を指定しない場合、クラスターは 1 つずつ順番に更新されます。
• NodeImageSelectionType (Latest, Consistent) を使用して、Kubernetes バージョンのアップグレード時にノード イメージを選択する方法を指定します。

ラピッド チャネル

ラピッド チャネルは、常に AKS でサポートされている最新の Kubernetes のマイナー リリースです。 クラスターのマイナー バージョンは、AKS が新しい Kubernetes マイナー バージョンをリリースすると自動的に変更されます。

例 :

• サポートされている最新のマイナー バージョンは 1.30 です。 1.30 マイナー範囲のパッチ リリースは、Rapid チャネルの更新プログラムと見なされます。
• 新しい Kubernetes のマイナー バージョン 1.31 が公開されました。 1.30 は安定チャネルに移行します。 以前に 1.30 から更新プログラムを受け取ったクラスターは、 1.31 の最新のパッチに更新され、現在は Rapid チャネルになっています。

安定チャネル

安定チャネルは、常に Rapid チャネルの前のマイナー バージョンです。 場合によっては、Stable を "N-1" と言うことがあります。 ここで、"N" は最新 (Rapid チャネル) でサポートされている Kubernetes マイナー バージョンです。 クラスターのマイナー バージョンは、AKS が新しい Kubernetes マイナー バージョンをリリースすると自動的に変更されます。

例 :

• サポートされている最新の Kubernetes のマイナー バージョンは 1.30 です。 1.29 マイナー範囲内のすべてのパッチ リリースは、安定チャネルの更新プログラムとみなされます。
• 新しい Kubernetes のマイナー バージョン 1.31 が公開されました。 安定チャネルでは、 1.30 マイナー範囲のパッチ リリースが更新プログラムと見なされます。 以前に 1.29 から更新プログラムを受け取ったクラスターは、 1.30 の最新のパッチに更新されます。

TargetKubernetesVersion チャネル

TargetKbernetesVersion チャネルを使用すると、クラスターを次の Kubernetes マイナー バージョンに移動するタイミングを制御できます。 ターゲットの Kubernetes バージョンを "{major} という形式で指定する必要があります。{minor}" (例: "1.33")。 Fleet Manager は、パッチが利用可能になると、指定されたターゲット Kubernetes バージョンの最新のパッチ リリースにクラスターを自動的にアップグレードします。 自動アップグレード プロファイルのターゲット Kubernetes バージョンが更新されるまで、Fleet Manager は次のマイナー バージョンにアップグレードしません。

例 :

• TargetKbernetesVersion チャネルを使用して自動アップグレード プロファイルを作成し、ターゲット Kubernetes バージョン "1.30" を指定します。 新しいパッチ バージョン 1.30.5 が公開されました。 更新プログラムの実行は、ターゲットが 1.30.5 で自動的に作成されます。
• 自動アップグレード プロファイルは、TargetKbernetesVersion チャネルを使用して作成し、ターゲットの Kubernetes バージョン "1.29" を指定し、自動アップグレード プロファイルで LongTermSupport (LTS) を有効にします。 コミュニティでサポートされている最新のマイナー バージョンは "1.33" です。 新しいパッチ バージョン 1.29.5 が公開されました。 更新プログラムの実行は、ターゲットが 1.29.5 で自動的に作成されます。 生成された更新実行に LTS が有効になっていないクラスターが含まれている場合、失敗します。

マイナー バージョンのスキップ動作

自動アップグレードでは、複数のマイナー Kubernetes バージョンの違いがある場合 (たとえば、1.28 から 1.30) のマイナー Kubernetes バージョン間でクラスターが移動されることはありません。 管理者が多様な Kubernetes バージョンのセットを持っている場合は、最初に 1 つ以上の 更新実行 を使用してクラスターを一連の一連の一貫したバージョン管理されたリリースに取り込み、構成された Stable または Rapid チャネルの更新によって整合性が将来も維持されるようにします。

NodeImage チャネル

メンバー クラスター ノードは、週 1 回の頻度で、セキュリティ修正とバグ修正を含む新しくパッチが適用された VHD で更新されます。 新しい VHD の更新は、メンテナンス期間およびサージ設定の影響で混乱を引き起こします。 このオプションを選んだ場合、追加の VHD コストは発生しません。 ノード イメージのアップグレードでは、非推奨になったパッチ バージョンであっても、Kubernetes のマイナー バージョンがまだサポートされている限り、サポートされます。 ノード イメージは AKS でテストされ、完全に管理され、安全なデプロイ プラクティスで適用されます。

異なるオペレーティング システム上のノードは、それらのオペレーティング システムに合わせたノード イメージのバージョンに従って更新されます。

例:

• クラスターには、バージョン 20348.2582.240716 の AKSWindows-2022-containerd の NodeImage を持つノードがあります。 新しい NodeImage バージョン 20348.2582.240916 がリリースされ、クラスター ノードが自動的にバージョン 20348.2582.240916 にアップグレードされます。

ノード イメージのアップグレードとスナップショットについて

クラスターにノード プール スナップショットから作成されたエージェント プールがある場合、ノード イメージのアップグレードの結果は、Fleet Manager Update Run ノード イメージの選択によって異なります。

SecurityPatch チャネル (プレビュー)

週単位でセキュリティ修正のみを使用して、メンバー クラスター Linux ノードを更新します。 Canonical Ubuntu と Azure Linux では、OS セキュリティ パッチを 1 日に 1 回使用できます。 Microsoftこれらのパッチをテストし、ノード イメージの毎週の更新にバンドルします。

SecurityPatch 自動アップグレード チャネルは、可能な限り OS ライブ 修正プログラムを使用し、ノードの中断を最小限に抑えながら、既知の脆弱性からノードを保護しているため、中断が少なくなります。 ライブ パッチ適用が不可能な場合は、代わりに事前にパッチが適用されたノード イメージがデプロイされます。

SecurityPatchを使用する場合は Linux ベースのノードのみが更新され、Windows ベースのノードは自動的にスキップされます。

新しいノード イメージ (VHD) に付属するバグ修正、またはWindowsノードとの一貫したエクスペリエンスが必要な場合は、代わりに NodeImage チャネルを選択します。

更新戦略について

管理者は、一連の更新ステージとグループを使用して再利用可能な更新戦略を構築することで、クラスターの更新順序を制御できます。 これらのステージとグループ内で承認と一時停止を行うタイミングを構成できます。 構成全体を更新戦略として保存できます。更新プログラムの実行プロファイルまたは自動アップグレード プロファイルとは別に管理できるため、必要に応じて戦略を再利用できます。

メンバー ラベルを使用してクラスターをグループ化する (プレビュー)

メンバー ラベルを使用して、クラスターをグループ化し、Kubernetes スタイルのラベル セレクターを使用して更新シーケンスを構成できます。 これにより、複数のラベルをメンバー クラスターに割り当てて、クラスターごとに 1 つの更新グループに制限するのではなく、さまざまな戦略に使用できます。 戦略の memberSelector を 2 つのレベルで構成することで、戦略のクラスターをメンバー ラベルでグループ化できます。

• ステージ レベル: ステージ全体のクラスターを選択します。 グループが定義されていない場合、一致するすべてのクラスターが 1 つの暗黙的なグループを形成します。 グループも定義されている場合、ステージ レベル セレクターは、グループ レベルの一致が適用される前に、事前フィルターとして機能します。
• グループ レベル: ステージ内の特定のグループのクラスターを選択し、異なるコンカレンシー制限を持つ並列サブセットを有効にします。

memberSelector では、標準の Kubernetes ラベル セレクター構文を使用して解析される文字列ベースのラベル セレクターが使用されます。 サポートされている演算子は、 =、 ==、 !=、 in、 notin、 exists、および !existsです。

メンバー ラベルを割り当て、戦略で memberSelector を使用する手順については、「 メンバー セレクターを使用して更新戦略を作成する」を参照してください。

最大コンカレンシー (プレビュー)

Maximum concurrency は、同時にアップグレードできるクラスターの数を制御する更新戦略のオプション設定です。 Maximum concurrencyは、次の 2 つのレベルで設定できます。

• ステージ レベル: ステージ内のすべてのグループで同時にアップグレードできるクラスターの最大数を定義します。 ステージのグローバル上限として機能します。
• グループ レベル: 特定のグループ内で同時にアップグレードできるクラスターの最大数を定義します。

最大コンカレンシーは、次の 2 つの値の形式を受け入れます。

• 固定整数: たとえば、 "3" はコンカレンシーを 3 つのクラスターに制限します。
• 割合: たとえば、 "25%" は、コンカレンシーをクラスターの割合に制限します。 ステージ レベルの設定の場合、割合はステージ内のすべてのクラスターから計算されます。 グループ レベルの設定の場合、割合はそのグループ内のクラスターから計算されます。 パーセンテージは実行時に計算され、小数点以下を切り捨てて、最小解決値を1として適用されます。

コンカレンシー制御の提案

安全性を使用してアップグレードする場合 (速度は低下しますが、複数の壊れたクラスターで終了する可能性は低くなります):最大コンカレンシーを小さい値に設定します。 速度でアップグレードする場合 (より高速ですが、複数の壊れたクラスターで終了する可能性が高い): 最大コンカレンシーを大きな値に設定します。

ステージとグループの制限の相互作用

ステージ レベルの最大コンカレンシーは、常に全体的な上限として機能します。 個々のグループが高いコンカレンシーを許可する場合でも、ステージの制限が優先されます。 ステージ レベルの制限、グループ サイズ、またはメンバー固有の条件により、グループ レベルのコンカレンシーが構成よりも低くなる可能性があります。

例 1: 固定の制限

結果: クラスターの合計は最大 4 つで、グループごとに最大 2 つ。

例 2: ステージ制限によるグループの抑制

結果: ステージの制限が優先されるため、同時にアップグレードされるクラスターの合計は 2 つだけです。

例 3: パーセンテージベースのロールアウト

ステージには、グループ A (8 つのクラスター) とグループ B (12 クラスター) の 2 つのグループに 20 個のクラスターがあります。

結果: 個々の制限に従ってグループ間で分散される最大 5 つの同時アップグレード。

許容される最大エラー数 (プレビュー)

Maximum allowed failures は、マルチクラスターの更新中の障害に対する Fleet Manager の対応方法を制御するオプションの更新戦略設定です。

既定では、更新はフェイル ファースト モデルに従います。1 つのクラスター障害によって、それ以降の更新が停止されます。 maximum allowed failuresを構成すると、更新プログラムの実行はエラー トレラントになり、指定された障害しきい値に達するまでクラスター間で更新が続行されます。

この設定では、早期エラー検出とデプロイのモメンタムの維持の間の意図的なバランスが提供されます。 maximum allowed failuresを 2 つのレベルに設定します。

• ステージ レベル: ステージが失敗としてマークされる前に、ステージ内のすべてのグループで許容されるメンバー アップグレードエラーの最大数を定義します。
• グループ レベル: グループが失敗としてマークされる前に、特定のグループ内で許容されるメンバー アップグレードエラーの最大数を定義します。

Maximum allowed failures は、次の 2 つの値の形式を受け取ります。

• 固定整数: たとえば、 "3" では、グループまたはステージが失敗としてマークされる前に、最大 3 つのメンバー クラスター障害が発生します。
• 割合: たとえば、 "25%" では、最大 25% のメンバー クラスターの障害が許可されます。 ステージ レベルの設定の場合、割合はステージ内のすべてのクラスターから計算されます。 グループ レベルの設定の場合、割合はそのグループ内のクラスターから計算されます。 パーセンテージは、上限の丸めを使用して更新の実行時に解決されます。たとえば、25%、5 個のクラスターが 2 に解決されます。

Fleet Manager は、失敗したメンバーの更新の数に対してのみ、 maxAllowedFailures を評価します。 成功率は評価されません。また、成功したメンバーの最小数は必要ありません。 この設定が存在する場合、 Completed は、Fleet Manager がスケジュールの決定を行った時点で、構成されたエラーしきい値を超えていなかったことを意味します。 Completed は、ロールアウトが正常または成功したことを意味するものではありません。

例: 成功率 0% で完了

グループに 4 つのメンバーがあり、 group.maxAllowedFailures が "4" に設定されている場合を想定します。 4 つのメンバー更新がすべて失敗した場合でも、グループは Completedマークできます。 この結果は、4 つのエラーが構成された許容範囲に等しいため、しきい値を超えないので、バグではなく意図的に想定されます。 つまり、メンバーの 100% が失敗した場合でも、グループを Completed できます。

このようなしきい値は、その動作がロールアウトの期待値と一致する場合にのみ使用してください。

しきい値を慎重に選択する

• 絶対値は理解しやすいですが、小規模なグループでは直感に反する結果をもたらすことがあります。 たとえば、2 つのメンバー グループで "2" エラーを許可することは、どちらのメンバーも成功しなかった場合でも、グループ Completed を終了できることを意味します。
• パーセンテージの値 は、さまざまなグループ サイズ間でより適切にスケーリングされるため、ほとんどのユーザーに推奨されます。
• 意図的に "メンバーが失敗したために失敗しない" 動作が意図的に必要な場合を除き、 maxAllowedFailures メンバーの合計数と同じ値に設定しないでください。 その動作が意図的な場合、通常、 100% は固定数よりも明確にスケーリングされます。
• 1 つの障害がロールアウトの大部分を表す可能性がある小さなグループには特に注意してください。
• フリートの増加に合わせてしきい値を再評価します。 5 つのクラスターで安全であると感じる値は、500 個のクラスターでは厳しすぎるか、制限が大きすぎる可能性があります。

FailureCount について

FailureCountフィールドはメトリックを報告しています。 メンバー更新の失敗件数をカウントします。 比率や割合ではなく、構成された強制しきい値と同じではありません。

• UpdateRun.FailureCount: 実行中のすべてのステージとすべてのグループで失敗したメンバーの更新の合計数。
• Stage.FailureCount: そのステージ内のすべてのグループで失敗したメンバーの更新の合計数。
• Group.FailureCount: そのグループ内で失敗したメンバーの更新の合計数。

ロールアウトの結果が受け入れられるかどうかを決定する前に、メンバー レベルの状態、条件、およびエラー メッセージと共に、これらのカウントを常に確認してください。

FailureCount が maxAllowedFailures を超える理由

maxAllowedFailures は、新しい作業を引き続きスケジュールするかどうかに関する Fleet Manager の判断を制御します。 これは、最終的に報告される失敗回数の厳密な上限ではありません。

maxConcurrencyを使用して並列メンバーの更新を許可した場合、Fleet Manager がしきい値を超えたことを確認し、より多くの作業のスケジュール設定を停止する前に、複数のメンバーがほぼ同時に失敗する可能性があります。 その結果、 FailureCount が構成された maxAllowedFailures 値より大きくなる可能性があります。

ステージとグループの失敗上限がどのように相互作用するか

グループ レベルとステージ レベルの maxAllowedFailures は、個別に評価されます。

• 各グループは、それぞれのしきい値に対して、それぞれの障害回数を追跡します。
• それらのグループの障害も、ステージの FailureCount に集約されます。
• いずれかのしきい値を超えた場合、Fleet Manager はそのセグメントの新しい作業のスケジュールを停止します。
• すでに開始済みのメンバー更新はその後も完了することがあり、その結果、停止が決定された後に報告される最終的な FailureCount が増加する可能性があります。

ステージ レベルの maxAllowedFailures は、ステージでの障害許容度の全体的な上限として機能します。 個々のグループでより多くの失敗回数が許可されていても、ステージの制限が優先されます。 グループの障害数が独自の maxAllowedFailuresを超えた場合、ステージ レベルの設定に関係なく、そのグループは失敗としてマークされます。

例 1: 固定された障害制限

結果: グループ A は最大 2 つの障害を許容し、グループ B は最大 3 つまで許容します。 ステージ全体の合計障害数が 5 を超えると、ステージは失敗します。

例 2: パーセンテージベースの許容範囲

ステージには、グループ A と 7 つのクラスター、グループ B と 12 個のクラスターの 2 つのグループに 19 個のクラスターがあります。

推奨される使用と推奨されていない使用

大規模なフリートをアップグレードする場合、一時的な障害が発生すると見込まれる場合、または厳密なフェールファスト動作を取ることよりもロールアウトの進行を優先する場合は、より高いしきい値またはパーセンテージ ベースのしきい値を使用します。

安全性が極めて重要なロールアウト、厳密に制御された本番段階、または最初の失敗後に必ず停止して確認する必要があるあらゆる状況では、0 または非常に小さい値を使用します。

次のステップ

• 方法: Azure Kubernetes Fleet Manager 更新プログラムの実行を使用して複数のクラスターをアップグレードする。
• 方法: Azure Kubernetes Fleet Manager を使用して複数のクラスターを自動的にアップグレードします。
• 方法: Azure Kubernetes Fleet Manager の更新プログラムの実行を監視します。
• マルチクラスターの更新に関する FAQ。