首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >用 OpenClaw 做 K8s AIOps:4 个场景从构思到落地

用 OpenClaw 做 K8s AIOps:4 个场景从构思到落地

作者头像
运维有术
发布2026-04-01 19:51:31
发布2026-04-01 19:51:31
30
举报
文章被收录于专栏:运维有术运维有术

🚩 2026 年「术哥无界」系列实战文档 X 篇原创计划 第 55 篇,OpenClaw 最佳实战「2026」系列第 25 篇 大家好,欢迎来到 术哥无界 | ShugeX | 运维有术。 我是术哥,一名专注于 AI 编程、AI 智能体、Agent Skills、MCP、云原生、Milvus 向量数据库的技术实践者与开源布道者Talk is cheap, let's explore。无界探索,有术而行。

封面图:用 OpenClaw 做 K8s AIOps 综合信息图
封面图:用 OpenClaw 做 K8s AIOps 综合信息图

图 1:用 OpenClaw 做 K8s AIOps 综合信息图

说明:这是一篇技术可能性探索文章,而非已落地实施方案。所有内容基于 OpenClaw 官方文档和技术分析推导而来,旨在探讨 K8s AIOps 的可行路径。欢迎读者一起讨论和验证。

1. 为什么关注这个话题?

K8s 集群的日常运维是个体力活。

故障诊断时,你需要:查 Pod 状态、看日志、检查事件、分析指标...一套流程下来,少说也要半小时。如果是凌晨三点的告警,还得强打精神,生怕手抖输错命令。

资源优化更是个细活:收集使用数据、分析趋势、调整配置、验证效果。这些重复性工作消耗了大量时间,却难以自动化——因为每个场景都需要判断和决策。

AI 智能体能帮上忙吗?

最近在研究 OpenClaw 这个 AI 智能体网关项目时,发现它的一些特性跟 K8s 运维场景挺契合:Skills 机制可以封装运维能力,Subagent 可以并行处理任务,Cron 可以做定时巡检。

能不能用它来做 K8s AIOps?这篇文章就是一次探索性的思考。

2. OpenClaw 核心能力:适合 AIOps 的三个特性

在讨论具体场景之前,先了解 OpenClaw 的几个核心能力——这些是实现 K8s AIOps 的技术基础。

2.1 Skills:运维能力的封装方式

OpenClaw 使用 Skills 来教智能体如何使用工具。每个 Skill 是一个包含 SKILL.md 文件的目录,兼容 AgentSkills 规范。

Skills 的结构长这样

代码语言:javascript
复制
---
name: k8s-troubleshoot
description: Kubernetes 故障诊断 Skill
metadata:
  openclaw:
    requires:
      bins: ["kubectl"]
      env: ["KUBECONFIG"]
    primaryEnv: "KUBECONFIG"
---

# K8s 故障诊断流程

当收到告警时,按以下步骤执行:

1. 获取告警资源信息
2. 检查 Pod 状态
3. 查看日志
4. 检查事件
5. 查询 Prometheus 指标

Skills 的门控机制很有意思:

  • requires.bins:检查 kubectl 是否存在
  • requires.env:检查 KUBECONFIG 环境变量
  • requires.config:检查 OpenClaw 配置

如果前置条件不满足,Skill 就不会被加载。这对于运维场景很重要——你不会想在没装 kubectl 的机器上跑 K8s 命令。

Skills 的优先级:工作区 Skills → 用户 Skills → 内置 Skills。这意味着每个智能体可以有自己的运维能力,互不干扰。

2.2 Subagent:并行处理的秘密武器

Subagent(子智能体) 是 OpenClaw 的一个亮点。

当你需要同时诊断多个故障时,可以让主智能体"派"出多个子智能体,并行处理。每个子智能体在独立的会话中运行,完成后自动把结果通告回来。

启动方式

代码语言:javascript
复制
{
  "task": "分析 production 命名空间的所有 Pod 日志,找出错误模式",
  "agentId": "log-analyzer",
  "model": "anthropic/claude-sonnet-4-5",
  "runTimeoutSeconds": 300,
  "cleanup": "keep"
}

这个机制对于 AIOps 特别有价值:

  • 一个告警触发后,可以同时派子智能体去查日志、查指标、查配置
  • 不同任务可以用不同模型(贵的做复杂分析,便宜的做数据收集)
  • 子智能体之间隔离,互不影响

子智能体默认不获得会话工具(防止无限套娃),但可以通过配置覆盖。

