Kubernetes 接入智能排障：从只读旁路到灰度自愈
示例场景：传统 Kubernetes 排障通常依赖运维工程师在监控面板和终端间收集日志与指标。节点出现 OOMKilled 或 Pod 持续 CrashLoopBackOff 时，直接给 Agent 集群写权限可能扩大故障影响。可先以旁路采集、检索和只读建议切入，再决定是否开放有限的自动化动作。
graph LR A[旧排障流程: 告警 -> 运维手动 kubectl/Prometheus] --> B[第一阶段: 旁路日志与 K8s 事件向量化采集] B --> C[第二阶段: 智能检索生成只读诊断报告] C --> D[第三阶段: SRE 确认后自动化执行修复指令]第一阶段：旁路采集与日志/指标上下文向量化挂载
平滑迁移的基础是搭建旁路数据通道。初始阶段不改变现有运维和告警链路，可通过后台服务定期拉取或使用 Watch 机制订阅集群事件（Events）、Pod 日志和 Prometheus 告警指标流。下文代码是一次性查询示例，并非持续监听实现。
采集到的日志与事件可经清洗后转换为向量索引，供后续检索增强生成（RAG）使用。采集批量、刷新周期和限流策略应按事件量及 API Server 余量设定；batch_size=100、flush_interval_ms=1000仅为示例。
import time from typing import List, Dict from kubernetes import client, config from kubernetes.client.rest import ApiException class EventCollector: def __init__(self, kubeconfig_path: str = None): try: if kubeconfig_path: config.load_kube_config(config_file=kubeconfig_path) else: config.load_incluster_config() self.v1 = client.CoreV1Api() except Exception as e: raise RuntimeError(f"初始化 Kubernetes 客户端失败: {str(e)}") def fetch_warning_events(self, namespace: str = "default") -> List[Dict[str, str]]: """获取指定命名空间下的警告事件并清洗数据""" cleaned_events = [] try: events = self.v1.list_namespaced_event(namespace=namespace) for event in events.items: if event.type == "Warning": cleaned_events.append({ "reason": event.reason or "Unknown", "message": event.message or "", "object": f"{event.involved_object.kind}/{event.involved_object.name}", "timestamp": str(event.last_timestamp) }) except ApiException as e: print(f"调用 API Server 获取 Event 异常: {e}") except Exception as e: print(f"处理 Event 数据未预期错误: {e}") return cleaned_events if __name__ == "__main__": collector = EventCollector() warns = collector.fetch_warning_events("production") print(f"捕获到 {len(warns)} 条 Warning 级事件，准备注入向量索引库")运维人员在管理节点上可以使用以下命令行快速核对 Warning 级别的集群事件，验证旁路采集服务捕获数据的完整性与时效性：
kubectl get events -n production --field-selector type=Warning --sort-by='.lastTimestamp'旁路采集上线前要按实际日志量压测，记录 CPU、内存、队列积压和丢弃量。容量结论必须来自目标集群，不能从示例配置直接推导。
第二阶段：只读决策建议与影子运维验证
在完成旁路数据注入后，智能检索系统可正式对接告警转发管道。当 Prometheus 触发 Alertmanager 告警信号时，系统将自动关联前一步收集到的日志片段、K8s Event 以及内部 Knowledge Base 中的排障手册，交由 LLM 推导并生成一份只读的根因分析与修复建议报告。
这一阶段应禁用自动写集群操作。诊断报告只作为辅助信息推送到协作或运维平台，由值班 SRE 审核、复核并记录采纳结果，以评估建议的有效性。
上下文大小需要按所用模型的 token 计算器和可用窗口控制。接近预算时可先保留告警、事件和最近错误日志，再对低优先级内容摘要；4096不是通用阈值。
import json import requests def build_troubleshooting_context(alert_name: str, pod_name: str, logs: str, events: list) -> str: """构建包含告警、日志与事件的提示词上下文""" prompt = f""" 诊断目标告警: {alert_name} 目标 Pod: {pod_name} 最近日志片段: {logs[:1000]} 相关事件列表: {json.dumps(events, ensure_ascii=False)} 请输出事故根因推断，并给出建议的 kubectl 操作指令。 """ return prompt def generate_readonly_suggestion(context: str, api_url: str) -> str: try: response = requests.post( api_url, json={"prompt": context, "max_tokens": 500}, timeout=10.0 ) response.raise_for_status() return response.json().get("text", "未能生成推荐文本") except requests.exceptions.RequestException as e: return f"AI 诊断服务请求失败: {str(e)}" mock_logs = "java.lang.OutOfMemoryError: Java heap space" mock_events = [{"reason": "OOMKilled", "message": "Memory limit exceeded"}] ctx = build_troubleshooting_context("PodMemoryHigh", "order-service-789f-xyz", mock_logs, mock_events) suggestion = generate_readonly_suggestion(ctx, "http://internal-ai-service.ops.local/predict") print("AI 生成建议报告:\n", suggestion)在收到诊断报告后，SRE 工程师仍需使用终端工具执行标准排障命令，用以交叉比对诊断报告的真实性与严谨性：
kubectl describe pod order-service-789f-xyz -n production kubectl logs order-service-789f-xyz -n production --previous --tail=50演练终端打印的拟真排障日志显示：
[示例输出] [ERROR] container "order-app" terminated with exitCode=137, reason="OOMKilled"影子运维阶段用于积累校验数据。评估时至少区分 OOM、探针失败、调度失败等故障类型，分别统计诊断命中率、误报率和生成延迟；没有真实标注集时，不宜给出准确率结论。
第三阶段：闭环自动化恢复与灰度流量比例切换
当只读建议报告在长期的影子运行中达到设定的准确率阈值（例如连续 30 天准确率高于 95%）后，系统方可逐步推进至受控闭环阶段。
在此阶段，系统将被授予执行特定低风险自愈动作的权限（例如自动重启挂起的无状态 Pod 或清理临时缓存目录）。而对于高风险变更操作（如调整 HPA 参数上限或变更 Deployment 镜像版本），依然要求强制走 GitOps 审核流程，提交 Pull Request 由人工审批后触发构建。
配置防错规则要求：自愈 Controller 在同一 Namespace 内 10 分钟内触发自愈动作次数不得超过 auto_remediation_max_quota=3，防止陷入连续重启死循环。
受控自动化恢复宜按 Namespace 灰度开启，并保留一键停用和审计记录：
# 查看已开启智能自愈 Annotation 标记的命名空间 kubectl get ns -l ai-auto-remediation=enabled # 对特定业务命名空间逐步开启自愈权限 kubectl label namespace payment-service ai-auto-remediation=enabled --overwrite这条路径可概括为“旁路观测、只读辅助、局部授权”。大模型适合协助关联日志和提出假设；风险较高的修复仍应有权限边界、回滚措施和人工确认。