运维 on 方糖猫Blog

☸️ Kubernetes 学习总结与避坑指南

Wed, 12 Feb 2025 10:00:00 +0800

☸️ Kubernetes 学习总结与避坑指南

参考书籍：龚正等《Kubernetes 权威指南：从 Docker 到 Kubernetes 实践全接触》、Marko Lukša《Kubernetes in Action》目标读者：会一点 Docker、刚接触 K8s，或者「YAML 会抄但一出问题就懵」的同学。

Kubernetes（简称 K8s，因为 K 和 s 之间有 8 个字母）是 Google 开源的容器编排系统，解决了「成百上千个容器跑在成百上千台机器上，谁来调度、谁来扩容、挂了谁来拉起」的问题。它不是一门「背完概念就会」的技术——新人最常见的状态是：每个名词都听过，但它们之间怎么串起来的说不清楚，Pod 一挂就不知道该看哪里。

这篇文章帮你建立主干知识框架：

K8s 集群整体长什么样？Master 和 Node 各自干什么？
Pod、Node、Service、Ingress、ConfigMap 这些核心对象到底是什么关系？
Istio 服务网格在解决什么问题？
共享存储（PV/PVC/NAS）怎么用，有哪些坑？
排查 K8s 问题需要补哪些 Unix 网络编程基础知识？
生产环境如何做内外网访问隔离（私网端点 / 内网 LB / NetworkPolicy）？
在阿里云 ACK（以及 AWS EKS）上落地时要注意什么？
Jenkins 如何与 K8s 打通，实现自动化部署、验证与失败回滚？
遇到 CrashLoopBackOff、OOMKilled、502、DNS 慢这些经典问题，该按什么思路排查？

一、K8s 整体架构：一个「中心化大脑 + 一群干活的节点」

K8s 集群在逻辑上分为两大部分：

控制平面（Control Plane，俗称 Master）：集群的大脑，负责「决策」——调度、扩缩容、故障自愈。
工作节点（Node）：真正跑容器的机器，负责「执行」。

graph TB
    subgraph 控制平面["控制平面 Control Plane（阿里云 ACK 托管，用户不可见）"]
        APIServer[kube-apiserver<br/>集群唯一入口，所有操作都经过它]
        ETCD[(etcd<br/>分布式 KV 存储<br/>集群所有状态都在这里)]
        Scheduler[kube-scheduler<br/>决定 Pod 调度到哪个 Node]
        CM[kube-controller-manager<br/>各种控制器：副本数维持、节点监控等]
        CCM[cloud-controller-manager<br/>对接云厂商：SLB/EBS/路由]
    end

    subgraph 节点1["Worker Node 1"]
        K1[kubelet<br/>节点上的「包工头」]
        P1[kube-proxy<br/>维护 Service 网络规则]
        C1[容器运行时<br/>containerd]
        Pod1[Pod A] ~~~ Pod2[Pod B]
    end

    subgraph 节点2["Worker Node 2"]
        K2[kubelet]
        P2[kube-proxy]
        C2[containerd]
        Pod3[Pod C]
    end

    APIServer --> ETCD
    Scheduler --> APIServer
    CM --> APIServer
    CCM --> APIServer
    K1 --> APIServer
    K2 --> APIServer
    User[kubectl / CI/CD] --> APIServer

记住这条主线：所有组件只跟 apiserver 说话，apiserver 把状态写进 etcd。你敲的每一条 kubectl 命令、每一个控制器的决策，都是「读/写 apiserver」这个动作。理解了这一点，后面所有概念都好串了。

K8s 的核心设计思想是声明式 API + 控制器循环：

graph LR
    A[你提交 YAML<br/>期望状态：3 个副本] --> B[apiserver 存进 etcd]
    B --> C{控制器不断对比<br/>期望状态 vs 实际状态}
    C -->|实际只有 2 个| D[再创建 1 个 Pod]
    D --> C
    C -->|一致| E[什么都不做]

这就是「自愈」的本质：不是有人盯着修，而是控制器永远在循环纠偏。所以 K8s 里的对象是「期望状态」的描述，不是一条条命令。

二、Node：干活的机器

2.1 Node 上有什么

每个 Node 上必装三个组件：

kubelet：节点代理。接收 apiserver 下发的 Pod 定义（PodSpec），调用容器运行时把容器拉起来，并持续上报节点和 Pod 状态。Pod 挂了重启、探针检测，都是 kubelet 干的。
容器运行时：真正拉镜像、跑容器的软件。Docker 已在 K8s 1.24 后被移除，现在主流是 containerd。
kube-proxy：维护节点上的网络规则（iptables/IPVS），让 Service 的虚拟 IP 能转发到真实 Pod。

2.2 节点相关的避坑点

节点 NotReady：最常见的原因是 kubelet 挂了、节点磁盘满（DiskPressure）、内存不足（MemoryPressure）或网络不通。排查顺序：先 kubectl describe node <名字> 看 Conditions，再登节点看 systemctl status kubelet 和日志 journalctl -u kubelet。
磁盘压力：容器日志、镜像、emptyDir 都在吃节点磁盘。务必给应用日志配轮转（logrotate 或运行时自带的日志上限 containerLogMaxSize），否则磁盘写满会把节点上所有 Pod 驱逐（Evicted）。
不要随意登节点手工改东西：K8s 期望节点是「牛」不是「宠物」——可替换、不特殊。手工装的 Agent、改的 iptables 规则，节点一重建全没了。需要节点级能力请用 DaemonSet。

三、Pod：K8s 的最小调度单元

3.1 为什么不是直接调度容器

Pod 是一组共享网络和存储的容器集合。同一个 Pod 里的容器：

共享同一个 IP 和端口空间（通过 localhost 直接互通）
可以共享 Volume

graph TB
    subgraph Pod["Pod（10.0.1.15）"]
        direction LR
        C1[主容器<br/>app:8080]
        C2[边车容器<br/>日志采集]
        V[(共享 Volume<br/>日志目录)]
        C1 --> V
        C2 --> V
    end
    C1 -.->|localhost:8080| C2

这个设计的经典用途就是 Sidecar（边车）模式：日志采集、流量代理（Istio 的 Envoy）都以边车容器形式注入 Pod，主容器无感知。

新人直觉「一个 Pod 跑一个容器」，这对 90% 的场景是对的。只有容器之间必须同生共死、共享 localhost 或共享文件时，才放进同一个 Pod。

3.2 Pod 生命周期与探针

stateDiagram-v2
    [*] --> Pending: 创建，等调度/拉镜像
    Pending --> Running: 调度成功，容器启动
    Running --> Succeeded: 正常退出（Job 类）
    Running --> Failed: 异常退出
    Running --> Running: 探针失败→kubelet 重启容器

三个探针，新人人手必配：

探针	作用	配错的后果
`livenessProbe`	判断容器是否活着，失败则重启容器	太灵敏 → 无限重启循环
`readinessProbe`	判断是否能接流量，失败则从 Service 摘除	不配 → 启动期请求打到没 ready 的 Pod，报 502
`startupProbe`	启动探针，成功前禁用另外两个	慢启动应用（如老 Java 服务）不配 → 被 liveness 误杀

3.3 资源 requests/limits 与 QoS：最容易被忽视的重灾区

resources:
  requests:        # 调度依据：保证分到这么多
    cpu: "250m"    # 0.25 核
    memory: "512Mi"
  limits:          # 使用上限
    cpu: "500m"
    memory: "1Gi"

requests 是调度的唯一依据：节点剩余可分配资源 ≥ Pod 的 requests 总和，Pod 才调度得上去。不配 requests，调度就是瞎排，节点超载。
CPU 超 limit → 被限流（throttle），容器变慢但不死；内存超 limit → OOMKilled，直接杀。这是两种完全不同的失败模式，排查时先分清。
QoS 等级：requests=limits 为 Guaranteed（最后被驱逐）；都不配为 BestEffort（节点资源紧张时最先被杀）。生产核心服务至少配 Burstable。

四、工作负载：不要直接创建裸 Pod

实际工作中你几乎不会手写 Pod，而是使用「管理 Pod 的控制器」：

对象	适用场景	一句话
Deployment	无状态服务（Web/API）	副本数 + 滚动更新 + 回滚
StatefulSet	有状态服务（MySQL/Kafka）	稳定的名字和网络标识、按序启停
DaemonSet	节点级 Agent（日志/监控）	每个 Node 跑一个
Job / CronJob	一次性/定时任务	跑完即退

Deployment 滚动更新过程：

sequenceDiagram
    participant U as 用户
    participant D as Deployment
    participant RS1 as ReplicaSet v1
    participant RS2 as ReplicaSet v2

    U->>D: kubectl set image 更新镜像
    D->>RS2: 创建新 RS，先拉起 1 个新 Pod
    RS2-->>D: 新 Pod ready
    D->>RS1: 缩掉 1 个旧 Pod
    Note over D,RS2: 循环：新 +1 → 旧 -1
    D->>RS1: 缩到 0（旧 RS 保留，可回滚）
    U->>D: kubectl rollout undo（随时回滚）

避坑点：

maxSurge / maxUnavailable 控制滚动节奏。默认 25%/25%，意味着更新中可能瞬间少 25% 的可用副本——容量紧张的服务要调小 maxUnavailable。
回滚靠旧 ReplicaSet 保留的 Pod 模板，revisionHistoryLimit 默认 10，别设成 0 否则无法回滚。
镜像 tag 不要用 latest：无法回滚、无法审计，且 imagePullPolicy 行为反直觉。用 git commit 号或语义化版本。

