Azure Kubernetes Fleet Managerで許容失敗数を設定する方法｜少数の更新失敗で停止させない

Azure Kubernetes Fleet Managerのupdate runsで少数の更新失敗を許容するには、ステージまたはグループのmaxAllowedFailuresを設定します。たとえば"2"なら2件まで、"10%"なら対象クラスター数の10％を切り上げた件数まで失敗を許容し、しきい値を超えた段階で後続の更新を停止します。未設定または"0"の場合は、最初の失敗で止まる従来のfail-fast動作です。(Microsoft Learn)

この機能は2026年7月にパブリックプレビューとして公開されました。プレビュー中はAzure CLIのfleet拡張機能またはREST APIから設定し、AzureポータルではmaxAllowedFailuresを構成できません。まず非本番環境で動作と監視方法を確認してから利用することが重要です。

Azure Kubernetes Fleet Managerで更新失敗の許容しきい値を設定する

Azure Kubernetes Fleet Managerは、複数のAKSクラスターをステージとグループに分けて順番に更新できます。ステージは順番に実行され、同じステージ内のグループは並行して処理されます。

maxAllowedFailuresは、この更新中に何件のメンバークラスター更新失敗を許容するかを指定するプロパティです。

設定場所	失敗数の集計範囲	主な役割
ステージ	ステージ内の全グループ	ステージ全体の失敗上限を設定する
グループ	そのグループ内だけ	リージョンや環境などの単位で局所的な上限を設定する
未設定または`"0"`	該当するステージまたはグループ	1件目の失敗で停止するfail-fast
固定数	`"1"`、`"2"`など	許容できる失敗数が明確な場合に使う
割合	`"5%"`、`"25%"`など	クラスター数が増減する環境で使う

ステージとグループのしきい値は別々に評価されます。グループで発生した失敗は、そのグループの失敗数だけでなく、所属するステージの失敗数にも加算されます。ステージの設定は全体上限、グループの設定は局所的な上限として機能します。(Microsoft Learn)

maxAllowedFailuresは「設定値を超えたら停止」する

maxAllowedFailuresで特に間違えやすいのが、停止するタイミングです。

設定値は「停止する失敗数」ではなく、許容する失敗数です。そのため、"2"を設定した場合は2件目では止まらず、3件目の失敗でしきい値を超えます。

設定値	許容される失敗数	しきい値を超えるタイミング
未設定または`"0"`	0件	1件目
`"1"`	1件	2件目
`"2"`	2件	3件目
`"5"`	5件	6件目

しきい値を超えると、該当するステージまたはグループがFailedになり、その範囲で新しいクラスター更新がスケジュールされなくなります。ただし、すでに開始されている更新処理は完了まで動作する場合があります。(Microsoft Learn)

ステージとグループの両方を明示する

ステージとグループでは、それぞれ未設定時の値が0として扱われます。そのため、ステージ全体と各グループの両方で失敗を許容したい場合は、両方にmaxAllowedFailuresを記述するのが安全です。(Microsoft Learn)

たとえば、次の設定を考えます。

設定対象	maxAllowedFailures
ステージ全体	`"5"`
グループA	`"2"`
グループB	`"3"`

この場合、グループAは2件、グループBは3件まで失敗を許容します。同時に、ステージ全体では合計5件が上限です。

グループAで3件目の失敗が発生すれば、ステージ全体が5件以内でもグループAは失敗します。反対に、各グループが個別の上限内でも、ステージ全体の失敗数が5件を超えればステージが失敗します。(Microsoft Learn)

固定数と割合のどちらを選ぶべきか

maxAllowedFailuresには、固定数と割合の2種類を指定できます。

固定数が適しているケース

固定数は、許容できる失敗クラスター数が運用ルールとして明確な場合に適しています。

たとえば、次のような要件です。

各リージョンで1クラスターまでの失敗を許容する
検証環境では2クラスターまで処理を継続する
冗長構成上、停止せずに継続できるのは最大1クラスターまで

設定例は次のとおりです。

"maxAllowedFailures": "1"

クラスター数が常にほぼ一定の小規模グループでは、固定数のほうが結果を予測しやすくなります。

