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

图 1:用 OpenClaw 做 K8s AIOps 综合信息图
说明:这是一篇技术可能性探索文章,而非已落地实施方案。所有内容基于 OpenClaw 官方文档和技术分析推导而来,旨在探讨 K8s AIOps 的可行路径。欢迎读者一起讨论和验证。
K8s 集群的日常运维是个体力活。
故障诊断时,你需要:查 Pod 状态、看日志、检查事件、分析指标...一套流程下来,少说也要半小时。如果是凌晨三点的告警,还得强打精神,生怕手抖输错命令。
资源优化更是个细活:收集使用数据、分析趋势、调整配置、验证效果。这些重复性工作消耗了大量时间,却难以自动化——因为每个场景都需要判断和决策。
AI 智能体能帮上忙吗?
最近在研究 OpenClaw 这个 AI 智能体网关项目时,发现它的一些特性跟 K8s 运维场景挺契合:Skills 机制可以封装运维能力,Subagent 可以并行处理任务,Cron 可以做定时巡检。
能不能用它来做 K8s AIOps?这篇文章就是一次探索性的思考。
在讨论具体场景之前,先了解 OpenClaw 的几个核心能力——这些是实现 K8s AIOps 的技术基础。
OpenClaw 使用 Skills 来教智能体如何使用工具。每个 Skill 是一个包含 SKILL.md 文件的目录,兼容 AgentSkills 规范。
Skills 的结构长这样:
---
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。这意味着每个智能体可以有自己的运维能力,互不干扰。
Subagent(子智能体) 是 OpenClaw 的一个亮点。
当你需要同时诊断多个故障时,可以让主智能体"派"出多个子智能体,并行处理。每个子智能体在独立的会话中运行,完成后自动把结果通告回来。
启动方式:
{
"task": "分析 production 命名空间的所有 Pod 日志,找出错误模式",
"agentId": "log-analyzer",
"model": "anthropic/claude-sonnet-4-5",
"runTimeoutSeconds": 300,
"cleanup": "keep"
}
这个机制对于 AIOps 特别有价值:
子智能体默认不获得会话工具(防止无限套娃),但可以通过配置覆盖。
OpenClaw 提供了一套完整的工具集,覆盖运维场景的需求:
工具组 | 能力 | K8s 场景应用 |
|---|---|---|
exec | 执行 shell 命令 | 运行 kubectl 命令 |
read/write/edit | 文件操作 | 读取配置文件、写报告 |
web_search/web_fetch | 网络请求 | 查文档、调 Prometheus API |
browser | 浏览器控制 | 访问 Grafana、K8s Dashboard |
cron | 定时任务 | 定期巡检、报告生成 |
sessions_spawn | 启动子智能体 | 并行诊断 |
exec 工具的安全策略值得关注:
{
tools: {
exec: {
pathPrepend: ["~/bin", "/opt/k8s/bin"],
notifyOnExit: true,
host: "sandbox", // 在容器中运行
security: "allowlist" // 只允许白名单命令
}
}
}
deny:拒绝所有执行(安全)allowlist:仅允许白名单命令(推荐)full:允许所有命令(危险)对于 K8s AIOps,allowlist 模式是个合理的选择。

图 2:OpenClaw 核心能力架构图
你的团队在用 AI 辅助运维吗?是哪个工具?欢迎在评论区聊聊
基于 OpenClaw 的能力,我设计了 4 个 K8s AIOps 场景。这些场景从易到难,每个都有具体的实现路径。
场景描述:凌晨 2 点,Prometheus 发出告警:"production 命名空间的 api-server Pod CPU 使用率超过 90%"。运维工程师被叫醒,开始排查...
如果有 AIOps:告警自动触发智能体诊断,5 分钟内给出根因分析和处理建议。
实现路径:
告警(Webhook/定时轮询)
↓
OpenClaw 接收告警
↓
调用 k8s-troubleshoot Skill
↓
执行诊断命令(exec)
↓
分析日志和指标(web_fetch + 子智能体)
↓
生成诊断报告
↓
推送到 Slack/钉钉