五、K8s 网络模型与必备的 Unix 网络编程知识

K8s 的网络问题占了线上故障的一半以上。而很多「K8s 网络问题」本质上是 Unix 网络编程/TCP 协议问题，只是发生在容器环境里。这一节把两边打通。

5.1 K8s 网络的三条铁律

K8s 对网络模型只有三个基本要求（具体实现交给 CNI 插件，如 Flannel、Calico、阿里云 Terway）：

每个 Pod 有自己的独立 IP
任意两个 Pod 之间可以直接通信（不经过 NAT）
Node 和 Pod 之间可以直接通信

graph LR
    subgraph 节点A["Node A"]
        PA["Pod A<br/>10.244.1.5"]
    end
    subgraph 节点B["Node B"]
        PB["Pod B<br/>10.244.2.8"]
    end
    PA <-->|"Pod 网络（CNI：Terway/Flannel/Calico）<br/>直连，无 NAT"| PB

5.2 Service：一组 Pod 的稳定入口

Pod 会漂移（重建后 IP 就变了），所以不能在代码里写死 Pod IP。Service 提供一个固定虚拟 IP（ClusterIP）+ DNS 名字，负载均衡到后端 Pod。

graph LR
    Client[客户端 Pod] -->|"访问 my-svc:80<br/>DNS 解析为 10.96.0.10"| SVC["Service: my-svc<br/>ClusterIP 10.96.0.10"]
    SVC -->|kube-proxy 的 iptables/IPVS 规则转发| P1[Pod 1]
    SVC --> P2[Pod 2]
    SVC --> P3[Pod 3]

三种 Service 类型：

ClusterIP（默认）：仅集群内可达
NodePort：在每个节点开一个高端口（30000-32767），可从集群外访问
LoadBalancer：对接云厂商负载均衡器（阿里云 CLB/SLB、AWS NLB/ALB），对外暴露的标准姿势

5.3 为什么排查 K8s 网络要懂 Unix 网络编程

下面这几组知识，是在 K8s 环境里排查连接问题的「元技能」：

（1）TCP 连接状态与 TIME_WAIT

TCP 挥手后主动关闭方会进入 TIME_WAIT 状态，默认保持 2MSL（Linux 上约 60s）。在高并发短连接场景（比如服务间大量 HTTP/1.0 式短调用），客户端端口会被 TIME_WAIT 大量占用，最终 Cannot assign requested address。

stateDiagram-v2
    ESTABLISHED --> FIN_WAIT1: 主动方 close()
    FIN_WAIT1 --> FIN_WAIT2: 收到对端 ACK
    FIN_WAIT2 --> TIME_WAIT: 收到对端 FIN
    TIME_WAIT --> CLOSED: 2MSL 超时（约60s）
    ESTABLISHED --> CLOSE_WAIT: 对端先 close()
    CLOSE_WAIT --> LAST_ACK: 我方 close()
    LAST_ACK --> CLOSED

K8s 里的对应症状与解法：

症状：服务间调用偶发超时，ss -s 看到 timewait 几万。
正解：应用层用长连接 + 连接池（HTTP keep-alive、gRPC），别依赖 net.ipv4.tcp_tw_reuse 这类内核参数硬扛。
另一个常见坑是 CLOSE_WAIT 堆积：对端关了连接但你的代码没 close()（连接泄漏），ss -ant | grep CLOSE_WAIT 一查便知。

（2）socket、backlog 与「连接被 Reset」

服务端 listen(fd, backlog) 的 backlog 是「已完成三次握手但应用还没 accept」的队列长度。K8s 场景下突发流量打到刚重启的 Pod，如果应用 backlog 太小（或迟迟不 accept），内核会直接 RST，客户端看到的是 Connection reset by peer。这类问题在 Pod 扩容瞬间、探针刚通过时高发——readinessProbe 通过 ≠ 应用真的能扛流量。

（3）epoll 与 I/O 多路复用

一个进程通过 epoll 可以管理数万连接（C10K 问题的解法）。Nginx Ingress、Envoy 都是 epoll 模型。要懂的点：

进程能开的连接数受 文件描述符上限限制：ulimit -n。容器里同样生效，高并发服务记得确认 limit（cat /proc/<pid>/limits）。
每个 TCP 连接 = 一个四元组（源IP:源端口 → 目标IP:目标端口）。客户端对单一目标的并发连接数理论上受源端口数（约 2.8 万个可用）限制——这又回到「必须用连接池复用连接」。

（4）conntrack：K8s 特有的网络坑

kube-proxy 的 iptables 模式依赖内核 conntrack（连接跟踪表）。节点上连接数巨大时 conntrack 表被打满（默认 nf_conntrack_max 往往不够），表现为新建连接随机丢包、无日志，极难排查。解法：调大 net.netfilter.nf_conntrack_max，或干脆把 kube-proxy 切到 IPVS 模式。阿里云 ACK 的 Terway 模式在这方面压力小很多。

（5）DNS：K8s 里的「隐形依赖」

集群内所有服务名解析都靠 CoreDNS。两个经典坑：

glibc 的 DNS 解析是串行的，且默认 ndots:5 导致集群内短域名先查 5 次后缀。症状：应用偶发解析慢 5s（一次超时重传）。解法：FQDN 写法 my-svc.my-ns.svc.cluster.local.（结尾加点）或调整 Pod 的 dnsConfig。
Java 应用默认永久缓存 DNS 结果（networkaddress.cache.ttl=-1），Service 后端 IP 变了 JVM 不知道。容器里务必显式设置 DNS 缓存 TTL（如 30s）。

5.4 内外网访问隔离：哪些服务能暴露，哪些必须藏住

生产集群的基本安全原则：默认所有东西都不出集群，只开必要的口子。K8s 默认网络是「全通」的（任何 Pod 可以访问任何 Pod，LoadBalancer 一不小心就开到公网），隔离要靠自己显式配置。隔离分三个层面，从外到内：

graph TB
    Internet[公网用户] -->|只放行 443| WAF[WAF / 安全组<br/>云平台层]
    WAF --> PubLB[公网 ALB/CLB<br/>仅 Web 入口服务]
    PubLB --> PubIng[Ingress Controller<br/>公网命名空间]
    PubIng --> WebSvc[Web Service<br/>ClusterIP]

    Office[办公网/运维] -->|VPN/跳板机| IntLB[内网 LoadBalancer<br/>intranet 类型]
    IntLB --> AdminSvc[管理后台 / 监控<br/>Grafana / Jenkins]

    subgraph 集群内["集群内部（东西向流量）"]
        WebSvc -->|NetworkPolicy 允许| AppSvc[业务 Service]
        AppSvc -->|NetworkPolicy 允许| DBSvc[数据库 Proxy Service]
        AppSvc -.->|NetworkPolicy 拒绝| Other[其他 namespace]
    end

第一层：云网络边界（VPC / 安全组）

API Server 用私网端点：阿里云 ACK 创建集群时选择「专有网络（私网）」API Server 访问，或只绑定内网 EIP，运维通过 VPN/跳板机访问；公网端点即便有证书认证也是攻击面。AWS EKS 对应 endpoint private access。
节点安全组收紧入方向：只放行 NodePort 范围给内网、放行 LB 健康检查来源，其余一律拒绝。ACK 的节点安全组默认规则要审一遍。
数据库、Redis 这类云产品走 VPC 内网地址，安全组只对集群节点网段开放。

第二层：Service 暴露方式——内外网分流的关键

LoadBalancer 类型 Service 默认创建的是公网 LB，这是最常见的「误暴露」事故。面向内部的服务要用注解显式声明内网 LB：

# 阿里云：内网 CLB（VPC 内可达，公网不可达）
apiVersion: v1
kind: Service
metadata:
  name: internal-admin
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
spec:
  type: LoadBalancer
  ports:
    - port: 80

AWS EKS 对应注解：service.beta.kubernetes.io/aws-load-balancer-internal: "true"（NLB）或 aws-load-balancer-scheme: internal（ALB Controller）。

经验法则：

对外服务：公网 ALB/CLB + Ingress，前面最好再挂 WAF。
对内服务（管理后台、监控、Jenkins）：内网 LB 或纯 ClusterIP，配合 VPN/跳板机访问。
默认用 ClusterIP，需要出集群时再显式升级类型——把「暴露」当成一个需要评审的动作。
Ingress 上还可以用注解做来源 IP 白名单（如 nginx.ingress.kubernetes.io/whitelist-source-range: 10.0.0.0/8），给内部接口再加一道闸。

第三层：NetworkPolicy——集群内部的东西向隔离

即使流量不出集群，「测试 namespace 的 Pod 误连生产数据库」这类事故也常见。NetworkPolicy 是 Pod 级的防火墙（需要 CNI 支持，ACK 的 Terway、Calico 都支持，Flannel 不支持）：

# 第一步：namespace 默认全拒（白名单模式的起点）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: prod
spec:
  podSelector: {}          # 选中 namespace 内所有 Pod
  policyTypes: ["Ingress", "Egress"]
---
# 第二步：只放行需要的流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-app
  namespace: prod
spec:
  podSelector:
    matchLabels: {app: order-svc}
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels: {app: web-frontend}
      ports:
        - port: 8080

