Kubernetes 的发展历程是从 Google 内部集群管理系统 Borg 和 Omega 演进而来，2014 年开源后迅速成为容器编排的事实标准，其设计思想核心在于声明式 API 与控制平面和工作节点的解耦。
先说结论：Kubernetes 是云原生时代的操作系统，适合需要大规模容器自动化管理、高可用及弹性伸缩的场景。
- 适合：公有云、私有云及混合云环境下的微服务架构管理
- 重点看：声明式配置、自我修复机制及可扩展的 CRD 能力
- 别忽略：CNCF 社区生态对版本迭代和功能标准化的影响
快速处理思路
理解 Kubernetes 的发展与设计，建议按时间线梳理关键节点，并对照核心组件映射其设计意图：
- 2014 年 6 月：项目首次代码提交并宣布开源，基于 Borg 经验
- 2015 年 7 月：v1.0 发布，同日 CNCF 成立，Kubernetes 成为首个孵化项目
- 2018 年：成为 CNCF 毕业项目，生态趋于成熟
- 设计映射：Master 节点对应控制平面，Node 节点对应工作负载，中间通过 API 解耦
为什么会这样
Kubernetes 的设计并非凭空产生，而是继承了 Google 内部系统的经验教训。Borg 系统虽然强大但架构单体化，扩展性受限；Omega 系统引入了基于事务的共享状态存储和分离的调度器，提升了灵活性。Kubernetes 吸收了 Omega 的松耦合架构，将调度器从单体中分离，允许多个控制器并行工作。同时，它采用了声明式 API，用户只需描述期望状态，系统自动维护实际状态与期望状态一致，这降低了运维复杂度并实现了自我修复。
分步处理
若要深入理解其设计思想，可按以下步骤拆解架构：
- 识别控制平面组件：确认 kube-apiserver 作为唯一入口，etcd 存储集群状态，kube-scheduler 负责调度，kube-controller-manager 运行控制器逻辑。
- 识别工作节点组件：确认 kubelet 管理节点上的容器生命周期，kube-proxy 处理网络代理和负载均衡。
- 理解交互流程：观察用户通过 API 提交配置后，控制器如何监听状态变化并调用调度器分配资源，最终由 kubelet 执行容器启动。
- 查看扩展能力：了解 CustomResourceDefinitions (CRD) 如何允许用户定义任意类型的资源，这是平台可扩展性的关键。
怎么验证是否生效
验证对架构和设计思想的理解，可以通过以下方式确认：
- 组件检查：在集群中运行
kubectl get componentstatuses（旧版本）或检查核心 Pod 状态，确认控制平面组件健康。 - 状态验证：修改 Deployment 副本数，观察系统是否自动创建或删除 Pod 以匹配期望值，验证声明式逻辑。
- 故障模拟：手动删除一个 Pod，观察控制器是否自动重建新 Pod，验证自我修复能力。
- 日志分析：查看 kube-apiserver 或 kubelet 日志，确认请求处理和状态同步流程是否符合预期。
常见坑
- 混淆 Borg 与 K8s：Borg 是 Google 内部系统，未直接开源，Kubernetes 是其思想继承者而非代码复刻。
- 忽视版本差异：早期版本功能有限，如 CRD 在 v1.16 才正式发布，查阅资料时需注意版本上下文。
- 过度依赖托管服务：云厂商托管服务屏蔽了部分底层细节，学习设计思想时建议尝试自建集群以理解组件交互。
- 误以为全能：Kubernetes 擅长在线业务调度，对于特定 AI 训练作业或高性能计算场景，可能需要额外插件或定制。
参考来源
- Kubernetes——引言 (2)
- kubernetes
- Kubernetes 系列 (1) 从设计理念说起
- Kubernetes
- Kubernetes 前世今生 ( 附学习导图 )
- 颠覆 IT 世界的 20 万行代码:Kubernetes 的前世今生 (文末有彩蛋)
- 概述
- 网络工程师想学习 Kubernetes(K8s)?好好梭哈本文就足够了！-云社区 - 华为云