はじめに
私のチームではAzure Kubernetes Service上に、社員向けのツールを展開しながらKubernetesの開発運用についてのノウハウを獲得しています。
最近、生成AI周りの調査・開発にも軸足を移している中で、AKS MCPというツールがあることを知りました。
この記事では、AKS MCPの導入と今までKubectlコマンドを使って得ていた情報をGitHub Copilot Chatに聞いてみた結果を共有します。
環境
今回はAKS MCP:v0.0.6をWSLに導入し、VSCodeからRemote-WSLにより接続して使用しています。
AKS MCPの導入
こちらのGitHubリポジトリの手順に従って導入しました。
-
VSCode拡張機能のAzure Kubernetes Serviceをインストールします。
-
ctrl+shift+Pを押して、コマンドパレットを開き、AKS:Setup AKS MCP Serverを選択します。 -
拡張機能のMCPサーバーの一覧にAKS MCPが追加されます。
-
今回はRemote-WSLを使っていますので、構成ファイルを修正します。
MCPサーバー一覧のAKS MCPをクリックし、歯車マークから「構成の表示（JSON）」をクリックします。
-
リポジトリのREADME.mdにある通り、CommandとArgsを編集します。
この時、aks-mcpのパスは実際にはバージョンのディレクトリが存在するので実体に合わせて記載します。mcp.json"AKS MCP": { "command": "bash", "args": [ "-c", "/home/you/.vs-kubernetes/tools/aks-mcp/v0.0.6/aks-mcp", "--transport", "stdio" ] } -
MCPサーバを起動します。
-
15種類のツールが使えるようになりました。
AKS MCPの利用
- チャットにAKSのクラスタに関する質問をすると、先ほどの15種類のツールを使って情報収集して回答してくれます。
- Toolを実行する際には許可を求めてくるので「続行」をクリックすることでコマンドを実行してくれます。
- 今回は使用中の環境に対して検証を行ったため、読み取り専用の権限のみを付与したユーザーのコンテキストをカレントコンテキストにして試しました。
プロンプトと結果
GitHub Copilot Chatから色々質問してみました。
1. クラスターのPod数・コンテナ数を確認
プロンプト：
現在稼働中の総Pod数と、総コンテナ数を教えて。
結果：
現在稼働中のAKSクラスターにおける総Pod数と総コンテナ数は以下の通りです。
総Pod数：153
総コンテナ数：232
Podごとに「READY」列の値（例: 2/2）からコンテナ数を合計しています。必要に応じて、さらに詳細な内訳もご案内できます。
2. 長期間稼働しているアプリケーションPodの特定
プロンプト：
システムを除いて最も長期間稼働してるPodは何ですか？またどのくらいの期間稼働していますか？
結果（pod名やnamepace名は仮です）：
システム（kube-systemやmonitoringなどのインフラ系Namespace）を除くと、最も長期間稼働しているPodは以下です。
Pod名: pod-a-8559c48bf-qwfxm
Namespace: namespace-a
稼働期間: 153日
このPodが、アプリケーション系Namespaceの中で最も長く稼働しています。
3. Ingressルートの定義数を確認
プロンプト：
Ingressのルートはどのくらい定義されていますか？
結果（一部ぼかし）：
現在定義されているIngressのルート（Ingressリソース）は、合計20件です。
各Namespaceごとに複数のIngressが存在し、主にexample.comやhoge.comなどのホスト名でルーティングされています。必要に応じて、詳細な一覧や特定のNamespaceのみの集計も可能です。
プロンプト：
namespace単位のサービス数、Pod数、Ingressのルールの数を教えてください。
結果（抜粋）：
namespaceごとのサービス数、Pod数、Ingressルール数は以下の通りです。
| Namespace | サービス数 | Pod数 | Ingressルール数 |
|---|---|---|---|
| advent-prod | 1 | 1 | 1 |
| argocd | 6 | 7 | 2 |
| blackbox | 1 | 1 | 0 |
| cert-manager | 2 | 3 | 0 |
| clusterjob | 0 | 8 | 0 |
| dboperator | 2 | 2 | 0 |
| default | 1 | 0 | 0 |
| descheduler | 0 | 4 | 0 |
| external-secrets | 1 | 3 | 0 |
| gitea-prod | 1 | 1 | 1 |
| growi-prod | 5 | 6 | 1 |
| ingress-nginx | 2 | 3 | 0 |
| keycloak-prod | 1 | 1 | 1 |
| kube-system | 13 | 32 | 0 |
| kubernetes-replicator | 0 | 1 | 0 |
| linkerd-viz | 6 | 7 | 2 |
| linkerd | 9 | 7 | 0 |
| litmus-api | 3 | 1 | 1 |
| litmus | 7 | 13 | 1 |
| monitoring-prod | 22 | 18 | 1 |
| reloader | 0 | 1 | 0 |
| sonarqube | 3 | 2 | 1 |
| vault | 3 | 2 | 1 |
| velero | 1 | 15 | 0 |
ご要望に応じて、特定namespaceの詳細やリソース名一覧もご案内可能です。
4. Veleroバックアップジョブのスケジュール確認
プロンプト：
veleroのバックアップジョブごとのスケジュールは読み取れますか
結果（ジョブ名は仮）：
毎日17:00にdailyバックアップ、毎週金曜17:30にweeklyバックアップが実行されています。
プロンプト：
veleroの最新バックアップの結果を教えて
時刻はJSTでお願いします。
結果（ジョブ名は仮）：
最新のバックアップ（dailybackup-202508311170003）の結果は以下の通りです。
バックアップ状態: 正常終了（Completed）
バックアップ開始: 2025年8月31日 17:00:03 UTC → 2025年8月31日 26:00:03 JST（JST換算で翌日2:00:03）
完了: 2025年8月31日 17:03:30 UTC → 2025年8月31日 26:03:30 JST（JST換算で翌日2:03:30）
バックアップ対象Namespace: gitea-prod, growi-prod, keycloak-prod, vault
バックアップしたアイテム数: 1362
ボリュームスナップショット: 5件（全て成功）
エラーやイベント: なし
5. リソース使用量が高いPodのランキング
プロンプト：
リソース使用量が高いPod上位5件を教えて
結果：
リソース使用量（CPU/メモリ）が高いPod上位5件は以下の通りです。
【CPU使用量上位5件】
1. PodA（130m）
2. PodB（45m）
3. PodC（44m）
4. PodD（41m）
5. PodE（41m）
【メモリ使用量上位5件】
1. PodF（2050Mi）
2. PodG（1539Mi）
3. PodH（1099Mi）
4. PodI（1126Mi）
5. PodJ（958Mi）
ご要望に応じて、CPU/メモリどちらかのみや、詳細なPod情報もご案内可能です。
まとめ
簡単に導入でき、自然言語でクラスタの情報を取り出せるのはかなり扱いやすいと感じました。
Veleroのバックアップリソースの情報も問題なく取ってきてくれたのでちょっと知識があれば自然に使いこなすことができそうです。
今までは特定の目的に応じてkubectlのチートシートを整備していましたが、今後はそのようなものは不要またはプロンプト集を整備するほうが使い勝手が良さそうです。
Discussion