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

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

更新の実行はステージ、グループ、および戦略で構成され、1 回限りの更新の場合は手動で適用するか、または自動アップグレード プロファイルを使用する継続的な定期更新の場合は自動的に適用できます。 すべての更新の実行 (手動または自動) では、メンバー クラスターのメンテナンス期間が優先されます。

更新の実行について

次の図は 2 つの更新ステージを含むアップグレードの実行を視覚化したもので、各ステージには 2 つの更新グループがあり、それぞれに 2 つのメンバー クラスターが含まれています。 待機期間は、最初と 2 番目のステージの間で構成されます。

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

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

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

アップグレード先の Kubernetes バージョンを指定できますが、正確なターゲット ノード イメージのバージョンを指定することはできません。 これは、クラスターの Azure リージョンによって、利用可能な最新のノード イメージのバージョンが異なる可能性があるためです (詳細は AKS リリース トラッカーをご確認ください)。

ターゲット ノード イメージのバージョンは、設定に基づいて自動的に選ばれます。

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

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

定期的なメンテナンス

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

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

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

更新実行の状態

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

• NotStarted: 更新の実行が開始されていません。
• Running: 更新の実行で、少なくとも 1 つのメンバー クラスターに対してアップグレードが進行中です。
• Pending:
  • Member cluster: メンバー クラスターは、次のいずれかの理由で保留中状態になる可能性があり、メッセージ フィールドで確認できます。
    • メンテナンス期間がオープンしていません。 メッセージに次回のオープン時刻が示されています。
    • ターゲット Kubernetes バージョンは、そのメンバーの Azure リージョンではまだ使用できません。 メッセージはリリース トラッカーにリンクされるため、リージョン間でリリースの状態を確認できます。
    • ターゲット ノード イメージのバージョンは、そのメンバーの Azure リージョンではまだ使用できません。 メッセージはリリース トラッカーにリンクされるため、リージョン間でリリースの状態を確認できます。
  • 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 つあります。
  • 更新実行を停止すると、その時点で更新実行によるすべての操作の追跡が停止します。 更新の実行によって操作がすでに開始されている場合 (クラスターのアップグレードが進行中など)、その操作は個々のクラスターに対して中止されません。
  • 更新の実行中にエラーが発生した場合 (たとえば、クラスターの 1 つでアップグレードに失敗した場合など)、更新の実行全体が停止状態になります。 更新の実行で後続のクラスターに対する操作は試行されません。
• Failed: クラスターのアップグレードに失敗すると、次のアクションが発生します。
  • メンバー クラスター上で MemberUpdateStatus を Failed としてマークします。
  • すべての親 (グループ -> ステージ -> 実行) を Failed としてマークし、概要エラー メッセージを表示します。
  • 更新実行がこれ以上進行するのを停止します。

Note

スキップまたは失敗したアップグレードを再適用するために、いつでも更新の実行は再実行できます。

自動アップグレード プロファイルについて (プレビュー)

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

重要

Azure Kubernetes Fleet Manager のプレビュー機能は、セルフサービス、オプトイン ベースで利用できます。 プレビューは、"現状有姿のまま" および "利用可能な限度" で提供され、サービス レベル アグリーメントおよび限定保証から除外されるものとします。 Azure Kubernetes Fleet Manager のプレビューは、ベストエフォート ベースでカスタマー サポートによって部分的にカバーされます。 そのため、これらの機能は、運用環境での使用を意図していません。

自動アップグレード プロファイルでは、次の構成が可能です。

• クラスターに適用される自動アップグレードの種類を決定する Channel (Stable、Rapid、NodeImage)。
• クラスターをアップグレードするシーケンスを構成する UpdateStrategy。 戦略が指定されていない場合は、クラスターは 1 つずつ順番に更新されます。
• Kubernetes バージョンをアップグレードするときにノード イメージを選択する方法を指定する NodeImageSelectionType (Latest、Consistent)。

安定チャネル

安定チャネルは、マイナー バージョン N-1 で常に AKS でサポートされている最新の Kubernetes パッチ リリースです。ここで、N は、サポートされている最新のマイナー バージョンを指します。

例 :

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

ラピッド チャネル

ラピッド チャネルは、常に AKS でサポートされている最新の Kubernetes のマイナー リリースです。

例 :

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

NodeImage チャネル

メンバー クラスター ノードは、週 1 回の頻度で、セキュリティ修正とバグ修正を含む新しくパッチが適用された VHD で更新されます。 新しい VHD の更新は、メンテナンス期間とサージ設定に従って中断されます。 このオプションを選んだ場合、追加の VHD コストは発生しません。

このチャネルを使用する場合、Linux の無人アップグレードは既定で無効になります。 ノード イメージのアップグレードでは、非推奨になったパッチ バージョンであっても、Kubernetes のマイナー バージョンがまだサポートされている限り、サポートされます。 ノード イメージは AKS でテストされ、完全に管理され、安全なデプロイ プラクティスで適用されます。

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

例:

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

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

自動アップグレードでは、Kubernetes のマイナー バージョン間に 1 つ以上のバージョン差がある場合、Kubernetes クラスターを別のマイナー バージョンに移行しません (例: 1.28 から 1.30)。 管理者がさまざまなバージョンの Kubernetes を使用している場合は、まず 1 回以上の更新の実行を使用して、メンバー クラスターを一貫したバージョンのリリースに統一することをお勧めします。これにより、構成された Stable または Rapid チャネル更新プログラムで、将来にわたって一貫性が維持されることが保証されます。

Note

自動アップグレードを使用する場合は、次の情報にご注意ください。

• 自動アップグレードには、Fleet Azure CLI 拡張機能のバージョン 1.3.0 以降が必要です。

• 自動アップグレードは Kubernetes の GA バージョンにのみ更新され、プレビュー バージョンには更新されません。

• 自動アップグレードには、クラスターの Kubernetes バージョンが AKS サポート期間内である必要があります。

• クラスターに計画メンテナンス期間が定義されていない場合、更新の実行がクラスターに到達するとすぐにアップグレードされます。

• Kubernetes のバージョンをアップグレードする場合は、autoupgradeprofile を Rapid または Stable チャネルで作成する必要があります。

• NodeImage のバージョンをアップグレードする場合は、autoupgradeprofile を NodeImage チャネルで作成する必要があります。

• 同じフリートに対して複数の自動アップグレード プロファイルを作成できます。

次のステップ

• 方法: Azure Kubernetes Fleet Manager の更新の実行を使用して、複数のクラスターをアップグレードします。
• 方法: Azure Kubernetes Fleet Manager を使用して複数のクラスターを自動的にアップグレードします。