一方、2クラスターしかないグループに"2"を設定すると、2クラスターとも失敗しても許容範囲内です。固定数を使う場合は、設定値が対象クラスター数と同じになっていないかを必ず確認してください。(Microsoft Learn)

割合が適しているケース

割合は、フリートへのクラスター追加や削除があり、グループの規模が変化する場合に適しています。

"maxAllowedFailures": "25%"

割合は、update runを作成した時点の対象クラスター数に対して計算され、小数点以下は切り上げられます。

たとえば、5クラスターに"25%"を設定すると、計算結果は1.25ですが、許容失敗数は2件です。

対象クラスター数	設定割合	解決される許容失敗数
5	25％	2
7	25％	2
12	25％	3
19	25％	5

割合はフリート規模に追従しやすい一方、小規模グループでは実際の許容割合が大きくなります。計算上、1クラスターのグループに"10%"を設定しても切り上げによって1件となるため、唯一のクラスターが失敗しても許容範囲内です。小規模なcanaryグループでは、割合ではなく"0"や固定数を選ぶほうが判断しやすくなります。(Microsoft Learn)

Azure CLIでmaxAllowedFailuresを設定する手順

プレビュー中のmaxAllowedFailuresは、Azure CLIのfleet拡張機能またはREST APIから設定します。REST APIを直接利用する場合は、2026-06-02-preview以降のAPIバージョンが必要です。(Microsoft Learn)

Azure CLIとfleet拡張機能を準備する

fleet拡張機能をインストールしていない場合は、次のコマンドを実行します。

az extension add --name fleet

すでにインストール済みの場合は、最新バージョンへ更新します。

az extension update --name fleet

新しいプレビュープロパティを利用するため、Azure CLI本体とfleet拡張機能の両方を最新状態にしてから作業してください。(Microsoft Learn)

ステージとグループをJSONで定義する

次の例では、canaryステージをfail-fastにし、productionステージでは少数の失敗を許容しています。

fleet-stages.jsonという名前で保存します。

{
  "stages": [
    {
      "name": "canary-stage",
      "maxConcurrency": "1",
      "maxAllowedFailures": "0",
      "groups": [
        {
          "name": "canary",
          "maxConcurrency": "1",
          "maxAllowedFailures": "0"
        }
      ],
      "afterStageWaitInSeconds": 1800
    },
    {
      "name": "production-stage",
      "maxConcurrency": "4",
      "maxAllowedFailures": "10%",
      "groups": [
        {
          "name": "prod-east",
          "maxConcurrency": "2",
          "maxAllowedFailures": "1"
        },
        {
          "name": "prod-west",
          "maxConcurrency": "2",
          "maxAllowedFailures": "1"
        }
      ]
    }
  ]
}

この構成には、次の意図があります。

canary-stageは1クラスターずつ更新し、1件でも失敗したら停止する
canary完了後、30分待ってからproductionステージへ進む
productionステージ全体では、対象クラスター数の10％まで失敗を許容する
prod-eastとprod-westでは、それぞれ1件まで失敗を許容する
いずれかのグループで2件目の失敗が発生したら、そのグループのしきい値を超える
グループごとの上限以内でも、ステージ全体の上限を超えればステージを停止する

maxAllowedFailuresとmaxConcurrencyは文字列として記述します。固定値にも"1"のように引用符を付けてください。また、canary、prod-east、prod-westは、実際にFleetメンバーへ割り当てている更新グループ名に置き換えます。(Microsoft Learn)

JSONを指定してupdate runを作成する

環境変数を設定します。

export GROUP="rg-fleet"
export FLEET="my-fleet"
export RUN="aks-update-202608"
export TARGET_VERSION="<target-kubernetes-version>"

続いて、ステージ定義ファイルを指定してupdate runを作成します。

az fleet updaterun create \
  --resource-group "$GROUP" \
  --fleet-name "$FLEET" \
  --name "$RUN" \
  --upgrade-type Full \
  --kubernetes-version "$TARGET_VERSION" \
  --node-image-selection Latest \
  --stages fleet-stages.json

作成しただけでは更新は始まりません。内容を確認してから、次のコマンドで開始します。

az fleet updaterun start \
  --resource-group "$GROUP" \
  --fleet-name "$FLEET" \
  --name "$RUN"

