はじめに
こちらの記事につづいて今度は同じ環境でmcp-server-kubernetesを試してみたいと思います。こちらは読み取り以外も対応してるようなので、podなど作成してみたいと思います。
事前準備
claude codeへmcp-server-kubernetesを登録
以下を実行します。
claude mcp add kubernetes -- npx mcp-server-kubernetes
MCP で利用できるツール一覧
/mcp list で確認したところ、利用できるツールは以下のものでした。
こっちはcreate, applyだけでなくhelmなんかも扱えるようです。
1. cleanup
2. kubectl_get
3. kubectl_describe
4. kubectl_apply
5. kubectl_delete
6. kubectl_create
7. kubectl_logs
8. kubectl_scale
9. kubectl_patch
10. kubectl_rollout
11. kubectl_context
12. explain_resource
13. install_helm_chart
14. upgrade_helm_chart
15. uninstall_helm_chart
16. node_management
17. port_forward
18. stop_port_forward
19. exec_in_pod
20. list_api_resources
21. kubectl_generic
22. ping
実行例（Claude Code 実際のログ）
- ポッドの一覧を出してみる
> デフォルトネームスペースのポッドをリストしてください
● デフォルトネームスペースのポッドをリストします。
● kubernetes - kubectl_get (MCP)(resourceType: "pods", namespace: "default", output: "json")
⎿ {
"items": []
}
● デフォルトネームスペースにはポッドがありません。現在、このネームスペースは空です。
他のネームスペースのポッドを確認したい場合や、新しいポッドをデプロイしたい場合はお知らせください。
- nginxを作成してみる、失敗したら直しますかと聞いてきて直してくれる
> デフォルトネームスペースにnginxのポッドを作成してください
● デフォルトネームスペースにnginxのポッドを作成します。
● kubernetes - kubectl_create (MCP)(resourceType: "deployment", name: "nginx", image: "nginx", namespace: "default", replicas: 1)
⎿ apiVersion: apps/v1
kind: Deployment
metadata:
… +38 lines (ctrl+o to expand)
● nginxデプロイメントが正常に作成されました！ポッドの状態を確認します。
● kubernetes - kubectl_get (MCP)(resourceType: "pods", namespace: "default", output: "json")
⎿ {
"items": [
{
… +8 lines (ctrl+o to expand)
● nginxポッドが正常に作成されました！
作成されたリソース:
- デプロイメント名: nginx
- ポッド名: nginx-66686b6766-q4njz
- ステータス: Pending（現在起動中）
- ネームスペース: default
ポッドは現在「Pending」状態です。これは、コンテナイメージをプルしてポッドをスケジュールしている段階です。数秒後には「Running」状態になるはずです。
ポッドの詳細を確認したい場合や、ステータスを再度チェックしたい場合はお知らせください。
> デフォルトネームスペースのポッドをリストしてください
● デフォルトネームスペースのポッドをリストします。
● kubernetes - kubectl_get (MCP)(resourceType: "pods", namespace: "default", output: "json")
⎿ {
"items": [
{
… +8 lines (ctrl+o to expand)
● 現在、デフォルトネームスペースに1つのポッドがあります：
ポッド一覧:
- 名前: nginx-66686b6766-q4njz
- ステータス: Pending
- 作成日時: 2025-12-11T04:20:14Z
ポッドがまだ「Pending」状態です。詳細を確認して、なぜ起動していないのか調べることができます。ポッドの詳細情報やログを確認しますか?
> おねがいします
● ポッドの詳細情報を確認します。
● kubernetes - kubectl_describe (MCP)(resourceType: "pod", name: "nginx-66686b6766-q4njz", namespace: "default")
⎿ Name: nginx-66686b6766-q4njz
Namespace: default
Priority: 0
… +52 lines (ctrl+o to expand)
● 問題が見つかりました！ポッドがイメージのプルに失敗しています。
問題点:
- エラー: ImagePullBackOff
- 原因: 短縮イメージ名「nginx」が曖昧なため、イメージのプルに失敗しています
この環境では、完全修飾イメージ名（FQIN）が必要です。現在のデプロイメントを削除して、正しいイメージ名で再作成します。
● kubernetes - kubectl_delete (MCP)(resourceType: "deployment", name: "nginx", namespace: "default")
⎿ deployment.apps "nginx" deleted from default namespace
● kubernetes - kubectl_create (MCP)(resourceType: "deployment", name: "nginx", image: "docker.io/library/nginx:latest", namespace: "default", replicas: 1)
⎿ apiVersion: apps/v1
kind: Deployment
metadata:
… +38 lines (ctrl+o to expand)
● デプロイメントを再作成しました。完全修飾イメージ名（docker.io/library/nginx:latest）を使用しています。新しいポッドの状態を確認します。
● kubernetes - kubectl_get (MCP)(resourceType: "pods", namespace: "default", output: "json")
⎿ {
"items": [
{
… +8 lines (ctrl+o to expand)
● 完了しました！nginxポッドが正常に起動しました。
現在のポッド:
- 名前: nginx-568f7cfd68-75hj9
- ステータス: Running ✓
- 作成日時: 2025-12-11T04:24:47Z
完全修飾イメージ名（docker.io/library/nginx:latest）を使用することで、イメージのプルが成功し、ポッドが正常に起動しました。
- 適当なアプリケーションを作成してLBで公開してみる
> なんでもよいので適当なサンプルアプリケーションのpodを作成してLoadbalancer ポート80で公開してください
● サンプルアプリケーションをデプロイしてLoadBalancerで公開します。タスクを整理します。
● シンプルなWebアプリケーションをデプロイします。
● kubernetes - kubectl_create (MCP)(resourceType: "deployment", name: "hello-app", image: "gcr.io/google-samples/hello-app:1.0", namespace: "default", replicas: 2, port: 8080)
⎿ apiVersion: apps/v1
kind: Deployment
metadata:
… +41 lines (ctrl+o to expand)
● デプロイメントが作成されました。次にLoadBalancerサービスを作成します。
● kubernetes - kubectl_create (MCP)(resourceType: "service", name: "hello-app-lb", namespace: "default", serviceType: "loadbalancer", tcpPort: ["80:8080"], labels: ["app=hello-app"])
⎿ Error: MCP error -32603: MCP error -32603: Failed to create resource: Command failed: kubectl create service loadbalancer hello-app-lb --tcp=80:8080 -n default -l app=hello-app -o yaml
error: unknown shorthand flag: 'l' in -l
See 'kubectl create service loadbalancer --help' for usage.
● kubectl createコマンドに制限があるため、マニフェストを使用してサービスを作成します。
● kubernetes - kubectl_apply (MCP)(namespace: "default", manifest: "apiVersion: v1\nkind: Service\nmetadata:\n name: hello-app-lb\n namespace: default\nspec:\n type: LoadBalancer\n
selector:\n app: hello-app\n ports:\n - protocol: TCP\n port: 80\n targetPort: 8080")
⎿ service/hello-app-lb created
● LoadBalancerサービスが作成されました。サービスの詳細と外部IPを確認します。
● kubernetes - kubectl_get (MCP)(resourceType: "service", name: "hello-app-lb", namespace: "default", output: "json")
⎿ {
"apiVersion": "v1",
"kind": "Service",
… +44 lines (ctrl+o to expand)
● kubernetes - kubectl_get (MCP)(resourceType: "pods", namespace: "default", labelSelector: "app=hello-app", output: "json")
⎿ {
"items": [
{
… +15 lines (ctrl+o to expand)
● 完了しました！サンプルアプリケーションをデプロイし、LoadBalancerサービスで公開しました。
作成されたリソース:
📦 デプロイメント: hello-app
- イメージ: gcr.io/google-samples/hello-app:1.0
- レプリカ数: 2
- ポッドステータス: 両方とも Running ✓
🌐 LoadBalancerサービス: hello-app-lb
- タイプ: LoadBalancer
- ポート: 80 (外部) → 8080 (コンテナ)
- ClusterIP: xx.xx.xx.xx
- NodePort: 31970
接続方法:
1. 外部IPによるアクセス: 現在、外部IPは割り当て待ちです（クラウドプロバイダーがロードバランサーをプロビジョニング中、または追加設定が必要な可能性があります）
2. NodePortによるアクセス: http://<ノードのIP>:31970 でアクセス可能です
外部IPのステータスを確認したい場合は、kubectl get service hello-app-lb で確認できます。
> アプリケーションのurlおしえて
● サービスの最新状態を確認して、アクセスURLをお伝えします。
● kubernetes - kubectl_get (MCP)(resourceType: "service", name: "hello-app-lb", namespace: "default", output: "json")
⎿ {
"apiVersion": "v1",
"kind": "Service",
… +51 lines (ctrl+o to expand)
● kubernetes - kubectl_get (MCP)(resourceType: "nodes", output: "json")
⎿ {
"items": [
{
… +8 lines (ctrl+o to expand)
● 外部IPが割り当てられました！アプリケーションにアクセスできます。
アプリケーションURL:
http://xxx.xxx.xxx.xxx
または
http://xxx.xxx.xxx.xxx:80
このURLをブラウザで開くと、"Hello, world!" メッセージとバージョン情報が表示されます。
サービス情報:
- 外部IP: xxx.xxx.xxx.xxx
- ポート: 80
- バックエンド: 2つのhello-appポッド
ブラウザでみるとこんな感じ
- 次にOracle Database OperatorでADBプロビジョニングしようとしたらうまくいかなくてごちゃごちゃになったので削除
> バルス
● 了解しました。
作成したリソース(Autonomous Databaseリソース、Secrets、ConfigMap、Oracle Database Operator、cert-manager等)を削除しますか?それとも、そのまま残しておきますか?
> はい
● 作成したリソースを削除します。
● Bash(kubectl delete adb myadb -n default)
⎿ autonomousdatabase.database.oracle.com "myadb" deleted from default namespace
● Bash(kubectl delete secret oci-privatekey adb-admin-password -n default)
⎿ secret "oci-privatekey" deleted from default namespace
secret "adb-admin-password" deleted from default namespace
● Bash(kubectl delete configmap oci-config -n default)
⎿ configmap "oci-config" deleted from default namespace
● Bash(kubectl delete -f https://raw.githubusercontent.com/oracle/oracle-database-operator/main/oracle-database-operator.yaml)
⎿ namespace "oracle-database-operator-system" deleted
customresourcedefinition.apiextensions.k8s.io "autonomouscontainerdatabases.database.oracle.com" deleted
customresourcedefinition.apiextensions.k8s.io "autonomousdatabasebackups.database.oracle.com" deleted
… +26 lines (ctrl+o to expand)
● Bash(kubectl delete -f https://github.com/cert-manager/cert-manager/releases/download/v1.16.2/cert-manager.yaml)
⎿ namespace "cert-manager" deleted
customresourcedefinition.apiextensions.k8s.io "certificaterequests.cert-manager.io" deleted
customresourcedefinition.apiextensions.k8s.io "certificates.cert-manager.io" deleted
… +46 lines (ctrl+o to expand)
● Bash(rm -f /home/opc/adb-manifest.yaml)
⎿ (No content)
● すべてのリソースを削除しました:
- Autonomous Databaseリソース
- Secrets (oci-privatekey, adb-admin-password)
- ConfigMap (oci-config)
- Oracle Database Operator
- cert-manager
- マニフェストファイル
クリーンアップ完了です。
おわりに
自然言語でCreateやApplyまで実行できて、アプリケーションの公開などできたので満足感がありました。ただ、OraOperatorでADBをプロビジョニングしようとしたとき、Claude codeが動かない原因を調査し始めたのですが、適当にYes, Yes,...と押していったら、途中から何をしてるかわからなくなったし、結局動きませんでした。(たぶんプロンプトが適当すぎて必要なものが足りなかったんだと思います) こういった場合は全任せではなく調査の補助くらいにした方がいいのかと思いました。
参考リンク
mcp-server-kubernetes
https://github.com/Flux159/mcp-server-kubernetes