声明式API的控制回路思想及为何取代命令式交互

Kubernetes除了[[Kubernetes五层资源模型及各自对应的最小管理单位]]描述的 资源模型外，第二个核心设计理念是控制器模式，源自工业控制系统里成熟的 “控制回路”（Control Loop）思想。Kubernetes官方用空调调温类比：设定的 温度是”期望状态”（Desired State），传感器测出的房间实际温度是”当前 状态”（Current State），控制器根据两者差距去调节空调的制冷开关，让 当前状态逐渐逼近期望状态。搬到容器编排上，就是给每种资源都附加”期望 状态”和”实际状态”两个属性，用户不再像普通编程那样调用某个方法去”命令” 系统做什么，而是描述清楚资源应该达到的期望状态，交给对应的控制器持续 监视、驱动实际状态向期望状态靠拢——这就是声明式API，日常在元数据文件 里写的spec字段描述的正是期望状态。这也解释了为什么早期提供的 kubectl rolling-update命令式操作会被淘汰：它要求用户直接指挥Kubernetes “具体该怎么做”，这与”只说清楚要什么、不管怎么做到”的设计理念相悖（书中 调侃这也是它”不好用”的真正原因）。取而代之的是Deployment资源+部署控制器： 用户只需更新Deployment里的期望状态（比如换个镜像版本），部署控制器就会 自动创建新的ReplicaSet、逐步缩减旧ReplicaSet，直至完成滚动更新——声明 “要什么”，交给控制器持续追踪”怎么做到”，这个分工正是声明式API相比命令式 交互的核心优势。