避坑点：

NetworkPolicy 是白名单累加模型：任何一条 policy 选中某 Pod，该 Pod 未被放行的方向就被默认拒绝。写漏了 DNS（Egress 到 kube-dns 的 53 端口）会导致全 namespace 解析失败——默认拒绝后记得显式放行 DNS。
策略只对选中后新建立的连接生效，且 Flannel 下写了也不生效（静默失效，最坑的一种）。
云安全组管的是「节点/LB 维度」，NetworkPolicy 管的是「Pod 维度」，两者互补不替代。
上了 Istio 的话，还可以用 AuthorizationPolicy 做带身份（mTLS 服务身份）的七层鉴权，比纯 IP/端口的 NetworkPolicy 更细。

六、Ingress：HTTP 流量的统一入口

Service 解决的是四层（TCP）负载均衡；Ingress 解决的是七层（HTTP/HTTPS）路由：按域名、按路径把外部流量分发到不同 Service。

graph TB
    User[外部用户] -->|HTTPS| LB[云负载均衡<br/>阿里云 ALB/CLB]
    LB --> IC[Ingress Controller<br/>Nginx / ALB Ingress]
    IC -->|"a.example.com/api/*"| S1[Service: api]
    IC -->|"a.example.com/web/*"| S2[Service: web]
    IC -->|"b.example.com/*"| S3[Service: admin]
    S1 --> P1[api Pod]
    S2 --> P2[web Pod]
    S3 --> P3[admin Pod]

注意分清两层：

Ingress 资源（YAML 对象）：只是路由规则的声明，本身不做任何事。
Ingress Controller（真正干活的组件）：如 ingress-nginx、阿里云 ALB Ingress Controller。它 watch Ingress 资源，把规则翻译成 Nginx 配置并热加载。

避坑点：

pathType: Prefix 和 Exact 的区别，/api 配 Prefix 会把 /apiserver 也匹配进去。
后端重写（rewrite-target）是最容易写错的注解，先想清楚「客户端路径 → 后端真实路径」的映射。
HTTPS 证书放在 Secret 里，过期忘续是经典事故——建议上 cert-manager 自动签发续期。
502 的第一排查动作：看 Ingress Controller 日志里 upstream 是「连接拒绝」（Pod 没 ready）还是「超时」（应用卡死）。

七、ConfigMap 与 Secret：配置和代码分离

十二要素应用的第一条就是「配置存环境」。K8s 里对应两个对象：

ConfigMap：普通配置（应用参数、配置文件、特性开关）
Secret：敏感配置（密码、密钥、证书），etcd 中 Base64 编码（注意：Base64 不是加密，生产环境要开 etcd 静态加密或对接 KMS）

两种注入方式：

# 方式一：环境变量
env:
  - name: DB_HOST
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: db_host

# 方式二：挂载为文件（推荐，支持热更新）
volumeMounts:
  - name: config
    mountPath: /etc/app
volumes:
  - name: config
    configMap:
      name: app-config

两个必踩的坑，提前告诉你：

环境变量注入的配置，改了 ConfigMap 不会生效，必须重启 Pod。文件挂载方式会自动更新（kubelet 定期同步，有分钟级延迟），但应用要支持 reload。
subPath 挂载的 ConfigMap 不会自动更新。这是用了 subPath 挂单个配置文件的同学必踩的坑——改完 ConfigMap 发现容器里还是旧的。解法：挂载整个目录，或接受重启 Pod 的事实。
ConfigMap 有 1MB 大小限制，别把大文件塞进去。

八、共享存储：PV / PVC / StorageClass

容器是临时的，数据要持久化就必须落到外部存储。K8s 的存储抽象分三层：

graph TB
    subgraph 管理员/云平台侧
        SC[StorageClass<br/>定义「用什么盘」<br/>如 alicloud-disk-essd / nas]
        PV[PersistentVolume<br/>一块真实的存储<br/>云盘/NAS 文件系统]
    end
    subgraph 应用侧
        PVC[PersistentVolumeClaim<br/>「我要 100Gi 存储」的申请单]
        Pod[Pod 挂载 PVC]
    end
    PVC -->|绑定| PV
    SC -->|动态供给：PVC 一创建<br/>自动开出对应 PV| PV
    Pod --> PVC

现代用法几乎全是动态供给：你只需要写 PVC 声明要多少空间，StorageClass 自动调用云厂商 API 创建云盘/NAS，不用手工建 PV。

三种访问模式（Access Modes）是高频考点：

模式	含义	典型存储
ReadWriteOnce (RWO)	只能挂到一个节点	云盘（阿里云 ESSD、AWS EBS）
ReadWriteMany (RWX)	多节点共享读写	文件存储（阿里云 NAS、AWS EFS）
ReadOnlyMany (ROX)	多节点只读	对象存储挂载、只读数据卷

共享存储的避坑清单：

云盘（RWO）不能跨可用区挂载。PV 创建在可用区 A，Pod 被调度到可用区 B 就永远 Pending。解法：用 WaitForFirstConsumer 模式的 StorageClass（等 Pod 定好节点再开盘），并用拓扑约束调度。
要多副本共享文件（如多个 Web Pod 共享上传目录），必须用 NAS/EFS 这类 RWX 存储，云盘做不到。
NAS 挂载注意权限问题：容器内进程 UID 和 NAS 目录属主不匹配会 Permission denied，用 securityContext.fsGroup 或挂载参数解决。
删除 PVC 会不会丢数据，取决于 PV 的 persistentVolumeReclaimPolicy（Retain 保留 / Delete 连盘一起删）。生产数据盘务必确认是 Retain。
StatefulSet 用 volumeClaimTemplates 给每个副本独立开盘，扩缩容时数据卷跟着 Pod 名字走，这是有状态服务的标准姿势。

九、Istio 服务网格：把「网络能力」从业务代码里剥出来

微服务多了之后，每个服务都要自己实现超时重试、熔断、灰度、流量监控——这些和业务无关。Istio 的思路：给每个 Pod 注入一个 Envoy 边车代理，接管所有进出流量，上述能力全部在代理层实现，业务代码零侵入。

graph TB
    subgraph 控制平面["Istio 控制平面（istiod）"]
        Pilot[配置下发<br/>流量规则]
        Citadel[证书管理<br/>mTLS]
    end
    subgraph 数据平面
        subgraph PodA["Pod A"]
            App1[业务容器] --- E1[Envoy 边车]
        end
        subgraph PodB["Pod B"]
            App2[业务容器] --- E2[Envoy 边车]
        end
    end
    Pilot -.->|xDS 配置下发| E1
    Pilot -.->|xDS 配置下发| E2
    E1 <-->|"mTLS 加密流量<br/>（应用无感知）"| E2

核心能力速览：

流量管理：VirtualService + DestinationRule 实现按权重灰度（v1 90% / v2 10%）、按 Header 路由、超时重试、熔断
安全：服务间自动 mTLS 加密 + 身份认证（AuthorizationPolicy）
可观测：不用改代码就拿到全链路指标、调用拓扑、访问日志
入口：Istio Gateway 替代/补充原生 Ingress，作为网格的南北向入口

避坑点（Istio 坑不少，挑最重要的）：

边车有成本：每个 Pod 多一份 Envoy 的 CPU/内存（默认 requests 约 100m/128Mi），上千 Pod 规模要算这笔账，必要时调小。
Sidecar 启动顺序：业务容器可能比 Envoy 先起来导致启动瞬间网络不通（现在 holdApplicationUntilProxyStarts 可解）；Job 类任务跑完 Envoy 不退导致 Job 永不结束，需要显式退出或关掉注入。
协议识别：Service 端口名要带协议前缀（name: http-xxx），否则 Istio 按 TCP 处理，七层能力全部失效。这是网格内路由不生效的第一嫌疑。
排障三板斧：istioctl analyze（静态检查配置）、istioctl proxy-config（看 Envoy 实际生效配置）、Envoy 的 :15000/stats 和 :15000/clusters。
新人别一上来就上全量 Istio。先在非核心 namespace 开注入练手，理解 VirtualService 再说。

十、云上落地：阿里云 ACK 为主，AWS EKS 对照

自己从零搭一套生产级 K8s（etcd 高可用、证书、网络插件）成本极高，生产环境几乎都用云厂商托管服务。

10.1 阿里云 ACK 关键点

graph TB
    subgraph 阿里云托管["ACK 托管层（免费/Pro）"]
        MA[控制平面：apiserver/etcd/scheduler<br/>阿里云托管，SLA 保障]
    end
    subgraph 你的账号["你的 VPC 内"]
        N1[ECS 节点池 1<br/>按量/抢占式]
        N2[ECS 节点池 2<br/>弹性伸缩 ESS]
    end
    MA --> N1
    MA --> N2
    N1 -.对接.-> CLB[CLB/ALB<br/>负载均衡]
    N1 -.对接.-> NAS[云盘 ESSD / NAS<br/>持久存储]
    N1 -.对接.-> SLS[SLS 日志 / ARMS 监控<br/>可观测]

实践经验：

