Kubernetes 2.0 畅想：告别 YAML、etcd 束缚与 Helm 之痛，K8s 的下一站是什么？
本文永久链接 – https://tonybai.com/2025/06/21/kubernetes-2-0
大家好，我是Tony Bai。
自 2014 年首次提交以来，Kubernetes 已走过辉煌的十年。它从一个“没人能念对名字”的希腊词汇，成长为容器编排领域无可争议的事实标准，深刻地改变了我们构建、部署和管理应用的方式。我们不再满足于在服务器层面“管理基础设施”，一切都变得声明式、可扩展、可恢复，甚至（如果你足够幸运的话）能够自我修复。
然而，正如任何伟大的技术旅程一样，Kubernetes 的发展也并非一帆风顺。尽管它带来了巨大的生产力提升，但其陡峭的学习曲线、某些领域“不够固执己见 (not opinionated enough)”导致的常见错误和配置失误、以及生态系统中持续的“变动”，仍然让许多开发者和运维者“痛并快乐着”。我们依然会踩到那些文档早已记录的“地雷”。
站在十年的重要节点，回望过去，展望未来，一个有趣的问题自然而然地浮现：如果我们有机会基于今天的认知和经验，重新构想一个 Kubernetes 2.0，它会是什么样子？我们能做哪些改变，让这个伟大的工具更普惠、更强大、更易用？
最近，一篇题为《What Would a Kubernetes 2.0 Look Like》的博文，就针对这个问题提出了一系列大胆而深刻的畅想，直指当前 K8s 生态中的核心痛点。今天，我们就来一起探讨这些引人深思的观点。
注：本文观点主要源自上述博文，并结合我个人的一些思考，希望能为大家带来启发。
Kubernetes 的十年功与过：为何我们需要畅想“2.0”？
在畅想未来之前，我们必须承认 Kubernetes 取得的巨大成功。它之所以能成为云原生时代的基石，离不开其核心价值：
- 大规模容器化： 将容器从本地开发环境无缝推向数千台服务器的生产集群，赋予了组织前所未有的灵活性，催生了微服务架构的繁荣。
- 低维护性： 推动了基础设施从“宠物 (Pets)”到“牛群 (Cattle)”再到“UUID时代”的演进。服务器变得完全可替代，运维模式从手动修复转向“销毁节点，让K8s重组”。
- 改进的作业系统： 提供了比传统“孤岛式 cron01 服务器”更可靠、更灵活的批处理作业和消息队列任务执行方案。
- 简化的服务发现与负载均衡： 通过 Service API 提供了稳定的内部 DNS 和 IP，极大地简化了服务间的调用和依赖管理。
然而，正如文章作者所言，“旅程并非没有问题”。“默认值是技术中最强大的力量 (defaults are the most powerful force in technology)”，而 Kubernetes 在某些方面的“默认”或“缺失”，恰恰是许多痛点的根源。 这正是我们畅想“K8s 2.0”的出发点——通过设定更优的“快乐路径 (happy path)”，提升整个生态的健康度和用户体验。
畅想一：抛弃 YAML，拥抱 HCL——配置语言的救赎？
“YAML 之所以吸引人，是因为它既不是 JSON 也不是 XML，这就像说你的新车很棒，因为它既不是马也不是独轮车一样。” 文章作者对 YAML 的这句犀利点评，道出了许多 K8s 用户的心声。
YAML最初凭借其看似简洁的格式在 Kubernetes 中胜出，但其在实践中暴露的问题也日益突出：
- 模糊性与易错性： 缩进敏感、类型不明确（著名的“挪威问题”——NO 被解析为布尔值 false）、缺乏引用的数字可能被误解等。
- 难以扩展和调试： 超长的 YAML 文件令人望而生畏，调试错误往往如同大海捞针。
- 表达能力不足： 缺乏内置的变量、函数、条件逻辑等，导致大量依赖外部模板工具（如 Helm templates, Kustomize）。
文章大胆提议，Kubernetes 2.0 应该用 HCL (HashiCorp Configuration Language) 替换 YAML。 HCL 作为 Terraform 的配置语言，早已被广大云原生开发者所熟悉。其核心优势在于：
- 强类型与显式类型： 从源头上避免了 YAML 的许多类型相关错误。
- 内置变量、引用、函数和表达式： 能够动态生成配置，减少重复，提高可维护性。
- 条件逻辑与循环： 支持更灵活的环境特定配置和重复性配置的简化。
- 更好的注释、错误处理和模块化能力。
作者通过对比简单的 YAML 和 HCL 示例，直观地展示了 HCL 在类型安全和动态配置生成方面的优越性：
# YAML doesn't enforce types
replicas: "3" # String instead of integer
resources:
limits:
memory: 512 # Missing unit suffix
requests:
cpu: 0.5m # Typo in CPU unit (should be 500m)
vs.
# HCL
replicas = 3 # Explicitly an integer
resources {
limits {
memory = "512Mi" # String for memory values
}
requests {
cpu = 0.5 # Number for CPU values
}
}
尽管 HCL 可能略显冗长，且其 MPL-2.0 许可证与 K8s 的 Apache 2.0 许可证的整合需要法律审查，但作者认为，为了大幅改善配置体验，这些障碍值得克服。
畅想二：开放后端存储，etcd 不再是唯一选择——灵活性的追求
etcd 作为 Kubernetes 集群状态的权威存储，一直以来都扮演着至关重要的角色。然而，文章指出，etcd 作为唯一的默认后端存储，也带来了一些局限：
- 资源消耗： 对于小型集群或资源受限的边缘环境，etcd 可能显得过于“庞大”和资源密集。
- “强绑定”关系： Kubernetes 几乎是 etcd 现存唯一的“大客户”，这种高度绑定可能不利于双方的独立发展和技术选择的灵活性。
因此，文章建议 Kubernetes 2.0 应该官方化 kine (k3s-io/kine) 等项目的工作，提供可插拔的后端存储抽象层。 这将允许：
- 根据硬件和集群规模选择更合适的后端： 例如，对于小型或边缘集群，可以使用像 dqlite (基于 Raft 的分布式 SQLite) 这样的轻量级方案，它们资源占用小，升级维护可能更简单。
- 促进存储技术的创新与竞争： 开放后端接口，可以鼓励更多针对 K8s 优化的存储方案涌现。
- 降低对单一项目的依赖。
此外，Go 语言在构建分布式一致性存储方面拥有优秀的库（如 hashicorp/raft，etcd 本身也是 Go 编写的）。这些技术积累能否为 Kubernetes 构建更灵活、更高效的可插拔存储后端提供更多思路？
畅想三：超越 Helm，构建原生包管理器——生态治理的进化
Helm 作为 Kubernetes 事实上的包管理器，为社区贡献了标准化的应用分发和管理方式。文章作者首先感谢了 Helm 维护者的辛勤工作。但紧接着，便毫不留情地指出了 Helm 在实践中的诸多“噩梦”：
- Go模板的复杂性与调试困难： 复杂的模板逻辑、令人困惑的错误场景、以及难以理解的错误信息。
- 依赖管理能力的孱弱： 难以优雅地处理传递性依赖和版本冲突，尤其在多个应用依赖同一子 Chart 的不同版本时。
- 其他痛点： 跨命名空间安装不便、Chart 验证过程繁琐且少有人用（作者甚至吐槽了 Artifact Hub 上官方 Chart 的验证状态）、元数据搜索能力弱、不严格执行语义化版本控制、以及卸载/重装包含 CRD 的 Chart 可能导致用户数据丢失的严重安全隐患。
作者断言：“没有办法让 Helm 足够好地完成‘管理地球上所有关键基础设施的包管理器’这项任务。”
因此，文章畅想了一个名为 KubePkg 的 Kubernetes 原生包管理系统，其核心设计理念借鉴了成熟的 Linux 包管理系统，并充分利用了 Kubernetes CRD 的能力：
- 一切皆为 Kubernetes 资源： 包定义、仓库、安装实例等都通过 CRD 管理，拥有标准的 status 和 events。
- 一流的状态管理： 内置对有状态应用备份、恢复、升级策略的支持。
- 增强的安全性： 强制的包签名、验证机制和安全扫描集成。
- 声明式配置，告别模板： 使用结构化的配置（可能基于 HCL 或类似带有 Schema 的语言），而非难以调试的文本模板。
- 完善的生命周期管理： 提供全面的 pre/post-install/upgrade/remove 钩子。
- 强大的依赖解析： 类似 Linux 包管理器的、基于语义化版本的依赖管理和冲突解决能力。
- 完整的审计追踪： 记录所有变更的“who, what, when”。
- 策略执行与简化的用户体验。
加分项：默认拥抱 IPv6——未雨绸缪的网络升级
除了上述三大核心变革，文章还提出了一个颇具前瞻性的建议：Kubernetes 2.0 应将默认网络模式切换到 IPv6。
其理由在于，IPv4 带来的 NAT 穿透复杂性、IP 地址耗尽焦虑（即使在私有网络中，大规模集群也可能迅速耗尽 /20 这样的网段）等问题，已经浪费了全球开发者和运维者大量的时间和精力。
在 K8s 内部默认使用 IPv6，可以：
- 极大简化集群内部网络拓扑。
- 在组织层面，如果使用公网 IPv6 地址，可以更容易地忽略多集群之间的界限。
- 提升网络流量的可理解性。
- 更好地利用 IPv6 内置的 IPSec 等安全特性。
作者强调，这并非要求整个互联网立即切换到 IPv6，而是 Kubernetes 自身可以主动进化，以解决其在当前规模下面临的 IP 地址管理和网络复杂性问题。
小结：“默认即王道”，Kubernetes 的未来在于更优体验
“Kubernetes is an open platform, so the community can build these solutions.” （K8s 是一个开放平台，所以社区可以构建这些解决方案。）这是对类似“2.0”畅想的常见反驳。但文章作者一针见血地指出，这种说法忽略了一个关键点：“默认值是技术中最强大的力量。” 核心项目定义的“快乐路径”将主导 90% 用户的交互方式。
如果 Kubernetes 2.0 能够在配置语言、后端存储、包管理乃至网络模型这些核心体验上，提供更简洁、更安全、更强大、更易用的“默认选项”，那么整个生态系统都将因此受益。
这无疑是一份雄心勃勃的畅想清单。但正如作者所言：“如果我们打算做梦，那就做个大梦。毕竟，我们是那个认为将一项技术命名为‘Kubernetes’也能流行起来的行业，而且不知何故它确实做到了！”
Kubernetes 的第一个十年，奠定了其在云原生领域的王者地位。下一个十年，它需要在保持核心优势的同时，勇于直面和解决用户在实践中遇到的真实痛点，不断进化，提供更极致的用户体验。这些“2.0”的畅想，无论最终能否完全实现，都为我们指明了值得努力的方向。
参考文章地址：https://matduggan.com/what-would-a-kubernetes-2-0-look-like
聊一聊，也帮个忙：
- 对于文中提出的 Kubernetes 2.0 的三大核心变革（HCL替换YAML、可插拔etcd、原生包管理器KubePkg），你最期待哪一个？为什么？
- 你认为当前使用 Kubernetes 最大的痛点是什么？这些“2.0畅想”是否触及了你的痛点？
- 关于默认使用 IPv6，你认为在实际推行中会遇到哪些挑战？
欢迎在评论区留下你的真知灼见。如果你觉得这篇文章引发了你的思考，也请转发给你身边的云原生同道们，一起畅想 Kubernetes 的未来！
精进有道，更上层楼
极客时间《Go语言进阶课》上架刚好一个月，受到了各位读者的热烈欢迎和反馈。在这里感谢大家的支持。目前我们已经完成了课程模块一『语法强化篇』的 13 讲，为你系统突破 Go 语言的语法认知瓶颈，打下坚实基础。
现在，我们已经进入模块二『设计先行篇』，这不仅包括 API 设计，更涵盖了项目布局、包设计、并发设计、接口设计、错误处理设计等构建高质量 Go 代码的关键要素。
这门进阶课程，是我多年 Go 实战经验和深度思考的结晶，旨在帮助你突破瓶颈，从“会用 Go”迈向“精通 Go”，真正驾驭 Go 语言，编写出更优雅、更高效、更可靠的生产级代码！
扫描下方二维码，立即开启你的 Go 语言进阶之旅！
如果你对Go语言的底层原理和高级技巧充满好奇，渴望构建更坚实的技术壁垒，我诚挚地邀请您关注我的微专栏系列。在这里，我们拒绝浮光掠影，只做深度挖掘：
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
评论