はじめに
Kubernetesを運用していると、基本的な操作は k9s や Lens などのGUIツールで十分ですよね。
- Podの一覧を見る → k9sで一発
- ログを確認する → GUIでポチポチ
- リソースの状態確認 → 視覚的に分かりやすい
でも、こんな時はどうでしょう？
- 「全NamespaceでRestartが3回以上のPodを、メモリ使用量順に表示したい」
- 「特定のラベルを持つPodのイメージタグだけを一覧で出力したい」
- 「各Deploymentのレプリカ数とReadyな数の差分を集計したい」
こういった ちょっと工夫が必要なクエリ になると、途端に困りませんか？
GUIツールではできないし、kubectlでやろうとすると...
# えーっと、jsonpathの書き方は...
kubectl get pods --all-namespaces -o jsonpath='{range .items[?(@.status.containerStatuses[0].restartCount>2)]}{.metadata.name}{"\t"}{.status.containerStatuses[0].restartCount}{"\n"}{end}'
# いや、custom-columnsの方がいいのか...？
kubectl get deployments --all-namespaces -o custom-columns=NAME:.metadata.name,DESIRED:.spec.replicas,READY:.status.readyReplicas
# sort-byも組み合わせて...あれ、これどう書くんだっけ？
「もういいや、ChatGPTに聞こう」
そして、お馴染みの流れ
- ブラウザ開いてChatGPT起動
- 「kubectlで〜を取得するコマンドは？」
- 回答をコピペして実行
- エラーが出る
- またChatGPTに戻って「エラーが出ました。こういう状況なんですが...」
- 修正版をまたコピペ
- やっと動く
この往復、面倒じゃないですか？
そんな悩みを解決してくれるのが kubectl-ai です。
ターミナルから直接、自然言語で複雑なKubernetes操作ができる革命的なツールを試してみました。
- 基本的な操作 → k9sやGUIツール
- 複雑なクエリ・独自の集計 → kubectl-ai
この使い分けで、Kubernetes運用が劇的に効率化しそうなので試してみました。
kubectl-aiとは
kubectl-aiは、自然言語をkubectlコマンドに変換してくれるkubectlプラグインです。
# 従来
kubectl get pods --all-namespaces --field-selector status.phase=Running
# kubectl-ai
kubectl ai "稼働中のPod一覧を全Namespaceで見せて"
主な特徴
- 自然言語 → kubectlコマンド生成・実行
- 対話形式で使える（一度起動すれば、続けて質問できる）
- 日本語でもOK（LLM次第）
- 複数のLLM対応（Gemini, OpenAI, Claude, Ollama等）
- 既存のkubeconfigを使用（コンテキスト切り替え後にそのまま使える）
環境構築
1. kubectl krewのインストール
kubectl-aiは、kubectlのプラグインマネージャー「krew」経由でインストールします。
# krewインストール（Homebrewを使う場合）
brew install krew
# PATHに追加（~/.zshrcや~/.bashrcに記載）
export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"
# 反映
source ~/.zshrc
2. kubectl-aiのインストール
kubectl krew install ai
# 確認
kubectl ai version
3. LLMの準備（Gemini）
kubectl-aiは複数のLLM（OpenAI, Claude, Ollama等）に対応していますが、デフォルトがGeminiなので、今回はそのままGoogle Geminiを使います。
Gemini APIキーの取得
以下のリンクからAPIキーを取得できます。
- Google AI Studio: https://aistudio.google.com/app/apikey
- 公式ドキュメント: https://ai.google.dev/gemini-api/docs/api-key
Googleアカウントでログインして「Create API key」をクリックするだけで取得できます。
環境変数の設定
# ~/.zshrc または ~/.bashrc に追加
export GEMINI_API_KEY="AIza..."
# 反映
source ~/.zshrc
# 確認
echo $GEMINI_API_KEY
これだけで準備完了です！kubectl-aiはデフォルトでGeminiを使うので、--llm-providerのような指定は不要です。
検証環境の準備
kindでローカルKubernetesクラスタを作成します。
# クラスタ作成
kind create cluster --name kubectl-ai-demo
# 確認
kubectl cluster-info --context kind-kubectl-ai-demo
いくつかサンプルリソースをデプロイしておきます。
# nginx deployment
kubectl create deployment nginx --image=nginx --replicas=3
# service
kubectl expose deployment nginx --port=80 --type=ClusterIP
# payment-service deployment
kubectl create deployment payment-service --image=nginx --replicas=5
# configmap
kubectl create configmap app-config \
--from-literal=DATABASE_URL="postgresql://localhost:5432/db" \
--from-literal=CACHE_ENABLED="true"
# 確認
kubectl get all
基本的な使い方
Podの一覧を取得
kubectl ai "Podの一覧を見せて"
出力例:
はい、承知いたしました。Podの一覧を表示します。
Running: kubectl get pods
Podの一覧を表示しました。
NAME │ READY │ STATUS │ RESTARTS │ AGE
──────────────────────────────────┼─────────┼─────────┼──────────┼────────
nginx-77b4fdf86c-6744k │ 1/1 │ Running │ 0 │ 3d19h
nginx-77b4fdf86c-htzws │ 1/1 │ Running │ 0 │ 3d19h
nginx-77b4fdf86c-pk447 │ 1/1 │ Running │ 0 │ 3d19h
payment-service-59dd78fcff-5ksff │ 1/1 │ Running │ 0 │ 3d19h
payment-service-59dd78fcff-9vwq2 │ 1/1 │ Running │ 0 │ 3d19h
payment-service-59dd78fcff-f2p99 │ 1/1 │ Running │ 0 │ 3d19h
payment-service-59dd78fcff-xnpz2 │ 1/1 │ Running │ 0 │ 3d19h
payment-service-59dd78fcff-xwdp2 │ 1/1 │ Running │ 0 │ 3d19h
すべてのPodが正常に稼働中です。
ポイント:
- 自然言語で質問するだけ
- 実行されたコマンド（
kubectl get pods）も表示される - 日本語で説明してくれる
対話形式で使える（重要！）
kubectl-aiの便利な点は、一度起動すれば対話形式で続けて質問できることです。
毎回 kubectl ai を打つ必要はありません。
kubectl ai "Podの一覧を見せて"
すると、プロンプトが >>> に変わり、そのまま続けて質問できます：
>>> 各Deploymentのレプリカ数を教えて
出力例:
はい、承知いたしました。各Deploymentのレプリカ数をお知らせします。
Running: kubectl get deployments
承知いたしました。各Deploymentのレプリカ数は以下の通りです。
DEPLOYMENT │ レプリカ数
─────────────────────────────────────┼────────────────────────────────────
nginx │ 3
payment-service │ 5
続けて別の質問もできます：
>>> app=nginxのラベルがついたPodを表示
出力例:
はい、承知いたしました。 app=nginx のラベルがついたPodの一覧を表示します。
Running: kubectl get pods -l app=nginx
はい、承知いたしました。 app=nginx のラベルがついたPodは以下の通りです。
NAME │ READY │ STATUS │ RESTARTS │ AGE
────────────────────────┼────────────┼────────────┼───────────┼───────────
nginx-77b4fdf86c-6744k │ 1/1 │ Running │ 0 │ 3d19h
nginx-77b4fdf86c-htzws │ 1/1 │ Running │ 0 │ 3d19h
nginx-77b4fdf86c-pk447 │ 1/1 │ Running │ 0 │ 3d19h
このように、ChatGPTと会話するような感覚でKubernetesを操作できます。
実践：複雑なクエリを試す
ServiceとCluster IPの確認
>>> Serviceの一覧と、それぞれのCluster IPを表示して
出力例:
はい、承知いたしました。Serviceの一覧と、それぞれのCluster IPを表示します。
Running: kubectl get services
はい、承知いたしました。Serviceの一覧とそれぞれのCluster
IPは以下の通りです。
NAME │ TYPE │ CLUSTER-IP
────────────────────────┼────────────────────────┼────────────────────────
kubernetes │ ClusterIP │ xx.xx.xx.xx
nginx │ ClusterIP │ xx.xx.xx.xx
ConfigMapの中身を確認
>>> app-configというConfigMapの内容を見せて
出力例:
はい、承知いたしました。 app-config
という名前のConfigMapの内容を表示します。
Running: kubectl get configmap app-config -o yaml
はい、承知いたしました。 app-config ConfigMapの内容は以下の通りです。
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
namespace: default
# ...その他のメタデータ...
data:
CACHE_ENABLED: "true"
DATABASE_URL: postgresql://localhost:5432/db
データとして、 CACHE_ENABLED と DATABASE_URL
の2つのキーが設定されています。
jsonpathやYAML出力の指定を覚えなくても、自然言語で聞くだけでOKです。
Namespaceごとのリソース集計
>>> 全NamespaceのPod数を集計して
出力例:
はい、承知いたしました。すべてのNamespaceのPod数を集計して表示します。
The following commands require your approval to run:
• kubectl get pods --all-namespaces -o=custom-columns=NAMESPACE:.metadata.namespace --no-headers | sort | uniq -c
Do you want to proceed ?
1. Yes
2. Yes, and don't ask me again
3. No
Enter your choice: y
Running: kubectl get pods --all-namespaces -o=custom-columns=NAMESPACE:.metadata.namespace --no-headers | sort | uniq -c
はい、承知いたしました。全NamespaceのPod数は以下の通りです。
Namespace │ Pod数
─────────────────────────────────────┼────────────────────────────────────
default │ 8
kube-system │ 8
local-path-storage │ 1
合計で 17 個のPodがクラスタ内で稼働しています。
ポイント:
- awkやsortを使った複雑なパイプラインも自動生成
- 実行前に確認を求めてくれる（安全）
Podのログ確認
>>> payment-serviceのPodのログを表示して
出力例:
はい、承知いたしました。 payment-service
Deploymentに属するPodのログを表示します。
Running: kubectl logs deployment/payment-service
はい、承知いたしました。 payment-service Podのログを表示しました。
ログは payment-service-59dd78fcff-xwdp2 というPodから取得されたものです。
nginxの起動シーケンスが記録されており、正常に起動しているように見えます。
実践：エラー調査と修正をkubectl-aiでやってみる
ここからが本番です。実際の運用では、Podがエラーになることがよくあります。
kubectl-aiを使って、エラーの発見→原因調査→修正まで、どれだけ素早くできるか試してみましょう。
エラーの再現
存在しないDockerイメージを指定してDeploymentを作成します。
# わざとエラーを起こす
kubectl create deployment broken-app --image=nginx:nonexistent-tag --replicas=2
ステップ1: エラーになっているPodを探す
kubectl-aiの対話モードで質問します：
>>> エラーになっているPodを見せて
出力例:
はい、承知いたしました。エラーが発生しているPodがないか確認します。
Running: kubectl get pods --all-namespaces
調査した結果、 default Namespaceにエラー状態のPodが見つかりました。
NAMESPACE │ NAME │ READY │ STATUS │ RE… │ AGE
───────────┼───────────────────────┼───────┼──────────────────┼─────┼─────
default │ broken-app-f795f7d5b- │ 0/1 │ ImagePullBackOff │ 0 │ 26s
│ snwvk │ │ │ │
default │ broken-app-f795f7d5b- │ 0/1 │ ImagePullBackOff │ 0 │ 26s
│ zk4d4 │ │ │ │
これらのPodは ImagePullBackOff というステータスになっています。
これは、Podがコンテナイメージを正常に取得できずにいることを示します。
原因として、以下のような可能性が考えられます。
• イメージ名またはタグが間違っている
• イメージが存在しない
• プライベートリポジトリへの認証情報が設定されていない
これらのPodについて、さらに詳しく調査することも可能です。ご希望の場合はお申し付けください。
すごいポイント
- エラーの状態を自動で説明してくれる
- 考えられる原因まで提示してくれる
- 次のアクションを促してくれる
ステップ2: 詳細を確認
>>> broken-appのPodで何が起きてるか教えて
出力例:
はい、承知いたしました。 broken-app のPodで何が起きているか、詳しく調査します。
Podの詳細情報を確認することで、エラーの原因を特定できます。
broken-app-f795f7d5b-snwvk の情報を取得します。
Running: kubectl describe pod broken-app-f795f7d5b-snwvk
broken-app Podで何が起きているか、詳細を調査しました。
原因は、存在しないコンテナイメージを指定しているためです。
Podの詳細情報の中の Events（イベントログ）に、問題の核心が記録されています。
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Failed 25s (x2 over 39s) kubelet Failed to pull image
"nginx:nonexistent-tag": rpc error: code = NotFound desc = ... not found
Warning Failed 11s (x2 over 38s) kubelet Error: ImagePullBackOff
### 何が起きているか
1. Pulling image "nginx:nonexistent-tag":
Kubernetesが nginx:nonexistent-tag というイメージを取得しようとしました。
2. Failed to pull image:
しかし、このイメージはDocker Hubに存在しないため、取得に失敗しました (not found)。
3. ImagePullBackOff:
イメージの取得に失敗したため、Kubernetesは少し時間をおいてから再試行しようとします。
この待機状態が ImagePullBackOff です。
### 解決策
この問題を解決するには、Deploymentで指定しているイメージ名を、nginx:latest
や nginx:1.25 のような実際に存在する正しいイメージタグに修正する必要があります。
ご希望であれば、私がDeploymentのイメージ名を修正するコマンドを実行することも可能です。
すごいポイント
-
kubectl describeを自動で実行 - Eventsから原因を特定
- 何が起きているかを段階的に説明してくれる
- 解決策まで提示してくれる
- 修正も代行できることを提案してくれる
ステップ3: 修正を依頼
ここが一番すごいところです。自然言語で修正を依頼できます。
>>> 正しいイメージタグに修正して
出力例:
はい、承知いたしました。 broken-app Deploymentのコンテナイメージを
正しいタグ nginx:latest に修正します。
The following commands require your approval to run:
• kubectl set image deployment/broken-app nginx=nginx:latest
Do you want to proceed ?
1. Yes
2. Yes, and don't ask me again
3. No
Enter your choice: y
Running: kubectl set image deployment/broken-app nginx=nginx:latest
はい、 broken-app Deploymentのイメージを nginx:latest に更新しました。
新しいPodが正常に起動しているか確認してみましょう。少々お待ちください。
Running: kubectl get pods -l app=broken-app
状況を更新します。
broken-app Deploymentが新しいイメージ nginx:latest を使ってPodを再作成しています。
NAME │ READY │ STATUS │ RESTARTS │ AGE
─────────────────────────────┼───────┼───────────────────┼──────────┼─────
broken-app-54d8c855bf-bg74t │ 1/1 │ Running │ 0 │ 2s
broken-app-54d8c855bf-v22mh │ 0/1 │ ContainerCreating │ 0 │ 1s
broken-app-f795f7d5b-snwvk │ 0/1 │ ErrImagePull │ 0 │ 67s
broken-app-f795f7d5b-zk4d4 │ 0/1 │ Terminating │ 0 │ 67s
• 新しいPod ( broken-app-54d... ):
• Running と ContainerCreating ステータスのPodがあり、正常に起動処理が進んでいます。
• 古いPod ( broken-app-f795f... ):
• エラーの出ていたPodは Terminating（終了処理中）となり、順次削除されます。
しばらくすると、新しいPodがすべて Running 状態になるはずです。
完全に修正されたか、もう一度だけ確認させてください。
The following commands require your approval to run:
• sleep 5 && kubectl get pods -l app=broken-app
Do you want to proceed ?
1. Yes
2. Yes, and don't ask me again
3. No
Enter your choice: y
Running: sleep 5 && kubectl get pods -l app=broken-app
修正が完了しました！ 🎉
broken-app のPodはすべて正常に Running 状態になりました。
NAME │ READY │ STATUS │ RESTARTS │ AGE
─────────────────────────────┼───────────┼──────────┼──────────┼──────────
broken-app-54d8c855bf-bg74t │ 1/1 │ Running │ 0 │ 20s
broken-app-54d8c855bf-v22mh │ 1/1 │ Running │ 0 │ 19s
ImagePullBackOff エラーは解消されました。
他に何かお手伝いできることはありますか？
驚きのポイント
- 「正しいイメージタグに修正して」という曖昧な指示でも理解してくれる
-
kubectl set imageコマンドを自動生成 - 修正後、自動で状態確認
- さらに、数秒待ってから再確認（完全に修正されたか確認）
- 最後に「修正完了！🎉」と報告してくれる
従来の方法だと…
# 1. エラーを探す
kubectl get pods | grep -v Running
# 2. 詳細を確認
kubectl describe pod <pod-name>
# 3. Deploymentを確認
kubectl get deployment broken-app -o yaml
# 4. イメージを修正
kubectl set image deployment/broken-app nginx=nginx:latest
# 5. 確認
kubectl get pods -l app=broken-app
# 6. もう一度確認（数秒待って）
sleep 5
kubectl get pods -l app=broken-app
これだけの手順が、自然言語での会話だけで完結します。
実務での活用シーン
シーン1: 複数クラスタの調査
実務では、awsp + kubieでAWSプロファイルとKubernetesコンテキストを切り替えることが多いです。
kubectl-aiは現在のコンテキストをそのまま使うので、コンテキスト切り替え後すぐに調査できます。
# 本番環境への切り替え（実務の例）
awsp production
kubie ctx eks-prod-ap-northeast-1
# kubectl-aiで即座に調査開始
kubectl ai "このクラスタにどんなNamespaceがある？"
>>> payment関連のDeploymentを全部見せて
>>> 直近1時間でRestartしたPodはある？
>>> メモリ使用量が多いPod top5を表示
コマンドを思い出す時間が不要になり、障害対応の初動が圧倒的に速くなります。
今回のkind検証環境では、kind create cluster時点で自動的にコンテキストが切り替わるため、awsp/kubieは不要です。
シーン2: 新人教育
kubectlコマンドを覚えていない新人でも、自然言語で操作できます。
kubectl ai "稼働中のPod一覧を見たい"
>>> エラーになっているPodを探して
>>> nginx Deploymentを3レプリカにスケールしたい
>>> payment-serviceのログを見せて
実行されるコマンドが表示されるので、kubectlの学習にもなります。
シーン3: 複雑な調査・トラブルシューティング
対話形式で、段階的に調査を深掘りできます。
kubectl ai "エラーになっているPodを見せて"
>>> そのPodの詳細を確認
>>> イベントログを見せて
>>> 関連するDeploymentの設定を確認
>>> 正しい設定に修正して
従来なら複数のコマンドを組み合わせる必要がありましたが、会話するだけで調査→修正まで完結します。
kubectl-ai vs 手動kubectlコマンド
| 項目 | kubectl-ai | 手動kubectl |
|---|---|---|
| 速度 | 自然言語で即入力可能 | コマンド・オプションを思い出す時間が必要 |
| 正確性 | LLMの精度に依存 | 正確（自分で書くため） |
| 学習コスト | ほぼゼロ | 中〜高（オプション、jsonpath等） |
| 複雑なクエリ | LLMが生成 | 自分で調べて組み立て |
| 日本語対応 | ○（LLM次第） | × |
| 対話形式 | ○（続けて質問できる） | ×（毎回コマンド入力） |
| 修正の依頼 | ○（自然言語で依頼） | ×（自分でコマンド実行） |
使い分けの考え方
- 調査・確認: kubectl-aiで高速化
- 本番での変更操作: 手動kubectlで慎重に実行（ただし、kubectl-aiも実行前に確認を求めてくれるので安全）
- CI/CD: 従来のkubectlコマンド（スクリプト化）
まとめ
kubectl-aiを使うことで、以下のメリットがありました。
- kubectlコマンドを思い出す時間が不要
- 複雑なjsonpath、custom-columnsを覚えなくていい
- 対話形式で調査を深掘りできる
- エラー調査→修正まで自然言語で完結
- 障害対応の初動が速くなる
- 新人教育のハードルが下がる
- 日本語でも操作できる（LLM次第）
特に、「正しいイメージタグに修正して」のような曖昧な指示でも理解してくれて、実行まで自動でやってくれるのは驚きでした。
ただし、kubectlの基礎は理解しておくべきです。kubectl-aiが生成するコマンドを見て学ぶ、という使い方もおすすめだなと思います。
Kubernetes運用の効率化に、ぜひkubectl-aiを試してみてください！