1. 运维人的真实痛点kubectl 记不住Pod 状态查不明白凌晨两点被告警叫醒脑子里只有一句“某个服务好像挂了”但具体是哪个 Pod、哪个命名空间、是 CrashLoopBackOff 还是 ImagePullBackOff全靠一条条kubectl命令去翻。我试过把常用命令存成 alias也写过一堆 shell 脚本但集群一多、命名空间一乱还是得现场拼参数。更别说新同事上手光kubectl get pods -n xxx -o wide和kubectl describe pod的区别就要解释半天。这就是自然语言查询 K8s 集群的价值所在你不需要记住kubectl的完整语法只需要用中文问“default 命名空间下有哪些 Pod 没跑起来”“帮我看看 nginx 这个 Pod 最近 100 行日志”AI 工具通过 MCP 协议调用集群只读接口把结果整理成人类能直接读的答案。适合谁适合日常要巡检、排障、写值班报告的运维和 SRE也适合刚接触 K8s、命令还不熟的开发同学。但这里有个现实问题AI 工具要调用模型模型要能稳定访问而很多团队的模型接入是分散的——这个工具配一个 Key那个工具配另一个 Key额度、计费、限流各管各的。TaoToken 解决的就是这一层用一个统一 Key 和统一 API 通道把模型调用收敛到一处再让 AI 客户端去连 K8s 的 MCP Server。整条链路是“自然语言 → AI 客户端 → TaoToken 统一通道 → 模型 → MCP Server → K8s API”模型侧走 TaoToken集群侧走只读 ServiceAccount两边都不碰生产写权限。下面我会先讲清楚 TaoToken 这一层怎么配再给出一套可复制的 K8s 只读 MCP 部署与验证步骤最后把常见报错逐个拆开。你跟着做能实现的效果是在支持 MCP 的 AI 客户端里输入“列出所有命名空间”“查看 default 下的 Pod”直接拿到集群真实状态不用再手敲kubectl。2. TaoToken 前置准备统一 Key 与 API 通道怎么落地TaoToken 在这里的角色是“模型调用的统一入口”。你不需要在每个 AI 工具里分别填不同的厂商 Key而是拿一个 TaoToken 的 Key配合统一的 Base URL让客户端把模型请求发到同一个通道。这样做的好处很直接额度集中管理、切换模型不用改一堆配置、排查问题时只需要看一个入口的日志。第一步是拿到 Key。访问https://taotoken.net/api-keysdeep link 带归因?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite在控制台里创建一个 API Key。创建时建议按用途命名比如k8s-ops-mcp方便后面区分是哪个场景在用。Key 只显示一次复制后先存到密码管理器里。第二步是确认 Base URL。TaoToken 的 API 入口是https://taotoken.net/api注意这个地址不带 UTM 参数直接作为客户端的 Base URL 使用。很多 AI 客户端比如 Cline、Continue、Cherry Studio 的模型配置都支持自定义 OpenAI 兼容的 Base URL填这个就行。第三步是选模型。K8s 查询场景对模型的要求是“能理解工具调用、能读懂 JSON 结构”不需要特别大的模型。你可以在https://taotoken.net/models带归因?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite里看当前可用的模型列表选一个支持 function calling / tool use 的即可。我实测下来中等规模的模型处理pods_list、events_list这类结构化返回已经够用响应也快。这里要强调一个边界TaoToken 是模型调用的统一通道不是 K8s 的代理。它不接触你的集群也不存储你的 Pod 日志。集群侧的访问控制完全由 K8s 的 ServiceAccount 和 RBAC 决定这一点在下一节的部署里会体现。把这两层分开理解安全边界就清楚了。如果你用的是 Claude Code 这类编码 AgentTaoToken 也提供了对应的接入方式可以在https://taotoken.net/doc带归因?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite里找到 ClaudeCodeAnthropic 的配置说明。不过本篇聚焦的是 K8s 自然语言查询模型侧只要保证客户端能正常调用即可。3. 可复制配置K8s 只读 MCP Server 与客户端接入片段这一节给的是可以直接复制粘贴的配置。整体思路是在集群里部署一个只读的kubernetes-mcp-server用最小权限的 ServiceAccount 运行然后通过 Ingress 暴露给 AI 客户端客户端侧配置 TaoToken 的 Base URL 和 Key再添加 MCP 连接。先看集群侧的命名空间和 ServiceAccount。创建命名空间mcp然后建一个mcp-viewer的 ServiceAccount绑定内置的viewClusterRole。view角色只允许读不允许写、删、改这是安全底线。kubectl create namespace mcp kubectl create serviceaccount mcp-viewer -n mcp kubectl create clusterrolebinding mcp-viewer-crb \ --clusterroleview \ --serviceaccountmcp:mcp-viewer接着是 Deployment 和 Service。镜像用ghcr.io/containers/kubernetes-mcp-server:latest资源请求给得很小CPU 10m、内存 32Mi限制 50m / 64Mi对集群几乎无影响。注意serviceAccountName要写成mcp-viewer这样 Pod 里的进程才有只读权限。apiVersion: apps/v1 kind: Deployment metadata: name: kubernetes-mcp-server namespace: mcp labels: app: kubernetes-mcp-server spec: replicas: 1 selector: matchLabels: app: kubernetes-mcp-server template: metadata: labels: app: kubernetes-mcp-server spec: serviceAccountName: mcp-viewer containers: - name: mcp-server image: ghcr.io/containers/kubernetes-mcp-server:latest resources: requests: cpu: 10m memory: 32Mi limits: cpu: 50m memory: 64Mi ports: - containerPort: 8080 --- apiVersion: v1 kind: Service metadata: name: kubernetes-mcp-server namespace: mcp spec: selector: app: kubernetes-mcp-server ports: - protocol: TCP port: 8080 targetPort: 8080 type: ClusterIP保存成mcp-server.yaml执行kubectl apply -f mcp-server.yaml。然后确认 Pod 状态kubectl get pods -n mcp kubectl logs -n mcp -l appkubernetes-mcp-server日志里看到正常启动、没有报错就说明服务端起来了。接下来是 Ingress把服务暴露给集群外的 AI 客户端。这里用 nginx ingressTLS 用 cert-manager 自动签发proxy-read-timeout和proxy-send-timeout设成 3600 秒因为 MCP 的流式响应可能持续较久。apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: mcp-server namespace: mcp annotations: cert-manager.io/cluster-issuer: letsencrypt-prod nginx.ingress.kubernetes.io/rewrite-target: / nginx.ingress.kubernetes.io/proxy-read-timeout: 3600 nginx.ingress.kubernetes.io/proxy-send-timeout: 3600 spec: ingressClassName: nginx tls: - hosts: - mcp-preview.example.com secretName: mcp-server-tls rules: - host: mcp-preview.example.com http: paths: - path: / pathType: Prefix backend: service: name: kubernetes-mcp-server port: number: 8080把mcp-preview.example.com换成你自己的域名kubectl apply之后等证书签发完成。到这里集群侧就准备好了。客户端侧以支持 MCP 的 AI 工具为例模型配置填 TaoToken 的 Base URL 和 KeyMCP 连接填https://mcp-preview.example.com/mcp传输类型选 Streamable HTTP。如果你用的是 Cline 或 CC Switch 这类工具配置结构类似核心三件套是 Base URL、Key、Model ID缺一不可。Model ID 从 TaoToken 的模型列表里选一个支持工具调用的即可。4. 验证请求从自然语言到集群真实状态配置完成后先别急着在客户端里问复杂问题用 curl 手动走一遍 MCP 的握手流程确认服务端和网络都通。这一步能帮你把“客户端问题”和“服务端问题”分开。MCP 的 Streamable HTTP 模式要求先发一个 POST 做初始化拿到Mcp-Session-Id后续请求带上这个 Header。直接 GET 会报400 Bad Request: GET requires an Mcp-Session-Id header这是正常的不是配置错了。curl -X POST https://mcp-preview.example.com/mcp \ -H Content-Type: application/json \ -d { jsonrpc: 2.0, method: initialize, params: { protocolVersion: 0.1.0, clientInfo: { name: test-client, version: 1.0 } }, id: 1 } -v成功的话响应头里会有mcp-session-idbody 里是{jsonrpc:2.0,id:1,result:{capabilities:{...}}}。把那个 session id 复制下来比如QPBAAFTBHI3X24Z35LJ47LUQF4然后带上它发流式请求curl -N -H Accept: text/event-stream \ -H Mcp-Session-Id: QPBAAFTBHI3X24Z35LJ47LUQF4 \ https://mcp-preview.example.com/mcp如果能看到event: message和data:开头的流式返回说明 MCP 通道完全打通。这时候回到 AI 客户端在对话框里输入“列出所有命名空间”客户端会自动完成 JSON-RPC 握手、加载工具列表包括namespaces_list、pods_list、nodes_list、events_list、resources_get等然后调用对应工具把结果整理成自然语言返回。你可以依次试这几个问题验证不同工具“集群里有多少个节点”——对应nodes_list“default 命名空间下有哪些 Pod”——对应pods_list“最近有哪些 Warning 事件”——对应events_list“帮我看看 xxx Pod 的日志”——对应resources_get或日志相关工具实测下来从提问到拿到答案通常在几秒内返回的内容比kubectl的原始输出更易读比如它会直接告诉你“有 2 个 Pod 处于 Running1 个处于 CrashLoopBackOff最近重启 5 次”。这就是自然语言查询的价值把命令和输出之间的翻译工作交给 AI。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节把实际会撞到的报错列出来对照着改。401 Unauthorized出现在模型调用侧说明 TaoToken 的 Key 没填对或过期了。检查客户端里的 API Key 是否和https://taotoken.net/api-keys里创建的一致Base URL 是否是https://taotoken.net/api。注意 Base URL 不要带 UTM 参数也不要多加/v1之外的路径具体以文档为准。如果 Key 刚创建确认没有多余空格。local proxy failed通常出现在客户端配置了本地代理或网络层拦截时。这个报错和 K8s 无关是客户端到 TaoToken 通道的连接问题。检查客户端的网络设置确认能正常访问https://taotoken.net/api。如果是公司网络确认出口策略允许该域名。reading choices 相关报错一般是模型返回结构不符合客户端预期常见原因是 Model ID 填错或者选了一个不支持工具调用的模型。回到 TaoToken 的模型列表确认所选模型支持 function calling然后把 Model ID 原样填回客户端。三件套 Base URL、Key、Model ID 要同时正确缺一个都会出这类错。OAuth 相关报错如果你用的是 Claude Code 或 Codex 这类带 OAuth 流程的工具报错往往出在认证回调上。检查auth.json或对应配置文件里的字段是否完整Base URL 是否指向 TaoToken 的通道。Claude Code 的接入方式在https://taotoken.net/doc里有说明按文档把 Anthropic 相关的 Base URL 和 Key 配好即可。不要混用多个来源的配置容易互相覆盖。MCP 侧 400 Bad Request如果报GET requires an Mcp-Session-Id header说明你直接 GET 了/mcp。按第 4 节先 POST 初始化拿 session id再带 Header 请求。客户端一般会自动处理手动 curl 时才需要注意。Pod 一直 Pending 或 ImagePullBackOff检查节点能否拉取ghcr.io的镜像。国内访问 ghcr.io 可能较慢可以提前在节点上用crictl pull预热或者配置镜像加速。资源限制给得很小Pending 一般不是资源不足而是调度或镜像问题。Ingress 502检查 Service 的targetPort是否和容器containerPort一致以及 Pod 是否 Ready。kubectl get endpoints -n mcp能看到后端地址才算正常。6. 把这条链路用起来从查询到日常巡检整套跑通之后你可以把常用问题固化成自己的“自然语言巡检清单”。比如每天早上问一遍“所有命名空间里有没有非 Running 的 Pod”“最近一小时有没有 Warning 事件”“节点资源使用率如何”AI 会依次调用 MCP 工具并把结果汇总。这比手敲一串kubectl再肉眼比对要省事得多。如果后面要扩展可以再接入 Grafana MCP、Prometheus MCP把指标查询也纳入同一套自然语言入口。模型侧继续走 TaoToken 的统一 Key新增工具时只需要在客户端加 MCP 连接不用再折腾模型配置。需要长期跑编码或 Agent 任务的可以看下 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite把额度规划好只是验证模型效果的用模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite先试几个问题也够。集群侧的只读权限和view角色保持不变安全边界始终清晰。