网络插件选 Terway：Pod 直接用 VPC 弹性网卡 IP，无 overlay 开销、conntrack 压力小，还能配 NetworkPolicy；Flannel 适合小规模简单场景。Terway 模式下规划 VPC 网段要留够，每个 Pod 占一个真实 IP。
节点池 + 弹性伸缩：按业务波峰波谷自动扩缩节点；抢占式实例（Spot）跑无状态任务能省 70% 成本，但要容忍随时被回收。
Ingress 用 ALB Ingress Controller：比自建 Nginx Ingress 省心，ALB 本身按量弹性，且和 ACK 深度集成。
日志和监控开箱即用：日志服务 SLS（采集容器 stdout 和文件日志）、ARMS Prometheus 监控，别再自己搭 ELK 了。
镜像仓库 ACR：用 ACR EE（企业版）+ ACK 免密拉取插件，避免在 YAML 里配 imagePullSecret。
存储选 CNFS/云盘 ESSD（有状态单副本）+ NAS（共享文件）+ OSS（静态资源、备份） 的组合。

10.2 AWS EKS 速查对照

需求	阿里云 ACK	AWS EKS
网络插件	Terway（VPC 网卡直连）	aws-vpc-cni（同理）
七层入口	ALB Ingress	AWS Load Balancer Controller (ALB/NLB)
块存储	云盘 ESSD	EBS (gp3)
共享文件存储	NAS	EFS
日志	SLS	CloudWatch
监控	ARMS Prometheus	Managed Prometheus / Grafana
镜像仓库	ACR	ECR
无服务器节点	虚拟节点（ECI）	Fargate

概念完全互通，换云只是换 Controller 和注解。

十一、典型问题排查手册

11.1 通用排查流程

graph TD
    A[发现问题] --> B{Pod 状态？<br/>kubectl get pods}
    B -->|Pending| C[kubectl describe pod<br/>看 Events]
    C --> C1{原因}
    C1 -->|资源不足| C2[加节点/降 requests<br/>或开弹性伸缩]
    C1 -->|存储挂载失败| C3[检查 PVC 绑定/可用区]
    C1 -->|镜像拉取失败| C4[ImagePullBackOff：查镜像名/凭证/网络]
    B -->|CrashLoopBackOff| D[kubectl logs --previous<br/>看上一个容器的临终日志]
    D --> D1{原因}
    D1 -->|应用自身报错| D2[修代码/配置]
    D1 -->|Exit 137| D3[OOMKilled：调大 memory limit<br/>或查内存泄漏]
    D1 -->|Exit 143| D4[被优雅终止：查探针/滚动更新]
    B -->|Running 但访问异常| E[分层验证]
    E --> E1[1. 进 Pod 内 curl localhost 通吗？]
    E1 --> E2[2. curl Pod IP 通吗？]
    E2 --> E3[3. curl Service ClusterIP 通吗？<br/>查 Endpoints 是否有后端]
    E3 --> E4[4. Ingress 域名通吗？<br/>查 Controller 日志]

11.2 高频问题速查表

症状	最常见原因	第一动作
ImagePullBackOff	镜像名/tag 错、私有仓库无凭证、节点无公网	`describe pod` 看 Events 报错原文
CrashLoopBackOff	配置错、依赖没起来、探针误杀	`kubectl logs --previous`
OOMKilled (137)	内存 limit 太小或泄漏	看监控曲线，调 limit；Java 服务注意堆外内存
Pod 一直 Pending	资源不够、PVC 未绑定、污点/亲和性	`describe pod` 看调度失败原因
服务间偶发超时	conntrack 满、DNS 慢、TIME_WAIT 耗尽	`ss -s`、CoreDNS 日志、查连接池配置
滚动更新后 502	没配 readinessProbe / 没处理 SIGTERM 优雅退出	配探针 + preStop + 应用优雅关闭
ConfigMap 改了不生效	环境变量注入 / subPath 挂载	重启 Pod 或改为目录挂载
跨可用区挂载失败	云盘和节点不在同一 AZ	WaitForFirstConsumer + 拓扑约束

11.3 优雅退出：滚动更新不断流的完整姿势

Pod 被删除时的标准流程（很多人只知道一半）：

sequenceDiagram
    participant K as kubelet
    participant P as Pod
    participant EP as Endpoints

    K->>EP: 把 Pod 从 Service 摘除（不再接新流量）
    K->>P: 执行 preStop 钩子（如 sleep 5，等摘流量生效）
    K->>P: 发送 SIGTERM
    P->>P: 应用应：停止接新请求，处理完存量请求后退出
    Note over K,P: 超过 terminationGracePeriodSeconds（默认30s）
    K->>P: SIGKILL 强杀

三个缺一不可：readinessProbe 保证新 Pod ready 才切流量；preStop/优雅关闭保证老 Pod 处理完存量请求；terminationGracePeriodSeconds 给够时间。Java/Go 服务请确认框架注册了 SIGTERM 处理器（Spring Boot 的 server.shutdown=graceful、Go 的 signal.Notify）。

11.4 kubectl 排障速查

kubectl get pods -o wide -n <ns>          # 看状态和所在节点
kubectl describe pod <pod> -n <ns>        # 看 Events（排障第一步）
kubectl logs <pod> -c <container> --previous   # 崩溃前的日志
kubectl get endpoints <svc> -n <ns>       # Service 后面到底有没有 Pod
kubectl exec -it <pod> -- sh              # 进容器内验证网络
kubectl run debug --rm -it --image=busybox:1.36 -- sh   # 临时网络调试 Pod
kubectl top pod / kubectl top node        # 资源占用
kubectl get events --sort-by=.lastTimestamp -n <ns>     # 按时间看事件

十二、CI/CD：Jenkins 与 K8s 打通，实现自动化部署与验证

手工 kubectl apply 只适合学习。生产环境的标准做法是把「构建 → 推镜像 → 部署 → 验证 → 失败回滚」串成流水线，代码合并后自动完成发布。

12.1 整体流水线长什么样

graph LR
    Dev[开发者 git push] --> Hook[Webhook 触发 Jenkins]
    Hook --> Build[阶段1: 构建<br/>单测 + Docker 镜像]
    Build --> Push[阶段2: 推送镜像<br/>到 ACR/ECR<br/>tag = git commit]
    Push --> Deploy[阶段3: 部署<br/>kubectl set image<br/>更新 K8s]
    Deploy --> Verify[阶段4: 验证<br/>rollout status + 冒烟测试]
    Verify -->|成功| Done[发布完成<br/>钉钉/邮件通知]
    Verify -->|失败| RB[自动回滚<br/>rollout undo] --> Alarm[告警通知]

关键认知：K8s 侧不需要装任何 Jenkins 插件或 Agent 也能被部署——Jenkins 只要有目标集群的 kubeconfig（访问凭证），用 kubectl 就能驱动 apiserver 完成一切。打通的本质就两件事：凭证怎么管、流水线脚本怎么写。

12.2 Jenkins 的两种部署形态

形态	说明	适用
Jenkins 在集群外（独立服务器/另一集群）	通过 kubeconfig 远程操作业务集群	一套 Jenkins 管多个集群，最常见
Jenkins 跑在 K8s 集群内	配合 Kubernetes 插件，每次构建动态拉起一个 Pod 作为构建 agent，用完即销毁	构建任务多、想弹性利用集群资源

graph TB
    subgraph Jenkins侧["Jenkins（集群外或集群内）"]
        J[Jenkins Master]
        C1[凭据1: kubeconfig<br/>Secret file 类型]
        C2[凭据2: ACR 账号<br/>Username/Password 类型]
        J --> C1
        J --> C2
    end
    subgraph 阿里云["阿里云"]
        J -->|docker push| ACR[ACR 镜像仓库]
        J -->|"kubectl（走内网 API Server 端点）"| API[ACK apiserver]
        API --> Pod[滚动更新业务 Pod]
        Pod -->|免密拉取| ACR
    end

推荐做法：Jenkins 与 ACK 在同一 VPC 内，kubectl 直接走 API Server 的内网端点（安全且免公网流量）；镜像仓库用 ACR 企业版 + ACK 免密拉取，业务侧零凭证。

12.3 最小权限的部署凭证：别把 admin kubeconfig 给 Jenkins

这是 CI/CD 安全的第一课。给 Jenkins 一个只能操作特定 namespace、只能改 Deployment 的 ServiceAccount：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins-deployer
  namespace: prod
---
# Role 只在 prod namespace 内生效
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployer
  namespace: prod
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "patch", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jenkins-deployer
  namespace: prod
subjects:
  - kind: ServiceAccount
    name: jenkins-deployer
    namespace: prod
roleRef:
  kind: Role
  name: deployer
  apiGroup: rbac.authorization.k8s.io

然后为这个 SA 生成 token，做成只含该 token 的 kubeconfig，存进 Jenkins 的 Secret file 凭据。好处：凭证泄露也只影响一个 namespace 的 Deployment，且可以随时 kubectl delete rolebinding 吊销。

12.4 完整 Jenkinsfile 示例

