Kubernetes 正在鼓励开发者更深入地了解 KYAML——这是一种更严格的 YAML 方言，旨在让 Kubernetes 配置更加明确、可预测，并减少常见 YAML 错误的发生。在最近一篇 Kubernetes 博文中，该项目团队解释了开发者如何将现有清单以 KYAML 格式进行美化打印，以及为何该格式能为处理日益复杂的 Kubernetes 配置提供一种更一致的方式。
关键在于，KYAML 并非一种新的配置语言。它是 YAML 的严格子集，这意味着现有的 YAML 解析器和 Kubernetes 工具仍然可以继续处理它。KYAML 并未改变底层的配置生态系统，而是减少了开发人员需要做出的语法选择。Kubernetes 在 v1.34 版本中将 KYAML 作为 Alpha 功能引入，然后在 v1.35 版本中将其升级为 Beta 功能，并默认启用。
YAML 之所以与 Kubernetes 如此契合，是因为它易于人类阅读而且支持注释，但其灵活性也可能带来一些问题。缩进决定了结构，而未加引号的值有时会被解释为与作者本意不同的数据类型。当清单由 Helm 等模板系统生成或处理时，这些问题会变得尤为棘手。
KYAML 采用了一种更明确的方法：对象使用 {}，数组使用 []，字符串值用双引号括起来。它保留了 YAML 中有用的特性（如注释和尾随逗号），同时避免了传统块式 YAML 相关的一些歧义。其结果是在视觉上更接近 JSON，但仍然是有效的 YAML，因此不需要新的解析器或生态系统。
最新指南的实际意义在于，开发者无需手动重写其清单文件。Kubernetes 现在已经支持将 -o kyaml 作为 kubectl 的输出格式，而 Kubernetes 的 yamlfmt 工具和谷歌的 yamlfmt 均可以将现有的 YAML 转换为 KYAML。Kubernetes 项目还指出，由于 KYAML 仍然属于有效的 YAML，所以旧版本的 kubectl 也能处理它。
Kubernetes 也刻意没有将 KYAML 设为默认格式。团队可以继续使用传统的 YAML，而如果团队更看重更明确的语法，则可以有选择地采用它，或者配置其工具来优先使用它。这使得 KYAML 更像是一种渐进式的工程实践，而非颠覆性的迁移。
这一发布时机颇具深意，因为 Kubernetes 配置正越来越多地通过生成的方式实现，而非手动编写。Helm、GitOps 平台、基础设施即代码（IaC）系统，以及日益普及的 AI 编码代理，都会生成或修改 Kubernetes 配置文件。
这使得模糊性带来的后果更为严重。人类开发者在审查相对较小的清单时，通常能够发现缩进问题或意外值。而生成数百个资源的自动化系统，则较少有机会进行上下文判断。更严格的表示方式减少了配置的表达方式，使人类和机器都能更轻松地识别结构以及与类型相关的错误。
这使得 KYAML 在人工智能辅助的 Kubernetes 环境中尤为引人关注。如果智能代理在创建和修改清单方面承担的责任日益加重，那么一种受限的配置方言不仅能减少这些智能代理需要做出的语法决策，还能使其输出结果更具有确定性，并且更易于验证。
KYAML 也反映了工程领域存在的一个更广泛的趋势：为了保持一致性而降低灵活性。类似的原则也支撑着强约束的代码格式化工具、代码检查工具、强类型 API、“策略即代码”（policy-as-code）以及平台工程中的“黄金路径”。
标准化 Kubernetes 配置的表示方式，可以简化代码审查流程、减少不必要的格式差异、优化差异对比结果，并提高自动化验证的可靠性。此外，这还为平台团队提供了一种新机制，有助于在可能多达数百个的 Kubernetes 代码库中建立一致的工程实践。
KYAML 不太可能在一夜之间取代传统的 Kubernetes YAML，Kubernetes 方面也并未表示有必要这样做。它的价值更为精妙：它旨在让业界使用最广泛的配置格式之一变得更加明确，同时又不破坏已经围绕它构建起来的生态系统。
Kubernetes 贡献者和官方项目已经在各社交渠道上重点推介了这一功能，而独立的 DevOps 评论则着重强调了它能够消除 YAML 长期存在的一些意外问题（包括隐式类型转换），而且不需要新的解析器或生态系统。这或许正是 KYAML 最具说服力的优势：它不需要 Kubernetes 用户学习完全陌生的内容，而是直接从他们已经使用的格式中剔除了部分不必要的选择。由于 KYAML 仍然符合 YAML 规范，而且可被现有的 Kubernetes 工具所处理，所以尝试使用这一格式的门槛相对比较低。
原文链接：https://www.infoq.com/news/2026/09/kubernetes-kyaml-manifests/