开箱即用 · 开源免费（MIT 协议）

一个二进制，装下整个运维

控制台 · 诊断引擎 · 群聊运维（ChatOps）· 实时告警，一次部署全部都有。浏览器里点、群里喊、终端里 klaw diag。

打开控制台 >_ git clone 立即安装

线上演示为模拟数据（Mock），本地 make build && ./klaw 运行后 http://localhost:8080 可管理真实集群

klaw@ops:~ · 演示输出

$ klaw diag

10:21:34 [OK] Kubernetes 版本兼容性检查

10:21:34 [OK] API Server 可用性检查

10:21:35 [OK] CoreDNS 解析检测

10:21:35 [WARN] Pod 重启策略风险检测

10:21:36 [CRIT] nginx-7d9f-x2k OOMKilled → 内存超限

10:21:36 [OK] 节点资源水位检查

10:21:37 [OK] RBAC 最小权限审计

10:21:37 [WARN] 存储类回收策略检测

10:21:38 [OK] etcd 备份完整性校验

10:21:38 [OK] Ingress TLS 配置检查

10:21:39 [WARN] 镜像漏洞扫描（trivy）· 2 高危

10:21:39 [OK] 成本：检出 2 个闲置 Deployment

10:21:39 [DONE] 诊断完成 · 1 CRIT · 3 WARN · 8 OK · diag-0831.html

采集

事件监听（Watch）+ 指标轮询

→

分析

73 个分析器

→

根因

告警收敛因果链

→

报告

HTML 网页 / JSON / 纯文本

→

修复

可执行建议

四种入口，一套能力

同一份配置驱动网页控制台、群聊运维（ChatOps）、命令行与实时告警，不拼盘、不割裂。

网页控制台

集群概览，容器组（Pod）、部署（Deployment）、服务（Service）、节点（Node）全生命周期管理，深浅色双主题。

多集群统一视图，按名称切换
实时日志、扩缩容、滚动重启
多租户 + 操作审计可追溯

诊断引擎 · 73 分析器

9 大类可编排流水线：采集 → 分析 → 根因 → 报告 → 修复建议。

kernel（内核）network（网络）log（日志）security（安全）eBPF（内核级观测）
YAML（配置格式）规则引擎，免改代码加检查项
trivy（漏洞扫描器）镜像扫描 + 成本分析

群聊运维（ChatOps）+ 实时告警

钉钉 / 飞书群里 @ 机器人直接操作集群；Watch（事件监听）秒级推送事件。

命令缩写：klaw p ls prod default
限流 / 去重 / 聚合 / 静音窗口
SOS 语音应急，智能打断双向字幕

打开浏览器，集群尽收眼底

网页控制台是四个入口的首页：集群概览、工作负载、诊断报告、操作审计都在同一处，不写 kubectl（K8s 命令行工具）也能管。

Klaw 控制台 https://klaw.ops.local:8080/overview 演示数据

production · v1.29 事件流已连接（Watch）· 延迟 <1s

节点33 / 3 就绪

容器组（Pod）1412 运行中 · 2 等待中

CPU 使用率45%阈值 85% · 正常

内存使用60%阈值 75% · 正常

集群资源 · 近 45 分钟 CPU内存

10:0010:1510:3010:45

实时告警3 条 · 今日

10:21CRITPod OOMKilled
production/nginx-7d9f-x2k

10:19WARNCrashLoopBackOff ×5
default/payment-7c9d8b4c6

10:15INFOHPA 扩容 2 → 4
prod/api-server

master-1

CPU32%

内存48%

worker-1

CPU62%

内存71%

worker-2

CPU41%

内存58%

控制台全景，10 页尽收

同一份配置驱动全部管理页面，浏览器里点击就能管——不写 kubectl，不拼盘。

Klaw 控制台 https://klaw.ops.local:8080/ 演示数据

production · v1.29 事件流已连接（Watch）· 延迟 <1s

节点33 / 3 就绪

容器组（Pod）1412 运行中 · 2 等待中

CPU 使用率45%阈值 85% · 正常

内存使用60%阈值 75% · 正常

集群资源 · 近 45 分钟 CPU内存

10:0010:1510:3010:45

实时告警3 条 · 今日

10:21CRITPod OOMKilled
production/nginx-7d9f-x2k

10:19WARNCrashLoopBackOff ×5
default/payment-7c9d8b4c6

10:15INFOHPA 扩容 2 → 4
prod/api-server

名称	命名空间	状态	重启	CPU	内存	运行时长
nginx-7d9f-x2k	production	OOMKilled	3	—	1.21Gi/1Gi	42d 3h
api-server-5f8b-x7m	prod	Running	0	120m	256Mi	14d 6h
payment-7c9d8b4c6-vrmqs	default	CrashLoop	5	—	128Mi/256Mi	2h 18m
redis-6b4f-k9w	production	Running	0	45m	180Mi	42d 3h