pipeline {
    agent any
    environment {
        IMAGE     = "registry.cn-hangzhou.aliyuncs.com/mycompany/order-svc"
        TAG       = "${env.GIT_COMMIT.take(8)}"   // 用 git commit 做 tag，可回滚可追溯
        KUBECONFIG = credentials('ack-prod-kubeconfig')   // Secret file 凭据
    }
    stages {
        stage('构建') {
            steps {
                sh 'mvn -q test'                       // 先跑单测，挂了直接终止
                sh "docker build -t ${IMAGE}:${TAG} ."
            }
        }
        stage('推送镜像') {
            steps {
                withCredentials([usernamePassword(
                    credentialsId: 'acr-account',
                    usernameVariable: 'U', passwordVariable: 'P')]) {
                    sh 'echo $P | docker login registry.cn-hangzhou.aliyuncs.com -u $U --password-stdin'
                    sh "docker push ${IMAGE}:${TAG}"
                }
            }
        }
        stage('部署到 ACK') {
            steps {
                sh "kubectl --kubeconfig=$KUBECONFIG -n prod \
                    set image deployment/order-svc order-svc=${IMAGE}:${TAG}"
            }
        }
        stage('验证') {
            steps {
                // 阻塞等待滚动更新完成；超时/失败会非零退出
                sh "kubectl --kubeconfig=$KUBECONFIG -n prod \
                    rollout status deployment/order-svc --timeout=300s"
                // 冒烟测试：走内网 SLB 打健康检查和关键接口
                sh "curl -fsS --retry 5 --retry-delay 3 \
                    http://order-svc-internal.prod.svc.cluster.local/healthz || exit 1"
            }
        }
    }
    post {
        failure {
            // 部署验证失败自动回滚到上一个版本
            sh "kubectl --kubeconfig=$KUBECONFIG -n prod \
                rollout undo deployment/order-svc || true"
        }
    }
}

12.5 「验证」环节的正确姿势

很多流水线只做到 kubectl apply 就算「发布成功」，这是自欺欺人。apply 返回成功只代表 apiserver 收下了 YAML，Pod 起不起得来是另一回事。可靠的验证链：

rollout status 阻塞等待：确认所有新副本 ready（背后靠的就是 readinessProbe——再次体现探针的重要性）。
冒烟测试：对真实入口打 /healthz 和一两个核心业务接口，确认「能起来」且「能干活」。
失败自动回滚：rollout undo 依赖旧 ReplicaSet 还在（revisionHistoryLimit 别设 0）且镜像 tag 可追溯——这就是前面说「不要用 latest」的根本原因。
更严谨的做法是灰度验证：先用 Istio 把 5% 流量切到新版本观察指标，确认无误再全量（见第九章）。

12.6 CI/CD 避坑清单

镜像 tag 必须唯一可追溯：git commit 短哈希或构建号，杜绝 latest，否则回滚时根本不知道该回滚到哪个镜像。
凭据最小化 + 分环境：dev/staging/prod 用不同的 SA 和 Jenkins 凭据，prod 的部署动作加人工审批（Jenkins 的 input 步骤）。
声明式优先：服务变多后，把 kubectl set image 换成 Helm/Kustomize（YAML 也进 Git 仓库，可审计可 diff）；再进一步上 GitOps（ArgoCD/Flux）——Jenkins 只负责构建推镜像，部署由集群内的 ArgoCD 从 Git 仓库自动同步，Jenkins 不再需要生产集群的任何凭证，安全性大幅提升。
Jenkins 到集群的网络：kubectl 走内网 API Server 端点；如果 Jenkins 在另一个 VPC，用云企业网/对等连接打通，不要把 API Server 暴露公网给 Jenkins 用。
构建产物（镜像）与部署配置分离管理，避免「同一个 tag 被覆盖推送」导致回滚失效——ACR 里给 prod 仓库开镜像 tag 不可变（immutable）开关。

十三、学习路线建议

第一周：本地装 minikube 或 kind，把 Deployment/Service/ConfigMap 各玩一遍，亲手制造一次 CrashLoopBackOff 并修好它。
第二周：搞懂网络——Pod 网络、Service 转发（iptables）、Ingress、NetworkPolicy 内外网隔离，配合 tcpdump/ss 在容器里抓包看真实流量。
第三周：上云。开一套阿里云 ACK（按量付费，玩完就删），跑通「ACR 推镜像 → ACK 部署 → ALB Ingress 暴露 → NAS 挂共享盘 → SLS 看日志」全流程。
第四周：打通 CI/CD。用 Jenkins + 最小权限 SA 实现「推代码 → 自动构建 → 自动部署 → rollout 验证 → 失败回滚」完整流水线。
进阶：Helm 包管理、HPA 自动扩缩容、Istio 灰度发布、GitOps（ArgoCD）。

最后送一句《Kubernetes 权威指南》反复强调的心法：K8s 的一切都是声明式的——你描述「我要什么」，控制器负责「做到」。排查问题时永远先问：期望状态（YAML/Spec）是什么？实际状态（Status/Events）是什么？两者的差距就是答案所在。

参考资料：

《Kubernetes 权威指南：从 Docker 到 Kubernetes 实践全接触（第 4 版）》龚正等

《Kubernetes in Action》Marko Lukša

《Unix 网络编程卷1》W. Richard Stevens（网络排障内功）

Kubernetes 官方文档

阿里云 ACK 文档

Google SRE 工作手册详细总结：写给从未接触过 SRE 的人

Tue, 26 Oct 2021 10:00:00 +0800

Google SRE 工作手册详细总结：写给从未接触过 SRE 的人

参考书籍：Google SRE 团队《The Site Reliability Workbook》（《SRE 工作手册》，2018）目标读者：第一次听说 “SRE” 这个词，想知道它到底是什么、解决什么问题、能不能用在自己团队的人。

〇、这本书是什么？

Google 在 2016 年出版了《Site Reliability Engineering》（第一本 SRE 书），讲的是 SRE 的原理——Google 是怎么想的。2018 年这本《Workbook》（工作手册）是它的姊妹篇，讲的是 怎么落地——两本书的章节基本一一对应（比如第一本书第 4 章"服务级别目标"对应本书第 2 章"实施 SLO"）。

这本书最有价值的一点是：它故意收录了大量 Google 之外的公司 的落地案例——Evernote、Home Depot（家得宝）、《纽约时报》、Spotify、Waze、PagerDuty——就是为了破除"SRE 只在 Google 那种规模和文化下才玩得转"的误解。全书由 100 多人贡献完成。

用前言里 Mark Burgess 的话说，整本书可以浓缩成三句话：

承诺：明确地设定服务的目标、期望和水平；
评估：根据指标和预算约束持续评估这些承诺；
反应：快速做出反应以兑现承诺。

一、SRE 到底是什么？和 DevOps 什么关系？

SRE = Site Reliability Engineering，网站可靠性工程。这个词由 Google 工程副总裁 Ben Treynor Sloss 创造。一句话概括：

SRE 就是让软件工程师去做运维团队的工作——“运维是一个软件问题”。

传统模式里，开发团队（追求快速出新功能）和运维团队（追求稳定别出事）天然对立：开发想"快发"，运维想"别动"。SRE 用一套量化的工程方法消解这个矛盾，而不是靠开会吵架。

那它和 DevOps 是什么关系？第 1 章的标题本身就是一行代码，堪称全书最著名的梗：

class SRE implements DevOps

DevOps 是一套文化和哲学，SRE 是它的一种具体实现——就像极限编程（XP）是敏捷（Agile）的一种具体实现。Puppet 前 VP Andrew Clay Shafer 在前言里甚至说：如果第一本 SRE 书早几年出版，社区会团结在"消除琐事"的旗帜下，“DevOps"这个词可能根本不会存在。

DevOps 的五个关键思想与 SRE 的对应实现：

DevOps 思想	SRE 的具体做法
不再有孤岛	SRE 与开发共享所有权、用相同的工具
事故是正常的，指责无用	对事不对人的事后总结（blameless postmortem）
变更应该小步快跑	金丝雀发布、CI/CD、降低失败成本（MTTR）
工具和文化相互关联	统一的工具链本身就是文化载体
度量至关重要	SLI / SLO / 错误预算

SRE 的七条核心原则：

运维是一个软件问题——用写代码的方式消灭重复劳动；
按 SLO 管理——不追求 100% 可用性（为什么，下面细讲）；
努力减少琐事（toil）；
自动化今年的工作——Google 硬性规定 SRE 花在琐事上的时间不超过 50%，而且要把它当成"保证"而不是"上限”；
通过降低失败成本来加快开发速度——恢复快（MTTR 低）比不出事更重要；
与开发者共享所有权；
无论头衔如何，都使用相同的工具。

这里有一个值得记住的反面案例：2017 年 5 月英国航空大停运，被书中引为"把运维当成本中心拼命压缩"的失败典型——一场大事故抵消了低成本运营省下的所有钱。

二、全书的地基：SLI、SLO、SLA 和错误预算

第 2 章被作者称为"本书最重要的章节"，金句是：“没有 SLO，就不需要 SRE”。这一节是全书的地基，务必看懂。

2.1 三个容易混淆的概念

用一个"外卖小哥"的比喻：

SLI（Service Level Indicator，服务级别指标）：你实际测出来的数字。比如"过去 30 天，99.2% 的外卖在 40 分钟内送达"。
SLO（Service Level Objective，服务级别目标）：你给自己定的目标。比如"我们承诺 99% 的订单 40 分钟内送达"。
SLA（Service Level Agreement，服务级别协议）：和客户签的、违约要赔钱的商业合同。通常比 SLO 宽松，SLO 是内部"提前预警线"，SLA 是"最后底线"。

工程上的标准写法：

SLI = 好事件数 / 总事件数        （0% ~ 100% 之间）
错误预算 = 100% − SLO

