用 STAROps 做 Kubernetes 巡检：从数据到根因

AI云原生可观测

STAROps 读取 Kubernetes 实体、事件、指标和日志，通过巡检 Skill 关联异常对象与依赖，再以长期任务执行周期巡检。目标集群、工作空间和只读角色需预先配置。

数据源与权限

在目标工作空间里，分别查询实体、事件、指标和日志。创建了数字员工，并不代表数据已经接入。

数据	至少验证一次
集群对象	能定位目标 Cluster、Node、Namespace、Pod 和工作负载
Kubernetes Events	能按对象与时间查看 Warning、调度和挂载事件
Prometheus	能查询资源使用、重启趋势及应用指标
SLS	能定位目标应用日志，时间与环境正确
告警	能区分当前告警与历史恢复记录
拓扑及依赖	能把异常服务关联到节点、数据库或中间件

数据库、Redis、消息队列等依赖没有接入时，应在报告中注明。查不到数据需要继续检查权限、采集配置和保留时间，不能据此判定系统健康。Events 通常也有保留期限，不能默认查到完整的历史记录。

创建数字员工并添加巡检 Skill

在 STAROps 创建或选择自定义数字员工，绑定只读运维角色。在技能管理中选择添加技能或上传，名称可使用 k8s-cluster-health-inspection。

Skill 负责固定范围、顺序和输出要求，实际数据仍由工具查询。上传 SKILL.md 时，文件应直接以 frontmatter 开始，前面不要再加标题或说明。

可保存为 SKILL.md 的核心内容如下。将默认集群与数据源名称按实际环境补充：

Markdown

---
name: k8s-cluster-health-inspection
description: 对指定 Kubernetes 集群执行只读健康巡检和故障诊断。
---

# 集群巡检

输入：集群、环境、时间范围；未明确目标集群时先确认范围。
巡检默认最近 24 小时，故障诊断默认最近 1 小时。

1. 确认实体、Events、Prometheus、SLS 与告警是否可用。
2. 查询核心业务与集群告警，定位异常工作负载。
3. 对异常对象关联节点、容器退出原因、事件、指标与日志。
4. 检查网络、存储和已接入的数据库及中间件依赖。
5. 输出异常对象、时间、证据、影响范围、判断与复查方式。

数据不可用时写清缺失项。证据不足的原因标记为待验证。
查询按授权执行；重启、扩缩容、删除、回滚及参数修改先审批。

健康巡检可以约定最近 24 小时；单次故障先看最近 1 小时；发布验证再按实际发布时间比较前后窗口。这些是任务约定，遇到明确的故障时间应调整。

执行巡检

在目标工作空间中选择集群实体，提交明确的任务：

Text

通过 k8s-cluster-health-inspection 检查指定测试集群最近 24 小时状态。
先列出可用和不可用的数据源，再检查节点、异常 Pod、工作负载、
Events、资源水位、日志、Service/Ingress、存储与已接入依赖。
每个异常给出对象、时间和证据；只输出变更建议，不执行修改。

异常对象检查

先看告警、业务错误率和核心工作负载，再缩小到具体对象：

节点：Ready 状态、资源压力、kubelet 与运行时异常。
工作负载：期望副本与可用副本、发布状态、探针和重启趋势。
Pod：调度、镜像、退出原因、资源限制与相关事件。
入口与网络：Service 后端、Ingress、DNS、网络策略和负载均衡健康检查。
存储与依赖：挂载、容量、延迟，以及数据库连接、缓存或消息积压。

不要只凭汇总的 status 字段给 Pod 分类。CrashLoopBackOff、ImagePullBackOff 属于常见的容器等待原因，OOMKilled 通常从容器上次终止状态读取；它们与 Pod 的 phase 不是同一层信息。

可以用只读命令复查某个对象：

Shell

kubectl get pods -n example -o wide
kubectl describe pod example-pod -n example
kubectl logs example-pod -n example --previous --tail=100
kubectl get events -n example --sort-by=.metadata.creationTimestamp

多容器 Pod 需要指定容器；--previous 依赖存在上一轮容器日志。日志已轮转或 Pod 已删除时，应到集中日志平台继续查。

核对报告与证据

看到 OOMKilled 可以确认一次内存相关终止，但内存泄漏、流量增长、限制过低都还只是待验证方向。需要继续比较终止前内存曲线、限制值、请求量、发布记录和应用日志。

同样，一次 Pod 重启不等于业务中断。还要检查可用副本、Service 后端、错误率和持续时间。报告中保留能直接用于决策的内容：

内容	需要写清楚什么
异常与影响	哪个对象、何时发生、影响哪些服务
证据	来自哪条事件、指标或日志
判断	已确认原因，或仍需验证的假设
处理与复查	建议动作、审批条件和恢复标准

证据不足时写清缺口，比补齐一个看似完整的根因更有用。

配置周期巡检

手动巡检能够稳定完成后，再设置周期任务，例如每天 9:00，明确采用 Asia/Shanghai 时区。固定目标集群、时间窗口、查询范围和报告位置，并检查任务失败后的通知渠道。

创建任务后立即执行一次，查看真实工具调用、权限错误和报告。任务显示启用，不代表每轮查询都会成功；报告还要能区分“本轮未发现异常”与“本轮部分数据不可用”。

重启、扩容、回滚等操作保留为单独的变更步骤。巡检报告发现问题后，再根据影响范围和证据决定是否执行。