图 3:故障诊断流程图
告警触发有两种方式:
方式一:Alertmanager Webhook
# alertmanager.yml
route:
receiver:'openclaw-webhook'
receivers:
-name:'openclaw-webhook'
webhook_configs:
-url:'http://openclaw-gateway:18789/webhook/alert'
send_resolved:true
方式二:定时轮询 Prometheus
openclaw cron add \
--name "Alert Check" \
--cron "* * * * *" \
--session isolated \
--message "查询 Prometheus 是否有 firing 状态的告警,如果有则执行诊断"
Skill 定义示例:
创建 ~/.openclaw/skills/k8s-troubleshoot/SKILL.md 文件:
---
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,可以派子智能体并行处理:
{
"task": "诊断 production 命名空间的 api-server-* 系列 Pod,找出 CPU 飙高的原因",
"agentId": "ops",
"model": "anthropic/claude-sonnet-4-5",
"runTimeoutSeconds": 300,
"cleanup": "keep"
}
场景描述:每周一早上,运维团队需要分析上周的资源使用情况,找出优化机会——哪些 Pod 资源浪费了?哪些需要扩容?哪些可以删除?
如果有 AIOps:智能体自动收集数据、分析趋势、生成优化建议报告。
实现路径:
定时任务触发(每周一 9 点)
↓
收集集群资源数据(exec + web_fetch)
↓
分析使用模式
↓
识别优化机会
↓
生成报告和建议
↓
推送到指定渠道
Cron 配置:
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"
数据收集示例:
# 获取所有 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
这个场景的优势在于:完全是只读操作,风险可控。智能体只提供建议,最终决策还是由人来做。
场景描述:公司要求每季度对 K8s 集群进行安全审计,检查 RBAC 配置、Pod 安全策略、网络策略等。这是个繁琐但重要的工作。
如果有 AIOps:智能体定期执行安全检查,生成审计报告,发现问题及时告警。
实现路径:
定时任务触发(每周或每月)
↓
执行预定义的安全检查项
↓
对比安全基线
↓
生成审计报告
↓
发现高风险问题则告警
Skill 定义:
创建 ~/.openclaw/skills/k8s-security-audit/SKILL.md 文件:
---
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 配置:
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"
场景描述:运维团队希望每小时自动检查集群健康状态,及时发现潜在问题,而不是等告警响了才去处理。
如果有 AIOps:智能体每小时执行巡检,发现问题自动告警,健康状态可视化展示。
实现路径:
定时任务触发(每小时)
↓
执行预定义检查项
↓
收集健康状态数据
↓
发现异常则告警
↓
生成健康报告
Cron 配置:
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"
检查脚本示例:
# 检查 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:技术可行性分析对比图
1. Skills 机制灵活
Skills 可以封装任意运维能力,支持环境变量和二进制文件检查。这意味着你可以为不同的集群、不同的环境定义不同的 Skills。
{
skills: {
directories: [
"~/.openclaw/skills", // 用户级 Skills
"/opt/openclaw/skills" // 系统级 Skills
]
}
}
2. 子智能体并行处理
多个运维任务可以并行执行,互不干扰。比如一个告警触发后,可以同时派子智能体去:
最后汇总成完整的诊断报告。
3. 多渠道集成
支持 Slack、Telegram、Discord、钉钉等 IM 渠道,告警和报告可以直接推送到团队频道。运维人员可以随时随地接收信息,甚至通过 IM 与智能体交互。
4. 定时任务能力
Cron 任务支持持久化存储,重启不丢失。这对于定期巡检、报告生成等场景非常重要。
1. 安全性
这是绕不开的问题。让 AI 执行 kubectl 命令,意味着给它访问 K8s 集群的权限。
需要考虑:
建议方案:
# 只读权限的 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. 可靠性
依赖大模型的稳定性,可能会遇到:
建议:
3. 成本
频繁的巡检和诊断会消耗大量 Token。按每小时巡检一次计算,一天就是 24 次,一个月就是 720 次。
优化方案:
4. 准确性
大模型可能产生幻觉,给出错误的分析结果。
建议:
基于以上分析,我建议分三个阶段实施。

图 5:落地路径三阶段时间线图
目标:验证技术可行性,建立信任
范围:
配置:
{
tools: {
exec: {
security: "allowlist",
allowlist: ["kubectl get", "kubectl describe", "kubectl logs", "kubectl top"]
}
}
}
验收标准:
目标:扩大自动化范围,提升效率
范围:
配置:
{
tools: {
exec: {
security: "allowlist",
ask: "on-miss" // 非白名单命令需要确认
}
}
}
验收标准:
目标:在充分信任的基础上,自动化更多场景
范围:
配置:
{
tools: {
exec: {
security: "allowlist",
ask: "always" // 所有操作都需要确认
}
}
}
注意:这个阶段需要非常谨慎,建议建立完善的审批和回滚机制。
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
好啦,谢谢你观看我的文章,如果喜欢可以点赞转发给需要的朋友,我们下一期再见!敬请期待!