错误预算（Error Budget） 是全书最重要的发明。它的逻辑是：既然 100% 不可靠也不必要，那么"允许出错的额度"就是一种可以花掉的预算——你可以用它来快速发布新功能、做架构实验；预算花光了，就冻结发布，全员回头修可靠性。开发和运维的矛盾，从"立场之争"变成了"看数据说话"。

2.2 为什么不追求 100% 可用性？

书中给了四个理由：

组件同时故障的概率永远不为零，100% 在数学上就做不到；
用户访问你的服务要经过很长的链路（手机 → 运营商 → 公网 → 机房），你把可用性从 99.9% 提到 99.99%，用户的实际体验提升微乎其微——边际效用递减；
100% 意味着你不能做任何变更，而变更是功能迭代的前提；
100% 的 SLO 只是"运维团队的 SLO"，不是一种工程文化。

还有一个很直观的乘法效应：如果你的服务依赖 9 个可用性 99.99% 的关键上游，你的总可用性 ≈ 0.9999¹⁰ ≈ 99.9%——4 个 9 直接掉到 3 个 9。第 19 章还有一个更扎心的数字：客户在 99.999% 的平台上自己只做到 99%，最终用户感受到的是 99% × 99.999% = 98.99901%。

2.3 一个完整的例子：手机游戏后端

第 2 章用一个手机游戏案例贯穿始终，非常适合入门者理解。架构如下：

graph LR
    A["📱 手机 App"] --> B["HTTP API 服务"]
    B --> C[("永久存储<br/>游戏状态/排行榜")]
    A --> D[("用户数据存储<br/>头像等")]
    C --> E["⏰ 定时管道<br/>生成今日/本周/历史排行榜"]
    E --> F[("排行榜数据存储")]
    G["🌐 网站"] --> F

先量现状：过去 4 周 API 总请求 3,663,253 次，成功 3,557,865 次（可用性 97.123%），P90 延迟 432ms，P99 延迟 891ms。据此定出入门级 SLO：

可用性：97% 请求成功
延迟：90% 请求 < 450ms，99% 请求 < 900ms

对应的错误预算：每四周允许失败约 109,897 个请求。

然后看两个真实事故的"预算消耗"对比，这是全书最有说服力的算账方式：

事故	错误数	消耗预算
一次坏发布，NullPointerException 持续 4 小时	14,066	13%
唯一的状态数据库故障，从备份恢复花了 20 小时	~72,000	65%

结论很反直觉：五年只发生一次的数据库故障，远没有每年 2~3 次的坏发布值得投入——改进发布流程的优先级应该高于调查服务器故障。这就是错误预算的意义：它把"该把工程资源投到哪"从拍脑袋变成了算术题。

2.4 落地 SLO 的完整流程

flowchart TD
    A["绘制服务架构图"] --> B["组件分类：<br/>请求驱动 / 管道 / 存储"]
    B --> C["为每类组件选 SLI 规范<br/>（不超过 5 种）"]
    C --> D["选择 SLI 实现方式<br/>（日志 → 探针 → 客户端插桩，精度递增）"]
    D --> E["基于历史数据定初始 SLO"]
    E --> F{"三方达成一致？<br/>产品：对用户够用<br/>开发：预算耗尽愿意行动<br/>SRE：不靠英雄主义守得住"}
    F -- 否 --> E
    F -- 是 --> G["白纸黑字写错误预算政策<br/>（预算耗尽怎么办）"]
    G --> H["监控 + 告警上线"]
    H --> I["定期审查迭代 SLO"]

三类组件各自推荐的 SLI：

请求驱动型（API 服务）：可用性、延迟、品质；
管道/流水线型（数据处理）：新鲜度、正确性、覆盖范围；
存储型：耐用性（数据丢不丢）。

错误预算政策里要事先写清楚"预算耗尽怎么办"：可靠性 bug 最优先、冻结生产变更（P0 问题和安全补丁除外），极端时宣布"紧急状态"，直到服务回到 SLO 以内。附录 B 还有一个值得抄的细节：单个事件消耗超过四周预算的 20% → 必须做事后调查，且至少包含一个 P0 行动项；对错误预算计算有分歧 → 上报 CTO 裁决。

三、非 Google 公司怎么落地？两个完整案例

3.1 Evernote：和云厂商"打破 SLO 的墙"

背景：全球 2.2 亿用户、存储 120 亿条信息、750+ 个 MySQL 实例，从自建数据中心迁往 GCP。传统"开发 vs 运维"两种模式（“you build it, you run it” 和 “you build it, we run it”）都试过了，都不满意，于是在 Google CRE（客户可靠性工程）团队帮助下落地 SLO。

首版 SLO：按月窗口、99.95% 正常运行时间；用第三方探针 Pingdom 每分钟轮询，需两个地理独立的探针连续失败才算"停机"；维护窗口也算停机（用户不知情就是不可用）；
治理节奏：每月与 Google 团队审查一次 SLO，每 6 个月修订一次，9 个月迭代了 3 版；指导原则是"完美是良好的敌人"——先有再优；
一个漂亮的故事：2017 年讨论是否压缩发布窗口时，双方用 SLO 计算把发布窗口从 5 个减到 2 个，量化了客户影响，消除了主观争论；
最创新的一点：与 Google 共享实时 SLO 仪表板。于是 Google 的告警从泛泛的"GCP 负载均衡今天有点慢"变成"该问题影响 Evernote SLO 的 5%"，重大事件双方作为联合 P1 故障单处理。

3.2 Home Depot（家得宝）：传统企业的规模化推广

背景：北美 2,200+ 门店、近 40 万员工、每年 15 亿+ 交易——证明 SRE 不是互联网公司专利。

他们发明了 VALET 框架（呼应 Google 的四大黄金信号，连批处理系统都能套用）：

Volume 容量（流量/处理记录数）
Availability 可用性
Latency 延迟
Errors 错误
Tickets 故障单（人工介入次数）

推广靠四板斧：

flowchart LR
    subgraph 推广四支柱
        A["通用语言<br/>VALET 缩写，人人会说"]
        B["布道<br/>内部博客/路演/T恤贴纸<br/>FiRE 学院培训"]
        C["自动化<br/>TPS Report 自动采集指标<br/>VALET 仪表板 + 聊天机器人"]
        D["激励<br/>SLO 纳入开发经理年度目标"]
    end
    A & B & C & D --> E["一年从 0 到 800 个服务<br/>每月新增约 50 个"]

给产品经理的简化分级表也很实用：99.5% = MVP/内部工具；99.9% = 大多数非销售系统；99.95% = 销售系统；99.99% = 共享基础设施。他们的原话值得引用：“我们是一家传统企业；如果我们能成功引入这么大的变化，您也可以。”

四、监控与告警：在预算烧光之前叫醒你

4.1 监控的基本盘

监控的五大用途：告警、诊断、可视化、长期趋势/容量规划、变更前后对比。指标和日志要分工：指标近实时但粒度低（告警、仪表板用它），日志有延迟但精确（根因分析用它）。数据新鲜度很关键——超过 4~5 分钟的失效数据会严重影响事件响应。

现代监控栈是松散耦合的：Prometheus（采集/规则）→ InfluxDB（长期存储）→ Alertmanager（告警聚合）→ Grafana（仪表板）。

4.2 告警的正确姿势：盯着错误预算的"消耗率"

新手最常见的告警写法是"错误率超过 X% 就报警"，书第 5 章用一整章论证这有多糟糕，并给出了演进路径：

flowchart TD
    M1["方法1：错误率≥SLO 就告警<br/>❌ 太敏感：10 分钟 0.1% 错误率就告警<br/>实际只消耗月预算 0.02%，每天可收 144 条"]
    M2["方法2：加大告警窗口<br/>❌ 检测太慢，大事故发现太晚"]
    M3["方法3：加持续时间参数 for:1h<br/>❌ 每 10 分钟一次 5 分钟的 100% 错误尖峰<br/>累计烧掉 35% 预算却永不触发"]
    M4["方法4：按消耗率 burn rate 告警<br/>⚠️ 进步明显，但重置时间长"]
    M5["方法5：多消耗率分档<br/>⚠️ 快烧/慢烧分开告警"]
    M6["方法6：多窗口多消耗率 ✅<br/>长窗保证精确度，短窗保证灵敏度"]
    M1 --> M2 --> M3 --> M4 --> M5 --> M6

消耗率（burn rate） = 当前错误率相对 SLO 允许错误率的倍数。对照表（99.9% SLO，30 天窗口）：

消耗率	错误率	耗尽预算需时
1	0.1%	30 天
10	1%	3 天
1000	100%	43 分钟

最终推荐的"多窗口多消耗率"参数（针对 99.9% SLO，可直接抄）：

呼叫值班（紧急）：1 小时长窗 + 5 分钟短窗，消耗率 14.4（约 2% 预算/小时）
呼叫值班（次紧急）：6 小时 + 30 分钟，消耗率 6
工单（不紧急）：3 天 + 6 小时，消耗率 1

短窗口取长窗口的 1/12。两个极端情况的提醒：低流量服务（每小时 10 个请求时，1 个失败就是 10% 错误率）要合并请求或拉长时间窗；99.999% 的服务 100% 中断 26 秒就耗尽预算——比大多数监控采集间隔还短，只能靠自愈。

五、消除琐事（Toil）：SRE 的时间去哪了

