Agentic CI/CD：使用 Kubernetes 部署门控，结合 Elastic MCP Server

关注

原创 2026-02-20 21:23:11 1.2k 阅读 AI 写同款· GEO 优化 ›

作者：来自 Elastic Bahubali Shetti

使用 Elastic MCP Server 部署 agentic CI/CD 门控。将 AI agents 集成到 GitHub Actions 中，通过 O11y 监控 K8s 健康状况，并提升部署可靠性。

“Build-Push-Deploy”循环从来都不简单。高可用环境需要自动化护栏 —— 在目标集群处于压力状态时，主动检查并阻止部署开始。如今，这些检查通常在 CI/CD 过程中通过 API 和脚本完成。流程中会触发不同的 gate，以确保应用测试已通过、制品是干净的、基础设施是稳定的，等等。

随着 AI 和 agents 的引入，这些 gate 正在逐步变得更加智能。越来越多的 gate 开始使用 Model Context Protocol（ MCP ） server 来完成检查。这是一种更新、更前沿的“ agentic ”方式。它让你的 CI/CD 流水线像一个智能 agent，在变更之前先向集群“询问”其健康状态。

一个标准的 Kubernetes 部署工作流通常遵循以下高层步骤：

Verification Gate：确保所有自动化测试已通过。
Artifact Creation：构建 Docker 容器。
Environment Gate：验证生产 Kubernetes 环境、支撑基础设施以及现有应用是否健康。

Kubernetes Deployment：触发最终发布。现代工作流通常使用 GitOps 工具，如 ArgoCD 或 Flux，只需在 Docker Hub 中更新镜像 tag，集群即可自动同步。

Kubernetes 健康检查的复杂度取决于你的 Service Level Objectives（ SLOs ）和运维成熟度。通常，主要目标是确保集群健康，并且没有接近资源瓶颈。此类 gate 中常见的“ red flag ”指标包括：

Red Flag	场景	SRE 含义
Pod Count > 90%	高 Pod 密度	接近节点级调度上限。
CPU Usage > 70%	实时负载过高	在部署过程中存在 CPU 限流风险。
Memory Usage > 80%	内存压力	发生 Out-of-Memory（ OOM ） kill 的高风险。
OOM Terminating Processes	资源限制已达上限	Pod 配置或资源规模不合理。
Available vs. Requested	容量不平衡	由于预留资源不足，存在部署失败风险。

我将向你展示如何使用一个 CI/CD 流水线，通过 Model Context Protocol（ MCP ） server 将 Observability AI Agents 集成到 GitHub Actions 中，为 Kubernetes 集群创建自动化的部署前健康检查。

通过在部署之前引入一个可观测性检查点，我们将流水线转变为一个智能系统，它可以：

查询来自 Kubernetes 集群的实时指标
使用自定义 ESQL 查询分析容量
对部署就绪性做出自主决策
主动防止失败，而不是事后响应
向工程团队提供可执行的反馈

下面是本文中所部署内容及其工作方式的 “架构 ”示意。

如你所见，这个流程使用了 Elastic Observability，它负责存储和分析来自 Kubernetes 的 OpenTelemetry 指标，这些指标由 opentelemetry-kube-stack-cluster-stats-collector 收集（通过 OpenTelemetry Operator 部署）。

GitHub Actions 通过 Elastic MCP server 调用 Observability Kubernetes Agent。这个 agent 提供了一组工具，用来检查上表中提到的一些“ red flag ”问题。

根据检查结果， GitHub Actions 要么中止流程，要么继续执行，通过触发 ArgoCD 来部署构建好的 artifact。

Observability Kubernetes Agent 是基于 Elastic 的 Agent Builder 能力构建的，同时也包含了它所使用的一些工具。这些能力随后通过 MCP server 对外暴露。

因此，这里的整体组件包括：

GitHub Actions：负责编排构建和部署工作流
Elastic MCP Server：暴露 AI agents 的 serverless 端点
Observability Kubernetes Agent：带有专用 ESQL 工具的自定义 agent
Kubernetes Cluster：目标部署环境，并启用了指标采集
ES|QL Query Tools：用于节点和 pod 资源分析的高精度查询工具

当 Kubernetes 健康检查在 GitHub Actions 中失败时，会发生什么？

