AKS 運用でつまずきやすいのは、「問題がクラスタ全体なのか、特定の namespace や workload なのか」を見極める前に、Insights、Grafana、Log Analytics、kubectl を何度も行き来してしまうことです。2026年4月8日、Microsoft は AKS 名前空間とワークロード ビューの可観測性 が GA（一般提供）に到達したと公開しました。AKS の Namespace / Workload 画面に、Azure Monitor managed service for Prometheus の可観測性データが直接表示されるようになり、クラスタやワークロードの健全性確認、pending / failed pod の切り分け、nodes・namespaces・workloads・pods をまたいだリソース利用状況の把握、event / utilization summary を使った pod 性能評価がしやすくなります。 (Microsoft)
この改善の本質は、監視ツールを増やすことではなく、Kubernetes オブジェクトの文脈で最初の判断を下しやすくすることです。Microsoft は 2024年5月21日の Build 2024 関連ブログで、AKS object overviews に Azure Monitor managed service for Prometheus ベースの observability を埋め込む方向性を示しており、今回の GA でその流れが本番運用の導線として扱いやすい段階に入ったと見てよいでしょう。この記事では、AKS 名前空間とワークロード ビューの可観測性が何を変えるのか、Azure Monitor for AKS の既存機能とどう使い分けるのかを、実務目線で整理します。 (TECHCOMMUNITY.MICROSOFT.COM)
AKS 名前空間とワークロード ビューの可観測性が GA に到達で何が変わるか
GA でいちばん大きい変化は、調査の入口をクラスタ全体ではなく、問題の起きている namespace / workload に置きやすくなったことです。AKS の Kubernetes resources には Namespaces と Workloads のカテゴリがあり、Workloads では deployment、pod、replica set、stateful set、daemon set、job、cron job を扱えます。そこに Azure Monitor managed service for Prometheus のデータが直接重なることで、オブジェクトを開いた時点で「この単位で何が起きているか」を把握しやすくなります。 (Microsoft Learn)
Microsoft の公開内容を実務寄りに整理すると、変化は次のとおりです。 (TECHCOMMUNITY.MICROSOFT.COM)
| 比較項目 | これまで起きがちだったこと | 今回の GA で改善される点 |
|---|---|---|
| 調査開始地点 | Insights や Grafana から全体を見て当たりを付ける | Namespace / Workload 画面から異常箇所を起点に見られる |
| 失敗 Pod の発見 | pod 一覧やイベントを個別に追う | pending / failed pod を見つけやすい |
| リソース偏りの判断 | node・pod・namespace を別画面で照合する | nodes・namespaces・workloads・pods の利用状況を関係付きで把握しやすい |
| 次の深掘り | どのログやダッシュボードを見るか迷いやすい | event / utilization summary から次の調査先を決めやすい |
Azure Monitor for AKS では「メトリクス」と「ログ」を分けて考える
AKS の監視は、platform metrics、Prometheus metrics、activity logs、resource logs、Container insights などを組み合わせる前提です。つまり、新しい Namespace / Workload view は「すべてを置き換える万能画面」ではなく、メトリクス起点で最初の判断を速くする入口と捉えるのが実務的です。 (Microsoft Learn)
特に重要なのは、Microsoft 自身が メトリクスは Managed Prometheus を主役にし、Container insights はログ寄りに使う ことを勧めている点です。さらに Monitor > Insights の single cluster view でも Managed Prometheus visualizations が preferred setting とされ、Azure Managed Grafana には Namespace (Pods)、Namespace (Workloads)、Workload などの既定ダッシュボードが用意されています。今回の GA は、この既存の Prometheus ベース監視を AKS リソース画面へ自然につなぐ改善だと理解すると迷いません。 (Microsoft Learn)
目的別に見ると、役割分担は次のように整理できます。 (Microsoft Learn)
| 目的 | まず使う場所 | 向いている理由 |
|---|---|---|
| 異常の当たりをつける | Namespaces / Workloads | オブジェクト文脈で状況をつかみやすい |
| クラスタ全体を俯瞰する | Monitor > Insights | time range や namespace / node フィルターで横断確認しやすい |
| 詳しい時系列分析をする | Azure Managed Grafana | Namespace / Workload 系の既定ダッシュボードがある |
| ログ・イベントで確証を取る | Container insights / Log Analytics | live logs、historical logs、イベント確認に向く |
Monitor > Insights 側では、single cluster view の Nodes / Controllers / Containers タブで time range を変えたり、node / namespace でフィルターしたりできます。Namespace で当たりを付けたあとに「本当にその namespace だけの問題か」を横断確認する流れが組みやすいのも、今回のビュー改善と相性がよい点です。 (Microsoft Learn)
Namespace view と Workload view で見るべきポイント
初心者が迷いやすいのは、「名前空間を見るべきか、ワークロードを見るべきか」です。判断基準は単純で、広がりを見るなら Namespace、原因候補を絞るなら Workload です。
Namespace view は「影響範囲」を見る画面
Namespace view は、共有クラスターで偏りや blast radius を見極める入口に向いています。今回の GA では nodes・namespaces・workloads・pods をまたいだ利用状況の分析がしやすくなると案内されており、既定ダッシュボードにも Namespace (Pods) と Namespace (Workloads) が含まれます。たとえば、本番 namespace だけが急に CPU を使い始めたのか、特定チーム用 namespace に pending pod が集中しているのか、といった切り分けを最初に行う場面で効きます。 (Microsoft)
Namespace view を開いて、複数の workload が同時に悪化しているなら、個別アプリの不具合だけでなく、割り当て、配置、スケール、共有ノード側の圧迫まで視野に入れて考えるべきです。逆に、1 つの workload だけが目立って悪いなら、次は Workload view に降りるのが最短です。
Workload view は「原因候補」を絞る画面
Workload view では deployment / pod / replica set / stateful set / daemon set / job / cron job を直接開けます。Microsoft Learn でも、Workloads から deployment insights として CPU と memory usage を見られることが案内されており、今回の GA 公開では pending / failed pod のトラブルシューティングと、event / utilization summary を使った pod 性能評価が強化点として挙げられています。つまり、ワークロード単位で「どの pod が落ちているか」「負荷なのか起動失敗なのか」「次にログを見るべきか」を判断するまでの距離が短くなります。 (Microsoft Learn)
実際の使い分けを簡単にすると、次のようになります。
| 画面 | 最初に開く場面 | 次のアクション |
|---|---|---|
| Namespace view | 複数サービスにまたがる異常、共有クラスターの偏り確認 | 問題が集中する workload に降りる |
| Workload view | 単独 deployment / pod の障害、起動失敗、再起動増加 | Live Logs / Events / Grafana / kubectl で確証を取る |
Workload の詳細確認では、kubectl もまだ有効です。Microsoft の運用ガイドでも、READY と desired の不一致を見たら kubectl describe、kubectl logs、kubectl events で詳細を確認する流れを案内しています。ポータルの新ビューは「置き換え」ではなく、「最初の 1 分を短縮する入口」と考えると運用設計しやすくなります。 (Microsoft Learn)
有効化の前提と最短セットアップ
有効化前に押さえるべき前提は3つです。オンボーディングには少なくとも Contributor 権限が必要で、既存の Managed Grafana と連携する場合は Owner か Contributor + User Access Administrator が必要です。監視を有効にした後の閲覧には Monitoring Reader か Monitoring Contributor が必要になります。また、Prometheus metrics を有効にする前提として、cluster は managed identity authentication を使い、関連リソースプロバイダーが登録済みであることが求められます。 (Microsoft Learn)
CLI や IaC で進めるなら、少なくとも cluster / Azure Monitor workspace 側で Microsoft.ContainerService Microsoft.Insights Microsoft.AlertsManagement Microsoft.Monitor、Grafana 側で Microsoft.Dashboard の登録を確認してください。CLI フローでは古い aks-preview 拡張が残っているとつまずくため、先に整理しておくと安全です。 (Microsoft Learn)
Azure portal での最短手順
Azure portal で試すだけなら、次の順番が最短です。
- AKS クラスターを開き、
Monitor>Monitor Settingsを開く。 Prometheus metricsを有効にし、必要ならGrafanaとContainer Logs and eventsも一緒に構成する。- 既存ワークスペースがあれば選択し、なければ新規作成する。Container logs を使う場合は logging profile も選ぶ。
- 設定後、
Kubernetes resources>NamespacesまたはWorkloadsを開いて、対象 namespace / deployment から観測を始める。
Azure portal では新規クラスターでも既存クラスターでも概ね同じ構成画面が使え、既存クラスターでは Monitor > Monitor Settings から入れます。設定画面では Prometheus metrics、Grafana、Container Logs and events が選択された状態になり、Workloads から deployment insights を確認できます。 (Microsoft Learn)
CLI で有効化する場合の最小例
az aks update \
--resource-group <resource-group> \
--name <cluster-name> \
--enable-azure-monitor-metrics \
--azure-monitor-workspace-resource-id <azure-monitor-workspace-resource-id>既存クラスターへ最小構成で Prometheus metrics を入れるなら、公式ドキュメントは az aks update の --enable-azure-monitor-metrics オプションを案内しています。Grafana まで同時に結ぶ場合は --grafana-resource-id も使えます。 (Microsoft Learn)
すぐ使えるトラブルシューティングフロー
実務では、Namespace / Workload view だけで完結させようとせず、入口 → 確証 → 再発防止 の3段で使うと失敗しにくくなります。 (Microsoft)
入口: Namespace / Workload view で異常集中箇所を決める
まず Namespace view で影響範囲を見るか、Workload view で個別ワークロードを見るかを決めます。広がりを見るなら namespace、単独障害なら workload から入るのが速いです。release では cluster / workload health、pending / failed pod、nodes・namespaces・workloads・pods の resource utilization 分析を主目的に挙げています。 (Microsoft)
確証: Live Logs / Live Events / kubectl で原因を固める
次に、Workloads から Live Logs を開くか、Monitor 側の Live Events / Live Metrics に進みます。Live Data は Kubernetes API に直接アクセスする仕組みで、プライベートクラスターでは同一プライベートネットワーク上からの利用が必要です。さらにセッションを閉じるとデータは保持されず、metrics は 5 分 window の可視化に限られます。履歴を追うなら Log Analytics、詳細確認なら kubectl describe kubectl logs kubectl events を併用するのが堅実です。 (Microsoft Learn)
再発防止: Grafana と alert を必ずつなぐ
恒常運用に戻す段階では、Azure Managed Grafana の Namespace / Workload 系ダッシュボードで時系列を見直し、Prometheus ベースの recommended alert rules も有効にしておくと再発検知までつながります。AKS 向けの recommended alert rules には、KubeDeploymentReplicasMismatch、KubePodCrashLooping、KubePodFailedState、KubeContainerAverageCPUHigh などが含まれます。 (Microsoft Learn)
導入前に知っておきたい注意点
新しいビューだけで監視は完結しない
AKS の監視はもともと複数レイヤーで構成されており、platform metrics、Prometheus metrics、resource logs、Container insights などが役割分担しています。新しい Namespace / Workload view は非常に便利ですが、ログの履歴分析、監査、長期の時系列比較まで1画面で完結するわけではありません。 まず状況をつかむ画面 と割り切ると、期待値を外しません。 (Microsoft Learn)
Live Data は保存用ではない
Live Logs / Live Events / Live Metrics は、リアルタイム切り分けには強い一方で保存用途には向きません。Microsoft Learn でも、セッション終了時に情報は削除され、metrics は 5 分 window に限られると明記されています。障害報告や事後分析に使うなら、最初から Log Analytics や保存済みログの導線を用意しておくべきです。 (Microsoft Learn)
既定のメトリクスだけで足りるとは限らない
Prometheus metrics は何でも自動で入るわけではありません。既定では minimal ingestion profile が有効で、default dashboards・recording rules・default alerts で使う指標に絞って収集されます。必要な指標が足りない場合は scrape customization を検討し、むやみに minimal ingestion を外すと ingestion volume が大きく増える点に注意してください。 (Microsoft Learn)
Prometheus visualizations が思ったように出ない場合は、recording rules の状態も確認候補です。Microsoft は Prometheus visualizations を支える recording rules を既定展開すると説明しており、Insights 側でも recording rules を有効にして高性能な Prometheus visualizations を unlock する案内があります。 (Microsoft Learn)
監査ログは安易に全部集めない
AKS の resource logs は、特に kube-audit を集め始めるとコストが大きくなりやすい領域です。Microsoft は、必要な場合に限って収集し、kube-audit-admin の活用や resource-specific mode、Basic logs の利用でコストを抑えることを勧めています。可観測性強化の流れでログまで一気に増やすと、後から請求で驚きやすいポイントです。 (Microsoft Learn)
ポータルで見えないときは、まず権限とネットワークを疑う
Kubernetes resources に入れない、Live Logs が開けない、といった場面は、機能不全よりも権限やネットワーク起因であることが多いです。Microsoft Learn では、AKS cluster、Kubernetes API、Kubernetes objects へのアクセス権が必要とされ、既存クラスターでは authorized IP ranges の設定が必要になる場合があります。プライベートクラスターの live logs は、同じプライベートネットワーク上からでないと使えません。 (Microsoft Learn)
まずやるべきこと
AKS 名前空間とワークロード ビューの可観測性の GA は、Kubernetes 運用の「最初の 5 分」を短くする更新です。namespace で影響範囲を絞り、workload で症状を確かめ、logs / events / Grafana / alerts へつなぐ流れを決めておけば、障害時の迷いはかなり減ります。 (Microsoft)
最初の一歩としては、次の順番がおすすめです。
- 既存 AKS クラスターで Managed Prometheus が有効か確認する。
Monitor > Monitor Settingsで Azure Monitor workspace、Grafana、Container Logs and events の接続を整理する。- 重要な production namespace と主力 deployment を
Namespaces/Workloadsから実際に開く。 - Live Logs と Log Analytics の導線を確認する。
- Grafana の
Namespace (Workloads)とWorkloadダッシュボード、recommended alert rules まで整備する。
まずは 1 つの AKS クラスターでここまで整えるだけでも、トラブルシューティングのスピードと再現性は大きく変わります。特に、共有クラスターで「どの namespace が悪いのか」「どの workload が原因なのか」を毎回探しているチームほど、今回の GA の効果を実感しやすいはずです。 (Microsoft Learn)
コメント