琐事（toil） 的六大特征：手动、重复、可自动化、被动应对、无持久价值、随服务规模线性增长。Google 规定 SRE 花在琐事上的时间不超过 50%，保证至少一半时间做"让明天比今天更好"的工程。

书中几个精彩案例：

John Looney 修内核：2005 年他入职 Google 时的活儿是修坏机器——任何时候都有超过 20,000 台坏机器。发现大量机器是日志把根分区填满，他本想写个脚本"截断大日志 + 重启 syslog"了事，被队友拦下要求修根因。最终他向 Linux 内核提交补丁，并用"这个问题导致 Google 每小时损失约 1000 美元"的成本分析说服了内核团队。修症状是琐事，修根因才是工程。
“不完美的自动化就够了”：Google 数据中心网络维修自动化（Saturn/Jupiter 项目）中，内存错误诊断被过度分析了三年（收集了 650+ 个离散问题数据），后来发现多数错误是暂时性的，重启重装即可恢复——完美的自动化不值得，“足够好"的自动化先跑起来。
“买下那个侏儒”：早年 Froogle 搜索"跑鞋"会返回一个穿跑鞋的花园侏儒（eBay 商品），修不掉这个 bug，团队干脆在 eBay 上把侏儒买了下来。引申义：有时改变现实去适应代码，比反过来便宜。

遗留系统的四阶段处理路径：避免 → 封装/增强（高息技术债转低息）→ 替换/重构 → 退役/监护。

与琐事相关的第 7 章"简单化"还有两个名案例：

Borg vs Omega：Omega 本想做成"更干净的 Borg"重写版，但 Borg 持续演进让 Omega 永远追不上移动的目标，迁移成本高到不可行。结局：Omega 的想法回流 Borg，概念最终催生了开源的 Kubernetes。教训：重写前先算一算"同样的精力投入改进现有系统会怎样”。
pDNS 循环依赖：客户端查服务 IP 依赖 Svelte，Svelte 依赖 pDNS，pDNS 的负载均衡器又依赖 Svelte——“我们就像洞穴居民，只能用上一次篝火点燃的火炬点火”（系统冷启动成为不可能）。解法：低级组件本地缓存关键 IP 列表，打破环路。

六、值班与事件响应：像消防队一样打仗

6.1 可持续的值班体系

关键数字：轮班不超过 12 小时；每 12 小时班次最多 2 个事件（再多就处理不过来了）；多站点 24/7 值班每站点至少 5 人；保证 ≥50% 的时间留给项目工作。警惕"温水煮青蛙"式的运维过载——值班负载用 21 天移动平均来看趋势。

Evernote 的事件分级很清爽：P1 立即处理（呼叫值班、影响 SLO）、P2 下一工作日（邮件通知）、P3 仅供参考（只看仪表板）。

6.2 事件指挥体系（ICS/IMAG）

大规模事件的打法直接借用了消防系统：1968 年消防员为应对野火创建的事件指挥系统（ICS），Google 内部叫 IMAG。核心思想：混乱中最大的敌人不是故障本身，而是"谁说了算都不知道"。

graph TD
    IC["🎖️ 事件指挥官 IC<br/>总负责，做决策，默认承担未委派的角色"]
    CL["📢 沟通主管 CL<br/>对用户/领导/媒体发通告"]
    OL["🔧 运维主管 OL<br/>带领团队执行技术操作"]
    IC --> CL
    IC --> OL

事件管理围绕"三个 C"：Coordinate（协调）、Communicate（沟通）、Control（控制）。四条基本原则：保持命令清晰、明确角色、实时记录、尽早且频繁地宣布事件。行动顺序永远是"缓解优先"：评估影响 → 缓解影响 → 根因分析 → 修复与事后报告。

三个真实案例，一正一反一个惊险：

反例：Google Home/Assistant 事件（2017）：一个 bug 让文件获取频率比预期高 50 倍，5 月 22 日就发现 QPS 异常，但误判了根因，而且在周六把灰度推到了 100%（违反"首次上线仅在工作日"的铁律），用户丢了一半请求，靠开发者周末"英雄主义"硬扛。教训：没有尽早宣布事件、缓解后没定根因就继续推送。
惊险：GKE CreateCluster 中断：欧洲集群创建失败率超 60%，根因竟是从 DockerHub 拉取的一个镜像损坏（美国正常）。伦敦 SRE 6:41 被呼叫，9:10 才正式建立 IMAG 结构（太晚了），最后发现用现成的 GCR 镜像站点（--registry-mirror=https://mirror.gcr.io）就能缓解——镜像其实早就就位了。总中断 6 小时 40 分钟，41 人参与，事后报告列出 28 个行动项。最大教训：发现大致位置后就该先用"通用缓解"（回滚到已知良好状态），而不是继续深挖根因。
正面：比利时数据中心雷击（2015）：两分钟内 4 次雷击，UPS 电池在第 3、4 次雷击间隔太近时未能切换，磁盘托盘断电。事件指挥得当：IC 定了三个明确目标，沟通主管对四类受众（公司领导、依赖团队、外部客户、工单客户）分别通报。最终数据丢失仅 0.000001%——管理良好的事件，损失可以极小。

七、事后总结文化：从失败中学习

SRE 文化的灵魂是对事不对人的事后总结（blameless postmortem）。第 10 章用同一个真实事故的"坏版本"和"好版本"两版报告做对比，极其有教育意义。

事故本身（2014-08-11，Google 卫星擦除事故）：Google 在托管机房部署的代理/缓存机架叫"卫星"。一次机架退役流程中，自动化中途失败，工程师手动重跑——重跑时 GetMachines() 返回了空列表，而 API 有个 bug：空列表被当作"无过滤条件"，而不是"不操作任何机器"。于是全球所有卫星机器在几分钟内被磁盘擦除。

flowchart TD
    A["机架退役自动化失败"] --> B["工程师手动重跑流程"]
    B --> C["GetMachines() 返回空列表"]
    C --> D["API bug：空列表 = 无过滤条件<br/>（而不是不操作任何机器）"]
    D --> E["全球所有卫星进入退役流程"]
    E --> F["磁盘被全部擦除 💥"]
    F --> G["边缘流量切到核心集群<br/>用户延迟上升约两天"]
    G -.->|"容量规划良好，<br/>用户几乎无感知"| H["几天后恢复"]

两版事后报告的对比：

	坏版本	好版本
发布时间	拖了 4 个月	4 天内（8/11 出事，8/15 发布）
根本原因	“dylanfour@ 粗心大意忽略自动化”	深入分析 API 语义缺陷与流程漏洞
行动项	全是 P2，措辞含糊（“使自动化更好”）	每项有唯一所有者、优先级、bug 号，含 P0 级"大红色按钮"（紧急停止开关）
分享范围	团队小范围	全公司工程师

后续更有说服力：三年后类似事件重演，但第一次事后总结落实的行动项大幅缩小了爆炸半径。Google 运维副总裁 Ben Treynor Sloss 的原话：

“没有后续行动的事后总结等于没写事后总结。所有影响用户的停机事后总结必须至少关联一个 P0/P1 bug，例外由我亲自审批，例外极少。”

事后总结文化崩塌的信号也要警惕：工程师回避参与、高管说指责性语言、没时间写、同类事故重复发生。

八、管理负载：Pokémon GO 的惊险一课

Google 管理流量的三层工具：负载均衡 + 自动扩缩容 + 减载（load shedding）。核心警告是：必须把它们当作一个整体系统设计，否则工具之间会形成灾难性的反馈回路。

8.1 案例：Pokémon GO（2016，真实）

上线前按最乐观估计的 5 倍做了负载测试，实际流量是估计的近 50 倍。随后发生的级联故障堪称教科书：

flowchart TD
    A["真实流量超预期 50 倍"] --> B["Niantic 前端代理跟不上入站连接"]
    B --> C["后端变慢但不拒绝请求"]
    C --> D["负载均衡层自动重试 GET"]
    D --> E["GFE 的 SSL 客户端代码被打到极限"]
    E --> F["GCLB 全球容量实际下降 50% ⚠️"]
    C --> G["客户端立即重试 + 固定退避<br/>错误时所有客户端同步重试（雷群）"]
    G --> H["同步峰值达此前全球 RPS 峰值的 20 倍"]
    F & H --> I["Google SRE 三步止血：<br/>①隔离 Pokémon GO 专用池 ②扩容 ③限流"]

事后双方各自改进：Niantic 给客户端加了抖动（jitter）+ 截断指数退避；Google 学会把 GFE 后端当潜在负载源、建立准入负载测试。共同教训：尽可能靠近客户端测量负载。

8.2 案例：Dressy 减载反馈回路（虚构但典型）

三区域部署，A 区流量上涨先触发减载（CPU 超阈值直接拒绝请求）→ 被拒请求几乎不耗 CPU → 负载均衡器一看"A 区每个请求成本只有 B/C 的 1/10，效率最高！"→ 把更多流量发给 A → A 区 503 爆炸。恶性循环的根源：配减载的和配负载均衡的是两拨人，没人把它们当统一的负载管理系统检查。修法很巧妙：让被拒绝的请求按 120% CPU 计入利用率，A 区立刻"显得"过载，流量自然流向 B/C。

九、NALSD：把白板上的架构图翻译成数字

