Kubernetes 引入 KYAML：更安全的 YAML 子集

Kubernetes 的配置文件几乎全部使用 YAML 编写。YAML 可读性好，但灵活性也带来了无数陷阱------缩进错一个空格，配置就可能被静默解析成完全不同的对象。2025 年，Kubernetes SIG CLI 通过 KEP-5295 提出了 KYAML，一种更严格、更少歧义的 YAML 子集，并在 2026 年 9 月发布的 1.37 版本中达到 Stable 状态。

什么是 KYAML

KYAML 是标准 YAML 的严格子集，专门为 Kubernetes 设计。它不是新格式，也不引入新解析器。核心理念是：Kubernetes 只使用了 YAML 规范中很小的一部分，标准化这个子集可以避免开发者做出容易出错的选择。

KYAML 的关键规则：所有字符串值必须双引号包裹；使用 {} 表示映射，[] 表示列表；不依赖缩进表达结构；支持注释和尾随逗号；文档以 --- 开头，以便和 JSON 区分开来。

与普通 YAML 的区别

我们通过一个 Pod 配置来做下对比：

传统 YAML：

yaml 复制代码

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: demo
spec:
  containers:
  - name: nginx
    image: nginx:1.20

KYAML：

yaml 复制代码

---
{
  apiVersion: "v1",
  kind: "Pod",
  metadata: {
    name: "my-pod",
    labels: {
      app: "demo",
    },
  },
  spec: {
    containers: [{
      name: "nginx",
      image: "nginx:1.20",
    }],
  },
}

核心区别：KYAML 用花括号代替缩进，字符串值始终带引号，缩进不再影响语义。格式化工具或模板引擎改变缩进时，配置的含义保持不变。

列表写法也有所不同：

传统 YAML：

yaml 复制代码

ipFamilies:
- IPv4
- IPv6

KYAML：

yaml 复制代码

ipFamilies: ["IPv4", "IPv6"]

这解决了什么问题

"挪威问题" ：YAML 中未加引号的 NO 会被静默转换为布尔值 false。KYAML 强制双引号包裹字符串，消除了隐式类型转换。

缩进敏感性：传统 YAML 中缩进决定结构，一个多余的空格可能让字段"跳"到错误的父级对象。KYAML 用花括号显式标记结构，Helm 模板等场景下更可靠。

CI/CD 可靠性：PR 中的 diff 能更准确地反映实际部署的内容。

为什么是这个时候

KYAML 的正式发布时机非常有趣。当前 Kubernetes 配置越来越多地由程序自动生成------Helm、GitOps 平台、AI 编码 Agent 都在生产或修改清单。

有分析指出：如果 Agent 越来越多地负责创建和修改清单，一种受约束的配置方言可以让这些 Agent 做出更少的语法选择，同时让输出更具确定性、更易于验证。

最新研究发现，让 LLM 直接编写或修改 YAML 文件是不安全的------全文件重写会导致非确定性结果，每次运行可能丢失字段或错误地编辑了相邻的字段。KYAML 的显式结构使得清单编辑更准确：AI 只需要发出结构化的字段变更意图，不需要理解缩进敏感的格式规则。

如何使用

KYAML 的使用方式很简单：

bash 复制代码

kubectl get -o kyaml pod my-pod

在 -o yaml 基础上加一个 "k" 即可。输出可以直接再传给 kubectl，因为 KYAML 本身就是合法的 YAML。

现有文件转换可以使用官方提供的 yamlfmt：

bash 复制代码

yamlfmt -o=kyaml my-deployment.yaml

总结

KYAML 不是要取代 YAML，而是在 Kubernetes 的实际使用范围内，提供一种更安全、歧义更少的标准化写法，既保留了注释和尾随逗号等便捷的特性，又消除了缩进敏感和隐式类型转换等陷阱。对于正在将 AI Agent 引入 Kubernetes 配置工作流的团队，KYAML 提供了更可靠的基础------让人类和机器都能更自信地编写和验证配置文件。