实战目标
在前一篇笔记中，我们了解了 client-go 的基础用法。本篇将结合 AIOps 场景，构建一个能够自动观察 Kubernetes 集群状态、识别异常并执行修复动作的智能运维工具。该工具将展示如何将 client-go 与 LLM 推理、Function Calling 相结合，实现真正的"数据 + 决策 + 执行"闭环。
场景设计
假设我们需要解决以下运维问题：
- 集群中经常出现
CrashLoopBackOff、ImagePullBackOff、Evicted等异常 Pod。 - 部分 Pod CPU 或内存使用接近极限，存在 OOM 风险。
- 传统告警只能通知问题，修复仍依赖人工介入。
我们希望通过一个 Go 程序，定时扫描集群状态，将异常信息汇总后交给 LLM 进行根因分析，再由程序根据 LLM 建议调用 K8s API 执行修复。
系统架构
+----------------+ +----------------+ +----------------+
| client-go |----->| LLM Agent |----->| client-go |
| 采集集群状态 | | 根因分析与决策 | | 执行修复动作 |
+----------------+ +----------------+ +----------------+
整个流程分为三个阶段：
- 观测阶段：使用 client-go 拉取 Pod、Node、Event 等数据。
- 决策阶段：将数据组织成 Prompt，调用 LLM 获取修复建议。
- 执行阶段：解析 LLM 的 Function Calling 输出，调用 client-go 执行修复。
观测阶段：采集集群状态
func listProblematicPods(ctx context.Context, clientset *kubernetes.Clientset) ([]v1.Pod, error) {
pods, err := clientset.CoreV1().Pods("").List(ctx, metav1.ListOptions{})
if err != nil {
return nil, err
}
var problems []v1.Pod
for _, pod := range pods.Items {
phase := pod.Status.Phase
for _, cs := range pod.Status.ContainerStatuses {
if cs.State.Waiting != nil {
reason := cs.State.Waiting.Reason
if reason == "CrashLoopBackOff" || reason == "ImagePullBackOff" {
problems = append(problems, pod)
}
}
}
if phase == v1.PodFailed {
problems = append(problems, pod)
}
}
return problems, nil
}
除了 Pod 状态，还可以采集：
- Node 资源使用率
- Deployment 副本与滚动更新状态
- Events 中的 Warning 事件
- HPA 状态与指标
决策阶段：构造 Prompt 并调用 LLM
将采集到的数据以结构化方式提供给 LLM：
你是一名资深 Kubernetes SRE。当前集群存在以下异常 Pod：
1. Namespace: prod, Pod: api-gateway-xxx, 状态: CrashLoopBackOff, 重启次数: 12
最近事件: Back-off restarting failed container api-gateway
请分析可能原因，并决定是否需要重启 Pod 或检查镜像标签。如果需要重启，请输出函数调用：
restart_pod(namespace, pod_name)
LLM 根据上下文输出结构化的 Function Calling 结果，例如：
{
"name": "restart_pod",
"arguments": {
"namespace": "prod",
"pod_name": "api-gateway-xxx"
}
}
执行阶段：解析并调用 client-go
func restartPod(ctx context.Context, clientset *kubernetes.Clientset, namespace, name string) error {
return clientset.CoreV1().Pods(namespace).Delete(ctx, name, metav1.DeleteOptions{})
}
通过 Delete Pod，K8s 控制器会根据 Deployment/ReplicaSet 重新调度新的 Pod，从而完成重启。
进阶：资源画像与自动扩缩容
除了异常修复，client-go 还可以用于采集资源画像，为 AIOps 模型提供训练数据。例如：
| 指标项 | 采集方式 |
|---|---|
| Pod CPU/内存使用 | metrics-server 或 Prometheus API |
| 请求 QPS | Ingress Controller 指标 |
| 启动时间 | Pod 状态时间戳计算 |
| 节点负载 | Node 对象的 status.capacity 与 status.allocatable |
将这些数据持久化到时序数据库或数据湖，即可用于训练流量预测模型，实现预测性自动扩容。
安全与审计
自动化修复必须考虑安全：
- 操作白名单：只允许执行预定义的安全操作，如重启 Pod、扩容副本。
- 人工确认：对高风险操作（如删除 StatefulSet、修改网络策略）要求人工审批。
- 审计日志：记录每次决策的上下文、LLM 输出和执行结果，便于复盘。
- 回滚机制：执行后持续观察，若指标恶化则自动回滚。
总结
client-go 不仅是 K8s 的编程接口，更是 AIOps 系统与集群交互的"手脚"。结合 LLM 的推理能力，我们可以构建从观测、决策到执行的完整智能运维闭环。后续课程将在此基础上，进一步学习如何开发 Kubernetes Operator，将这类能力以声明式方式沉淀到集群中。