NALSD（Non-Abstract Large System Design，非抽象大型系统设计） 是 Google 要求的系统设计方法：从问题出发迭代设计，每一步都必须把架构图翻译成具体的资源估算（多少台机器、多少字节、多少 IOPS），并回答四个问题——“可能吗？能做得更好吗？可行吗（钱和硬件）？有弹性吗（故障怎么办）？”

书中用 AdWords 点击率统计系统做了五轮完整迭代：每秒 50 万次搜索查询、1 万次广告点击，为数百万广告主出实时仪表板（SLO：99.9% 的查询 1 秒内完成，数据延迟不超过 5 分钟）。

flowchart LR
    I1["迭代1 单机方案<br/>100TB/天日志<br/>需 2500 块 HDD 或 1563 台机器<br/>❌ 单点故障一串"] --> I2["迭代2 MapReduce 批处理<br/>❌ 做不到 5 分钟内可见"]
    I2 --> I3["迭代3 LogJoiner<br/>流式 join 查询日志与点击日志<br/>⚠️ IOPS 单机扛不住"]
    I3 --> I4["迭代4 分片 + 副本<br/>hash(query_id) mod N<br/>⚠️ 单数据中心仍是单点"]
    I4 --> I5["迭代5 多数据中心 + Paxos ✅<br/>每 DC 约 4TB RAM、64 台机器<br/>网络带宽只用 25%"]

给面试和日常设计的启发：每轮迭代不是"画个更复杂的图"，而是算一笔账——日数据量 = QPS × 86400 × 条目大小；磁盘数 = QPS ÷ 单盘 IOPS；Paxos 顺序吞吐 = 1000ms ÷ 跨机房 RTT。假设不必完美，有价值的是把多个不完美但合理的估算组合起来做决策。

十、数据处理管道、配置与金丝雀发布

10.1 把管道当服务运营（Spotify 案例）

数据管道也要定 SLO：新鲜度（“99% 的数据 30 分钟内处理完”）、正确性、完整性。Spotify 的事件传递系统每天收集数千亿条事件（听歌、点广告……），用于向艺术家支付版税——可靠性是财务级要求。

flowchart LR
    A["Spotify 客户端事件"] --> B["Cloud Pub/Sub 主题<br/>（按事件类型完全隔离）"]
    B --> C["消费微服务"]
    C --> D["分区微服务<br/>分配到小时桶"]
    D --> E["Dataproc 批作业去重"]
    E --> F[("GCS 小时桶<br/>与下游的唯一接口")]

三个值得抄的设计决策：时间戳用服务器接收时间而非客户端时间（用户可以离线缓冲 30 天、可以改设备时间）；只给"财务相关"事件承诺偏度/完整性 SLO，刻意不提供数据质量 SLO——“我们是邮政服务：负责按时完整送达，包裹里的内容质量归寄件人”；容量规划留安全边际，高峰 CPU 不超 50%。

10.2 配置：最好的人机界面是"没有配置"

配置三要素哲学：理想配置是完全没有配置（系统自动识别正确值）；以用户为中心（用户说"我要热的绿茶"，而不是指定水量/温度/浸泡时间）；动态默认值（线程数默认 = CPU 核数）。任何配置变更必须满足安全三属性：逐步部署、可回滚、失控时自动回滚（想想多少人用防火墙规则把自己锁在服务器外面过）。

10.3 金丝雀发布：用小部分错误预算买安全感

术语来自煤矿里的金丝雀。核心是一笔账：一个缺陷导致 20% 请求出错，直接全量发布就是 20% 总错误率；先部署到 5% 的金丝雀集群，总错误率只有 5% × 20% = 1%。

flowchart TD
    A["新版本部署到 5% 金丝雀集群"] --> B["细分指标对比：<br/>金丝雀组 vs 对照组"]
    B --> C{"错误率/延迟显著偏离？"}
    C -- 是 --> D["暂停发布 + 回滚<br/>通知人工介入"]
    C -- 否 --> E["逐步扩大：1%→10%→50%→100%"]
    E --> F["全量发布 ✅"]
    D -.->|"修复后重来"| A

两个容易踩的坑：监控指标的聚合间隔必须小于等于金丝雀时长（30 分钟的金丝雀用"每小时错误数"评估，噪声会淹没信号）；金丝雀指标首选 SLI，且总数不要超过 12 个。

十一、人的部分：过载恢复、团队建设与组织变革

第三部分"流程"处理的是书中最"软"也最难的部分。

11.1 识别过载并恢复（第 17 章）

过载分两种：真实过载（任务量客观超支）和感知过载（沟通不足导致的主观感受）——书中强调，感知过载的实际危害和真实过载一样大，而且会传染。恶性循环是这样的：

flowchart LR
    A["运维过载"] --> B["心理压力"]
    B --> C["犯错增多"]
    C --> D["可靠性下降"]
    D --> E["更多运维工作"]
    E --> A
    B --> F["心理安全下降<br/>协作与信息共享停滞"]
    F --> G["效率更低"]
    G --> E

真实案例：Google 一个支撑 Gmail/Drive 后端的存储 SRE 团队，2016 年三分之二的成员短期相继转岗。恢复方法朴素得出奇：全队进一个房间把所有职责写上白板分类，两天时间（一天分类、一天写文档/做自动化）清理了几个月的积压；之后每两周分类一次，每人最多 10 张打开的工单，超了就有五种干预动作。另一个感知过载团队（悉尼/苏黎世两地）的恢复路线是分三档：短期先减压（圆桌吐槽会、删掉垃圾警报、“慷慨地静音”）、中期减负（把一项服务交还开发团队、补员）、长期治本（SLO 对齐、服务统一化）。约一年后匿名调查显示团队重回"高效且安全"。

11.2 SRE 怎么参与一个服务（第 18 章）

SRE 永远是稀缺资源（Google 把 SRE:开发比例控制在 1:10 左右），所以要主动选择参与模式。服务的生命周期：

flowchart LR
    A["架构与设计"] --> B["积极开发<br/>（生产化）"] --> C["有限可用 Beta<br/>GA 前必须定 SLO"] --> D["一般可用 GA<br/>通过 PRR 生产准备审查"] --> E["弃用<br/>SRE 同时运维新旧两套"] --> F["放弃<br/>运维交还开发团队"] --> G["不支持"]

两个一正一反的收场案例：Ares 团队（好聚）——反滥用团队 CAT 内部建立了具备生产知识的 Ares 小组，SRE 通过"交流计划"转移知识后体面退出，CAT 开发速度反而提升；数据分析管道（好散）——合作十年后关系恶化（旧系统到极限、沟通破裂），最终解散 SRE 团队、平稳移交，教训是"如果关系健康，本可以暂时交还再取回"。

11.3 SRE 团队生命周期（第 20 章）

从 0 到 1 的路径，三条原则贯穿：①SRE 需要有结果的 SLO；②SRE 必须有时间让明天比今天更好；③SRE 团队必须能调节自身工作量。

flowchart TD
    A["没有 SRE？<br/>先用 SLO：承认不要 100% → 定 SLO → 写错误预算政策 → 测量并执行"] --> B["招第一个 SRE<br/>考察：运维/软件工程/监控/自动化/架构"]
    B --> C["组建 SRE 团队<br/>Tuckman 模型：组建 → 震荡 → 规范 → 表现"]
    C --> D["多团队：按产品域或技术栈拆分<br/>⚠️ 警惕无人认领的组件"]
    D --> E["地理分布式<br/>时区间隔 6-8 小时最佳，避开凌晨值班"]

警告：不要在还没实践 SRE 原则之前，把"运维团队"改名成"SRE 团队"——品牌一旦失败，组织会彻底否定 SRE 这个概念。

11.4 组织变革管理：Waze 的逆袭（第 21 章）

Waze（2013 年被 Google 收购）的消息队列是全公司组件的通信命脉。吞吐量暴增后可靠性崩溃，最糟时整个 SRE 团队连续两周 24/7 救火，每小时手动重启部分组件才能维持数千万用户的服务。

变革路径（完美对应 Kotter 八步模型）：2 名 SRE + 1 名高级工程师组成"指导联盟"；评估现成产品后决定自研；招募志愿军先给占 30% 以上流量的单个组件建专用队列，挤出两个月的原型窗口；重写客户端库实现新旧系统流量切换；先迁低流量高重要性的消息流，双写提供备份路径。最终新系统承载旧系统 1000 倍以上的负载，且几乎无需人工干预。第二轮变革是部署流程：引入 Spinnaker 持续交付，如今 Waze 超过 95% 的服务持续部署，几乎无人工干预。

书里还有一条推广通用工具的朴素经验：迁移成本必须接近零（“重新编译就能用上”），收益必须明确（“现在你已经不受某某漏洞影响”），衡量推广成功的第一指标是采用率。

十二、结语：把这本书带走的五句话

没有 SLO，就不需要 SRE——先量化"什么叫足够可靠"，再谈可靠性工程。
错误预算是开发速度与稳定性的通用货币——预算充足就大胆发布，花光就冻结变更，不用吵架。
琐事不超过 50%，修根因不修症状——每小时损失多少钱，把账算给决策的人听。
缓解优先于根因，对事不对人——先把用户救回来，再写一份有 P0 行动项的事后总结。
SRE 不是 Google 专利——Home Depot 一年从 0 到 800 个服务，“如果我们能做到，您也可以。”

最后用全书结尾的祝福语收个尾：

愿你的查询流畅，愿你的传呼机保持沉默。 （May your queries flow and your pagers stay silent.）