2025：Kubernetes 进入现实主义阶段

云计算技术在跌跌撞撞中走过来许多年，2025是我在云计算领域的第六年，如果说2019年对k8s的印象还是如婴儿般稚嫩，但潜力巨大，那2025年的k8s就已经是一个成熟的青年了。这是云计算领域相关技术变化年度总结的三篇中的第一篇。本人不是专精云计算的专家，纯属一家之言、个人见解。这里只是抛砖引玉。

如果你在 2025 年回头看 Kubernetes，会发现一件有点反直觉的事：

这一年，几乎没有“大新闻”。

没有革命性 API，
没有推翻式架构，
没有“下一个 Kubernetes”。

但这恰恰说明了一件事：

Kubernetes 已经不再需要证明自己了。

就像 Linux 内核一样，当它变得“安静”，说明它已经进入了基础设施阶段。

---

一、为什么“没变化”，反而是最大变化？

对比一下历史节奏会更明显：

• 2017–2019：功能爆发期

  • CRD（自定义资源）成为万能扩展口
  • Operator 模式被神话

• 2020–2022：平台工程狂飙期

  • 人人都在“封装 Kubernetes”
  • 内部平台比业务还复杂

• 2023–2024：反思期

  • 成本、维护、人力开始失控

而 2025 年（Kubernetes 1.29 → 1.31） 的主旋律是：

• API 几乎不动
• 核心行为高度稳定
• 升级风险显著降低

打个比方：
Kubernetes 从“高速迭代的创业产品”，变成了“不允许随便出事故的电力系统”。

---

二、平台工程：从“造中台”到“做减法”

发生了什么？

2024 年之前，平台工程的常见画面是：

• 一个团队维护几十个 CRD
• 内部平台 UI 比公有云控制台还复杂
• 新同事 onboarding 要一周

到 2025 年，很多公司在做的事反而是：

• 合并 CRD
• 删除“没人敢动”的平台模块
• 直接迁移到托管 K8s（EKS / GKE / ACK）

为什么会这样？

核心原因很现实：

1. Kubernetes API 在 1.25 之后已经非常稳定
   再包一层，收益极低

2. 托管服务“足够好”

   • 控制面 SLA
   • 自动升级
   • 内建安全基线

3. 平台工程的长期成本暴露了

   • 维护人力
   • 文档债
   • 知识孤岛

一个形象的比喻是：

早期平台工程像“自己修路很酷”，
2025 年大家发现：
国家高速公路已经修好了，自己维护乡道反而更贵。

---

三、Kubernetes 与 AI：像“机房地板”，不是“计算引擎”

2025 年所有云计算话题，几乎都会绕到 AI。
但 Kubernetes 在 AI 系统中的位置，常被高估。

AI 真正“难”的地方不在 K8s

AI 训练 / 推理的关键瓶颈是：

• GPU 直通（PCIe / SR-IOV）
• 拓扑感知调度（NUMA、NVLink）
• 高吞吐网络
• 大规模 Checkpoint 存储

这些问题，Kubernetes 只能“配合”，不能“解决”。

Kubernetes 实际在干什么？

在 2025 年，K8s 更多扮演的是：

• 作业生命周期管理器
• 资源申请入口
• 失败重试与自动恢复框架

生态变化也很明显：

• Kubeflow：从“全家桶”变成“选用组件”
• KubeRay：强调工程落地，而非学术完整性
• GPU Operator：成为事实标准组件

可以把 Kubernetes 类比为：

AI 数据中心里的“地板”和“配电箱”，
没它不行，但没人指望它负责算力本身。

---

四、多集群：不再讨论“要不要”，而是“怎么管”

早期误区

早期多集群讨论常常是哲学问题：

• 一个大集群行不行？
• 多集群是不是过度设计？

2025 年，这些问题已经没意义了。

现实结论

只要满足其中任一条件，多集群几乎是必然选择：

• 多地域
• 多团队
• 多合规域
• AI + 普通业务混跑

因此焦点转向了治理问题：

• 集群作为最小隔离单元
• GitOps 成为唯一可信变更入口
• Policy 比调度策略更重要

工具层面也趋于稳定：

• Argo CD / Flux 成为“默认答案”
• 很少有人再自研多集群控制面

类比一句话：

多集群就像公司分部门，
问题不在分不分，而在财务和流程是不是统一。

---

五、YAML：没有被解决，但被“接受”了

很多人讨厌 Kubernetes，其实是在讨厌 YAML。

2025 年的变化不是“消灭 YAML”，而是停止幻想。

共识正在形成

• YAML 本质是接口定义，不是开发体验
• 问题在于“过度暴露内部细节”
• 好的平台不是隐藏 YAML，而是限制 YAML 能做什么

因此你会看到：

• Helm 还在，但不再是万能方案
• 更多团队明确 API Contract
• 应用开发者只接触少量受控配置

比喻一下：

YAML 像 SQL，
不好写，但你不希望它被完全藏起来。

---

六、Kubernetes 本身：终于像“操作系统内核”

从 Kubernetes 1.28 之后，几个趋势非常明显：

• 破坏性变更极少
• Feature Gate 收敛
• 文档和行为一致性显著提升
• 升级更像“例行维护”，而非“手术”

这说明 Kubernetes 已经进入了和 Linux 类似的阶段：

不追求惊喜，只追求可靠。

---

七、2025 年的一个清晰结论

Kubernetes 在 2025 年完成了一次角色转变：

• 从“我能做什么”
• 变成了“我不该做什么”

它不再是工程师展示创造力的舞台，
而是系统稳定性的前提条件。

当一个技术开始要求克制，而不是想象力，
说明它已经成功了。

---

参考资料（建议保留）

• Kubernetes 官方文档（1.29–1.31）
  https://kubernetes.io/docs/

• CNCF Annual Survey 2024 / 2025
  https://www.cncf.io/reports/

• CNCF Technology Radar
  https://radar.cncf.io/

• Kubeflow 官方文档
  https://www.kubeflow.org/docs/

• Argo CD 官方文档
  https://argo-cd.readthedocs.io/