7.2 Kubernetes：声明状态与控制循环

Kubernetes 的核心不是 YAML，而是 reconciliation：把 API 中声明的期望状态与集群当前状态持续比较并收敛。

控制面与节点

kubectl/client → API Server → etcd
                    │
          ┌─────────┴─────────┐
       Scheduler          Controllers
                              │
                         Kubelet on Node

• API Server 是资源操作和认证授权入口；
• etcd 保存控制面状态；
• Scheduler 为未绑定 Pod 选择节点；
• Controller 创建/删除对象使状态收敛；
• Kubelet 让节点上的 Pod 接近声明规格。

控制器按观察到的状态工作，操作需要幂等并容忍缓存延迟。一次 API 成功不表示所有资源已经收敛。

Pod 是调度和共享边界

一个 Pod 内的容器共享网络 namespace 和 volume 生命周期，通常一起调度和终止。只有生命周期和资源命运确实绑定的辅助进程才放同一 Pod。

Pod 是可替换实例，不是永久服务器。不要依赖 Pod 名称、IP 或本地磁盘长期稳定。

Deployment 管理无状态副本

Deployment 通过 ReplicaSet 维持副本，并执行滚动更新。发布期间新旧版本并存，API、消息和数据库必须兼容。

maxUnavailable、maxSurge、readiness 和终止排空共同决定实际可用容量。只设置 replicas: 3 不能证明故障或发布时仍有 3 个可服务实例。

Service 提供稳定发现

Service 用 selector/EndpointSlice 关联 ready 后端，为调用方提供稳定虚拟地址和 DNS 名。Service 不保证应用成功，也不替代 deadline、重试和业务负载均衡。

无 selector、ExternalName、headless Service 等具有不同发现语义，应按真实协议选择。

三类 Probe 不可混用

• startupProbe：应用是否完成慢启动；通过前可抑制其他探针；
• readinessProbe：当前是否应该接流量；失败不一定重启；
• livenessProbe：进程是否陷入只能重启恢复的状态。

把下游数据库短暂失败放进 liveness，可能让全部副本同时重启。探针要轻量、快速、有超时，不能成为新的高成本业务请求。

Requests、Limits 与调度

Scheduler 主要根据 requests 放置 Pod；limits 由运行时限制。requests 过低会过度装箱并在高峰争抢，过高会浪费容量或导致 Pending。

应用先通过负载测试得到每副本容量曲线，再配置资源和副本。CPU HPA 目标基于 requests 时，错误 requests 会让扩缩行为失真。

HPA 不是瞬时救火

扩容包含指标延迟、控制器决策、调度、拉镜像、启动和 readiness。突发流量可能在新副本可用前耗尽旧副本，因此仍需队列、并发限制、负载削减和预留容量。

缩容要设置稳定窗口，并让长任务可排空或迁移。对队列消费者，积压、处理速率和最老消息年龄通常比 CPU 更接近业务需求。

第 11 章会继续讲 NetworkPolicy、StatefulSet、存储与多租户生产治理。

参考资料

• Kubernetes, Kubernetes Components
• Kubernetes, Pods
• Kubernetes, Deployments
• Kubernetes, Horizontal Pod Autoscaling