2.3 工具生态:从命令行到浏览器

OpenClaw 提供了一套完整的工具集,覆盖运维场景的需求:

工具组

能力

K8s 场景应用

exec

执行 shell 命令

运行 kubectl 命令

read/write/edit

文件操作

读取配置文件、写报告

web_search/web_fetch

网络请求

查文档、调 Prometheus API

browser

浏览器控制

访问 Grafana、K8s Dashboard

cron

定时任务

定期巡检、报告生成

sessions_spawn

启动子智能体

并行诊断

exec 工具的安全策略值得关注:

代码语言:javascript
复制
{
  tools: {
    exec: {
      pathPrepend: ["~/bin", "/opt/k8s/bin"],
      notifyOnExit: true,
      host: "sandbox",     // 在容器中运行
      security: "allowlist" // 只允许白名单命令
    }
  }
}
  • deny:拒绝所有执行(安全)
  • allowlist:仅允许白名单命令(推荐)
  • full:允许所有命令(危险)

对于 K8s AIOps,allowlist 模式是个合理的选择。

OpenClaw 核心能力架构图
OpenClaw 核心能力架构图

图 2:OpenClaw 核心能力架构图

你的团队在用 AI 辅助运维吗?是哪个工具?欢迎在评论区聊聊

3. K8s AIOps 场景探索:4 个典型场景

基于 OpenClaw 的能力,我设计了 4 个 K8s AIOps 场景。这些场景从易到难,每个都有具体的实现路径。

3.1 场景一:故障诊断——从告警到根因

场景描述:凌晨 2 点,Prometheus 发出告警:"production 命名空间的 api-server Pod CPU 使用率超过 90%"。运维工程师被叫醒,开始排查...

如果有 AIOps:告警自动触发智能体诊断,5 分钟内给出根因分析和处理建议。

实现路径

代码语言:javascript
复制
告警(Webhook/定时轮询)
    ↓
OpenClaw 接收告警
    ↓
调用 k8s-troubleshoot Skill
    ↓
执行诊断命令(exec)
    ↓
分析日志和指标(web_fetch + 子智能体)
    ↓
生成诊断报告
    ↓
推送到 Slack/钉钉
故障诊断流程图
故障诊断流程图

图 3:故障诊断流程图

告警触发有两种方式

方式一:Alertmanager Webhook

代码语言:javascript
复制
# alertmanager.yml
route:
receiver:'openclaw-webhook'

receivers:
-name:'openclaw-webhook'
webhook_configs:
-url:'http://openclaw-gateway:18789/webhook/alert'
    send_resolved:true

方式二:定时轮询 Prometheus

代码语言:javascript
复制
openclaw cron add \
  --name "Alert Check" \
  --cron "* * * * *" \
  --session isolated \
  --message "查询 Prometheus 是否有 firing 状态的告警,如果有则执行诊断"

Skill 定义示例

创建 ~/.openclaw/skills/k8s-troubleshoot/SKILL.md 文件:

代码语言:javascript
复制
---
name: k8s-troubleshoot
description: Kubernetes 故障诊断 Skill
metadata:
  openclaw:
    requires:
      bins: ["kubectl"]
      env: ["KUBECONFIG"]
---

# K8s 故障诊断流程

收到告警后,按以下步骤执行:

## 1. 获取告警资源信息
根据告警标签定位资源:

    kubectl get <resource-type> <resource-name> -n <namespace> -o yaml

## 2. 检查 Pod 状态

    kubectl get pods -n <namespace> -o wide
    kubectl describe pod <pod-name> -n <namespace>

## 3. 查看日志

    kubectl logs <pod-name> -n <namespace> --tail=100
    # 如果容器重启过,查看上一个容器的日志
    kubectl logs <pod-name> -n <namespace> --previous

## 4. 检查事件

    kubectl get events -n <namespace> --sort-by='.lastTimestamp'

## 5. 查询 Prometheus 指标
使用 web_fetch 工具查询:
- CPU 使用率趋势
- 内存使用率趋势
- 网络流量
- 磁盘 I/O

## 6. 输出格式
诊断报告应包含:
- 告警摘要
- 故障现象
- 根因分析
- 处理建议

子智能体并行诊断

如果告警涉及多个 Pod,可以派子智能体并行处理:

代码语言:javascript
复制
{
  "task": "诊断 production 命名空间的 api-server-* 系列 Pod,找出 CPU 飙高的原因",
  "agentId": "ops",
  "model": "anthropic/claude-sonnet-4-5",
  "runTimeoutSeconds": 300,
  "cleanup": "keep"
}

