Azure Kubernetes Fleet Manager

解決する課題

• AKS クラスターがリージョンや環境ごとに増えすぎて、個別運用が回らなくなってきた
• 同じ ConfigMap・Namespace・RBAC・アプリ構成を全クラスターへ一貫して配布したい
• Kubernetes やノードイメージの更新を、クラスターを段階的・順序立ててロールアウトしたい（一斉適用による全停止を避けたい）
• 複数リージョンの同一サービスへクラスター横断でトラフィックを分散し、近接や可用性を高めたい
• 1台のクラスターで足りるならフリートは不要で、素の AKS だけで十分

主要概念と用語

• フリート（Fleet）: 管理対象の AKS クラスター群をまとめる論理単位。1つの Azure リソースとして表現される
• ハブクラスター: フリートの制御面。配布や更新の状態を保持する。ハブを持つ構成と、軽量に束ねるだけの構成を選べる
• メンバークラスター: フリートに参加（join）した個々の AKS クラスター。ラベルを付けて選択対象にできる
• リソース伝播（Resource Propagation）: ハブに置いたマニフェストを、選択したメンバークラスターへ配布する仕組み
• ClusterResourcePlacement（CRP）: どのリソースをどのメンバークラスターへ配るかを宣言するカスタムリソース
• 更新ラン / 更新ステージ: 更新を適用する順序・グループ・待機を定義するオーケストレーション単位
• マルチクラスター負荷分散: 複数メンバー上の同一サービスへ L4 でトラフィックを振り分ける機能

仕様・制限・クォータ

• フリートには複数の AKS クラスターをメンバーとして参加させられ、サブスクリプションやリージョンをまたいで束ねられる
• ハブあり構成ではリソース伝播やマルチクラスター負荷分散などのデータプレーン機能が使え、ハブなし構成では更新オーケストレーションを中心に軽量に運用できる
• メンバークラスター数や1フリートあたりの上限、対象リージョンには制限があり、具体値は変動するため最新は公式ドキュメントで確認する
• メンバーは既存の AKS クラスターを後から joinでき、フリート専用にゼロから作り直す必要はない
• 更新オーケストレーションは Kubernetes バージョンとノードイメージの両方を対象にでき、ステージ単位の順序付けと待機を定義できる

内部の仕組み

Fleet Manager は、複数の AKS クラスターを「フリート」というメタな管理単位で束ねます。各クラスターはメンバーとして join し、ラベルを付けておくことで「本番だけ」「特定リージョンだけ」といった選択ができます。

ハブあり構成では、フリートのハブクラスターが制御面となります。配布したいマニフェストをハブ側に置き、ClusterResourcePlacement（CRP） でどのリソースをどのメンバーへ配るかを宣言すると、リソース伝播の仕組みが対象メンバーへ反映します。これにより、共通の Namespace・RBAC・ポリシー・アプリ構成を多数のクラスターへ一貫して展開できます。

更新は更新ランとして定義し、メンバーをステージにグループ化して順序と待機を与えます。たとえば「カナリア用のクラスター群を先に更新し、問題なければ本番群へ進める」といった段階適用を、クラスターを1つずつ手作業で触らずに実行できます。さらにマルチクラスター負荷分散を使うと、複数メンバー上の同一サービスへ L4 でトラフィックを分散し、リージョン横断の可用性を高められます。

設計パターン / ベストプラクティス

• メンバークラスターには環境・リージョン・役割のラベルを付け、CRP の選択条件で配布先を明確にする
• 共通リソース（Namespace・RBAC・ポリシー）はハブから伝播し、クラスターごとの個別差分は最小限に保つ
• 更新はステージで段階化し、カナリア群から本番群へ進む順序と待機を定義してリスクを抑える
• マルチクラスター負荷分散は、リージョン横断の可用性やトラフィック近接が必要なサービスに限定して使う
• フリートは AKS の置き換えではなく上位のオーケストレーション層と捉え、個々のクラスター運用の基本は AKS 側の作法を踏襲する

運用・監視

• 伝播が反映されない → CRP の選択条件とメンバーのラベル、対象リソースの種類、メンバーの join 状態を確認
• 更新が進まない/止まる → 更新ランのステージ定義と待機条件、対象メンバーの更新可否、AKS 側のバージョン互換を確認
• 個々のメンバークラスターの詳細は、従来どおり AKS／Container Insights（Azure Monitor）と kubectl で調査する
• フリート全体の状態はハブ側で俯瞰し、メンバー単位の深掘りは各 AKS に降りる、という二段の見方で運用する

コスト

• フリート機能そのものに加え、メンバーである各 AKS クラスターのノード（VM）・ディスク・ロードバランサには引き続き課金が発生する
• ハブあり構成ではハブクラスター相当のリソースが伴うため、ハブなし構成で足りるかをまず検討するとコスト効率がよい
• 具体的な料金は変動するため、最新は公式の料金ページで確認する

セキュリティ

• フリートおよびメンバーへのアクセスは Entra ID と Azure RBAC で最小権限に設計する
• ハブから配布する RBAC・ネットワークポリシー・ガードレールを共通化し、全クラスターで一貫したセキュリティ基準を保つ
• メンバークラスター個別のワークロード ID・Key Vault 連携・Defender for Containers などの対策は、各 AKS 側の設計を踏襲する
• 伝播対象に機密情報を含むマニフェストを置く場合は、平文の埋め込みを避け Key Vault 連携などを用いる

関連サービス・比較

単体の AKS が「1クラスターの運用」を担うのに対し、Fleet Manager は「多数の AKS クラスターを横断する運用」を担います。両者は置き換え関係ではなく、フリートが AKS の上位に乗る形です。

ハンズオン / CLI例

# fleet 拡張機能を追加
az extension add --name fleet

# リソースグループを準備
az group create --name demo-rg --location japaneast

# ハブありのフリートを作成
az fleet create \
  --resource-group demo-rg \
  --name demo-fleet \
  --location japaneast \
  --enable-hub

# 既存の AKS クラスターをメンバーとして参加させる
az fleet member create \
  --resource-group demo-rg \
  --fleet-name demo-fleet \
  --name member-eastus \
  --member-cluster-id <AKS_CLUSTER_RESOURCE_ID>

# メンバー一覧を確認
az fleet member list \
  --resource-group demo-rg \
  --fleet-name demo-fleet -o table

# フリートのハブへ接続する資格情報を取得
az fleet get-credentials \
  --resource-group demo-rg \
  --name demo-fleet