Part IV · 分布式系统 · 第 11 章
11

编排：Kubernetes 与控制循环

Kubernetes 不只是“跑容器的工具”。它是一台把期望状态不断拉回现实状态的分布式控制机器。

难度 云原生核心 用时 约 60 分钟 交互 调和循环动画 · 声明式取舍 路线 螺旋式：先抓大图，再深入机制

0先把地图摊开

Kubernetes 不只是“跑容器的工具”。它是一台把期望状态不断拉回现实状态的分布式控制机器。 本章不会把概念排成术语表，而是沿着一条真实系统路径走：先看它解决什么痛点，再看 OS/云平台怎样实现，最后回到工程取舍。

声明式 API你描述想要什么，而不是逐步命令系统怎么做。
控制循环不断观察现实与期望差距，并采取动作缩小差距。
PodKubernetes 最小调度单位，包住一个或多个容器。
Controller负责某类资源调和的控制器，如 Deployment controller。
编排：Kubernetes · 核心流程 分步动画 点击节点或用键盘 ← →
图 11.1核心机制路径。把这一章最容易散掉的流程压成可播放的五步。

11.1Kubernetes 的灵魂是调和

你提交一个 Deployment，说“我要 3 个副本”。系统不是执行一次命令就结束，而是持续观察：如果只剩 2 个，就补；如果有 4 个，就删；如果节点挂了，就迁。

11.2API server 是全局事实入口

所有组件通过 API server 读写期望状态和集群状态。etcd 保存强一致元数据。控制面不是一堆脚本，而是围绕 API 对象运转的分布式系统。

11.3Scheduler 只做绑定，不保证永远正确

调度器为未绑定 Pod 选择节点。之后节点坏了、资源变了，是其他 controller 和 kubelet 继续调和。K8s 的优雅来自职责切分。

11.4Service 稳定了不稳定的 Pod

Pod 会被杀、替换、迁移，IP 也会变。Service 给一组 Pod 一个稳定入口，背后通过 label selector 和 kube-proxy/IPVS/iptables 把流量导过去。

11.5声明式系统适合自动化，也要求你尊重状态

手动改线上机器是命令式冲动；K8s 会把它拉回声明状态。GitOps、operator、自愈都建立在同一个控制循环之上。

编排：Kubernetes · 取舍实验 可玩模拟器 切换策略，看指标怎么变
图 11.2工程取舍。云和 OS 的概念真正进入工程时，几乎都不是“选最好”，而是在约束之间找一个诚实的点。

↔云与 OS 的桥

这一章不是孤立知识点。下面这张表把它和前后章节接起来：你会看到，同一个机制在单机、云平台和 AI 基建里会换名字，但问题结构没变。

本章机制云上形态为什么重要
etcd/共识API server 状态存储上一章的强一致日志支撑控制面的事实来源。
Pod/Service容器与网络抽象第 7、8 章的机制在这里组合成部署单位。
控制循环Autoscaler、operator、云控制面现代云平台几乎都是控制循环堆出来的。
深潜 读完本章后，怎么确认自己真的懂了？›

不要只背定义。你应该能把一个线上现象翻译回机制：慢在哪里、谁在排队、哪个抽象漏了、哪个资源被过度承诺。下面三个检查点可以当成小作业。

本章收束 · 你现在握住了什么

  • Kubernetes 是围绕声明式 API 运转的控制系统。
  • 控制循环不断比较期望状态和现实状态，并采取动作。
  • Pod 会变，Service 提供稳定入口。
  • Operator 把领域运维知识变成可运行的调和逻辑。

有了编排系统，下一步是让它在负载变化和故障面前保持体验：伸缩、重试、背压和韧性。