云原生交付复盘怎样转成可复用防线
复盘的价值在于改变下一次的操作路径。能自动检查的配置做成规则，能稳定执行的恢复动作做成脚本；其余判断保留在运行手册里，写清触发条件和停止条件。
纸面复盘与重复踩坑：为什么文档记录容易缺乏实际效果。
回顾上一次生产事故的现场命令行记录：
kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide dig @10.96.0.10 internal-service.prod.svc.cluster.local +time=1 +tries=1 kubectl get events -n kube-system --sort-by='.metadata.creationTimestamp' | tail -n 20监控面板反馈的诊断信息非常明确：
;; Connection timed out; no servers could be reached 2026-08-31T03:10:22Z Warning Unhealthy Pod/coredns-5d78c9869-z8x2q Readines probe failed: UDP dial timeout故障根本原因在于：Linux 内核 conntrack 模块在处理 UDP 并发竞争时存在丢包瑕疵，且节点未部署 NodeLocal DNSCache。然而，由于缺少自动化校验门禁，后续新建的业务集群依然未能默认启用 NodeLocal DNSCache。静态文档无法自动阻止同类问题在多个集群间复发。
故障模式闭环建模：将文字分析提炼为可量化的指标与触发器。
复盘报告的核心不在于责任追究，在于提取“故障特征指标”。对于 CoreDNS 抖动问题，需要提取出两个关键指标：第一，coredns_dns_request_duration_seconds_bucket{le="0.005"}的比例下降至 95% 以下；第二，system_conntrack_entries接近conntrack_max阈值的 80%。
把文字描述转译为 Prometheus 告警表达式：
apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: coredns-conntrack-warning namespace: monitoring spec: groups: - name: dns.rules rules: - alert: CoreDNSUDPTimeoutSpike expr: sum(rate(coredns_dns_responses_total{rcode="SERVFAIL"}[2m])) / sum(rate(coredns_dns_requests_total[2m])) > 0.05 for: 1m labels: severity: critical annotations: summary: "CoreDNS SERVFAIL error rate exceeded 5% in last 2m"自动化修复控制器：用 Go 编写一个 DNS 探针与自动重置 Operator。
为了降低人工响应延迟，可以使用 Go 编写内部控制器。当检测到 Pod 本地 DNS 解析连续失败时，自动重置挂起的 DNS 代理或更新 upstream 配置。
package controller import ( "context" "fmt" "net" "sync/atomic" "time" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/client-go/kubernetes" ) type DNSHealthOperator struct { kubeClient kubernetes.Interface targetHost string dnsServer string failsCount int64 } func NewDNSHealthOperator(client kubernetes.Interface, targetHost, dnsServer string) *DNSHealthOperator { return &DNSHealthOperator{ kubeClient: client, targetHost: targetHost, dnsServer: dnsServer, } } func (o *DNSHealthOperator) StartAutoHealLoop(ctx context.Context, interval time.Duration) { ticker := time.NewTicker(interval) defer ticker.Stop() for { select { case <-ctx.Done(): return case <-ticker.C: if err := o.checkDNSResolution(); err != nil { failures := atomic.AddInt64(&o.failsCount, 1) fmt.Printf("[WARN] DNS Probe failed (%d/3): %v\n", failures, err) if failures >= 3 { o.triggerSelfHealing(ctx) atomic.StoreInt64(&o.failsCount, 0) } } else { atomic.StoreInt64(&o.failsCount, 0) } } } } func (o *DNSHealthOperator) checkDNSResolution() error { r := &net.Resolver{ PreferGo: true, Dial: func(ctx context.Context, network, address string) (net.Conn, error) { d := net.Dialer{Timeout: 1 * time.Second} return d.DialContext(ctx, "udp", o.dnsServer) }, } ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second) defer cancel() _, err := r.LookupHost(ctx, o.targetHost) return err } func (o *DNSHealthOperator) triggerSelfHealing(ctx context.Context) { fmt.Println("[ACTION] DNS failure threshold reached. Restarting NodeLocalDNS daemonset pod...") // 查找并重启当前节点上的 NodeLocalDNS Pod pods, err := o.kubeClient.CoreV1().Pods("kube-system").List(ctx, metav1.ListOptions{ LabelSelector: "k8s-app=node-local-dns", }) if err != nil { fmt.Printf("[ERROR] Failed to list node-local-dns pods: %v\n", err) return } for _, pod := range pods.Items { err := o.kubeClient.CoreV1().Pods("kube-system").Delete(ctx, pod.Name, metav1.DeleteOptions{}) if err != nil { fmt.Printf("[ERROR] Failed to delete pod %s: %v\n", pod.Name, err) } else { fmt.Printf("[SUCCESS] Successfully evicted un-healthy DNS Pod: %s\n", pod.Name) } } }代码逻辑实现了带计数的探活机制。一旦确认 DNS 连续 3 次解析失败，直接通过 API Server 驱逐当前节点处于异常状态的 Pod，触发 Kubernetes 重新创建正常容器。
线上演练与应急验证：使用 Chaos Mesh 模拟 DNS 丢包并观察自愈。
控制代码编写完成后，需在测试环境中利用 Chaos Mesh 注入 50% 的 UDP 丢包故障，验证 Operator 的自动响应机制：
apiVersion: chaos-mesh.org/v1alpha1 kind: NetworkChaos metadata: name: dns-packet-loss-chaos namespace: prod spec: action: loss mode: one selector: namespaces: - kube-system labelSelectors: k8s-app: kube-dns loss: loss: '50' duration: '2m'提交故障注入配置后观察集群自愈过程：
kubectl apply -f chaos-dns-loss.yaml kubectl logs -n kube-system -l app=dns-health-operator --tail=50 -f控制台能够记录探针触发、错误计数累加至 3、以及驱逐故障 Pod 的完整日志链，受影响的业务 Pod 延迟在 10 秒内恢复正常。
防复发机制：把可自动检查的规则放进 CI/CD 与 Admission。
完成事故复盘的标志，不应当仅仅是复盘 Markdown 文件的 Pull Request 合并。
推荐包含三项硬性交付物：第一，新增的 Prometheus 告警规则文件；第二，自愈 Operator 的逻辑单元测试代码；第三，Kubernetes 部署清单模板（Helm/Kustomize）的强制配置更新。
通过将书面经验转译为可自动执行的程序代码，能够保障复盘成果真正转化为系统的防护能力。
