[转]通过 AI Agent 自动排查 K8s 问题

保持热爱奔赴山海

发布于 2025-11-18 20:51:28

840

文章被收录于专栏：DevOpsDevOps

原文

通过 AI Agent 自动排查 K8s 问题

郭子龙发表于 2025/11/18

一、背景与痛点

现状痛点（Dev & Ops）：

研发：排查 K8s 问题需要熟悉 kubectl/日志命令，遇到 CrashLoopBackOff、FailedMount、镜像拉取失败等底层问题，需要在开发工作之外投入额外精力，影响主线任务推进。
运维：登录多层环境（堡垒机/跳板机/多集群），拉日志、看事件、比节点状态，信息分散难沉淀，同样的问题反复回答。

典型场景：

日常上线后，个别 Pod 启动异常；研发需要登录跳板机、切换集群、查事件、拉日志，流程繁琐且信息分散。
测试/预发环境调试报错（依赖未就绪、配置不一致等）；需要快速判断是应用配置、镜像、节点资源还是网络/存储侧，手工排查路径长且易遗漏。

效果与收益：

用 Agent + 群聊协作，把繁琐的多步骤操作简化为一个按钮，让分散的日志/事件/状态信息聚合成结构化诊断结论，排查过程自动留痕便于复用。
效率提升：平均排查时间从 10 分钟降至 1 分钟内。
降低门槛：无需记忆 kubectl 命令，一键触发即可完成大部分排查。
信息聚合：日志、事件、指标在一次对话中集中呈现，不再多处切换。
知识沉淀：排查过程自动留痕，方便团队回溯和经验传承。

二、使用方式

Agent 自动完成排查，也可以再通过继续对话交互深入分析。

技术指导（如 K8s 最佳实践咨询）和需求支持（如资源配额调整建议）。

使用示例：

1. @机器人排查告警信息。自动回复结构化诊断结论、建议和关键日志片段

2. @机器人，提出任何k8s相关需求，如资源优化。

3. @机器人排查容器异常退出。

三、实现方式

技术流程：

能力覆盖：

场景支持：Pod 异常、Node 状态、Service 网络、镜像拉取、调度失败等常见问题
信息聚合：容器日志、K8s 事件、资源状态、配置信息、调度详情、网络连通性等关键排查数据一次性呈现

核心能力kubectl-ai：

google-cloud 开源的 kubectl-ai 实现的 kubectl MCP。项目地址：https://github.com/GoogleCloudPlatform/kubectl-ai。项目也提供agent能力，这里只用到了MCP，因为飞书和aily agent交互实现比较简单。
Kubectl-ai DockerFile：

FROM xxx-registry.cn-shanghai.cr.aliyuncs.com/public-test/alpine:3.21

# 下载 kubectl 和 kubectl-ai
# RUN wget https://dl.k8s.io/release/v1.33.0/bin/linux/amd64/kubectl -O /bin/kubectl && chmod +x /bin/kubectl && \
#     wget https://github.com/GoogleCloudPlatform/kubectl-ai/releases/download/v0.0.26/kubectl-ai_Linux_x86_64.tar.gz && tar -xzf kubectl-ai_Linux_x86_64.tar.gz -C /bin/ && rm kubectl-ai_Linux_x86_64.tar.gz

# 复制本地文件（如果存在）
COPY ./deploy/kubectl-ai /bin/kubectl-ai
COPY ./deploy/kubectl /bin/kubectl

# 设置权限并安装依赖
RUN chmod +x /bin/kubectl-ai && \
    chmod +x /bin/kubectl && \
    apk add bash &&  rm -rf /var/cache/apk/*

ENTRYPOINT [ "/bin/kubectl-ai" ]12345678910111213141516

Kubectl-ai MCP启动方式：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubectl-ai
  namespace: kubectl-ai
  labels:
    app: kubectl-ai
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kubectl-ai
  template:
    metadata:
      labels:
        app: kubectl-ai
    spec:
      serviceAccountName: kubectl-ai
      containers:
      - name: kubectl-ai
        image: xxx.cn-shanghai.cr.aliyuncs.com/public-test/devops:kubectl-ai-latest
        imagePullPolicy: Always
        args:
        - --llm-provider=openai
        - --model=qwen3-coder-plus
        - --skip-permissions=true
        - --max-iterations=20
        - --v=4
        - --alsologtostderr
        - --mcp-server
        - --mcp-server-mode=streamable-http
        - --http-port=9080
        envFrom:
        - secretRef:
            name: kubectl-ai
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 1000m
            memory: 512Mi
        livenessProbe:
          tcpSocket:
            port: 9080
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
        readinessProbe:
          tcpSocket:
            port: 9080
          initialDelaySeconds: 5
          periodSeconds: 5
          timeoutSeconds: 3
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354

Kubectl-ai 鉴权：使用k8s RBAC,屏蔽secret权限，防止集群密钥泄露：

---
# ServiceAccount for kubectl-ai deployment
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kubectl-ai
  namespace: kubectl-ai
  labels:
    app: kubectl-ai
---
# ClusterRoleBinding to grant the ServiceAccount cluster-wide read-only access
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubectl-ai-readonly-binding
  labels:
    app: kubectl-ai
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kubectl-ai-readonly
subjects:
  - kind: ServiceAccount
    name: kubectl-ai
    namespace: kubectl-ai
---
# ClusterRole with all read-only permissions
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kubectl-ai-readonly
  labels:
    app: kubectl-ai
rules:
  # Core API resources - 基于内置 view ClusterRole
  // ... 略
12345678910111213141516171819202122232425262728293031323334353637

飞书交互：

飞书 aily workflow配置入口：

Agent配置：

提示词配置，根据使用情况持续优化提示词，比如查询 log 时限制行数防止上下文超限。
模型：使用DeepSeek-V3.1
工具配置：添加kubectl-ai MCP。

四、后续改进

统一运维 Agent 入口，屏蔽底层差异：以 K8s 排查为起点，逐步整合更多运维能力：日志查询与分析（SLS）、指标监控与告警（Prometheus/Grafana）、服务拓扑与依赖关系（链路追踪）、资源变更历史与回滚建议、DBA 能力（慢查询分析、锁等待排查、索引优化建议等）、打造"一站式"运维助手，统一入口解决跨域问题。
知识库积累：沉淀 Agent 自动问答模板，例如 “Pod Crash 原因排查步骤”。
与监控联动：告警自动触发 Agent 自查，生成问题报告。比如结合基础平台 OnCall 告警系统，自动 @排查机器人。Agent 自动生成工单或建议修复命令。
持续优化模型能力：结合内部日志样本，微调分析准确率。

五、结语

通过 kubectl-ai + 飞书 aily workflow，我们把多步骤命令行操作简化为一个按钮，让运维经验沉淀为可复用的自动化能力。

Agent 能解决日常大部分琐碎问题，显著提高排查效率，但个别疑难杂症仍需人工介入 —— 它是第一道防线和效率工具，而非完全替代。

期待与基础平台团队深化合作，将 Agent 能力与 OnCall 告警系统等深度集成，共同构建更智能的研发协作体验。

本文系转载，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

aiops

本文系转载，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

aiops

登录后参与评论

0 条评论

热度

[转]通过 AI Agent 自动排查 K8s 问题

[转]通过 AI Agent 自动排查 K8s 问题

通过 AI Agent 自动排查 K8s 问题

一、背景与痛点

现状痛点（Dev & Ops）：

典型场景：

效果与收益：

二、使用方式

使用示例：

三、实现方式

技术流程：

能力覆盖：

核心能力kubectl-ai：

飞书交互：

四、后续改进

五、结语

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