第4章 自愈与演进：控制器调和循环

第4章 自愈与演进：控制器调和循环

章节摘要：本章跟着一条线走——orders-api 从"3 个就绪副本"的静态达标，进入"被持续守护"的动态世界。守护者是各类控制器：部署控制器盯着副本数，节点故障时补副本，版本升级时逐个换副本；StatefulSet、DaemonSet、Job 则把同一套调和循环用到有状态、节点级、一次性三类特殊负载上。

一条主线

第3章结束时声明已经完整兑现：3 个副本、3 台节点、探针把门。但如果故事到此为止，Kubernetes 只是一个"帮你起容器的工具"。它真正区别于手工运维与裸容器平台的地方，从本章才开始显现：声明的效力不是一次性的，而是持续的。你声明 3 个副本，集群就永远维持 3 个；你把镜像从 1.4.2 改成 1.5.0，集群就把旧副本逐个换成新的。维持与演进的发动机，是控制器模式。

控制器模式一句话可尽：观察现状、对比期望、采取行动、缩小差值，循环往复，永不停止。这个循环（调和循环，Reconciliation Loop）是第2章 Watch 广播的最大客户，也是本章三节的公共主角。

图 4-1：调和循环——期望与现状的永动收敛

沿途站点

本章三节，对应守护工作的三个层次：

• 4.1 调和循环：副本数守恒背后的自愈机制：拆解 Deployment 与 ReplicaSet 的分层——为什么删 Pod 反而"删不掉"、为什么节点宕机副本会自动补齐，以及水平扩缩容与自动扩缩容的分界。
• 4.2 滚动更新与回滚：声明的版本演进：把镜像从 1.4.2 改成 1.5.0 之后发生的全部事——maxSurge 与 maxUnavailable 的节奏控制、探针如何保住不中断、以及一条命令回滚的账本原理。
• 4.3 工作负载图谱：StatefulSet、DaemonSet 与 Job：同一套调和循环的三种变奏——有状态应用要稳定身份与独立存储，节点级守护要每台一份，一次性任务要跑完即退。选型对了，声明才有意义。

三节的层次感：4.1 是机制本体，4.2 是机制在版本演进上的应用，4.3 是机制在不同负载形态上的变体。理解了 4.1，后两节的所有现象都可以自行推导。

拐点与结论

本章有两个认知拐点。其一在 4.1：删除 Pod 不是破坏，而是给控制器制造一次差值——你删得越勤，它补得越快，想让副本真正消失只能改声明本身。其二在 4.2：滚动更新的安全性不是调度器或 kubelet 给的，而是 3.4 节的 readiness 探针给的——新副本过不了体检就不进流量名单，升级节奏由声明里的两个参数精确控制。

结论一句话：控制器把"维持"变成了一种服务。你不再守护进程，你守护声明；守护声明的成本是一份 YAML，守护进程的成本是一个随机器数量线性膨胀的值班表。

读完你应该

• 画出调和循环的四步，并解释每一步的数据来源（期望读账本、现状靠 Watch 与上报）；
• 说明 Deployment、ReplicaSet、Pod 三层的分工与"删不掉的 Pod"现象的机制；
• 演示一次手动扩缩容与缩容的完整过程，并指出 HPA 接管的前提指标；
• 写出带 maxSurge 与 maxUnavailable 的滚动更新声明，并解释参数与容量风险的关系；
• 完成一次升级与回滚，说清旧 ReplicaSet 为什么被保留；
• 为数据库、日志代理、批处理任务分别选出正确的工作负载类型并说明理由。

下一章的接力

副本守住了、版本演进有了章法，但 Pod 的 IP 每次重建都在变——外部世界拿什么地址访问订单服务？第5章把镜头拉到流量入口：Service 用一个稳定虚拟 IP 罩住一组 Pod，Ingress 在七层之上做域名与路径的分发，NetworkPolicy 则给这套流量体系立规矩。