3.2 场景二:资源优化——从数据到建议

场景描述:每周一早上,运维团队需要分析上周的资源使用情况,找出优化机会——哪些 Pod 资源浪费了?哪些需要扩容?哪些可以删除?

如果有 AIOps:智能体自动收集数据、分析趋势、生成优化建议报告。

实现路径

代码语言:javascript
复制
定时任务触发(每周一 9 点)
    ↓
收集集群资源数据(exec + web_fetch)
    ↓
分析使用模式
    ↓
识别优化机会
    ↓
生成报告和建议
    ↓
推送到指定渠道

Cron 配置

代码语言:javascript
复制
openclaw cron add \
  --name "K8s Weekly Resource Report" \
  --cron "0 9 * * 1" \
  --tz "Asia/Shanghai" \
  --session isolated \
  --message "分析过去一周的 K8s 资源使用情况,重点关注:

1. 资源利用率低于 20% 的 Pod(可减少 requests/limits)
2. 资源利用率超过 80% 的 Pod(需要增加资源或扩容)
3. 过去 7 天未使用的 Deployment/Service(可删除)
4. PVC 使用率超过 80% 的存储(需要扩容)

输出格式:
- 优化建议清单
- 预计节省/需要增加的资源量
- 优先级排序" \
  --announce \
  --channel slack \
  --to "channel:C1234567890"

数据收集示例

代码语言:javascript
复制
# 获取所有 Pod 的资源使用情况
kubectl top pods -A

# 获取 Pod 的资源请求和限制
kubectl get pods -A -o json | jq '.items[] | {name: .metadata.name, namespace: .metadata.namespace, requests: .spec.containers[].resources.requests, limits: .spec.containers[].resources.limits}'

# 查询 Prometheus 获取历史趋势
# 使用 web_fetch 工具调用 Prometheus API

这个场景的优势在于:完全是只读操作,风险可控。智能体只提供建议,最终决策还是由人来做。

3.3 场景三:安全审计——定期检查合规性

场景描述:公司要求每季度对 K8s 集群进行安全审计,检查 RBAC 配置、Pod 安全策略、网络策略等。这是个繁琐但重要的工作。

如果有 AIOps:智能体定期执行安全检查,生成审计报告,发现问题及时告警。

实现路径

代码语言:javascript
复制
定时任务触发(每周或每月)
    ↓
执行预定义的安全检查项
    ↓
对比安全基线
    ↓
生成审计报告
    ↓
发现高风险问题则告警

Skill 定义

创建 ~/.openclaw/skills/k8s-security-audit/SKILL.md 文件:

代码语言:javascript
复制

---
name: k8s-security-audit
description: Kubernetes 安全审计 Skill
metadata:
  openclaw:
    requires:
      bins: ["kubectl"]
      env: ["KUBECONFIG"]
---

# K8s 安全审计检查项

## 1. RBAC 检查

    # 检查是否有过度授权的 ClusterRoleBinding
    kubectl get clusterrolebindings -o wide

    # 检查所有命名空间的 RoleBinding
    kubectl get rolebindings -A -o wide

重点关注:
- 绑定到 cluster-admin 的 ServiceAccount
- 使用通配符 (*) 的权限规则

## 2. Pod 安全策略检查

    # 检查 Pod 的 securityContext 配置
    kubectl get pods -A -o jsonpath='{ra.items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.spec.securityContext.runAsNonRoot}{"\n"}{end}'

重点关注:
- 是否以 root 用户运行
- 是否启用了特权模式
- 是否挂载了宿主机敏感路径

## 3. 网络策略检查

    kubectl get networkpolicies -A

重点关注:
- 命名空间是否有默认拒绝入站/出站策略
- 敏感服务的网络隔离

## 4. 镜像安全检查

    kubectl get pods -A -o jsonpath='{ra.items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'

重点关注:
- 使用 latest 标签的镜像
- 使用未知来源的镜像
- 镜像是否经过签名

## 输出格式
审计报告应包含:
- 检查项清单及结果
- 发现的问题及风险等级
- 修复建议

Cron 配置

代码语言:javascript
复制
openclaw cron add \
  --name "K8s Security Audit" \
  --cron "0 2 1 * *" \
  --tz "Asia/Shanghai" \
  --session isolated \
  --message "执行 K8s 集群安全审计,生成报告并发送到安全团队频道" \
  --announce \
  --channel slack \
  --to "channel:SECURITY_CHANNEL"

