複数のメンバー クラスター間での更新のオーケストレーション

多数のクラスターを管理するプラットフォーム管理者は、安全かつ予測可能な方法で複数のクラスターの更新 (ノード OS イメージのバージョンのアップグレード、Kubernetes のバージョンのアップグレードなど) をステージングする際に問題を抱えていることがよくあります。 この問題点に対処するために、Azure Kubernetes Fleet Manager (フリート) では、更新実行、ステージ、グループ、戦略を使って複数のクラスター間で更新を調整できます。

• 更新実行: 更新実行は、AKS クラスターのコレクションに適用される更新を表し、更新の目標とシーケンスで構成されます。 更新目標には、必要な更新が記述されています (たとえば、Kubernetes バージョン 1.28.3 へのアップグレード)。 更新シーケンスは、ステージとグループを使って表現された、複数のメンバー クラスターに更新を適用する正確な順序が記述されます。 指定しない場合、すべてのメンバー クラスターが 1 つずつ順番に更新されます。 更新の実行は停止および開始できます。
• 更新ステージ: 更新実行は複数のステージに分割され、順次適用されます。 たとえば、最初の更新ステージでテスト環境のメンバー クラスターを更新し、その後、2 番目の更新ステージで運用環境のメンバー クラスターを更新します。 待機時間で、後続の更新ステージの適用間の延期期間を指定できます。
• 更新グループ: 各更新ステージには 1 つ以上の更新グループが含まれており、更新するメンバー クラスターを選ぶために使われます。 更新グループは、メンバー クラスターへの更新の適用を順序付けるためにも使われます。 更新ステージ内では、更新はすべての異なる更新グループに並列で適用されます。更新グループ内では、メンバー クラスターが順番に更新されます。 フリートの各メンバー クラスターは、1 つの更新グループにのみ含めることができます。
• 更新戦略: 更新戦略では、ステージとグループによる更新シーケンスが記述されます。 実行ごとにシーケンスを繰り返し定義する代わりに、更新実行で戦略を再利用できます。

現在、クラスターでサポートされている更新操作はアップグレードです。 次の 2 種類のアップグレードから選択できます。

• Kubernetes コントロール プレーンとノードの Kubernetes バージョンをアップグレードします (ノード イメージのアップグレードを含みます)。
• ノード イメージのみをアップグレードします。

アップグレード先のターゲット Kubernetes のバージョンを指定できますが、使用できる最新のノード イメージのバージョンはクラスターのリージョンによって異なる場合があるため、正確なターゲット ノード イメージのバージョンを指定することはできません (詳細については、リリース トラッカーを確認してください)。 ターゲット ノード イメージのバージョンは、設定に基づいて自動的に選ばれます。

• Latest: クラスターのアップグレードの開始時に、クラスターのリージョンで使用できる最新のノード イメージを使います。 その結果、クラスターがどのリージョンに存在するか、そのアップグレードが実際にはいつ開始されるかに応じて、異なるイメージのバージョンが使われる可能性があります。
• Consistent: 更新実行が開始されると、クラスター間で同じ一貫したイメージのバージョンが使われるように、この実行のメンバー クラスターのリージョン全体で最新の共通イメージのバージョンが選ばれます。

より新しいイメージのバージョンを使ってセキュリティ リスクを最小限にするには、Latest を選ぶ必要があります。また、後のクラスターで使う前に、クラスター内のイメージを初期の段階で使って確認することで信頼性を向上させるには、Consistent を選ぶ必要があります。

定期的なメンテナンス

更新実行では、Azure Kubernetes Service (AKS) クラスター レベルで設定した計画メンテナンス期間が優先されます。

更新実行 (1 つずつ または ステージ 型の更新実行の両方) 内で、更新実行では次の順序でクラスターのアップグレードが優先されます。

1. オープンし進行中のメンテナンス期間があるメンバー。
2. 今後 4 時間以内にメンテナンス期間がオープンするメンバー。
3. メンテナンス期間のないメンバー。
4. クローズド メンテナンス期間があるメンバー。

更新実行の状態

更新実行は、次のいずれかの状態になる可能性があります。

• NotStarted: 更新実行が開始される前の状態。

• Running: 更新実行で、少なくとも 1 つのクラスターに対してアップグレードが進行中です。

• [Pending]\(保留中\):

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

• Skipped: 更新実行のすべてのレベルをスキップできます。これはシステムによって検出されるか、ユーザーによって開始される可能性があります。

  • Member:
    • メンバーまたはその親のアップグレードをスキップしました。
    • メンバー クラスターは既にターゲット Kubernetes バージョンにあります (更新実行モードが Full または ControlPlaneOnly の場合)。
    • メンバー クラスターは既にターゲット Kubernetes バージョンにあり、すべてのノード プールはターゲット ノード イメージ バージョンにあります。
    • アップグレード実行に一貫性のあるノード イメージが選択されている場合、いずれかのノード プールのターゲット イメージ バージョンが見つからない場合、そのクラスターのアップグレードはスキップされます。 この状況の例としては、更新実行が開始された後に、新しい VM SKU を持つ新しいノード プールが追加される場合が挙げられます。
  • グループ:
    • すべてのメンバー クラスターは、システムによって Skipped として検出されました。
    • グループ レベルでスキップを開始しました。
  • Stage:
    • ステージ内のすべてのグループは、システムによって Skipped として検出されました。
    • ステージ レベルでスキップを開始しました。
  • Run:
    • すべてのステージがシステムによって Skipped として検出されました。

• Stopped: 更新実行のすべてのレベルを停止できます。 停止状態に入る可能性は 2 つあります。

  • 更新実行を停止すると、その時点で更新実行によるすべての操作の追跡が停止します。 更新実行によって操作がすでに開始されている場合 (クラスターのアップグレードが進行中など)、その操作は個々のクラスターに対して中止されません。
  • 更新実行中にエラーが発生した場合 (たとえば、いずれかのクラスターでアップグレードが失敗した場合)、更新実行全体が停止状態になり、更新実行で後続のクラスターに対して操作は試行されません。

• Failed: クラスターのアップグレードに失敗すると、次のアクションが発生します。

  • メンバー クラスター上で MemberUpdateStatus を Failed としてマークします。
  • すべての親 (グループ -> ステージ -> 実行) を Failed としてマークし、概要エラー メッセージを表示します。
  • 更新実行がこれ以上進行するのを停止します。

次のステップ

• 複数のメンバー クラスター間で更新を調整する。