传统的 Java 压测诊断流程通常是这样的：打开监控大盘、发现异常、SSH 进跳板机、kubectl exec 进 Pod、attach Arthas、手工敲命令、拼结论。这个流程的问题不是步骤多，而是每一步都依赖人工，压测窗口很短，诊断常常跟不上问题出现的节奏。

Arthas MCP 把这件事往前推了一步——让 AI Agent 可以直接调用 Arthas 的诊断工具，把"人工执行诊断命令"这件事自动化掉。

但在远端 K8s 场景下，开始动手才会发现：真正的挑战不在 MCP 的几个参数配置，而在于如何构建一条从本地 Agent 穿透到 Pod 内部的安全链路。 本文的答案是：把链路复杂度封装在连接层，让 Agent 始终看到一个稳定的 localhost 地址。

远端 K8s 的核心障碍

在本地环境里，Arthas MCP 的接入几乎没有门槛——启动 Arthas、指定 httpPort 和 mcpEndpoint，Agent 直接连。

但在远端 K8s 里，有三件事会让这条路走不通：

  1. 网络隔离：Pod 处于 K8s 内网，本地无法直接访问 Pod IP。
  2. 安全边界：把 Arthas HTTP 端口通过 LoadBalancer 或公网 Ingress 暴露出来，等于把高权限诊断入口开放给外部，风险极高。
  3. 动态性：Pod 名称和 IP 随时可能变化，Agent 侧配置无法写死。

所以问题的本质是：如何用一套对 K8s 改动最小、安全边界清晰的方式，把 Pod 内部的 Arthas MCP 端口安全地带到本地。

推荐链路：SSH + kubectl port-forward

综合安全性、临时性和改动成本，最推荐的方案是 SSH 隧道 + K8s 原生端口转发：

本地 Agent
  → localhost:18563
  → SSH 隧道（ssh -L）
  → 远端 Master / 跳板机
  → kubectl port-forward
  → Pod 内 Arthas（8563）

为什么是这套方案：

  • 安全：复用 SSH 认证和 K8s RBAC，不需要新开防火墙端口
  • 临时：链路按需建立，断开即失效，符合最小权限原则
  • 改动小：不修改 Service、不新增 Ingress、不部署额外基础设施

为什么不选 Arthas Tunnel：Tunnel 解决的是多实例集中管理的问题。如果你现在只需要在压测时连进一个特定 Pod，部署和维护一套 Tunnel Server 成本过高，不划算。等到需要同时诊断多个实例时再考虑 Tunnel。

服务端准备：开启 Arthas MCP

在 Pod 内启动 Arthas 时，最小必要配置：

arthas.mcpEndpoint=/mcp
arthas.httpPort=8563
arthas.password=your-secure-password

压测诊断不需要所有 Arthas 能力，建议禁掉以下高风险命令：

arthas.disabledCommands=stop,dump,heapdump
  • stop：防止 Agent 意外关闭 Arthas
  • dump / heapdump：避免在压测高峰期触发大量磁盘写入或 Full GC

连接前先在 Pod 内验证服务就绪：

curl -H "Authorization: Bearer your-secure-password" \
  http://127.0.0.1:8563/mcp

这一步通了，再建外部链路。跳过这步直接搭隧道，排障会很麻烦。

一键脚本：connect-arthas-mcp.sh

手工搭隧道的问题不是步骤多，而是容易出错，且每次压测都要重复。脚本把四件事自动化：

  1. 选择目标 Pod（Selector 或指定名称）
  2. 在远端执行 kubectl port-forward
  3. 在本地建立 ssh -L 隧道
  4. 输出本地 MCP 地址 + 可直接粘贴的 Agent 配置片段

典型使用方式：

通过 Selector 选 Pod（快速验证场景）：

bash connect-arthas-mcp.sh \
  --host 10.0.0.12 --user ops \
  --namespace prod --selector 'app=user-service' \
  --bearer-token 'your-secure-password'

指定 Pod（精确诊断场景）：

bash connect-arthas-mcp.sh \
  --host 10.0.0.12 --user ops \
  --namespace prod --pod user-service-7f8d9b-xxxxx \
  --bearer-token 'your-secure-password'

先 dry-run，看脚本会执行什么：

bash connect-arthas-mcp.sh \
  --host 10.0.0.12 --user ops \
  --namespace prod --selector 'app=user-service' \
  --dry-run

脚本成功后会输出：本地地址（http://127.0.0.1:18563/mcp）、验证用 curl、Agent 侧 MCP 配置片段。把配置片段粘进 Agent，它就能用这个地址直接调 Arthas。

压测中的诊断节奏

链路通了不等于可以随意调。在压测场景里，Arthas 应该是手术刀，不是电锯。

推荐的三层诊断顺序：

第一层：低侵入总览（先跑，不管结论如何）

  • dashboard、thread、memory、jvm
  • 目标：判断是 CPU 高、GC 频繁、线程数异常，还是堆内存压力

第二层：方法级统计（锁定接口后）

  • monitor 限定特定类和方法
  • 看调用量、RT 趋势、失败率

第三层：链路剖开（只在确定目标后）

  • trace、stack、watch
  • 必须加 -n 限定采集次数，必须加条件过滤，否则采集本身会污染压测结果

最容易踩的坑：连错 Pod

K8s Service 后通常挂多个副本。如果你连进了一个负载较低的 Pod，而性能瓶颈在另一个实例上，你看到的一切都是正常的，结论完全失效。

建立连接后，第一个动作应该是跑 dashboard，人工比对该 Pod 的 CPU 和线程数是否与压测预期匹配，确认你在看正确的实例。

总结

Arthas MCP 真正的价值是把 Java 诊断标准化成 Agent 可调用的工具接口。但在远端 K8s 场景下，工程价值的兑现，取决于你能不能把连接层做干净。

SSH + kubectl port-forward + 脚本化，这套组合的核心不是省命令，而是把链路变成一个可复用、可控制、易于排障的单元。Agent 侧不需要感知集群拓扑，只需要一个 localhost 地址。

落地路径建议：先打通单实例 → 脚本化 → 压测验证 → 多实例需求出现时再引入 Tunnel。顺序不要反。

参考文档：