3.4 场景四:自动巡检——持续监控健康状态

场景描述:运维团队希望每小时自动检查集群健康状态,及时发现潜在问题,而不是等告警响了才去处理。

如果有 AIOps:智能体每小时执行巡检,发现问题自动告警,健康状态可视化展示。

实现路径

代码语言:javascript
复制
定时任务触发(每小时)
    ↓
执行预定义检查项
    ↓
收集健康状态数据
    ↓
发现异常则告警
    ↓
生成健康报告

Cron 配置

代码语言:javascript
复制
openclaw cron add \
  --name "K8s Health Patrol" \
  --cron "0 * * * *" \
  --session isolated \
  --message "执行 K8s 集群健康巡检,检查以下项目:

1. 节点状态(Ready/NotReady/SchedulingDisabled)
2. Pod 状态(Running/Pending/CrashLoopBackOff/Error)
3. 资源使用率(CPU/Memory/Disk 超过 80%)
4. PVC 状态(Pending/Lost)
5. 证书有效期(30 天内过期)
6. 组件健康状态(etcd/apiserver/controller/scheduler)

发现异常时立即告警到 ops 频道,正常状态则静默" \
  --announce \
  --channel slack \
  --to "channel:OPS_ALERTS"

检查脚本示例

代码语言:javascript
复制
# 检查 NotReady 节点
kubectl get nodes --no-headers | awk '$2 != "Ready" {print $0}'

# 检查异常 Pod
kubectl get pods -A --no-headers | awk '$4 !~ /Running|Completed/ {print $0}'

# 检查资源使用率
kubectl top nodes | awk 'NR>1 && $2+0 > 80 {print "CPU High: " $0}'
kubectl top nodes | awk 'NR>1 && $4+0 > 80 {print "Memory High: " $0}'

这个场景的优势在于:提前发现问题,而不是被动等待告警。

4. 技术可行性分析:优势与挑战

设计完场景后,让我们客观分析一下技术可行性。

技术可行性分析对比图
技术可行性分析对比图

图 4:技术可行性分析对比图

4.1 OpenClaw 的优势

1. Skills 机制灵活

Skills 可以封装任意运维能力,支持环境变量和二进制文件检查。这意味着你可以为不同的集群、不同的环境定义不同的 Skills。

代码语言:javascript
复制
{
  skills: {
    directories: [
      "~/.openclaw/skills",        // 用户级 Skills
      "/opt/openclaw/skills"        // 系统级 Skills
    ]
  }
}

2. 子智能体并行处理

多个运维任务可以并行执行,互不干扰。比如一个告警触发后,可以同时派子智能体去:

  • 查 Pod 日志
  • 查 Prometheus 指标
  • 查事件历史

最后汇总成完整的诊断报告。

3. 多渠道集成

支持 Slack、Telegram、Discord、钉钉等 IM 渠道,告警和报告可以直接推送到团队频道。运维人员可以随时随地接收信息,甚至通过 IM 与智能体交互。

4. 定时任务能力

Cron 任务支持持久化存储,重启不丢失。这对于定期巡检、报告生成等场景非常重要。

4.2 需要面对的挑战

1. 安全性

这是绕不开的问题。让 AI 执行 kubectl 命令,意味着给它访问 K8s 集群的权限。

需要考虑:

  • RBAC 权限控制:给智能体最小必要权限
  • 敏感信息管理:kubeconfig、token 如何安全存储
  • 命令执行审批:关键操作是否需要人工确认

建议方案:

代码语言:javascript
复制
# 只读权限的 ServiceAccount
apiVersion:v1
kind:ServiceAccount
metadata:
name:openclaw-readonly
namespace:default
---
apiVersion:rbac.authorization.k8s.io/v1
kind:ClusterRole
metadata:
name:openclaw-readonly-role
rules:
-apiGroups:[""]
resources:["pods","nodes","services","events","namespaces"]
verbs:["get","list","watch"]
-apiGroups:["apps"]
resources:["deployments","replicasets"]
verbs:["get","list","watch"]

2. 可靠性

依赖大模型的稳定性,可能会遇到:

  • 模型调用失败或超时
  • Prompt 理解偏差
  • 输出格式不符合预期

建议:

  • 设计重试机制
  • 使用结构化输出(JSON)
  • 关键信息人工审核

3. 成本

