Azure Kubernetes Fleet Managerは、複数のAzure Kubernetes Service（AKS）クラスタやArc-enabled Kubernetesクラスタをまとめて管理するためのサービスです。結論から言うと、今回の公式情報で管理者が最初に確認すべきポイントは「どのクラスタをFleetに参加させるか」「Hub clusterを有効にするか」「更新・配置・名前空間・ネットワーク機能のどこまでをFleet Managerに任せるか」です。概要ページでは、マルチクラスタ更新、Kubernetesリソース配置、Fleet Managed Namespaces、DNSベースの負荷分散、Cross-cluster networkingなどが整理されています。(Microsoft Learn)
Microsoft Learn上のOverviewページは2026年6月2日に最終更新され、GitHub上のページメタデータでは2026年6月1日付になっています。本稿では、2026年6月3日時点で確認できる公式情報をもとに、AKS管理者・プラットフォームチーム・開発チームが実務で確認すべき変更点と注意点を整理します。(Microsoft Learn)
Azure Kubernetes Fleet Managerとは
Azure Kubernetes Fleet Managerは、複数のKubernetesクラスタを「Fleet」という単位で扱い、Azure上からまとめて管理するためのAzureサービスです。対象はAKSクラスタだけではなく、Azure Arcに接続されたKubernetesクラスタも含まれます。これにより、AzureリージョンやサブスクリプションをまたいだAKSクラスタ、クラウド外やオンプレミス上のArc-enabled Kubernetesクラスタを、単一のFleet Managerリソースに参加させられます。(Microsoft Learn)
Fleet Managerが解決する主な課題は、クラスタが増えたときに発生する運用のばらつきです。たとえば、各AKSクラスタを個別にアップグレードしていると、Kubernetesバージョン、ノードイメージ、メンテナンス時間帯、アプリ配置ルールがクラスタごとにズレやすくなります。Fleet Managerを使うと、更新順序をステージ化したり、共通の名前空間を複数クラスタに展開したり、ラベルやポリシーに基づいてリソースを配置したりできます。(Microsoft Learn)
ただし、Fleet Managerは「すべてのAKS運用を自動化する万能機能」ではありません。新しいAKSクラスタの作成やライフサイクル管理は、公式FAQではロードマップ上の項目として扱われています。Fleet Managerの役割は、既存の複数クラスタを束ね、更新・配置・ネットワーク・名前空間管理をスケールさせることです。(Microsoft Learn)
今回の公式情報で押さえるべき変更点
今回のOverview更新で重要なのは、単に機能一覧が増えたことではありません。実務上は、Arc-enabled Kubernetesクラスタの扱い、Hub clusterが必要な機能、承認付き更新、Managed Namespaces、Cross-cluster networkingの位置づけを見直す必要があります。
| 確認ポイント | 変更・整理された内容 | 実務への影響 |
|---|---|---|
| Arc-enabled Kubernetesクラスタ | Overview上の「Arc-enabled Kubernetes clusters (preview)」という表記からpreviewが外れ、AKS以外のクラウドやオンプレミスのクラスタもメンバークラスタとして扱う説明になっています。(GitHub) | ハイブリッド／マルチクラウド環境をFleetに含める検討がしやすくなります。ただし、機能ごとの対応範囲はAKSとArcで異なるため、サポート表の確認が必須です。 |
| メンバークラスタ上限 | FAQでは、Fleet Managerに参加できるKubernetesクラスタ数が最大1,000クラスタと説明されています。(Microsoft Learn) | 大規模なAKS基盤や、部門別・地域別にクラスタを分けている組織でも設計対象に入りやすくなります。 |
| 承認付き更新 | Overviewの差分では、更新グループやステージに対する手動・自動承認の説明からpreview表記が外れています。一方で、詳細ページ側ではApproval gatesにpreview表記が残る箇所があります。(GitHub) | 本番導入時は、Overviewだけで判断せず、Update orchestrationの詳細ページで現在のステータスを確認する必要があります。 |
| Cross-cluster networking | Overviewに、メンバークラスタ向けのCross-cluster networkingでグローバルに利用できるサービスを構成するシナリオが追加されています。(GitHub) | 複数クラスタ間通信をFleet Managerで扱う選択肢が増えます。ただしpreviewであり、KubernetesバージョンやACNS/Ciliumなどの前提条件があります。 |
| Fleet Managed Namespaces | アプリケーションチームに複数クラスタ横断の名前空間アクセスを与え、リソースクォータ、ネットワークポリシー、ユーザーアクセスを名前空間単位で管理する説明に整理されています。(Microsoft Learn) | マルチテナント運用に有効ですが、既存namespaceの採用ポリシーや削除ポリシーを誤ると、想定外のリソース削除につながります。 |
まず決めるべきはHub clusterを使うかどうか
Azure Kubernetes Fleet Managerには、Hub clusterなしの構成と、Hub clusterありの構成があります。ここを間違えると、あとから使いたい機能が使えなかったり、コストやネットワーク設計をやり直すことになります。
| 構成 | 使える主な機能 | 向いているケース | 注意点 |
|---|---|---|---|
| Fleet Manager without hub cluster | Kubernetesバージョン更新、ノードイメージ更新 | 複数AKSクラスタの更新順序やメンテナンス制御を一元化したい場合 | Kubernetesリソース配置、Managed Fleet Namespaces、DNS load balancingなどは使えません。(Microsoft Learn) |
| Fleet Manager with hub cluster | 更新管理、リソース配置、Managed Fleet Namespaces、DNS load balancingなど | 複数クラスタへのアプリ配置、名前空間管理、マルチクラスタネットワークまで扱いたい場合 | Hub clusterの分の費用が発生します。Hub clusterは単一ノードのStandard tier AKSクラスタとして扱われます。(Microsoft Learn) |
重要なのは、Hub clusterなしからHub clusterありへのアップグレードは可能ですが、Hub clusterありからHub clusterなしへは戻せない点です。更新管理だけを目的に導入するなら、まずHubなしで始める判断も現実的です。一方で、アプリケーション配置や名前空間管理までFleet Managerに任せる予定があるなら、最初からHub clusterありで設計した方が無駄がありません。(Microsoft Learn)
また、Hub clusterをpublicにするかprivateにするかは作成後に変更できません。検証環境ではpublicが扱いやすい場合がありますが、本番環境では管理者の接続経路、Azure Policy、プライベートネットワーク、アウトバウンド通信要件まで含めてprivate構成を検討するのが安全です。(Microsoft Learn)
AKS管理者が確認すべき影響範囲
Azure Kubernetes Fleet Managerの更新は、AKSクラスタを日々運用する管理者に最も影響します。特に、アップグレード方式、メンテナンスウィンドウ、既存の自動更新設定、ノードイメージ選択を確認する必要があります。
更新管理は「順番」と「止めどころ」を設計する
Fleet ManagerのUpdate runは、複数のAKSクラスタに対するKubernetesバージョン更新やノードイメージ更新を、ステージ、グループ、戦略に分けて実行します。たとえば、最初に開発環境のクラスタ、次にステージング、最後に本番クラスタという順番を作れます。更新戦略を再利用できるため、毎回クラスタ単位で手順を組み直す必要がありません。(Microsoft Learn)
管理者が特に見るべき設定は次の通りです。
| 確認項目 | 判断基準 |
|---|---|
| Update stage | dev、staging、prodなど、障害時の影響が小さい順に分ける |
| Update group | リージョン、業務システム、クラスタラベル単位で更新対象を分ける |
| Maximum concurrency | 安全性を優先するなら小さく、速度を優先するなら大きくする。ただし本番では一気に多くのクラスタを更新しない |
| Approval gates | 本番前後で手動承認や自動チェックを挟みたい場合に検討する |
| Maintenance window | Fleet ManagerのUpdate runはAKS側のメンテナンスウィンドウを尊重するため、閉じていると更新が待機状態になる |
Fleet ManagerのUpdate runは、メンバークラスタごとのメンテナンスウィンドウを考慮します。メンテナンスウィンドウは更新を開始するトリガーではなく、「更新してよい時間帯」を定義するものです。更新が長時間Pendingになる場合は、ウィンドウが閉じている、または対象バージョンがそのAzureリージョンにまだ公開されていない可能性があります。(Microsoft Learn)
AKS側の自動更新設定を放置しない
Fleet Managerで自動更新を管理したい場合、既存AKSクラスタ側のauto-upgrade設定を確認する必要があります。公式FAQでは、AKSクラスタのauto-upgradeを有効にしたままだと、Fleet ManagerかAKS側の自動更新のどちらか先に実行された方が更新を行うと説明されています。Fleet ManagerはAKSクラスタ側のauto-upgrade設定を変更しません。(Microsoft Learn)
つまり、Fleet Managerを更新管理の中心にするなら、各メンバーAKSクラスタのauto-upgrade設定を棚卸しし、必要に応じて無効化する必要があります。ここを見落とすと、「Fleetの更新順序を設計したのに、別ルートで先に本番クラスタが更新された」という事故につながります。
ノードイメージはLatestとConsistentを使い分ける
Update runでは、ノードイメージの選択にLatestとConsistentがあります。Latestは各クラスタのリージョンで利用可能な最新イメージを使うため、セキュリティ修正を早く取り込みやすい選択です。一方、Consistentは対象クラスタ間で共通して使えるイメージを選ぶため、段階的に同じイメージを検証しながら展開したい場合に向いています。(Microsoft Learn)
注意点は、選択されたノードイメージの有効期間です。公式ドキュメントでは、ノードイメージバージョンは公開日から90日間のみ有効で、Update runの進行が遅れてこの期間を超えると、対象メンバークラスタの更新が失敗する可能性があると説明されています。更新を何週間も止める運用にするなら、承認待ちやメンテナンスウィンドウの設計を見直しましょう。(Microsoft Learn)
Arc-enabled Kubernetesクラスタを含める場合の注意点
今回の更新では、Arc-enabled Kubernetesクラスタがより前面に出ています。ただし、AKSクラスタとArc-enabled Kubernetesクラスタで利用できるFleet Manager機能は同じではありません。
公式のメンバークラスタ種別ページでは、AKSクラスタとArc-enabled Kubernetesクラスタの対応機能が分けて示されています。たとえば、Kubernetes／ノードイメージ更新はAKSクラスタではGAですが、Arc-enabled Kubernetesクラスタでは非対応です。一方、Workload placementはAKSとArc-enabled Kubernetesの両方でGAとされています。Managed Namespacesは両方でpreview、Managed Namespace RBACはAKSのみpreviewです。(Microsoft Learn)
Arc-enabled KubernetesクラスタをFleetに参加させる場合は、次のように考えると整理しやすくなります。
| 目的 | AKSクラスタ | Arc-enabled Kubernetesクラスタ |
|---|---|---|
| Fleetにメンバーとして参加 | 対応 | 対応 |
| Kubernetes／ノードイメージ更新 | 対応 | 非対応 |
| Workload placement | 対応 | 対応 |
| Managed Fleet Namespaces | preview | preview |
| Managed Namespace RBAC | preview | 非対応 |
| 非public Azureリージョン | 対応 | 非対応 |
Arc-enabled Kubernetesクラスタを使う場合は、クラスタ上にFleet関連コンポーネント用のリソースが必要です。公式ドキュメントでは、少なくとも210MBのメモリ、1 CPUコアの2%、Fleet関連エージェント用の3 Pod予約などが示されています。また、fleet-system namespaceはFleet関連コンポーネント用に作成されるため、直接変更しないようにします。(Microsoft Learn)
Fleet Managed Namespacesはマルチテナント運用に効くが削除ポリシーに注意
Fleet Managed Namespacesは、複数クラスタにまたがる名前空間を中央から管理するための機能です。プラットフォーム管理者は、namespace単位でCPUやメモリのリソースクォータ、ネットワークポリシー、ラベル、アノテーション、アクセス制御を適用できます。(Microsoft Learn)
実務では、次のような場面で役立ちます。
- 複数リージョンのAKSクラスタに同じアプリチーム用namespaceを用意する
- 開発チームごとにCPU・メモリ上限を設定する
- namespace単位で通信ポリシーを標準化する
- アプリチームにはnamespace内の権限だけを渡し、クラスタ全体の操作権限は渡さない
ただし、Fleet Managed Namespacesはpreview機能として説明されており、公式ドキュメントではpreviewはSLAや限定保証の対象外で、本番利用向けではないと明記されています。試験導入や非本番環境で動作を確認し、既存namespaceへの影響を把握してから本番適用を判断しましょう。(Microsoft Learn)
特に危険なのは、Adoption policyとDelete policyです。Adoption policyは、同名の既存namespaceがある場合にFleet Managed Namespaceがどう扱うかを決めます。Delete policyは、Azure側のManaged Fleet Namespaceリソースを削除したときに、メンバークラスタ上のKubernetes namespaceを残すか、namespace内のリソースごと削除するかを決めます。Deleteを選ぶと、対象namespaceとその中のリソースがメンバークラスタから削除されるため、既存namespaceを取り込む場合は特に慎重に扱う必要があります。(Microsoft Learn)
開発者が見るべきポイントはリソース配置とデプロイ導線
開発チームにとって重要なのは、Fleet Managerがアプリケーションの「配置先クラスタ」をどう決めるかです。Fleet Manager with hub clusterでは、KubernetesリソースをHub clusterにステージングし、ClusterResourcePlacement（CRP）やResourcePlacement（RP）を使ってメンバークラスタへ配布します。(Microsoft Learn)
大きく分けると、CRPはクラスタスコープのリソースやnamespace全体を配置する用途、RPは特定namespace内のConfigMap、Secret、Service、Deploymentなどを細かく配置する用途に向いています。たとえば、プラットフォームチームがCRPでmy-app namespaceを全クラスタへ作り、開発チームがRPで環境別のConfigMapだけを対象クラスタへ配布する、といった分担ができます。(Microsoft Learn)
配置先の決め方には、主に次の3種類があります。
| Placement policy | 使いどころ |
|---|---|
| PickFixed | 特定のクラスタ名を明示して配置したい場合 |
| PickAll | すべてのクラスタ、または条件に合う全クラスタへ配置したい場合 |
| PickN | 複数候補の中から指定数のクラスタを選び、可用性や分散を考慮したい場合 |
開発者が自分たちで複数クラスタの差分を手作業で管理している場合、Fleet Managerのリソース配置は運用ミスを減らす手段になります。ただし、配置ポリシーはクラスタラベルやnamespace設計に依存します。最初に「どのラベルを誰が管理するか」「本番クラスタを誤ってPickAllに含めないルールをどう作るか」を決めておきましょう。
Automated Deploymentsは便利だがpreview前提で扱う
Fleet Manager Automated Deploymentsは、GitHubリポジトリのソースコードからアプリをビルドし、Azure Container Registry（ACR）へイメージを発行し、Fleet Manager hub cluster上のnamespaceへマニフェストをステージングする機能です。新しいコミットをきっかけにパイプラインが動き、Fleet内の複数AKSクラスタへ展開する流れを作れます。(Microsoft Learn)
ただし、この機能はpreviewです。利用にはGitHubアカウント、アプリケーション、Hub clusterありのFleet Manager、メンバーAKSクラスタ、Hub cluster上のnamespace、ACR、メンバーAKSクラスタへのAcrPull権限が必要です。公式ドキュメントでは、Automated Deploymentsが初期設定時に「どのクラスタに配置されるか」を判断できないため、ACRの権限設定は自動化の対象外であり、権限を持つユーザーが別途設定する必要があると説明されています。(Microsoft Learn)
実務では、いきなり本番CI/CDに組み込むより、次の順序で検証するのが安全です。
- 非本番のFleet Manager with hub clusterを用意する
- 検証用GitHubリポジトリとACRを使う
- メンバーAKSクラスタに必要な
AcrPullを明示的に付与する - 生成されたGitHub Actions workflowを確認する
- CRPやRPによる配置先を限定する
- 本番導入前にロールバック手順と権限境界を確認する
DNS load balancingとCross-cluster networkingは用途を分けて考える
Fleet Managerのネットワーク系機能は、名前が似ていても目的が異なります。DNS-based load balancingは、複数AKSクラスタ上のServiceエンドポイントに対して、Azure Traffic Managerを使ったDNSベースの負荷分散を構成する機能です。公式ページではpreviewとして扱われ、TrafficManagerProfile、TrafficManagerBackend、ServiceExportなどのKubernetesリソースを使います。(Microsoft Learn)
一方、Cross-cluster networkingは、複数クラスタ間にまたがる通信を扱う機能です。Fleet ManagerがCilium multi-cluster相当の構成を管理し、接続されたクラスタ間でエンドポイントに直接通信できるようにします。ただし、こちらもpreviewであり、最大255メンバークラスタ、Kubernetes v1.32以上、ACNSとCiliumの有効化、単一のフラットネットワークなどの前提条件があります。(Microsoft Learn)
判断基準は次の通りです。
| やりたいこと | 検討する機能 | 注意点 |
|---|---|---|
| 複数AKSクラスタの外部公開ServiceにDNSで振り分けたい | DNS-based load balancing | Azure Traffic Manager、ServiceExport、一意のDNS hostname設計が必要 |
| クラスタ間でServiceをローカルのように呼びたい | Cross-cluster networking | ACNS/Cilium、ネットワーク前提、Kubernetesバージョン条件を満たす必要がある |
| 本番の重要通信に使いたい | 慎重に検証 | preview機能はSLAや保証の扱いを確認し、非本番で十分にテストする |
ネットワーク機能は、アプリケーション影響が大きい領域です。名前だけで採用を決めず、「外部ユーザー向けの負荷分散なのか」「クラスタ間の内部通信なのか」「DNS切替で足りるのか」「L3/L4レベルの接続性が必要なのか」を先に整理しましょう。
導入前のチェックリスト
Azure Kubernetes Fleet ManagerをAKS環境へ導入する前に、最低限次の項目を確認しておきましょう。
| 項目 | 確認内容 |
|---|---|
| Fleetの目的 | 更新管理だけか、リソース配置・namespace管理・ネットワークまで含めるか |
| Hub cluster | 必要か不要か。必要な場合、public/privateをどちらにするか |
| メンバークラスタ | AKSかArc-enabled Kubernetesか。機能ごとの対応範囲を確認したか |
| Entra tenant | メンバークラスタがFleet Managerと同じMicrosoft Entra tenantにあるか |
| 権限 | Fleet Manager、AKS、Arc-enabled Kubernetesに対する必要なAzure RBAC権限があるか |
| CLI | Azure CLI 2.82.0以降、fleet拡張機能1.8.3以降を使っているか |
| 更新設計 | Update stage、group、member labels、maintenance window、approvalの設計があるか |
| AKS自動更新 | Fleet Managerで管理する場合、既存AKSクラスタのauto-upgrade設定を見直したか |
| namespace設計 | Managed Fleet NamespacesのAdoption policyとDelete policyを理解したか |
| 配置ルール | CRP/RP、PickFixed/PickAll/PickN、クラスタラベルの管理責任を決めたか |
| ネットワーク | DNS load balancingやCross-cluster networkingを使う場合、preview前提と制限を確認したか |
特に、CLIのバージョン要件は見落としやすいポイントです。公式Quickstartでは、Azure CLI 2.82.0以降とfleet拡張機能1.8.3以降が前提として示されています。古い手元環境やCI/CDランナーで操作すると、ドキュメント通りのコマンドが動かない可能性があります。(Microsoft Learn)
移行・展開時に失敗しやすいポイント
Fleet Manager導入時の失敗は、機能そのものよりも「既存運用との重なり」で起きやすくなります。以下の点は、設計レビューで必ず確認しておきたい項目です。
| 失敗パターン | 何が起きるか | 回避策 |
|---|---|---|
| Hub clusterを通常のAKSクラスタのように扱う | Hub clusterはユーザーワークロードを実行する場所ではなく、直接変更も制限されます。(Microsoft Learn) | Hub clusterは管理プレーンとして扱い、アプリ実行先はメンバーAKSクラスタに限定する |
| public/private hubを後から変えようとする | Hub clusterのネットワークアクセスタイプは作成後に変更できません。(Microsoft Learn) | 本番作成前に接続経路、運用端末、踏み台、DNS、Firewallを確認する |
| AKS自動更新を有効にしたままFleet更新を設計する | AKS側かFleet Manager側のどちらか先に動いた方で更新され、意図した順序にならない可能性があります。(Microsoft Learn) | Fleet Managerで管理するクラスタはAKS側のauto-upgrade設定を棚卸しする |
| Arc-enabled KubernetesでAKSと同じ機能が使えると思い込む | 更新管理、DNS load balancing、Managed Namespace RBACなど、Arcでは非対応の機能があります。(Microsoft Learn) | 機能ごとにAKS/Arcの対応表を確認して設計する |
| Managed NamespaceのDelete policyを誤る | Deleteを選ぶとnamespace内のリソースも削除されます。(Microsoft Learn) | 既存namespaceを取り込む場合は、検証環境でAdoption/Delete動作を確認する |
| Update runを長期間止める | Consistent node imageの選択時など、対象イメージが90日を超えて無効になり、更新失敗につながる可能性があります。(Microsoft Learn) | 承認待ちを放置せず、更新完了までの期限を運用ルールに入れる |
| preview機能を本番前提で設計する | previewはSLAや限定保証の対象外で、本番用途に向かない場合があります。(Microsoft Learn) | 非本番で検証し、正式サポート状況を確認してから本番採用する |
管理者と開発者が次にやるべきこと
Azure Kubernetes Fleet Managerは、AKSのマルチクラスタ運用を標準化したい組織にとって有力な選択肢です。特に、クラスタ数が増えて更新順序や配置ルールが属人化している環境では、Update run、auto-upgrade profile、Fleet Managed Namespaces、Resource Placementの効果が出やすくなります。
一方で、導入の第一歩は機能を全部試すことではありません。まずは現在のAKSクラスタとArc-enabled Kubernetesクラスタを棚卸しし、次の3点を決めることが重要です。
- 更新管理だけをFleet Managerに任せるのか、リソース配置やnamespace管理まで含めるのか
- Hub clusterありで始めるのか、Hub clusterなしで段階的に始めるのか
- 本番クラスタに適用する前に、どの非本番クラスタでUpdate run、CRP/RP、Managed Namespacesを検証するのか
最初の導入対象としては、更新管理の一元化が最も取り組みやすい領域です。次に、クラスタラベルとnamespace設計を整えたうえで、Resource PlacementやFleet Managed Namespacesを段階的に試すとよいでしょう。DNS load balancingやCross-cluster networkingなどのネットワーク機能は影響範囲が大きいため、previewである点と前提条件を確認し、検証環境で十分に動作を見てから採用判断するのが安全です。
コメント