流水线如何自动阻止部署

当集群超过容量阈值时，工作流会自动阻止部署。在这个示例中，我没有真正给集群施加负载，而是使用了一个简单的检查：如果资源使用率超过 25%，就故意停止部署。

工作流显示：

构建 Docker Image (28s)
推送到 Docker Hub (5s)
通过 Elastic O11y K8s Agent 检查 K8s 健康 (16s) — 失败
部署到 otel-test Cluster — 阻塞

注释: "Cluster 有资源问题 — 阻止部署"

AI Agent 的健康检查响应会是什么样？

该 agent 提供了详细分析：

Step 1: Finding Kubernetes analysis agent...
Found agent: Observability Kubernetes Agent (kubernetes_analysis_agent)

Step 2: Querying cluster health...
Prompt: tell me if my cluster otel-test is using more than 25% memory or CPU on any of its nodes

Agent Response:
================================================================
Yes, your cluster "otel-test" has nodes and pods using more than 25% of resources.

++Node exceeding 25%:++
- ip-192-168-165-175.us-west-2.compute.internal
  - Memory: 36.44%
  - CPU: 7.99% (below threshold)

++All other nodes are below the 25% threshold++ for both CPU and memory.

While the query for pods doesn't show percentage values directly, the data indicates
normal resource usage patterns for the pods in your cluster, with none appearing to
consume excessive resources relative to their allocations.
================================================================

Cluster has resource issues - blocking deployment
Error: Process completed with exit code 1.

如你所见，一个 prompt 通过 MCP 发送给 Observability Kubernetes Agent，而不需要构建额外逻辑或调用其他脚本等。

这个单一检查防止了：

一个会失败的部署
浪费的 CI/CD 时间
潜在的服务降级
手动 SRE 干预

它提供了：

为容量规划提供可执行的情报

如何在 Elastic 中构建 Kubernetes 健康检查 Agent

构建该 agent 并不难，Elastic 的 AgentBuilder UI 使创建它并在几分钟内运行变得简单。

如何配置 Observability Kubernetes Agent

除了为 agent 命名外，你还需要为它提供一些指令。

自定义指令：

# Agent Instructions

## Primary Role
You are a Kubernetes monitoring assistant that helps users analyze cluster performance
and resource utilization. Your primary goal is to provide clear, accurate information
about Kubernetes clusters using available data sources.

## Tool Selection Guidelines
1. When users ask about Kubernetes metrics, node performance, or cluster health:
   - Use ESQL tools for detailed analysis
   - Query metrics from kubeletstatsreceiver.otel-default

2. For alert-related queries:
   - Use the alerts tool to check active alerts

3. Always provide context about:
   - Time ranges queried
   - Cluster names
   - Resource thresholds

如何为 Kubernetes 节点和 Pod 指标编写 ES|QL 查询

我创建了几个工具，用于检查节点 CPU 和内存、Pod CPU 和内存，以及 Pod 的 OOM。此外，Observability Kubernetes Agent 利用了大量 OOTB 工具，如 observability_alerts，作为其功能的一部分。

这是一个节点 CPU 和内存工具的示例，它使用一个简单的 ES|QL 查询针对 OpenTelemetry 指标检查集群中的 CPU 和内存使用情况。

ES|QL 查询：

FROM metrics-kubeletstatsreceiver.otel-default
| WHERE resource.attributes.k8s.cluster.name == ?cluster_name
  AND @timestamp > NOW() - 3 hours
| STATS
    avg_cpu_usage = AVG(metrics.k8s.node.cpu.usage),
    avg_memory_usage = AVG(metrics.k8s.node.memory.usage),
    avg_memory_available = AVG(metrics.k8s.node.memory.available),
    avg_memory_working_set = AVG(metrics.k8s.node.memory.working_set)
  BY resource.attributes.k8s.node.name
| EVAL
    cpu_usage_pct = avg_cpu_usage * 100,
    memory_usage_pct = (avg_memory_working_set / (avg_memory_working_set + avg_memory_available)) * 100
| SORT cpu_usage_pct DESC, memory_usage_pct DESC
| KEEP resource.attributes.k8s.node.name, cpu_usage_pct, memory_usage_pct
| LIMIT 100

参数：