Azure Kubernetes Service（AKS）や AKS enabled by Azure Arc を運用している管理者にとって、今回確認すべきポイントは「Azure Arc 対応 Kubernetes クラスターで利用できる拡張機能の一覧が整理され、GitOps、監視、セキュリティ、証明書管理、エッジ AI などの運用領域を Azure 側から管理しやすくなっていること」です。
特に影響が大きいのは、Flux（GitOps）の非推奨 API 対応、Azure Policy 拡張機能の更新、cert-manager for Azure Arc-enabled Kubernetes のプレビュー追加、Edge RAG Preview の追加です。既存クラスターで拡張機能を使っている場合は、単に「新しい機能が増えた」と見るのではなく、拡張機能のバージョン、スコープ、サポート対象ディストリビューション、ネットワーク接続、既存 Helm インストールとの競合を確認する必要があります。Microsoft Learn では、Azure Arc 対応 Kubernetes クラスター拡張機能が Azure Resource Manager ベースでインストールとライフサイクル管理を行う仕組みとして説明されています。(Microsoft Learn)
Azure Arc 対応 Kubernetes クラスター拡張機能とは
Azure Arc 対応 Kubernetes クラスター拡張機能は、オンプレミス、エッジ、他クラウド、AKS on Azure Local などの Kubernetes クラスターに対して、Azure の監視、セキュリティ、ポリシー、GitOps、データサービスなどを追加するための仕組みです。
通常の Helm チャートを手動で入れる方法と違い、拡張機能は Azure Resource Manager のリソースとして管理されます。つまり、Azure Portal、Azure CLI、Azure Policy、ARM/Bicep などを使って、複数クラスターに対する導入状況や更新状態を一元管理できます。Microsoft の説明では、拡張機能は Helm のパッケージングを土台にしつつ、Azure Resource Manager 駆動のインストール、更新、削除を提供します。(Microsoft Learn)
AKS 利用者が見落としやすいのは、これは通常の Azure 上の AKS だけの話ではない点です。Azure Arc 対応 Kubernetes クラスターでは、AKS enabled by Azure Arc、AKS on Azure Local、Azure Red Hat OpenShift、GKE、EKS、Rancher、VMware Tanzu など、対応範囲が拡張機能ごとに異なります。そのため「AKS で使えるから、Arc 接続した全クラスターでも同じように使える」とは考えない方が安全です。
今回の更新で押さえるべき主な変更点
2026年5月時点で確認すべき変更点は、利用可能な拡張機能の追加・整理と、既存拡張機能の更新方針です。特に管理者が優先して見るべき項目は次のとおりです。
| 項目 | 変更・確認ポイント | 影響を受けやすい利用者 |
|---|---|---|
| Flux（GitOps） | 最新版と直近2世代、いわゆる N-2 がサポート対象。非推奨 API の削除予定に備えたマニフェスト更新が必要 | GitOps でアプリやクラスター設定を管理しているチーム |
| Azure Policy | 1.18.0 で Validating Admission Policy（VAP）生成が追加。Kubernetes 1.30 以降で CEL を含む Azure Policy が VAP を自動生成 | ガバナンス、ポリシー適用、Admission 制御を使う管理者 |
| cert-manager for Azure Arc-enabled Kubernetes | TLS 証明書と信頼バンドル管理の Microsoft サポート版拡張機能がプレビューとして追加 | 証明書更新、内部 CA、エッジ環境の TLS 管理に課題があるチーム |
| Edge RAG Preview | オンプレミスデータを使った RAG 型生成 AI 検索を Azure Arc 拡張機能として提供 | エッジ環境や閉域寄りのデータ活用を検討する組織 |
| Azure API Management on Azure Arc | 多くの拡張機能がクラスター スコープである一方、API Management は名前空間スコープ | API ゲートウェイをクラスター内の特定名前空間で運用するチーム |
Microsoft Learn の一覧では、ほとんどの拡張機能はクラスター スコープですが、Azure API Management on Azure Arc は名前空間スコープであると明記されています。拡張機能のスコープを誤ると、権限設計や削除時の影響範囲を読み違えやすいため、導入前に必ず確認してください。(Microsoft Learn)
利用可能な主な拡張機能と実務での使い分け
Azure Arc 対応 Kubernetes クラスターで利用できる拡張機能は多岐にわたります。すべてを導入するのではなく、目的に応じて選ぶことが重要です。
監視・運用管理で使う拡張機能
監視用途では、Azure Monitor の Container insights が代表的です。クラスター上のコントローラー、ノード、コンテナーから CPU やメモリ使用率などのメトリックを収集し、ワークロードのパフォーマンス把握に使えます。Microsoft Learn では、Container insights は CNCF 認定 Kubernetes クラスターをサポート対象としています。(Microsoft Learn)
既存環境で注意すべきなのは、過去に Helm チャートで Container insights を入れている場合です。Microsoft の手順では、拡張機能として Container insights を導入する前に、拡張機能を使わない古い Helm チャート インストールを削除する必要があるとされています。二重導入すると、収集エージェントの重複、ログ量の増加、設定の競合につながる可能性があります。(Microsoft Learn)
セキュリティ・ガバナンスで使う拡張機能
セキュリティとガバナンスでは、Azure Policy と Microsoft Defender for Containers が重要です。
Azure Policy 拡張機能は、Open Policy Agent（OPA）の Gatekeeper を拡張し、クラスターに対して集中管理されたポリシー適用を行うための仕組みです。2026年5月時点のリリースノートでは、Azure Policy Extension 1.18.0 に Validating Admission Policy（VAP）生成が導入され、Kubernetes 1.30 以降で CEL を含む Azure Policy が VAP を自動生成するとされています。(Microsoft Learn)
これは、Admission 制御の遅延削減や Kubernetes ネイティブなポリシー評価を重視する環境では注目すべき変更です。ただし、既存の Gatekeeper ベースのポリシー運用をすぐに置き換えるという意味ではありません。まずは、対象クラスターの Kubernetes バージョン、Azure Policy 拡張機能のバージョン、CEL を含むポリシーの有無を棚卸しするのが現実的です。
Microsoft Defender for Containers は、Kubernetes クラスターから監査ログなどのセキュリティ情報を収集し、推奨事項や脅威アラートを提供する拡張機能です。ただし、Azure Arc 対応 Kubernetes クラスター向けの Defender for Containers サポートはパブリック プレビューとされています。(Microsoft Learn)
本番環境で使う場合は、プレビュー機能の利用可否、社内のセキュリティ基準、サポート条件、リージョン制約を確認してから展開しましょう。
GitOps で使う Flux と Argo CD
GitOps では、Flux と Argo CD の拡張機能が確認対象です。
Flux 拡張機能は、Git リポジトリを信頼できる構成ソースとして使い、クラスター設定やアプリケーション展開を管理するための仕組みです。Microsoft Learn では、Flux 拡張機能の最新バージョンと直近2バージョン、つまり N-2 がサポート対象で、通常は最新バージョンの利用が推奨されています。(Microsoft Learn)
特に重要なのは、非推奨 API の削除予定です。Flux リリースノートでは、source.toolkit.fluxcd.io/v1beta1、kustomize.toolkit.fluxcd.io/v1beta1、helm.toolkit.fluxcd.io/v2beta1 など、複数の非推奨 API が今後削除される予定であり、互換性維持のために安定版 API へ移行するよう案内されています。(Microsoft Learn)
実務では、次のような置き換えを確認してください。
| リソース | 推奨される移行先 API の例 |
|---|---|
Kustomization | kustomize.toolkit.fluxcd.io/v1 |
HelmRelease | helm.toolkit.fluxcd.io/v2 |
GitRepository | source.toolkit.fluxcd.io/v1 |
HelmRepository | source.toolkit.fluxcd.io/v1 |
OCIRepository | source.toolkit.fluxcd.io/v1 |
Receiver | notification.toolkit.fluxcd.io/v1 |
ImageRepository | image.toolkit.fluxcd.io/v1beta2 |
GitOps の怖いところは、マニフェストが古い API のままでも、しばらくは動いているように見えることです。拡張機能や Kubernetes 側のアップグレード後に突然 reconcile が失敗するケースを避けるため、Git リポジトリ内の API バージョンを先に直しておきましょう。
証明書管理で使う cert-manager
今回の実務的な注目点の一つが、cert-manager for Azure Arc-enabled Kubernetes です。
この拡張機能は、Azure Arc に接続された Kubernetes クラスターで TLS 証明書と信頼バンドルを管理するための Microsoft サポート版 cert-manager / trust-manager を提供します。Microsoft Learn では、証明書の発行・更新、CA 証明書の名前空間間配布、企業 PKI との統合、エッジ環境や一時的な切断環境での利用をメリットとして挙げています。(Microsoft Learn)
たとえば、次のような環境では検討価値があります。
- 社内 CA で発行した証明書を複数名前空間に配布したい
- エッジ拠点の Kubernetes クラスターで証明書更新漏れを防ぎたい
- 手動で Kubernetes Secret を更新しており、期限切れリスクがある
- trust bundle をアプリごとに個別管理していて運用が属人化している
- オープンソース版 cert-manager を入れているが、Microsoft サポート版へ寄せたい
ただし、既存クラスターにすでに cert-manager や trust-manager を手動導入している場合は注意が必要です。Microsoft のトラブルシューティングでは、既存の cert-manager または trust-manager コンポーネントがあるクラスターに拡張機能をインストールしようとすると、リソース既存エラーが発生するケースが説明されています。(Microsoft Learn)
導入前には、以下を確認してください。
kubectl get ns cert-manager
kubectl get crds | grep cert-manager
kubectl get crds | grep trust.cert-manager.io既存リソースがある場合は、いきなり削除せず、どのアプリケーションが証明書を使っているか、Issuer / ClusterIssuer / Certificate / Secret の関係を洗い出してから移行計画を作るべきです。
管理者が確認すべき設定項目
Azure Arc 対応 Kubernetes クラスター拡張機能は便利ですが、導入時の設定を誤ると、更新不能、権限過多、予期しないバージョンアップ、名前空間の競合が起きます。管理者は次の項目を確認しましょう。
| 確認項目 | 見るべきポイント | よくある失敗 |
|---|---|---|
| 拡張機能の種類 | --extension-type が目的の拡張機能と一致しているか | 名前が似た拡張機能を選び間違える |
| クラスター種別 | Arc 対応 Kubernetes では基本的に connectedClusters を使う | AKS の managedClusters と混同する |
| 自動アップグレード | --auto-upgrade-minor-version を有効にするか、バージョン固定するか | 本番で意図しない更新、または逆にパッチ未適用 |
| リリース トレイン | Stable か Preview か | プレビュー機能を本番標準として扱ってしまう |
| スコープ | クラスター スコープか名前空間スコープか | API Management など名前空間スコープの設計漏れ |
| 設定値 | --configuration-settings と設定ファイルの使い分け | CLI 引数に機密情報を混ぜる |
| 保護された設定 | --config-protected-settings の扱い | 更新時に一部だけ指定し、未指定項目を削除してしまう |
| ネットワーク | Arc エージェントが Azure に接続できるか | 48時間以上接続できず、拡張機能が Failed になる |
Microsoft Learn では、Arc 対応 Kubernetes エージェントが48時間を超えてネットワーク接続できない場合、拡張機能をクラスター上に作成できず Failed 状態になると説明されています。閉域網、工場、店舗、船舶、遠隔地などのエッジ環境では、ネットワーク断を前提に運用設計をしてください。(Microsoft Learn)
展開前に実行したいチェックコマンド
既存環境に拡張機能を入れる前に、まず現在の状態を把握します。
Azure CLI 拡張機能を更新する
az extension add --upgrade --name connectedk8s
az extension add --upgrade --name k8s-extensionMicrosoft Learn では、事前条件として Azure CLI、connectedk8s、k8s-extension の最新バージョン利用が案内されています。古い CLI のまま作業すると、パラメーターが認識されない、状態表示が正しくない、プレビュー機能のコマンドが使えないといった問題が起きやすくなります。(Microsoft Learn)
インストール済み拡張機能を一覧表示する
az k8s-extension list \
--cluster-name <clusterName> \
--resource-group <resourceGroupName> \
--cluster-type connectedClusters確認する項目は、name、extensionType、installState、releaseTrain、version、autoUpgradeMinorVersion です。Pending や Failed のままになっている拡張機能がある場合、新しい拡張機能を追加する前に原因を確認しましょう。
個別の拡張機能を確認する
az k8s-extension show \
--name <extensionName> \
--cluster-name <clusterName> \
--resource-group <resourceGroupName> \
--cluster-type connectedClusters特に Flux、Azure Policy、Container insights、Defender、cert-manager は、バージョンと状態を必ず確認してください。
クラスター側の Pod と CRD を確認する
kubectl get pods -A
kubectl get crds
kubectl get namespacesAzure 側では Installed でも、クラスター側で Pod が CrashLoopBackOff、ImagePullBackOff、Pending になっていれば運用上は正常とは言えません。拡張機能は Azure のリソース管理と Kubernetes 内部の実体がセットで動くため、両方を見る必要があります。
Flux 利用者は非推奨 API を先に直す
Flux を使っているチームは、拡張機能のアップグレードより先に Git リポジトリ内のマニフェストを確認してください。
確認例は次のとおりです。
grep -R "toolkit.fluxcd.io/v1beta" ./manifests
grep -R "helm.toolkit.fluxcd.io/v2beta" ./manifests
grep -R "source.toolkit.fluxcd.io/v1beta" ./manifests古い API が見つかった場合は、対象リソースを安定版 API に置き換えます。たとえば HelmRelease で helm.toolkit.fluxcd.io/v2beta1 を使っているなら、helm.toolkit.fluxcd.io/v2 への移行を検討します。
移行時の注意点は、単純な文字列置換で終わらせないことです。API バージョンを変更すると、フィールド仕様やデフォルト動作が変わる場合があります。安全な進め方は次の順序です。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 現状確認 | Git リポジトリ内の Flux API バージョンを検索 | 非推奨 API が残っていないか |
| 差分作成 | API バージョンと必要なフィールドを更新 | kubectl apply --dry-run=server で検証 |
| 検証環境適用 | 本番と近い検証クラスターで reconcile を確認 | Flux の Ready が維持されるか |
| 本番反映 | 段階的に本番へ適用 | アプリのデプロイ遅延や失敗がないか |
| 拡張機能更新 | microsoft.flux を推奨バージョンへ更新 | N-2 サポート範囲に入っているか |
Flux リリースノートでは、次のリリースに備えて microsoft.flux 1.21.0 以上へアップグレードする必要がある旨も案内されています。自動アップグレードを無効にしているクラスターでは、手動更新の計画を立ててください。(Microsoft Learn)
Azure Policy 1.18.0 は Kubernetes 1.30 以降の環境で特に重要
Azure Policy Extension 1.18.0 では、Kubernetes ネイティブの Validating Admission Policy（VAP）生成が導入されています。Microsoft Learn では、Common Expression Language（CEL）を含む Azure Policy が Kubernetes 1.30 以降で VAP を自動生成すると説明されています。(GitHub)
管理者が見るべきポイントは次の3つです。
まず、クラスターの Kubernetes バージョンです。VAP の自動生成は Kubernetes 1.30 以降が対象とされているため、1.29以前のクラスターでは同じ効果を期待しない方がよいでしょう。
次に、Azure Policy 拡張機能のバージョンです。1.18.0 未満の場合は、更新計画を確認します。自動アップグレードを有効にしている場合でも、リリースが全リージョンに反映されるまで時間差が出ることがあります。
最後に、既存のポリシー定義です。CEL を含むポリシーを使っている場合は、VAP 生成によって Admission 評価の経路やトラブルシューティング観点が変わる可能性があります。検証環境で kubectl get validatingadmissionpolicy などを確認し、意図したポリシーが生成・評価されているかを見てください。
cert-manager 導入時の移行・展開上の注意点
cert-manager for Azure Arc-enabled Kubernetes は便利ですが、証明書管理は障害時の影響が大きい領域です。導入前に、既存の証明書管理を必ず棚卸ししてください。
既存 cert-manager がある場合
すでにオープンソース版 cert-manager を導入している場合、Microsoft サポート版拡張機能とリソースが競合する可能性があります。特に以下を確認します。
kubectl get deployment -n cert-manager
kubectl get clusterissuer,issuer -A
kubectl get certificate -A
kubectl get secret -A | grep tlsここで既存の ClusterIssuer や Certificate が見つかった場合、単純に namespace を削除するのは危険です。アプリケーションが参照している TLS Secret が消えれば、Ingress、mTLS、Webhook、内部 API 通信が止まる可能性があります。
証明書が更新されてもアプリが再読み込みしない場合
Microsoft のトラブルシューティングでは、証明書が更新されても Pod 内のプロセスが新しい Secret を認識しないケースが示されています。たとえば Java アプリケーションでは、キーストアの再読み込みやプロセス再起動が必要になる場合があります。(Microsoft Learn)
そのため、証明書自動更新を設計するときは、次の点を合わせて決めておきましょう。
- Secret 更新後にアプリが自動再読み込みできるか
- 再読み込みできない場合、再起動をどうトリガーするか
- Ingress コントローラーやサービスメッシュが証明書更新を検知するか
- 証明書期限切れ前にアラートを出せるか
- 本番証明書と検証証明書の Issuer を分けているか
証明書管理の目的は「cert-manager を入れること」ではありません。期限切れ、信頼チェーン不備、誤配布、更新後の未反映を防ぐことです。
Edge RAG Preview は AI 活用だが、本番適用は慎重に判断する
Available extensions の一覧には、Edge RAG Preview enabled by Azure Arc も含まれています。これは、オンプレミスデータに対して Retrieval Augmented Generation（RAG）を使い、生成 AI による検索やチャットアシスタント構築を可能にする Azure Arc 対応 Kubernetes 拡張機能です。Microsoft Learn では、AKS enabled by Azure Arc をサポート対象として示しています。(Microsoft Learn)
ただし、Preview と付く機能は、正式提供済みの機能と同じ前提で本番採用しない方が安全です。特に次の観点を確認してください。
| 確認観点 | なぜ重要か |
|---|---|
| データの所在 | オンプレミスデータや機密文書を扱うため、保存場所と転送経路の確認が必要 |
| アクセス制御 | RAG は検索できるデータ範囲が回答品質と情報漏えいリスクに直結する |
| 監査ログ | 誰が何を検索したか、どのデータが参照されたかを追跡できる必要がある |
| ネットワーク | エッジ環境では切断や帯域制限を前提に設計する必要がある |
| Preview 条件 | サポート、SLA、リージョン、将来の仕様変更リスクを確認する必要がある |
AI/Copilot 系の更新として見るなら、Edge RAG は「Azure Arc 上の Kubernetes を、生成 AI のエッジ実行基盤として使う流れ」の一部と捉えると分かりやすいです。ただし、PoC と本番では見るべきポイントが違います。PoC では検索精度や使い勝手を検証し、本番では認可、監査、データ分類、障害時運用まで設計してください。
自動アップグレードとバージョン固定の判断基準
拡張機能には、自動で minor / patch バージョンへ更新する設定と、特定バージョンに固定する設定があります。Microsoft Learn では、auto-upgrade-minor-version を true にすると最新の minor / patch に自動アップグレードされ、通常はセキュリティ修正や機能更新を受けるために自動アップグレードが推奨されています。一方で、major バージョンアップは破壊的変更を含む可能性があるため自動アップグレード対象外です。(Microsoft Learn)
判断基準は次のように考えると実務で迷いにくくなります。
| 運用方針 | 向いている環境 | 注意点 |
|---|---|---|
| 自動アップグレード有効 | セキュリティ修正を優先したい、標準構成に寄せたい、検証環境がある | 更新後の動作確認と監視を自動化する |
| バージョン固定 | 規制要件が厳しい、変更管理が必要、アプリ依存が強い | パッチ未適用状態を放置しない |
| 検証環境のみ自動、本番は手動 | 本番影響を抑えつつ更新に追従したい | 検証から本番反映までの期限を決める |
| Preview トレイン利用 | 新機能検証、PoC、限定環境 | 本番標準にしない。サポート条件を確認する |
おすすめは、検証クラスターでは自動アップグレードを有効にし、本番クラスターでは変更管理プロセスに合わせて段階的に更新する運用です。特に Flux、Azure Policy、cert-manager のようにクラスター全体の構成・ポリシー・証明書に関わる拡張機能は、アップグレード前後で動作確認項目を明文化しておきましょう。
拡張機能を導入する基本手順
ここでは、Arc 対応 Kubernetes クラスターに拡張機能を導入するときの基本的な流れを整理します。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 事前確認 | 対象拡張機能のサポート対象、Preview / Stable、スコープを確認 | クラスター種別と Kubernetes バージョンが合っているか |
| CLI 更新 | Azure CLI と connectedk8s、k8s-extension を更新 | 古い CLI による失敗を防ぐ |
| 既存状態確認 | az k8s-extension list と kubectl get pods -A を実行 | 既存拡張機能や Helm 導入と競合しないか |
| 作成 | az k8s-extension create を実行 | --cluster-type connectedClusters を指定 |
| 状態確認 | Azure 側の installState と Kubernetes 側の Pod 状態を見る | Installed / Succeeded と Pod Running を両方確認 |
| 運用監視 | ログ、アラート、更新方針を設定 | Failed、証明書期限、reconcile 失敗を検知 |
基本コマンド例は次のとおりです。
az k8s-extension create \
--name <extensionName> \
--extension-type <extensionType> \
--cluster-name <clusterName> \
--resource-group <resourceGroupName> \
--cluster-type connectedClusters \
--release-train Stable \
--auto-upgrade-minor-version true拡張機能ごとに必要な --configuration-settings は異なります。たとえば Azure Monitor なら Log Analytics ワークスペース、cert-manager なら証明書関連の設定、Azure Policy なら ARO Guardrails との関係などを確認する必要があります。共通コマンドだけをコピーして本番に流すのは避けてください。
よくある失敗と回避策
拡張機能が Failed になる
エージェントの接続断、権限不足、イメージ取得失敗、既存リソースとの競合が主な原因です。まず Azure 側で az k8s-extension show を実行し、次にクラスター側で Pod のイベントとログを確認します。
kubectl describe pod <podName> -n <namespace>
kubectl logs <podName> -n <namespace>閉域環境では、Azure Resource Manager、Microsoft Container Registry、Azure Container Registry、Microsoft Entra ID などへの通信要件も確認してください。
Preview 機能を本番で使ってしまう
Defender for Containers、Azure Container Apps on Azure Arc、Event Grid on Kubernetes、API Management on Azure Arc、Argo CD、Fleet Manager、cert-manager など、一部の機能はプレビューとして案内されています。Preview は検証や限定利用には有用ですが、本番システムの標準機能として採用する場合は、SLA、サポート、リージョン、将来変更の可能性を確認すべきです。(Microsoft Learn)
Protected settings を一部だけ更新してしまう
--config-protected-settings は、機密情報を含む設定に使われます。Microsoft Learn では、保護された設定を更新する場合、1つだけ変更する場合でもすべての保護設定を指定する必要があり、省略した設定は削除されると説明されています。(Microsoft Learn)
本番でこのミスをすると、接続文字列、認証情報、シークレット参照が消えて拡張機能が動かなくなる可能性があります。更新前に現在の設定を確認し、変更管理手順書に「protected settings は全量指定」と明記しておきましょう。
削除したのにクラスター側に残る
Azure 側で拡張機能リソースを削除しても、Kubernetes クラスター側の Helm release 削除は、クラスター上のエージェントが Azure サービスに接続できる場合に実行されます。Microsoft Learn でも、削除コマンドは Azure の拡張機能リソースを即時削除する一方、クラスター側の Helm release 削除にはネットワーク接続が必要と説明されています。(Microsoft Learn)
切断環境で削除を実行した場合は、後からクラスター側の namespace、CRD、Pod、Helm release を確認してください。
既存環境で最初にやるべき棚卸し
今回の更新を受けて、管理者が最初に実施すべきことは「入れる機能を選ぶ」ことではなく「既存環境の状態を可視化する」ことです。
まず、Arc 接続済みクラスターを一覧化します。次に、各クラスターで利用中の拡張機能、バージョン、リリース トレイン、自動アップグレード設定を確認します。最後に、GitOps、証明書、監視、セキュリティ、ポリシーという運用領域ごとに、更新が必要なものを優先順位付けします。
優先順位は次のように考えるとよいでしょう。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 高 | Flux の非推奨 API、Azure Policy、証明書期限管理 | 将来のアップグレード失敗や本番停止につながりやすい |
| 中 | Container insights、Defender、ネットワーク接続要件 | 監視・セキュリティ運用に影響する |
| 中 | cert-manager プレビュー検証 | 手動証明書更新のリスクを下げられる |
| 低〜中 | Edge RAG Preview、Argo CD Preview、Fleet Manager Preview | PoC や限定環境から始めるのが安全 |
まとめ：Azure Arc 拡張機能は「一覧確認」ではなく「運用設計」まで見る
Azure Arc 対応 Kubernetes クラスターで利用できる拡張機能は、AKS やハイブリッド Kubernetes 環境を Azure から一元管理するうえで重要な仕組みです。今回確認すべきポイントは、Flux の非推奨 API 対応、Azure Policy 1.18.0 の VAP 生成、cert-manager for Azure Arc-enabled Kubernetes のプレビュー、Edge RAG Preview の追加、そして各拡張機能のスコープとサポート対象です。
管理者は、まず az k8s-extension list で現状を棚卸しし、Flux の古い API、証明書管理、Azure Policy、監視拡張機能の状態を確認してください。開発者は、GitOps マニフェスト、証明書の参照方法、アプリの証明書再読み込み、Preview 機能の利用範囲を見直すべきです。
次に取るべき行動は明確です。既存クラスターの拡張機能一覧を取得し、バージョンと状態を確認し、Flux と証明書管理から優先的に修正計画を作りましょう。新機能の導入よりも、まずは今動いているクラスターが将来の更新に耐えられる状態かを確認することが、安定した Azure Kubernetes Service / Azure Arc 運用への近道です。
コメント