--upgrade-typeには、コントロールプレーンとノードプールを更新するFull、コントロールプレーンのみのControlPlaneOnly、ノードイメージのみのNodeImageOnlyを指定できます。(Microsoft Learn)

繰り返し使う場合はupdate strategyとして保存する

毎回同じステージ構成を使う場合は、JSONをupdate strategyとして保存すると管理しやすくなります。

export STRATEGY="failure-tolerant-strategy"

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

保存したupdate strategyを指定してupdate runを作成します。

az fleet updaterun create \
  --resource-group "$GROUP" \
  --fleet-name "$FLEET" \
  --name "$RUN" \
  --upgrade-type Full \
  --kubernetes-version "$TARGET_VERSION" \
  --node-image-selection Latest \
  --update-strategy-name "$STRATEGY"

その後、通常どおりupdate runを開始します。

az fleet updaterun start \
  --resource-group "$GROUP" \
  --fleet-name "$FLEET" \
  --name "$RUN"

update strategyの内容は、update runを作成した時点でrun側へコピーされます。そのため、後からupdate strategyを変更しても、すでに作成済みのupdate runには反映されません。設定変更後は新しいupdate runを作成してください。(Microsoft Learn)

fail-fastと許容失敗数を使い分ける判断基準

すべてのステージで失敗を許容すればよいわけではありません。早期検出を優先する場所と、更新の継続を優先する場所を分けることが重要です。

運用要件	適した設定
最初の異常で必ず調査したい	`"0"`
canaryクラスターで安全性を確認したい	`"0"`と低い`maxConcurrency`
各リージョンで1件だけ許容したい	グループ単位で`"1"`
フリートの台数が頻繁に増減する	割合指定
全グループを通じた総失敗数も制限したい	ステージとグループの両方を設定
一時的な失敗があっても残りを更新したい	小さな固定数または割合
最終的な失敗件数を厳密に上限以内にしたい	`maxConcurrency`も小さくする

実務では、次のような多層構成が扱いやすくなります。

canaryステージはfail-fastにする

最初の1～数クラスターはmaxAllowedFailuresを"0"にして、更新手順そのものに問題がないかを確認します。

canaryで発生した失敗は、広範囲へ同じ問題が拡大する前に止めるべきシグナルです。ここで失敗を許容しすぎると、段階的ロールアウトの意味が薄れます。

本番ステージは全体上限と局所上限を分ける

本番環境では、ステージに全体の許容割合を設定し、各リージョンやサービスグループには固定数の上限を設定する方法が有効です。

たとえば、ステージ全体では"10%"、各リージョングループでは"1"とします。これにより、1つのリージョンへ失敗が集中した場合は早く止めつつ、別リージョンで発生した単発の失敗では全体を止めない構成にできます。

許容失敗数とmaxConcurrencyをセットで考える

maxAllowedFailuresは、最終的な失敗件数を強制的に設定値以内へ収める機能ではありません。

たとえば、許容失敗数を"1"、maxConcurrencyを"4"にしていると、4クラスターが並行更新され、そのうち複数がほぼ同時に失敗する可能性があります。Fleet Managerがしきい値超過を検出して新しい処理を止めるまでに、開始済みの更新が失敗するため、最終的なFailureCountが1を超えることがあります。

同時に失敗し得るクラスター数を抑えたい場合は、許容失敗数だけでなくmaxConcurrencyも小さくしてください。(Microsoft Learn)

設定時に失敗しやすいポイント

よくある認識	実際の動作	対応
`"2"`なら2件目で停止する	2件までは許容され、3件目で超過する	許容数として設計する
ステージだけ設定すればすべて継続する	未設定のグループは`0`として扱われる	必要なグループにも明示する
グループだけ設定すれば全体も継続する	未設定のステージはfail-fastのままになる	ステージ全体の上限も設定する
`Completed`なら全クラスター成功している	許容範囲内の失敗が残っている可能性がある	`FailureCount`とメンバー状態を確認する
FailureCountは設定値を超えない	並行処理中の複数失敗で超える場合がある	`maxConcurrency`を調整する
クラスター数と同じ値を設定すれば安全	全クラスター失敗でも`Completed`になり得る	総数と同じ値を避ける
update strategyを直せば既存runも変わる	作成済みrunには反映されない	新しいrunを作成する
Azureポータルから設定できる	プレビュー中はCLIまたはREST APIのみ	JSONとCLIで管理する

