Kubernetes 故障演练：如何验证探针、驱逐与回滚
Kubernetes 故障演练：如何验证探针、驱逐与回滚
Kubernetes 演练的目标不是制造戏剧化故障，而是验证探针、调度和回滚是否按预期工作。每次只改变一个条件，记录对象事件与时间线，并在开始前写清停止条件。
1. 问题现象与排查入口
当一次 Chaos 实验触发非预期故障时，排查现场往往被大量无用信息淹没。要还原真相，必须收集四种不同粒度的数据证据链：
- Control Plane 审计日志：API Server 是否发起了被动 Pod 驱逐（Eviction）？
- K8s Event 序列：Kubelet 抛出
OOMKilled与Unhealthy Liveness Probe的精确毫秒级时间戳。 - Container 终端日志与 Trace Context：上游服务在超时挂起前，分布式链路 TraceID 最后的死锁位置。
- Cgroup 级指标：Kernel
memory.failcnt的增长速率。
如果把这些几百兆的原始日志直接喂给通用 LLM，大模型不仅会产生严重的“长上下文幻觉”，还会试图去解释已经失效的过时Pod日志。因此，智能检索的前提是结构化上下文编排。
2. 基于 RAG 与知识拓扑的证据链编排架构
可以设计的 AI 排障助手不直接“阅读”原生日志，而是先通过矢量化引擎与拓扑提取器，将 Kubernetes 状态变更转化为时序证据节点（Chronological Evidence Nodes）。
这种架构的核心在于：用 Kubernetes 架构拓扑收紧向量检索的范围。如果 Node-A 上的 DNS 服务挂了，RAG 检索器只会检索同 Node 或挂载相同 CoreDNS 配置的关联 Pod 证据，防止无关 Pod 干扰。
3. Kubernetes 证据链检索与上下文构造实现
以下是用 Python 实现的 K8s 诊断证据链结构化编排器。该代码从 Kubernetes Client API 获取故障时间窗口内的事件，并基于时间戳与空间关系进行 Prompt 组装。
#!/usr/bin/env python3 # -*- coding: utf-8 -*- import time from typing import List, Dict from kubernetes import client, config class K8sEvidenceChainBuilder: def __init__(self, namespace: str = "default"): # 加载 K8s 集群配置 try: config.load_incluster_config() except config.ConfigException: config.load_kube_config() self.v1 = client.CoreV1Api() self.namespace = namespace def collect_event_timeline(self, start_time_epoch: int, end_time_epoch: int) -> List[Dict]: """收集指定时间窗口内的确定性 K8s 核心事件证据链""" evidence_chain = [] events = self.v1.list_namespaced_event(self.namespace) for event in events.items: # 转换事件时间戳 event_time = event.last_timestamp or event.event_time if not event_time: continue epoch = int(event_time.timestamp()) # 时间窗口筛选 if start_time_epoch <= epoch <= end_time_epoch: evidence_chain.append({ "timestamp": epoch, "readable_time": event_time.strftime("%Y-%m-%d %H:%M:%S"), "kind": event.involved_object.kind, "name": event.involved_object.name, "reason": event.reason, "message": event.message, "type": event.type }) # 按时间升序排序，保证时间线确定性 evidence_chain.sort(key=lambda x: x["timestamp"]) return evidence_chain def build_structured_prompt(self, failure_summary: str, timeline: List[Dict]) -> str: """组装带强语义约束的 LLM 诊断上下文""" prompt = f"""[System Context] 你是一个严谨的 Kubernetes 云原生诊断专家。请依据下方按时间顺序排列的真实 K8s Event 证据链，分析混沌实验失败的终态根因。 绝对不允许凭空捏造事件数据。如果证据不足，请明确指出缺失的观察点。 [故障描述] {failure_summary} [毫秒级确定性事件链 (Timeline)] """ for idx, item in enumerate(timeline, 1): prompt += f"{idx}. [{item['readable_time']}] [{item['type']}] Object: {item['kind']}/{item['name']} | Reason: {item['reason']} -> Message: {item['message']}\n" prompt += """ [输出要求] 请按以下结构输出诊断报告： 1. 真正触发级联失效的第一因果节点 (Root Cause Node) 2. 证据链条匹配度说明 3. 建议的 Helm/K8s 修复配置字段 """ return prompt if __name__ == "__main__": builder = K8sEvidenceChainBuilder(namespace="production") # 模拟混沌实验在过去 10 分钟内的窗口 now = int(time.time()) chain = builder.collect_event_timeline(now - 600, now) prompt = builder.build_structured_prompt("Chaos Mesh 注入 300ms 网络延迟后，Order 支付服务 Pod 出现 CrashLoopBackOff", chain) print(f"生成的 LLM 诊断上下文长度: {len(prompt)} 字符")4. 问题现象与排查入口
在 Chaos 实验失败或线上 Pod 出现异常抖动时，运维人员应当使用一系列工具抓取现场“犯罪证据”。
1. 快速抽取指定 Pod 的上一代退出日志与 Cgroup 溢出证据
# 1. 抓取因 OOM 崩溃容器的最后 100 行退出日志 kubectl logs --previous -n production payment-service-78d4c99-x29z1 --tail=100 # 2. 查看容器详细状态与退出的 Terminated Exit Code (例如 137 即为 SIGKILL/OOM) kubectl describe pod payment-service-78d4c99-x29z1 -n production | grep -E "(State|Exit Code|Reason|Limits)" # 3. 按事件发生时间倒序排列特定 namespace 下的所有 Warning 事件 kubectl get events -n production --field-selector type=Warning --sort-by='.metadata.creationTimestamp'2. 时序证据链与智能诊断的时序互动
在诊断 Agent 处理上述日志时，系统会形成一条清晰的上下文验证闭环：
5. 确定性治理：把混沌实验变成持续迭代的规范
混沌实验结束后，除了恢复环境，还要把已确认的缺陷转成 GitOps 规则或测试。AI 可以整理证据，最终规则仍由维护者审核并在 CI 中验证。
- 修改 Liveness/Readiness 探测防线：如果证据链显示 Pod 是因为在 GC 期间被 Kubelet 误杀，应当提高
periodSeconds并增加timeoutSeconds，避免在网络抖动时发生集群自残。 - 将 AI 诊断结论固化为 Rego/OPA 校验策略：例如防范
limits.memory缺乏 1.2 倍安全冗余的 YAML 提交。 - 构建自动复现脚本：把由 AI 还原的故障路径转化为开箱即用的 Chaos Mesh 自动化测试用例，集成在 nightly build 流水线中。
将模型输入限制为 K8s Event 时间线和结构化字段，可以减少无关上下文。实验是否有效，仍由探针、事件记录和回滚结果判断。