k8s(raspberry pi)のpodのログをチャットで観れるか実験してみました。
この後、エラーがログに出てないかも聞いてみました
2026年3月30日月曜日
2026年3月29日日曜日
M4 MaxのRoo Codeから自宅ラズパイk8sクラスターをMCPで「完落ち」させるまで
1. はじめに（背景）
最新の M4 Max搭載 Mac Studio を導入しました。この圧倒的なパワーをローカルLLMの実行だけに使うのはもったいない。そこで、長年運用している 自作のラズパイ・クラスター（3台構成） を、VS CodeのAIエージェント「Roo Code」から直接操作・管理できる環境を構築することにしました。
AIに「インフラの目と手」を与えるための架け橋として、GoogleやAnthropicが推進する Model Context Protocol (MCP) を活用します。
技術スタック
Client: Roo Code (VS Code Extension)
Protocol: Model Context Protocol (MCP)
Runtime: Node.js
Infrastructure: Kubernetes (Raspberry Pi Cluster), kubectl
[構成図]
2. フェーズ1：MCPブリッジの構築（疎通編）
AIとKubernetesを繋ぐ既成のMCPサーバーが見当たらなかったため、Node.jsで簡易ブリッジ k8s-bridge.js を自作しました。
ハマりポイント：環境変数PATHの壁
ターミナルでは動くのに、Roo Code経由だと kubectl が見つからない問題が発生。VS Codeから起動されるMCPプロセスには、普段のシェル（.zshrc等）の PATH が引き継がれないのが原因でした。
対策: * kubectl をフルパス（/opt/homebrew/bin/kubectl）で指定。
mcp_settings.jsonのenvセクションにも明示的にPATHを記述。
3. フェーズ2：JSONとハンドシェイクの格闘（接続編）
Roo Codeの設定画面でランプが「黄色（再試行中）」から変わらず、接続に苦労しました。
ハマりポイント：JSON-RPCプロトコルの厳密さ
MCPは標準入出力を介した JSON-RPC 通信です。AIからの initialize リクエストに対し、仕様に沿ったレスポンスを即座に返さないと、AIは接続先が生きていると認識してくれません。
対策: 最小限の initialize 応答と tools/list 応答を実装。ついにランプが 「緑（Connected）」 へ変わり、AIがクラスターを認識しました。
4. フェーズ3：万能ツールへの進化（実行編）
当初は「ノード一覧を取得するだけ」のReadOnlyなツールでしたが、これではPodの生成ができません。そこで、引数を自由に渡せる汎用ツール run_kubectl へ刷新しました。
実装の肝
Node.jsの spawn を使い、stdout（標準出力）と stderr（標準エラー）の両方をバッファリングしてAIに返すロジックを実装しました。これにより、AIが「自分でYAMLを書き、自分でapplyし、エラーが出れば自分で修正する」という自律的なループが可能になりました。
5. 動作確認：AIにPodを作らせてみた
実験指示: 「NginxのPodを作って」 結果: AIが run_kubectl を使って default namespaceに my-web Podを生成。
感動ポイント: get pods -A を実行した際、自分が長年運用してきた Argo CD や Cilium と並んで、AIが生成した my-web が Running になっている のを見た瞬間、インフラ運用の新しい時代を感じました。
6. まとめ：AI時代のインフラ管理
M4 Maxのパワーがあれば、ローカルでAIを回しながら、物理インフラの運用（ログ解析、トラブルシュート、デプロイ）を対話形式で自動化できます。
インフラエンジニアにとってのMCPは、単なる便利ツールではありません。「自分の長年の経験とスキルを、AIという強力な相棒に移植するためのプラグ」 なのだと確信しました。
🛠 実装リソース
万能型MCPブリッジ：k8s-bridge.js
標準モジュールのみで構成しているため、npm install 不要で動作します。
JavaScript(kubectl & helm対応)
-------------------------------------------------
#!/usr/bin/env node
const { spawn } = require('child_process');
// Mac (Homebrew) のデフォルトパス
const KUBECTL_PATH = '/opt/homebrew/bin/kubectl';
const HELM_PATH = '/opt/homebrew/bin/helm';
let buffer = '';
process.stdin.on('data', (chunk) => {
buffer += chunk.toString();
let lines = buffer.split('\n');
buffer = lines.pop();
for (let line of lines) {
if (!line.trim()) continue;
try {
handleMessage(JSON.parse(line));
} catch (e) {
console.error("JSON Parse Error:", e);
}
}
});
function handleMessage(message) {
const respond = (result) => {
process.stdout.write(JSON.stringify({ jsonrpc: "2.0", id: message.id, result }) + '\n');
};
// 1. 初期化
if (message.method === 'initialize') {
respond({
protocolVersion: "2024-11-05",
capabilities: { tools: {} },
serverInfo: { name: "k8s-helm-bridge", version: "1.2.0" }
});
// 2. ツール一覧の定義
} else if (message.method === 'tools/list') {
respond({
tools: [
{
name: "run_kubectl",
description: "kubectl コマンドを実行します（例: get pods, logsなど）",
inputSchema: {
type: "object",
properties: {
args: { type: "array", items: { type: "string" } }
},
required: ["args"]
}
},
{
name: "run_helm",
description: "helm コマンドを実行します（例: list, status, installなど）",
inputSchema: {
type: "object",
properties: {
args: { type: "array", items: { type: "string" } }
},
required: ["args"]
}
}
]
});
// 3. 実行ロジック
} else if (message.method === 'tools/call') {
const toolName = message.params.name;
const args = message.params.arguments.args;
// ツール名によってバイナリを選択
let commandPath;
if (toolName === 'run_kubectl') {
commandPath = KUBECTL_PATH;
} else if (toolName === 'run_helm') {
commandPath = HELM_PATH;
} else {
return respond({ content: [{ type: "text", text: "Unknown tool" }], isError: true });
}
// コマンド実行
const proc = spawn(commandPath, args, {
env: { ...process.env } // kubeconfigやHelmのパスを通すために重要
});
let stdout = '';
let stderr = '';
proc.stdout.on('data', (d) => { stdout += d.toString(); });
proc.stderr.on('data', (d) => { stderr += d.toString(); });
proc.on('close', (code) => {
const isError = code !== 0;
respond({
content: [{
type: "text",
text: isError ? stderr.trim() || `Error: Exit code ${code}` : stdout.trim() || "Success"
}],
isError: isError
});
});
}
}
----------------------------------------------------------------------
Roo Code設定：mcp_settings.json
設定ファイルの場所: ~/Library/Application Support/Code/User/globalStorage/rooveterinaryinc.roo-cline/settings/mcp_settings.json
JSON
{
"mcpServers": {
"kubernetes": {
"command": "node",
"args": ["/Users/hidenari/src/k8s-bridge.js"],
"env": {
"KUBECONFIG": "/Users/hidenari/.kube/config",
"PATH": "/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
}
}
}
}
実際の設定の様子。
MCPサーバーの状態もグリーンランプが表示されていることを確認します。
💡 技術Tips
pkillの重要性: コード変更後は
pkill -f k8s-bridge.jsで旧プロセスを掃除しないと、新旧コードが混在してハマります。バッファリングの罠: Node.jsの
dataイベントは分割されて届くため、lines.pop()によるバッファ保持がプロトコル通信の生命線です。[検証]
検証として、Podの作成をチャットを通してお願いした結果になります。
2026年3月3日火曜日
Pod Security Admission
[用途]
ルール対象外のマニフェストをデプロイさせないための
防止策で利用するイメージになる
[検証]
以下のコマンドを投入する
kubectl label ns default pod-security.kubernetes.io/warn=baseline
[各種コマンドの意味]
1. kubectl label ns default
- 意味: default という名前空間（Namespace）に「付箋（ラベル）」を貼るという指示です。
- ポイント: 新しい設定ファイルを作るのではなく、既存の「箱（Namespace）」の属性を書き換えるだけで設定が完了するのが、最新の PSA (Pod Security Admission) の特徴です。
2. pod-security.kubernetes.io/
- 意味: これは「Podセキュリティ機能に対する設定ですよ」という接頭辞（プレフィックス）です。
- 役割: k8sには多くのラベルがありますが、この名前で始まるラベルを貼ることで、k8sのエンジンが自動的に「セキュリティのチェックを開始しなきゃ！」と判断します。
3. warn (コントロール・モード)
PSAには3つのモードがありますが、今回はその中の 警告モード を選びました。
- enforce (強制): 基準に合わないPodは起動させない。
- audit (監査): ログに記録するだけ。
- warn (警告): 今回の結果の通り、Podは起動させるが、実行者に警告を出す。
セキュリティの「厳しさ」のレベルです。
- Privileged: 無制限。何でも許容する。
- Baseline: 今回の設定。 最小限の「危ない設定」を禁止する標準レベル。
- Restricted: 非常に厳しい。Podを動かすために、細かいセキュリティ設定が必須。
問題があるマニフェストをデプロイしてみる
apiVersion: v1
kind: Pod
metadata:
name: security-test-pod
spec:
hostNetwork: true # ← これが基準違反のポイント
containers:
- name: nginx
image: nginx:alpine
以下の警告表示が出ることが確認できる
登録:
コメント (Atom)
-
apk add openrc --no-cache [ 以下のように使えることが把握できる ] alpinelinuxのサービスの再起動コマンド： rc-service nginx restart -
以下のログに表示されている、" network unreachable resolving"は IPv6に関するメッセージではあるが、基本的にIPv4しか使用していないため このメッセージを消したい時の対策を以下に示す。 上記は、IPv4での名前解決...