频繁的巡检和诊断会消耗大量 Token。按每小时巡检一次计算,一天就是 24 次,一个月就是 720 次。

优化方案:

  • 子智能体使用更便宜的模型(如 Claude Haiku)
  • 主智能体使用高质量模型(如 Claude Sonnet)
  • 调整巡检频率(健康时降低频率)

4. 准确性

大模型可能产生幻觉,给出错误的分析结果。

建议:

  • 仅用于只读分析和报告,不要让 AI 执行写操作
  • 关键结论需要人工确认
  • 建立反馈机制,持续优化 Prompt

5. 落地路径建议:从只读到自动化

基于以上分析,我建议分三个阶段实施。

落地路径三阶段时间线图
落地路径三阶段时间线图

图 5:落地路径三阶段时间线图

5.1 第一阶段:只读场景(1-2 个月)

目标:验证技术可行性,建立信任

范围

  • 资源使用报告生成
  • 安全审计检查
  • 诊断报告生成(仅分析,不执行)

配置

代码语言:javascript
复制
{
  tools: {
    exec: {
      security: "allowlist",
      allowlist: ["kubectl get", "kubectl describe", "kubectl logs", "kubectl top"]
    }
  }
}

验收标准

  • 报告准确率 > 90%
  • 运维人员满意度 > 80%

5.2 第二阶段:低风险操作(2-3 个月)

目标:扩大自动化范围,提升效率

范围

  • 自动扩缩容(HPA/VPA)
  • Pod 重启(非关键服务)
  • 配置备份

配置

代码语言:javascript
复制
{
  tools: {
    exec: {
      security: "allowlist",
      ask: "on-miss"  // 非白名单命令需要确认
    }
  }
}

验收标准

  • 自动化处理率 > 50%
  • MTTR(平均恢复时间)降低 30%

5.3 第三阶段:高风险操作(谨慎推进)

目标:在充分信任的基础上,自动化更多场景

范围

  • Deployment 更新
  • 资源删除
  • 配置修改

配置

代码语言:javascript
复制
{
  tools: {
    exec: {
      security: "allowlist",
      ask: "always"  // 所有操作都需要确认
    }
  }
}

注意:这个阶段需要非常谨慎,建议建立完善的审批和回滚机制。

6. 写在最后

OpenClaw 具备成为 K8s AIOps 平台的技术基础:Skills 机制可以封装运维能力,Subagent 可以并行处理任务,Cron 可以做定时巡检,多渠道集成可以打通告警推送。

但 AIOps 的落地不是一蹴而就的。建议从只读场景开始,逐步建立信任;建立审批机制,确保安全可控;优化 Prompt 和成本,让方案可持续。

这是一次探索性的思考,实际的落地效果还需要在实践中验证。如果你也在探索 K8s AIOps,欢迎在评论区交流经验和想法。

相关资源

OpenClaw 官方文档:https://docs.openclaw.ai/zh-CN

OpenClaw Tools 文档:https://docs.openclaw.ai/zh-CN/tools

OpenClaw Skills 文档:https://docs.openclaw.ai/zh-CN/tools/skills

OpenClaw Subagents 文档:https://docs.openclaw.ai/zh-CN/tools/subagents

ClawHub Skills 市场:https://clawhub.com

好啦,谢谢你观看我的文章,如果喜欢可以点赞转发给需要的朋友,我们下一期再见!敬请期待!

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-03-17,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 运维有术 微信公众号,前往查看

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

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1. 为什么关注这个话题?
  • 2. OpenClaw 核心能力:适合 AIOps 的三个特性
    • 2.1 Skills:运维能力的封装方式
    • 2.2 Subagent:并行处理的秘密武器
    • 2.3 工具生态:从命令行到浏览器
  • 3. K8s AIOps 场景探索:4 个典型场景
    • 3.1 场景一:故障诊断——从告警到根因
    • 3.2 场景二:资源优化——从数据到建议
    • 3.3 场景三:安全审计——定期检查合规性
    • 3.4 场景四:自动巡检——持续监控健康状态
  • 4. 技术可行性分析:优势与挑战
    • 4.1 OpenClaw 的优势
    • 4.2 需要面对的挑战
  • 5. 落地路径建议:从只读到自动化
    • 5.1 第一阶段:只读场景(1-2 个月)
    • 5.2 第二阶段:低风险操作(2-3 个月)
    • 5.3 第三阶段:高风险操作(谨慎推进)
  • 6. 写在最后
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档