名称	命名空间	副本	镜像	策略	更新时间
nginx	production	2 / 2	nginx:1.25-alpine	RollingUpdate	08-31 14:22
api-server	prod	4 / 4	kudig/api:v2.3.1	RollingUpdate	08-30 09:15
payment	default	0 / 1	pay-svc:1.0.4	Recreate	09-01 10:19

名称	类型	ClusterIP	端口	Endpoints	状态
nginx	ClusterIP	10.96.4.12	80/TCP	1 / 2 Ready	降级
api-server	NodePort	10.96.7.83	8080:30080	4 / 4 Ready	正常
redis	ClusterIP	10.96.2.41	6379/TCP	1 / 1 Ready	正常

master-1

CPU32%

内存48%

worker-1

CPU62%

内存71%

worker-2

CPU41%

内存58%

告警规则 · 3 条已启用

规则名称	严重级别	条件	最近触发
Pod 内存超限	CRIT	container_memory > limits.memory	10:21:36
Pod 重启过多	WARN	restart_count ≥ 5 in 10m	10:19:02
CPU 使用率过高	WARN	node_cpu_usage ≥ 85%	—

CRIT1

WARN3

OK8

耗时2.1s

AI 根因分析 · kudig-ai

问题：nginx-7d9f-x2k 5 分钟内两次 OOM Killer，影响 23% 请求。
根因：内存 30s 内 612Mi → 1.21Gi，超过 limit 1Gi。
建议：limits.memory 1Gi → 1.5Gi，并补 HPA 内存指标

总备份12

总大小4.8GB

最近备份09-01

备份名称	类型	存储	大小	状态	完成时间
etcd-full-20260901	Full	S3	1.2GB	完成	09-01 03:00
etcd-incr-1000	Incr	S3	180MB	完成	09-01 10:00
etcd-incr-1030	Incr	S3	—	进行中	—

租户	命名空间	CPU 配额	内存配额	Pod 上限	默认角色
ops-team	production, monitoring, kube-system	60%6 / 10 核	55%11 / 20Gi	68 / 100	admin
dev-team	default, staging	30%3 / 10 核	25%5 / 20Gi	22 / 100	viewer

SOS 应急语音助手

通话中 · 00:42

AI 助手检测到 nginx-7d9f-x2k OOMKilled，建议将 memory limit 提升至 1.5Gi。是否立即执行？

值班工程师执行，并同步通知值班群

在群里，把集群喊明白

凌晨告警不必开电脑，手机群里一条命令，富文本回复直达。

KKlaw· 运维值班群 · 演示

Klaw · 事件推送 · 10:21:36

CRIT

Pod OOMKilled production/nginx-7d9f-x2k

内存 1.21Gi / limit 1Gi，5 分钟内第 2 次触发。回复 klaw diag nginx-7d9f-x2k 开始诊断。

值班工程师 · 10:22:01

@Klaw klaw diag nginx-7d9f-x2k -n production

Klaw · 机器人 · 10:22:04

根因定位 · 耗时 2.1s
内存 30s 内 612Mi → 1.21Gi，超过 limit 1Gi
建议：limits.memory 1Gi → 1.5Gi，并补 HPA 内存指标
完整报告（HTML / JSON）已生成

事件，秒级到达

基于 Kubernetes 的 Watch（事件监听）接口，事件驱动而非轮询。左侧是推送样式，右侧是两种模式的差距。

事件流 · production已去重聚合

10:21:36CRITPod OOMKilled
production/nginx-7d9f-x2k · 已推送钉钉值班群

10:19:02WARNCrashLoopBackOff ×5
default/payment-7c9d8b4c6-vrmqs · 同类聚合，1 条代替 5 条

10:15:47INFOScalingReplicaSet 2 → 4
prod/api-server · HPA（自动扩缩容）触发

10:12:33INFONodeReady
worker-2 · 恢复就绪

维度	轮询模式	Watch（事件监听）模式
事件延迟	30–60 秒	< 1 秒
API 调用	高频轮询	事件驱动，下降约 90%
连接方式	短连接	长连接

三种方式，十分钟上线

从本地二进制到集群内 Helm（K8s 包管理器）部署，全部路径均已端到端验证。

本地二进制

# 一键构建前端 + 后端
make build
# 配置后运行
./klaw
# http://localhost:8080

Docker（容器镜像）

docker build -t kudig-io/klaw:latest .
docker run -d -p 8080:8080 \
  -e KLAW_API_TOKEN='your-token' \
  kudig-io/klaw:latest

kind + Helm（本地集群）

kind create cluster \
  --config deployment/kind/cluster-config.yaml
helm upgrade --install klaw helm/klaw \
  -n klaw --create-namespace --wait

73个诊断分析器

10个管理页面

<1s事件推送

127MB最终镜像

9大类分析

MIT开源许可协议（MIT 协议）