ReplicaSet-Deployment-Autoscaling三层控制器叠加实现韧性与弹性

[[声明式API的控制回路思想及为何取代命令式交互]]落到具体能力上，是靠三层 控制器逐级叠加实现的。ReplicaSet（副本集）在元数据里声明期望的Pod副本 数量，副本集控制器持续追踪：Pod崩溃退出或状态异常（可靠默认的进程返回值 或自定义探针判定）就自动创建新Pod替补，多出的Pod也会被回收——单靠 ReplicaSet就能满足”故障自动恢复”这一项能力，但它无法优雅处理版本升级 （只能先中断旧Pod再建新Pod，服务会中断）。Deployment在ReplicaSet之上 再加一层：更新Deployment里的镜像版本信息后，部署控制器会自动创建新版本 的ReplicaSet，让新ReplicaSet逐步创建新Pod副本，同时让旧ReplicaSet逐渐 缩减旧Pod副本，直至完全替换——这就是滚动更新，不中断服务。Autoscaling （自动扩缩控制器）再叠一层：根据处理器/内存占用率或自定义度量指标， 自动调整Deployment（或ReplicaSet）的期望副本数，免去人工凭经验估算 扩容数量的不精确和滞后。三层组合起来，度量指标变化会按”Autoscaling→ Deployment→ReplicaSet→Pod”的顺序层层传导，最终实现”故障自动恢复+滚动 更新不中断+压力自动扩缩”这三种通用的分布式系统韧性弹性能力——理解这 三层控制器为什么这样分层、各自解决了上一层解决不了的哪个具体问题，比 死记它们的YAML配置语法更重要。

结构图：

flowchart TD
    A[Autoscaling控制器] -->|按度量指标调整期望副本数| B[Deployment控制器]
    B -->|滚动创建新ReplicaSet, 缩减旧ReplicaSet| C[ReplicaSet控制器]
    C -->|Pod崩溃/异常时自动补齐| D[Pod]
    C -.只能解决故障恢复, 升级会中断服务.-> B
    B -.只能滚动更新, 无法感知压力.-> A