特に注意したいのは、Completedが「正常」や「全件成功」を保証しない点です。4クラスターのグループに"4"を設定した場合、4クラスターすべてが失敗しても、失敗数は設定値を超えていないためCompletedになり得ます。(Microsoft Learn)

update runの実行結果を確認する

update runの状態は、次のコマンドで確認できます。

az fleet updaterun show \
  --resource-group "$GROUP" \
  --fleet-name "$FLEET" \
  --name "$RUN" \
  --output jsonc

確認すべきなのは、最上位のrun状態だけではありません。

update run全体のFailureCount
各ステージのFailureCount
各グループのFailureCount
各メンバークラスターのstate
失敗したメンバークラスターのmessage
実際に解決されたmaxAllowedFailures
後続のステージやグループが開始されたか

失敗したメンバークラスターの状態は、しきい値の範囲内でrunが継続してもFailedのままです。Completedだけを監視条件にせず、FailureCount > 0も検知対象にしてください。Microsoftの監視例でも、最終状態がFailedの場合に加え、Completedであっても失敗数が1件以上あるrunを検出する方法が示されています。(Microsoft Learn)

まずはcanaryをfail-fastのまま検証する

Fleet Managerの更新を少数の失敗で停止させないためには、maxAllowedFailuresを単純に大きくするのではなく、次の順序で設計します。

最初に、業務影響なく許容できる失敗クラスター数を決める
canaryステージは"0"と低いmaxConcurrencyで早期検出を優先する
本番ステージには全体上限を設定する
各リージョンやサービスグループには局所的な上限を設定する
クラスター数が変動する大規模環境では割合を検討する
小規模グループでは切り上げの影響を確認する
実行後はCompletedだけでなくFailureCountとメンバー状態を確認する

最初は非本番のupdate runで意図的に失敗ケースを作り、1件目、許容上限、上限超過後の動作を確認すると安全です。従来のfail-fastへ戻す場合は、ステージとグループのmaxAllowedFailuresを"0"に設定します。(Microsoft Learn)

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure Kubernetes Fleet Managerで許容失敗数を設定する方法｜少数の更新失敗で停止させない

Azure Kubernetes Fleet Managerで更新失敗の許容しきい値を設定する

maxAllowedFailuresは「設定値を超えたら停止」する

ステージとグループの両方を明示する

固定数と割合のどちらを選ぶべきか

固定数が適しているケース

割合が適しているケース

Azure CLIでmaxAllowedFailuresを設定する手順

Azure CLIとfleet拡張機能を準備する

ステージとグループをJSONで定義する

JSONを指定してupdate runを作成する

繰り返し使う場合はupdate strategyとして保存する

fail-fastと許容失敗数を使い分ける判断基準

canaryステージはfail-fastにする

本番ステージは全体上限と局所上限を分ける

許容失敗数とmaxConcurrencyをセットで考える

設定時に失敗しやすいポイント

update runの実行結果を確認する

まずはcanaryをfail-fastのまま検証する

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure Kubernetes Fleet Managerで許容失敗数を設定する方法｜少数の更新失敗で停止させない

Azure Kubernetes Fleet Managerで更新失敗の許容しきい値を設定する

maxAllowedFailuresは「設定値を超えたら停止」する

ステージとグループの両方を明示する

固定数と割合のどちらを選ぶべきか

固定数が適しているケース

割合が適しているケース

Azure CLIでmaxAllowedFailuresを設定する手順

Azure CLIとfleet拡張機能を準備する

ステージとグループをJSONで定義する

JSONを指定してupdate runを作成する

繰り返し使う場合はupdate strategyとして保存する

fail-fastと許容失敗数を使い分ける判断基準

canaryステージはfail-fastにする

本番ステージは全体上限と局所上限を分ける

許容失敗数とmaxConcurrencyをセットで考える

設定時に失敗しやすいポイント

update runの実行結果を確認する

まずはcanaryをfail-fastのまま検証する

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル