Kubernetes 可观测性：用于更安全 EKS 故障排查的 MCP 专家 agents

作者：来自 Elastic Ramprasad KM

在 Elastic AI Agent 进行故障排查时，为集群检查限定一个专家 EKS MCP agent；通过几个提示使用该专家 agent 修复服务配置错误。

Elastic Observability 会向你展示在 service map 中哪些服务和边出现故障。你可能仍然需要访问诸如实时 kubernetes service specs 以及 containerPort 到 targetPort 映射等细节，而这些信息仍然存在于集群中。它们可以通过 EKS MCP 提供给 Elasticsearch。解决方案是通过一个专家 agent，为你的 Elastic AI Agent 配备一组聚焦的 EKS 工具。Elastic AI agent 会保留其默认工具，并继续作为你的 SRE 唯一交互入口。一个专家 K8s Troubleshooter agent 携带约 20 个 EKS MCP 工具，并限定在单一 IAM identity 和 Kubernetes RBAC 范围内。它们通过一个调用 Agent Builder converseAPI 的 Elastic Workflow 进行交接，因此可观测性推理与集群操作之间的边界是可调用、可审查且可审计的。为了证明其有效，我们在 elastic-opentelemetry-demo 中破坏了 product-catalog 的 targetPort，并在单个线程中的 4 个提示内完成恢复。

问题背景

故障通常会在 Elasticsearch 中表现为多个服务（如 checkout、frontend 和 recommendation）上的关联错误。这种模式可能意味着存在共享依赖，也可能意味着 Kubernetes 正在误导调用方：错误的 targetPort、空的 Endpoints，或者始终未进入 ready 状态的 pods。像 Elasticsearch 这样的可观测性工具会告诉你调用方失败了，以及哪些边看起来有问题。它们通常不会替你获取实时 Service spec，也不会替你比较 containerPort 与 targetPort。

Agent Builder 中的 Elastic AI Agent 是为 APM、日志、指标、依赖关系和 service maps 构建的。它并不是一个完整的 EKS 运维控制台。你当然可以把所有 EKS MCP 工具附加到同一个 agent 上，但过长的工具列表会增加错误工具调用、降低规划速度，并且如果某个提示意外请求了修改操作，还会扩大 blast radius。

解决方案概览

将 Elastic AI Agent 作为你的 SRE 唯一交互的 agent。它会首先基于 Elasticsearch 进行推理。当证据指向集群配置问题时，它会调用一个 workflow tool，通过 /api/agent_builder/converse 和结构化的 user_prompt 来调用 K8s Troubleshooter agent。K8s Troubleshooter agent 只携带 EKS MCP 工具，并且集群访问权限始终限定在单一专家 identity、IAM 和 RBAC 范围内。你可以像审计其他集成一样对其进行审计。

Elasticsearch 通过集群内桥接访问 EKS，并以带共享密钥的 MCP connector 形式暴露给 Kibana。

开始之前

你需要：

• 配置好 kubectl 的 EKS 集群。
• Elasticsearch 9.3+ 部署、OTLP endpoint、Elasticsearch API key、Agent Builder，以及创建 agents、MCP tools 和 Workflows 的权限。
• 用于你所选 LLM 的 Elasticsearch AI Connector。
• 第一次执行这些步骤时，请预留两到四小时。

实现演练

步骤 1：部署 Elastic OpenTelemetry Demo 并将遥测数据发送到 Elastic Observability

按照 elastic/opentelemetry-demo 的 Kubernetes 指南，在你的 EKS 集群中部署 elastic-opentelemetry-demo 应用。配置你的 Elasticsearch OTLP endpoint 和 API key，确认 workloads 正常运行，并记录 namespace。在 Kibana（APM、Logs 或 Service Map）中，确认 checkout、frontend、recommendation 和 product-catalog 的数据已经出现。

如果你看到流向 product-catalog 的健康流量，那么你已经准备好进行故障演练。

步骤 2：运行 EKS MCP bridge、注册 connector，并批量导入 EKS MCP tools

完整执行 aws-eks-mcp-setup 中的所有步骤。你将遵循以下流程：

1. 构建并推送 EKS MCP Bridge 镜像
2. 创建 IAM policies
3. 创建 IRSA Service Account
4. 在 aws-auth 中映射 IRSA role 并应用 Kubernetes RBAC
5. 使用强 API_ACCESS_TOKEN 将 bridge 部署到 EKS 集群
6. 将 Elastic Agent Builder 连接到 EKS MCP

绿色 MCP connector 表明 Kibana 可以访问该 bridge。

对于生产环境，应将 LoadBalancer security groups 限制为已知 Elasticsearch 出口地址，在真实路径上优先使用 TLS，将 token 存储在 Kubernetes Secrets 中，并在仅进行诊断时使用只读 MCP 模式。

步骤 3：创建仅包含 EKS 工具的 K8s Troubleshooter agent

在 Agent Builder 中创建一个 agent，agent ID 设置为 k8s_troubleshooter，显示名称为 K8s Troubleshooter，并使用来自 k8s_troubleshooter_agent 的自定义指令。该 agent 仅绑定 EKS MCP tools。

然后直接与 K8s Troubleshooter agent 进行一次对话，并确认执行一个无害的读取操作（例如列出 demo namespace 中的 pods）。

步骤 4（仅 Elasticsearch 9.3）：克隆不包含 EKS 工具的 Observability Agent

在 Agent Builder 中克隆内置的 Observability Agent（进入 Agent Builder → Manage Agents → Observability Agent → Clone），并将其命名为 Elastic AI Agent，以便保留原有的 Observability 系统指令和工具。不要在这个副本中添加 EKS MCP tools。

父级 Elastic AI Agent 将继续作为面向可观测性的交互入口，所有用户仍然通过它进行对话。

步骤 5：创建 workflow 并将其作为可调用工具

通过导入 k8s_troubleshooter_workflow.yaml 来创建一个新的 Elastic Workflow，并将其启用。

在 Agent Builder 中创建一个新的 Workflow 类型工具。选择 k8s_troubleshooter workflow，将工具 ID 设置为 custom.k8s_troubleshooter，并将描述设置为"用于处理和排查 kubernetes 相关问题的工具"（或你们团队标准化后的等价描述）。

在 Elastic AI Agent 上，挂载你刚刚创建的 custom.k8s_troubleshooter workflow 工具。

父级的工具列表中应显示已附加 custom.k8s_troubleshooter workflow 工具，同时 K8s Troubleshooter agent 在被单独调用时仍然能够正常响应。

步骤 6：注入 product-catalog 服务配置错误

保存原始的 targetPort，然后将其 patch 为一个错误的值（例如 9999）。

kubectl get svc -A | grep product-catalog
kubectl get svc product-catalog -n YOUR_NAMESPACE -o yaml

kubectl patch svc product-catalog -n YOUR_NAMESPACE --type='json' \
  -p='[{"op": "replace", "path": "/spec/ports/0/targetPort", "value": 9999}]'

kubectl rollout restart deployment/checkout deployment/recommendation deployment/frontend -n YOUR_NAMESPACE

调用方仍然能够解析 Endpoints，但流量会被发送到容器未监听的端口，因此 Elasticsearch 会在 checkout、frontend 和 recommendation 上显示下游错误。

现在你已经在 Elasticsearch 中看到了症状，并且确认了一个明确的 kubernetes 集群侧故障。

步骤 7：在父级 agent 上运行两个提示

使用 Elastic AI Agent 的 AI Agent chat，而不是在 specialist 上运行。

注意：如果你使用的是 Elasticsearch 9.3，请确保使用你自己创建的 Elastic AI Agent，而不是系统默认的 agent。

Prompt 1: Why are failure transactions increasing for services like checkout and frontend?

期望 Elastic AI Agent 将问题范围收敛到 product-catalog 服务，并将可能的配置问题作为潜在原因之一进行提示，但此时还不会调用 custom.k8s_troubleshooter 工具。

Prompt 2: Why is product-catalog service not servicing any requests in (insert your k8s cluster name) cluster? Is there any misconfiguration in the service?

期望 Elastic AI Agent 调用 custom.k8s_troubleshooter 工具，该工具会触发 K8s Troubleshooter agent，并读取 Service、Endpoints 和 pods，比较 targetPort 与 containerPort，并基于证据解释不匹配问题，同时给出推荐的修复步骤。

注意：根据你使用的 LLM，不同 agent 返回的结果可能会有所差异。

这样你就可以在 Elastic Observability 中获得 agent 主导的故障定位，同时在同一对话线程中获得基于集群的确认以及推荐的修复步骤。

第8步：修补 product-catalog service

Prompt 3: Patch the product-catalog service in (your EKS cluster name) cluster to have 8080 as the targetPort

期望 Elastic AI Agent 调用 custom.k8s_troubleshooter tool ，它调用 K8s Troubleshooter agent 并修补 product-catalog service 。

Prompt 4: Rollout restart upstream services of product-catalog service

期望 Elastic AI Agent 识别 product-catalog 的所有上游服务，并调用 custom.k8s_troubleshooter tool ，该工具会调用 K8s Troubleshooter agent，对上游服务（例如 checkout、frontend 和 recommendation）执行滚动重启。

确认 product-catalog 以及上游服务在 Elasticsearch 中恢复正常。

验证与权衡

你验证了 Elastic AI Agent 仍然是主要入口，约 20 个 EKS tools 被集中放在一个专家级 K8s Troubleshooter agent 上，并且 Workflow 与 Agent Builder converse API 之间保持清晰边界，便于审计与评审。

权衡：MCP 桥接需要持续的 token 与网络卫生管理，并且在你接受风险之前，应当将变更型 tools 关闭或严格进行 RBAC 限制。

常见问题

为什么 Elastic AI Agent 没有按本文所述进行问题分诊？

可能有两个主要原因。(A) 如果你使用的是 Elasticsearch 9.3，请确认你在与自己创建的 Elastic AI Agent 对话，而不是默认的 stock agent。(B) 请确保使用 Large language model performance matrix for Observability 中评级为 Excellent 或 Great 的 LLM 模型。

为什么在应用代码没有变更的情况下，我的服务在 Elasticsearch 中显示不健康？

Kubernetes 可能会误导 HTTP clients：例如 Service targetPort 配置错误、Endpoints 为空，或者 pods 一直未进入 ready 状态，这些问题会在 traces 和 service maps 中向外扩散为多处错误。Elastic Observability 可以展示哪些依赖失败，但要确认真实的 Service 状态通常仍需要集群访问。

如何在不把所有 EKS tools 放到 Elastic AI Agent 上的情况下给予 Kubernetes 访问权限？

运行两个 Agent Builder agents：在父级 Elastic AI Agent 上保留标准 tools，只在一个专门的 K8s Troubleshooter agent 上挂载 EKS MCP tools。通过 workflow 调用 Agent Builder converse API 来触发该专家 agent，从而保持边界清晰且可审计。

为什么要用 Elastic Workflows 进行 agent 链接，而不是一个很长的 system prompt？

Workflows 提供了一个可调用、可审查的步骤，用于连接 observability 推理与集群操作，有助于治理，并保持父 agent 的 tools 列表简洁。过长的统一 tools 列表容易增加误操作概率，并在 prompt 请求变更操作时扩大影响范围。

这种方式和 kubectl 或云控制台的应急响应有什么区别？

控制台与 kubectl 仍然是实时对象状态的真实来源。该模式通过 MCP 将 Elastic Observability 信号自动转交给这些检查步骤，同时仍依赖 IAM 和 Kubernetes RBAC 来约束专家身份。

EKS MCP bridge 的主要限制或风险是什么？

MCP bridge 需要 token 轮换、网络访问限制以及 TLS 规范的严格执行。变更型 EKS tools 在充分评估风险之前应保持关闭或严格 RBAC 限制。

为什么需要 EKS MCP bridge？

托管 EKS MCP server 通过 mcp-proxy-for-aws 使用 AWS SigV4 认证并运行在 stdio proxy 之上。Elastic 的 MCP connector 需要 HTTP/SSE endpoint，因此需要 bridge pod 通过 mcp-proxy 将 stdio proxy 暴露为 SSE/HTTP endpoint。

可以在 GKE、AKS 或自建 Kubernetes 上复用同样架构吗？

可以。核心原则一致：将 observability 数据放在 Elasticsearch，并配合一个具备集群作用域 tools 的专家 agent，再通过 workflow 进行中转。只需替换 MCP server 或 bridge，调整 RBAC，并在 workflow 输入中参数化 cluster name 或 region 即可。

原文：https://www.elastic.co/observability-labs/blog/eks-agent-builder-mcp-kubernetes-troubleshooting