K8s 系统研发从 0 到 1 · 目录与导读
用「如果让你从零设计一个容器编排系统」的视角，重走 Kubernetes 的设计之路。 每一章不告诉你「K8s 怎么用」，而是告诉你「当年那个设计决策，有哪几条路、各自代价是什么、为什么最后选了这条」。
一、这个教程在讲什么
一句话结论：Kubernetes 的精华，不在 kubectl 命令，而在它背后那一套用 Go 写的分布式系统设计思想——声明式 API、控制器模式、etcd 一致性、调度、网络、扩展机制。这些东西是「用 Go 造系统」的顶级教材，正好接得上你「自己造 ES、给行业提供方案」的目标。
我们会一起做一件事：假设你手里什么都没有，只有一堆跑着容器的机器，怎么一步步把它们变成一个能自愈、能扩展、能让人放心交托业务负载的编排系统。
二、K8s 的「身世」：先搞清它从哪来
K8s 不是凭空设计的，它有一个重要的血统——Google 的 Borg（内部大规模容器管理系统）。理解这个身世，很多设计决策就「为什么」了：
- Borg 管理 Google 数十万台机器、上百万容器，跑了十几年。
- K8s 是 Borg 的经验「开源化 + 通用化」的产物，创始团队很多就是 Borg 的人。
- 所以 K8s 的设计处处透着「在大规模、真实生产环境里被验证过」的克制——它不追新，它求稳。
记住这句话：K8s 的很多「看起来保守」的设计，是因为它在为「几万台机器、几百万容器、十几年运行」这种尺度做设计，而不是为「本地跑个 demo」做设计。 读它的时候，时刻问自己：这个设计在 10 万台机器上还成立吗？
三、版本现状（截至 2026-10，写教程时）
| 版本 | 代号 | 发布 | 状态 | EOL |
|---|---|---|---|---|
| 1.37 | Garhwal | 2026-08-26 | 最新稳定 | 2027-10-28 |
| 1.36 | Haru | 2026-04-22 | 稳定 | 2027-06-28 |
| 1.35 | Timbernetes | 2025-12-17 | 稳定 | 2027-02-28 |
| 1.34 | O’ WaW | 2025-08 | 维护模式（仅安全修复） | 2026-10-27 |
| 1.38 | — | 计划 2026-12-16 | 开发中 | — |
- 节奏：每 4 个月一个 minor 版本，一年 3 个；N-2 支持策略（只维护最近 3 个 minor）。
- 本教程的「最新版功能」部分（第 10 章）聚焦 1.35 → 1.37 这条演进主线。
四、章节地图
| 章 | 主题 | 核心问题 |
|---|---|---|
| 01 | 为什么需要编排系统 | 单机容器到多机，问题是怎么「长」出来的 |
| 02 | 声明式 API | 命令式 vs 声明式，K8s 的第一性原理 |
| 03 | 控制器模式与调谐循环 | 谁把「期望状态」变成「实际状态」 |
| 04 | etcd 与一致性 | 状态存哪？怎么让所有控制器看到一致状态 |
| 05 | 资源模型：为什么是 Pod | 最小调度单元怎么定，抽象怎么分层 |
| 06 | 调度器 | 「把 Pod 放哪」这个 NP-hard 问题怎么工程化 |
| 07 | 网络：Service 与 kube-proxy | 扁平网络，以及 ipvs 被弃用的故事 |
| 08 | 扩展：CRD / Operator | 把 K8s 从「平台」变成「你的平台」 |
| 09 | 插件化：CRI / CNI / CSI | 为什么要用接口把核心拆开 |
| 10 | 演进到最新版（1.35→1.37） | 原地扩容、Pod 级资源、gang scheduling…为什么要加 |
| 11 | 可复用的分布式系统设计清单 | 所有决策点收拢成一张表 + Go 落点 |
演进篇（第 12~17 章）：组件级演进史
第 1~9 章讲「实现原理」（每个组件现在是怎么设计的），演进篇讲「演进过程」（每个组件当年是什么样、踩了什么坑、为什么改方案、怎么一步步变成今天这样）。每个组件一章，聚焦「遇到问题 → 升级改方案」的完整过程。
| 章 | 组件 | 演进主线 |
|---|---|---|
| 12 | 演进总览 | 从 1.0 到 1.37 的十年时间线，三次「搬家」 |
| 13 | 调度器 | 从「写死的谓词/优先级」到「插件框架」 |
| 14 | 存储 | 从「手动建卷」到「PV/PVC → StorageClass → CSI 外置」 |
| 15 | API 版本 | 从「extensions/v1beta1 临时堆」到「分组 + 分级 + 弃用政策」 |
| 16 | 网络（服务暴露） | 从「Service 三类型」到「Ingress → Gateway API」 |
| 17 | 运行时与云提供商 | 从「内嵌 Docker/云代码」到「CRI + cloud-provider 外置」 |
问题链篇（第 18 章）：一条因果线串起全书
前两篇是「组件视角」（这个组件是什么、怎么变），问题链篇换成「因果视角」——把 K8s 十年拉成一条线：每一步都是「遇到什么问题 → 才逼出什么功能或改法 → 这个解决又埋下什么新问题」。这条线是「从 0 到 1 再到现在」的完整叙事，也是全书三种视角的收束。
| 章 | 主题 | 核心问题 |
|---|---|---|
| 18 | 问题链 | 一条因果线看 K8s 的诞生与演化（四圈推进 + 两个驱动源 + 三类形态） |
五、阅读建议
- 按顺序读。第 02 章的「声明式」是后面一切设计的地基，跳过它，后面的「控制器」「etcd」「Operator」都会失去支撑。
- 伪代码是 Go 风格。K8s 本身就是 Go 写的，所以这次伪代码直接用 Go 语法——对你不是负担，反而是「这套思想在 Go 里怎么落地」的直接示范。
- 每章有「思考的分叉」和「思考题 + 参考答案」。参考答案是「一种站得住的推导」，欢迎反驳——反驳本身就是在建立你的系统判断。
- 关键决策点有「思维流重放」。在第 02、03、05、13、14、16 章，除了「结论 + 论证」，还各有一段「如果我是当年的设计者」的第一人称重放——带你从直觉出发，经历试错、卡壳、反转，一步步走到结论。「论证」告诉你答案为什么对，「重放」告诉你答案是怎么想出来的，后者才是能迁移到你系统里的思考能力。
- 重点盯「为什么」而不是「是什么」。K8s 的命令查文档就有，但「为什么这么设计」才是能迁移到你自己系统里的硬通货。
六、几个贯穿全文的约定
- 「编排」的定义：跨多台机器，自动地「调度 + 自愈 + 扩缩容 + 服务发现 + 滚动更新」一组容器，而不是单机
docker run。 - 「声明式」的定义（先埋个钩子，第 02 章展开）：你描述「我要什么状态」，系统自己负责「怎么达到这个状态」——和「命令式」（你一步步指挥系统做什么）相对。
- 案例来源：真实的设计决策、KEP（Kubernetes Enhancement Proposal，K8s 的「RFC」）、以及 release note / issue 里能考证到的事实。
准备好了吗？我们从最朴素的问题开始：一台机器跑容器已经很好用了，为什么还需要「编排」这种东西？