Kubernetes 是一个把「大量机器 + 容器 + 网络 + 存储」统一抽象成“操作系统”的工程实现。
它解决的不是“怎么跑一个程序”，而是：
当程序规模失控之后，系统还能不能被人类管理。
一、Kubernetes 的问题边界
在 Kubernetes 出现之前，工程世界面临一个非常现实的问题：
- Docker 解决了 “怎么打包和运行应用”
- 但没解决：
- 跑在哪台机器？
- 挂了怎么办？
- 怎么扩容？
- 多个服务怎么通信？
- 更新时怎么不中断？
当系统规模从：
- 1 台 → 10 台 → 100 台 → 1000 台
“SSH + 脚本 + 人肉运维”彻底失效。
Kubernetes 的边界很清晰：
它不关心你的业务逻辑，只关心系统是否始终处在“你声明的状态”。
二、声明式系统：Kubernetes 的工程核心
Kubernetes 的设计思想，本质上只有一句话：
你描述“目标状态”，系统负责不断逼近它。
例如：
replicas: 3这不是一个命令，而是一条约束条件。
- 如果现在只有 2 个 → 补 1 个
- 如果有 5 个 → 杀 2 个
- 如果节点挂了 → 迁移
这和传统脚本式运维的区别在于：
| 传统方式 | Kubernetes |
|---|---|
| 人决定每一步 | 人只声明结果 |
| 一次性动作 | 持续收敛 |
| 成功即结束 | 永远在对齐 |
从工程角度看，Kubernetes 更像是一个“约束求解系统”。
三、从架构看：一个典型的大型分布式系统
如果你把 Kubernetes 当成“工具”，会用得很浅；
但如果你把它当成 分布式系统样本，价值会非常高。
核心组件非常“教科书级”：
1. API Server：唯一真相源（Single Source of Truth）
- 所有状态写入这里
- etcd 是底层存储
- 所有组件 只能通过 API 通信
这是典型的 中心化状态 + 去中心化执行
2. Scheduler：约束下的最优解搜索
Scheduler 的工作不是“随便找台机器”，而是：
- 过滤（资源 / 亲和性 / 污点）
- 打分（负载 / 均衡 / 策略）
- 选择最优节点
这本质上是一个 受限优化问题。
3. Controller：持续对齐世界
Controller 的逻辑非常朴素：
观察状态 → 对比期望 → 执行动作 → 再观察但工程价值极高，因为它带来：
- 自动修复
- 状态自愈
- 系统稳定性
👉 很多工程师第一次真正理解 “控制论”，就是在这里。
4. Kubelet：执行层代理
- 跑在每个节点上
- 把“抽象状态”翻译成“真实容器操作”
- 是控制平面和物理世界的接口
四、为什么 Kubernetes 源码这么“重”
很多人第一次看源码会困惑：
为什么这么多代码？这么多抽象？
原因不是“过度设计”，而是：
- 需要支持 插件化
- 需要支持 云厂商差异
- 需要支持 向后兼容
- 需要支持 规模化演进
Kubernetes 的工程取舍是：
复杂性集中在平台层，释放业务层。
这是一个非常成熟、也非常昂贵的工程决策。
五、不是框架，是基础设施
在工程生态中的位置：
- Docker：运行时
- Kubernetes：平台内核
- Helm / Operator：生态层
- 云厂商：托管与集成
Kubernetes 已经不是“选型问题”，而是“是否参与现代工程体系”的问题。
Github：https://github.com/kubernetes/kubernetes
油管：https://youtu.be/ZF1l65YyMEc
