Azure Kubernetes Service（AKS）を複数リージョン、オンプレミス、他クラウドで運用している管理者にとって、今回のポイントは明確です。Azure Kubernetes Fleet Manager が Azure Arc-enabled Kubernetes クラスターを GA サポートしたことで、AKS だけでなく、Arc で接続した Kubernetes クラスターも Fleet のメンバーとして一元管理しやすくなりました。 Azure Updates では「Azure Kubernetes Fleet Manager for Arc-enabled clusters」が Launched として案内されており、Launched は本番利用可能な正式リリースを意味します。(Microsoft Azure)
ただし、AKS 向けの Fleet Manager 機能がそのまま Arc-enabled Kubernetes にすべて開放されたわけではありません。実務では、ワークロード配置は GA として使える一方、Kubernetes/node image 更新、DNS load balancing、cross-cluster networking などは Arc-enabled Kubernetes では未対応という線引きを最初に押さえることが重要です。(Microsoft Learn)
Azure Kubernetes Fleet Manager for Arc-enabled clustersで何が変わったのか
Azure Kubernetes Fleet Manager は、複数の Kubernetes クラスターを「Fleet」として束ね、更新、リソース配置、監視、ガバナンスを扱いやすくするための管理サービスです。公式ドキュメントでは、AKS クラスターをリージョンやサブスクリプションをまたいで参加させられるだけでなく、Arc-enabled Kubernetes クラスターもメンバーとして参加できると説明されています。(Microsoft Learn)
今回の GA により、Azure 上の AKS だけを中心に考えていた Fleet Manager の使い方が、オンプレミス、エッジ、他クラウドの Kubernetes まで広がります。Azure Updates では、Azure Kubernetes Fleet Manager が Azure Arc-enabled Kubernetes を GA でサポートし、CNCF 準拠ディストリビューションを Fleet のメンバーとして参加させられる趣旨が示されています。(Microsoft Azure)
| 観点 | これまでの課題 | GA後に期待できること |
|---|---|---|
| 管理対象 | AKS、オンプレ、他クラウドの Kubernetes を別々の管理画面・手順で扱いがち | Arc 接続済みクラスターを Fleet のメンバーとして扱える |
| 展開管理 | クラスターごとにマニフェスト適用や環境差分を調整しがち | Fleet のリソース配置で展開先を宣言的に制御しやすい |
| ガバナンス | 環境ごとに命名、権限、Namespace、ポリシーがばらつきやすい | Fleet 単位で運用ルールをそろえやすい |
| 本番利用判断 | プレビュー機能は SLA、サポート、運用リスクの確認が必要 | Launched/GA として本番設計に組み込みやすい |
| 注意点 | 「Fleetに入れれば全部一元化できる」と誤解しやすい | Arc では未対応の Fleet 機能があるため、用途別に見極めが必要 |
管理者が最初に理解すべきポイント
Fleet Managerは外部クラスターをAKS化するサービスではない
Arc-enabled Kubernetes クラスターを Fleet に参加させても、そのクラスターのコントロールプレーンやノードのライフサイクルが AKS と同じように Microsoft 管理になるわけではありません。
たとえば、EKS、GKE、オンプレミス Kubernetes、エッジ環境のクラスターを Arc 経由で Azure から見えるようにしても、元のクラスターのアップグレード、ノード管理、ネットワーク、ストレージ、障害対応の責任は基本的にその環境側に残ります。Fleet Manager は、あくまで複数クラスターをまとめて扱うための管理プレーンです。
この違いを理解せずに導入すると、「Fleetに入れたのに外部クラスターのバージョン更新が自動化されない」「DNSやネットワークも全部統合されると思っていた」といった認識違いが起きます。
主なメリットはワークロード配置と運用標準化
今回の GA で特に実務メリットが大きいのは、Arc-enabled Kubernetes クラスターに対する Workload placement です。公式の機能表では、AKS クラスターと Arc-enabled Kubernetes クラスターの両方で Workload placement が GA とされています。(Microsoft Learn)
たとえば、次のような運用で効果が出やすくなります。
- 国内リージョンの AKS とオンプレミス Kubernetes に同じ基盤コンポーネントを展開する
- 本番、検証、災害対策用のクラスターをラベルで分類し、配置先を制御する
- エッジ拠点ごとの Kubernetes に同一の監視エージェントや共通 Namespace を展開する
- 特定の地域、クラウド、コンプライアンス条件に合うクラスターだけを配置先に選ぶ
Fleet Manager の Arc 統合では、Arc-enabled Kubernetes クラスターに Fleet Arc Extension が導入され、メンバーエージェントが Fleet のハブクラスターと通信する構成になります。Arc-enabled Kubernetes クラスターは、Fleet のハブ上で MemberCluster リソースとして表現されます。(Microsoft Learn)
AKSとArc-enabled Kubernetesで使える機能の違い
今回の更新で最も注意すべきなのは、GA になったのは Arc-enabled Kubernetes クラスターを Fleet Manager のメンバーとして扱う部分であり、AKS 向けの全機能が Arc に対応したわけではないという点です。
公式ドキュメントの機能表を実務目線で整理すると、次のようになります。(Microsoft Learn)
| 機能 | AKSクラスター | Arc-enabled Kubernetesクラスター | 実務上の判断 |
|---|---|---|---|
| Kubernetes/node image updates | GA | 未対応 | 外部クラスターのバージョン更新管理は、従来の運用や各クラウドの仕組みが必要 |
| Workload placement | GA | GA | 今回の GA で最も使いやすくなった中核機能 |
| Cross-cluster networking | Preview | 未対応 | Arc クラスター間のネットワーク統合までは期待しない |
| DNS load balancing | GA | 未対応 | Arc を含むグローバルな DNS 分散用途では別設計が必要 |
| Managed Namespaces | Preview | Preview | 本番適用は組織のプレビュー利用ポリシーに従う |
| Managed Namespace RBAC | Preview | 未対応 | Arc 側の RBAC 統制は別途 Kubernetes RBAC や Azure Arc 側の設計が必要 |
| Non-public Azure regions | GA | 未対応 | Azure public cloud region 前提で設計する |
特に混同しやすいのが、更新管理です。Fleet Manager は AKS の複数クラスター更新を扱えますが、Arc-enabled Kubernetes クラスターでは Kubernetes や node image updates が未対応です。オンプレミスや他クラウドのクラスター更新まで Fleet Manager に集約する設計は、現時点では避けるべきです。
影響を受ける利用者と受けにくい利用者
影響が大きい組織
今回の GA の恩恵が大きいのは、Kubernetes クラスターが複数環境に分散している組織です。
| 組織・チーム | 具体例 | 期待できる効果 |
|---|---|---|
| プラットフォームチーム | AKS、オンプレ Kubernetes、他クラウド Kubernetes を横断管理している | 管理単位を Fleet に寄せ、配置や標準化を進めやすい |
| SRE/運用チーム | 拠点別・リージョン別に同じ運用コンポーネントを展開している | 監視、共通 Namespace、基盤リソースの展開漏れを減らしやすい |
| セキュリティチーム | クラスターごとの設定差分や権限差分を監査している | Fleet 単位で対象クラスターを把握しやすい |
| アプリケーション開発チーム | 複数クラスターへの段階的展開が必要 | 配置条件やロールアウト単位を設計しやすい |
| エッジ/店舗/工場系システム担当 | 小規模 Kubernetes が多数ある | 拠点単位のばらつきを抑えやすい |
影響が小さい組織
一方、単一の AKS クラスターだけを使っている場合は、今回の Arc 対応 GA による直接的な影響は大きくありません。単一クラスターの運用であれば、まずは AKS の標準機能、Azure Monitor、Azure Policy、Microsoft Defender for Cloud、GitOps などの整備を優先したほうが効果的です。
また、Arc-enabled Kubernetes を Fleet に入れたい理由が「外部クラスターのアップグレードをまとめたい」「Arc クラスターを含めて DNS load balancing したい」という場合も注意が必要です。これらは Arc-enabled Kubernetes 側では未対応のため、今回の GA だけでは要件を満たせません。(Microsoft Learn)
導入前に確認すべき前提条件
必要な権限を整理する
Fleet Manager にメンバークラスターを追加するには、Fleet Manager、AKS、Arc-enabled Kubernetes、リソースグループに対する権限が必要です。公式クイックスタートでは、Fleet Manager の read/write、members の read/write、AKS の managedClusters 操作、Arc-enabled Kubernetes の connectedClusters や KubernetesConfiguration extensions の read/write/delete、リソースグループの Contributor などが前提として示されています。(Microsoft Learn)
実務では、次のように権限を分けて確認すると安全です。
| 確認項目 | 見るべきポイント |
|---|---|
| Fleet Managerを作成・変更する権限 | Microsoft.ContainerService/fleets/* 相当の操作が許可されているか |
| メンバークラスター追加権限 | AKS または Arc-enabled Kubernetes の参照・登録に必要な権限があるか |
| Arc拡張機能の操作権限 | Microsoft.KubernetesConfiguration/extensions/write や delete が許可されているか |
| リソースグループ権限 | Contributor 相当の権限が過剰付与になっていないか |
| CI/CD実行主体 | 手動ユーザーではなく、サービスプリンシパルやマネージド ID で再現できるか |
最小権限で運用する場合は、検証環境で必要な操作を洗い出してから、カスタムロールに落とし込むのが現実的です。最初から広い Contributor を本番サブスクリプションに付与すると、後から棚卸しが難しくなります。
Hub clusterありで作るかを決める
Fleet Manager には hub cluster あり・なしの構成があります。Azure portal の作成手順では、hub cluster mode として、リソース配置、Managed Fleet Namespaces、DNS load balancing、クラスターアップグレードを使う構成と、安全な複数クラスター更新や監視向けの構成が示されています。(Microsoft Learn)
今回の Arc-enabled Kubernetes 連携で Workload placement を使うなら、基本的には hub cluster ありの構成を前提に検討します。ただし、hub cluster はアプリケーションを動かす場所ではありません。公式 FAQ でも、ユーザーワークロードは Fleet Manager hub cluster 上では実行できないと説明されています。(Microsoft Learn)
Arc-enabled Kubernetes側のリソース余力を確認する
Arc-enabled Kubernetes クラスターを Fleet Manager に追加すると、Fleet Manager Arc extension のエージェントが動作します。公式ドキュメントでは、少なくとも 210 MB のメモリ、1 CPU コアの 2% に相当する余力、Fleet 関連エージェント用の 3 Pod 分の予約が必要とされています。また、fleet-system Namespace が作成され、この Namespace は直接変更しないよう注意されています。(Microsoft Learn)
エッジ環境や小規模クラスターでは、この条件を軽く見ないほうがよいです。特に、監視エージェント、セキュリティエージェント、サービスメッシュ、ログ収集基盤がすでに動いているクラスターでは、Pod 数やメモリの余裕が不足しがちです。
ネットワークとプロキシを事前に確認する
Private Fleet を使う場合、Arc-enabled Kubernetes クラスターは Azure Arc Gateway を使う必要があります。また、TLS 終端プロキシはサポートされず、パススループロキシを使う場合も Azure Arc Gateway の構成が必要です。(Microsoft Learn)
企業ネットワークでは、プロキシ、SSL インスペクション、閉域接続、ファイアウォール制御が原因でエージェント通信が失敗することがあります。導入前に、次の観点を確認してください。
| 確認項目 | 失敗しやすいポイント | 対策 |
|---|---|---|
| Outbound通信 | クラスターから Azure 側への通信が遮断される | 必要な宛先、ポート、プロキシ設定をネットワークチームと確認する |
| TLSインスペクション | TLS 終端プロキシによりサポート外構成になる | パススルー方式と Azure Arc Gateway の利用を検討する |
| Private Fleet | Arc Gateway 前提を見落とす | 検証時点で Private Fleet と同じネットワーク条件を再現する |
| エッジ拠点 | 一時的な回線断でエージェント状態が不安定になる | オフライン時の運用手順と復旧確認を用意する |
リージョン制限を確認する
Arc-enabled Kubernetes クラスターの Fleet Manager サポートは、Azure public cloud regions のみが対象です。非パブリッククラウドリージョンで Arc-enabled member cluster を作成しようとすると、FeatureNotAvailableInCloud エラーが返ると説明されています。(Microsoft Learn)
Azure Government、Azure China、ソブリンクラウド、特殊な規制環境を検討している場合は、今回の GA をそのまま前提にしないでください。導入可否はリージョン、クラウド環境、Azure Arc Gateway の対応状況を個別に確認する必要があります。
移行・展開の進め方
いきなり本番Fleetに混ぜない
プレビュー時代から検証していた環境がある場合でも、GA 後にすぐ本番の全クラスターを Fleet に参加させるのは避けるべきです。まずは、影響範囲が限定された検証用の Fleet を作り、Arc-enabled Kubernetes クラスターを 1〜2 台だけ参加させます。
おすすめの進め方は次の通りです。
| 手順 | 作業内容 | 成功条件 |
|---|---|---|
| 棚卸し | AKS、Arc-enabled Kubernetes、対象外クラスターを一覧化する | 所有者、用途、リージョン、ネットワーク、Kubernetes バージョンが分かる |
| 小さく検証 | 非本番の Fleet Manager を作成する | hub cluster あり構成で作成できる |
| Arc接続確認 | 対象クラスターが Azure Arc に正常接続されているか確認する | connected cluster と拡張機能の状態が正常 |
| メンバー追加 | Arc-enabled Kubernetes クラスターを Fleet に追加する | MemberCluster として認識される |
| 配置テスト | 共通 Namespace や非重要ワークロードを配置する | 期待したクラスターだけに反映される |
| 運用設計 | 監視、ロールバック、権限、変更申請を整備する | 本番展開前のチェックリストが完成する |
| 段階展開 | dev、staging、本番の順に対象を広げる | 障害時に影響範囲を限定できる |
プレビュー時代のAPIやIaCを見直す
プレビュー時代から ARM、Bicep、Terraform、SDK、CI/CD パイプラインで Fleet Manager を扱っていた場合は、API バージョンや provider の対応状況を確認してください。Fleet Manager のプレビュー API は、一定期間で非推奨・廃止される可能性があり、公式ドキュメントでも preview API や関連ツールを定期的に更新することが推奨されています。(Microsoft Learn)
確認すべきポイントは次の通りです。
- ARM/Bicep テンプレートに
*-previewの API バージョンが残っていないか - Terraform provider が GA 後のリソースやプロパティに対応しているか
- Azure CLI と
fleet拡張機能が古いまま固定されていないか - CI/CD のサービスプリンシパルに Arc 拡張機能の操作権限があるか
- プレビュー時代の CRD やマニフェストが現行ドキュメントと合っているか
「Azure portal ではできるが CI/CD では失敗する」という状態は、本番運用でよくある落とし穴です。検証段階から手動操作だけでなく、実際のデプロイ経路でも動作確認しておきましょう。
管理者が確認すべき設定チェックリスト
| 項目 | 確認内容 | 判断基準 |
|---|---|---|
| Fleet構成 | hub cluster ありで作成しているか | Workload placement を使うなら hub cluster ありを基本にする |
| メンバー種別 | AKS と Arc-enabled Kubernetes を区別しているか | 機能差を前提に運用手順を分ける |
| クラスター命名 | Fleet 内で一意で分かりやすい名前か | 環境、地域、用途が判別できる |
| ラベル設計 | 配置条件に使うラベルが定義されているか | env=prod、region=japan、tier=edge などを標準化する |
| 権限 | Fleet、Arc、拡張機能の操作権限があるか | 人ではなく CI/CD 実行主体でも再現できる |
| ネットワーク | Arc Gateway、プロキシ、Outbound 通信を確認したか | 本番と同じ条件でエージェント通信を検証済み |
| Namespace | fleet-system を直接変更していないか | Fleet 関連 Namespace は運用対象から除外する |
| 監視 | Arc クラスターのログ取得制限を理解しているか | Fleet agent logs の Arc 対応状況を確認する |
| 更新管理 | AKS の auto-upgrade と Fleet 管理が競合しないか | Fleet で管理する AKS は個別 auto-upgrade の扱いを明確にする |
| リージョン | Public Azure region 前提か | 非パブリッククラウドでは利用可否を事前確認する |
Arc-enabled Kubernetes クラスターでは、Fleet agent logs のログ取り込みが現在サポートされていない点にも注意が必要です。AKS と同じ監視設計をそのまま流用すると、トラブルシュート時に必要な情報が不足する可能性があります。(Microsoft Learn)
開発者が気を付けるべき設計ポイント
「どのクラスターで動くか」をアプリ側でも意識する
Fleet Manager の Workload placement を使うと、配置先クラスターを宣言的に制御しやすくなります。ただし、アプリケーション側が複数クラスター配置を前提にしていなければ、運用時に問題が出ます。
確認すべき代表例は次の通りです。
| 観点 | 確認すること |
|---|---|
| コンテナイメージ | すべての対象クラスターから ACR やレジストリに到達できるか |
| Secret | 同じ Secret を全クラスターへ配布してよいか |
| ConfigMap | 環境別の値をハードコードしていないか |
| Ingress | Arc クラスターを含む入口設計を別途用意しているか |
| DNS | Fleet の Arc 対応だけで DNS 分散できると誤解していないか |
| 永続データ | DB、Storage、PVC が配置先ごとに適切か |
| 監視 | アプリログ、メトリック、トレースの集約先が決まっているか |
特に Secret とネットワークは慎重に扱うべきです。複数クラスターへ同じマニフェストを置けることと、同じ資格情報を配布してよいことは別問題です。本番では、Azure Key Vault、External Secrets、各クラウドのシークレット管理、環境別の権限分離を組み合わせる設計が必要になります。
ロールアウトとロールバックはアプリ仕様まで含めて考える
Fleet Manager の Arc 統合では、段階的ロールアウトや配置先制御によって、複数クラスターへの展開をより安全に扱いやすくなります。公式の説明でも、Fleet Manager はヘルス確認を伴う段階的ロールアウトや、失敗時の停止・ロールバックにより blast radius を抑える考え方を示しています。(Microsoft Learn)
ただし、ロールバック可能なのは Kubernetes リソースだけとは限りません。データベーススキーマ、外部 API、メッセージキュー、キャッシュ、証明書、Feature Flag などが絡む場合、アプリケーション全体として戻せる設計が必要です。
たとえば、次のような設計にしておくと事故を減らせます。
- 破壊的な DB 変更はアプリの複数バージョン互換を確保してから行う
- Feature Flag で機能を段階的に有効化する
- クラスターごとのメトリックを見て展開を止められるようにする
- ロールバック時に古いコンテナイメージを確実に pull できるようにする
- 配置先ラベルの変更履歴を Git で管理する
失敗しやすいポイントと対策
| 失敗しやすいポイント | なぜ問題になるか | 対策 |
|---|---|---|
| GAだからArcでも全機能が使えると思う | Arc では更新、DNS load balancing、cross-cluster networking などが未対応 | 公式の機能表をもとに要件を分解する |
| 既存のArcクラスターを無条件に追加する | CPU、メモリ、Pod 数、ネットワーク要件を満たさない可能性がある | 非本番で extension 導入時の負荷を確認する |
fleet-system Namespaceを変更する | Fleet 関連コンポーネントの動作に影響する | 監視対象にはしても、手動変更や削除はしない |
| Private FleetでArc Gatewayを考慮しない | 通信要件を満たせずメンバー参加や同期に失敗する | 設計段階で Arc Gateway とプロキシ方式を確認する |
| TLS終端プロキシを通す | サポート外構成になり得る | パススルー方式と Arc Gateway を検討する |
| AKSのauto-upgradeとFleet更新を混在させる | どちらが先に更新するかで運用が読みにくくなる | Fleet で管理する AKS は個別 auto-upgrade の扱いを明確化する |
| 非パブリッククラウドで使えると思う | Arc member cluster サポートは public cloud regions 前提 | 利用リージョンとクラウド環境を事前確認する |
| 監視がAKSと同じと思い込む | Arc-enabled Kubernetes では Fleet agent logs の制限がある | Arc 側のログ・メトリック取得方法を別途設計する |
| クラスターIDやID管理を変更する | メンバークラスターと Fleet の通信が壊れる可能性がある | 変更時の再登録・復旧手順を用意する |
AKS の個別 auto-upgrade を有効にしたまま Fleet Manager でも更新を管理しようとすると、更新は Fleet Manager または AKS cluster auto-upgrade のどちらか先に実行された側で進むと説明されています。Fleet Manager で管理したい場合は、個別 AKS クラスター側の auto-upgrade 設定を無効にする必要があります。(Microsoft Learn)
また、Fleet Manager はメンバークラスターごとの maintenance window を尊重します。メンテナンスウィンドウは更新を開始するトリガーではなく、更新を適用できる時間帯を定義するものです。(Microsoft Learn)
どのような構成から始めるべきか
最初から全社標準の Fleet を作るより、用途を絞った小さな構成から始めるのがおすすめです。
検証に向いている構成
- AKS クラスター 1 台
- Arc-enabled Kubernetes クラスター 1 台
- hub cluster ありの Fleet Manager
- 非本番 Namespace
- 影響の小さい Deployment または ConfigMap
- 配置先制御用のシンプルなラベル
この構成なら、AKS と Arc-enabled Kubernetes の機能差を確認しながら、Workload placement の動き、権限、ネットワーク、エージェント通信、トラブルシュート方法を一通り検証できます。
本番展開前に決めるべき運用ルール
本番に進む前に、少なくとも次のルールは決めておきましょう。
| ルール | 決める内容 |
|---|---|
| Fleetの所有者 | 誰が Fleet Manager、hub cluster、メンバー追加を管理するか |
| クラスター参加基準 | どの条件を満たしたクラスターだけ Fleet に入れるか |
| ラベル標準 | 配置条件に使うラベル名と値をどう統一するか |
| 変更管理 | 配置ポリシー変更を誰がレビューするか |
| 障害時対応 | Fleet 同期失敗、Arc extension 異常、配置失敗時に誰が見るか |
| 監視設計 | AKS と Arc-enabled Kubernetes の監視差分をどう埋めるか |
| セキュリティ | Secret、RBAC、Namespace、ネットワークポリシーをどう扱うか |
| 機能制限 | Arc では未対応の Fleet 機能を代替手段で補うか |
今回のGAを受けて管理者が次にやるべきこと
まずは、既存の Kubernetes クラスターを棚卸ししてください。AKS、Arc-enabled Kubernetes、今後 Arc 接続したいクラスター、Fleet 管理の対象外にするクラスターを分けます。
次に、Arc-enabled Kubernetes で本当に Fleet Manager を使いたい理由を明確にします。理由が「複数環境へのワークロード配置を標準化したい」「クラスターごとの展開差分を減らしたい」「ハイブリッド/マルチクラウドの管理単位をそろえたい」であれば、今回の GA は有力な選択肢になります。
一方で、理由が「外部クラスターの Kubernetes 更新をまとめたい」「Arc クラスターを含めて DNS load balancing したい」「全クラスターのネットワークを Fleet だけで統合したい」であれば、現時点の機能差を踏まえて別の運用設計が必要です。
最後に、非本番の小さな Fleet で検証し、次の 5 点を確認してから本番展開へ進めるのが安全です。
- Arc-enabled Kubernetes クラスターを問題なく Fleet に追加できるか
- Workload placement が期待したクラスターだけに反映されるか
- ネットワーク、プロキシ、Arc Gateway の条件を満たしているか
- 監視とトラブルシュートの手順が AKS と Arc で分かれているか
- 本番展開時のロールバック手順がアプリケーション側まで含めて用意されているか
Azure Kubernetes Fleet Manager for Arc-enabled clusters の GA は、AKS を中心に Kubernetes 運用を標準化してきた組織にとって、ハイブリッド/マルチクラウド管理を一歩進める更新です。重要なのは、「Arc対応で何でもできる」と捉えるのではなく、Workload placement を軸に、対応機能と未対応機能を分けて設計することです。まずはクラスター棚卸しと小規模検証から始めることで、本番導入時の手戻りを大きく減らせます。
コメント