Kubernetes 为什么会坚持 Configuration 应该是 data-only

翻了一遍 Kubernetes 关于支持 Configuration Template 的 issue 和 PR，会发现几年里不断有人提类似想法，但大多都被否了，有些讨论甚至拉了两年多。

Google 在《Borg, Omega, and Kubernetes》那篇论文里也承认，Configuration 本身是一个复杂而开放的问题，并没有一个足够好的通用解。

但他们有一个判断我一直很认同：

Configuration 应该是 data-only 的，比如 json / yaml，而不应该包含逻辑。

为什么？

因为一旦在配置文件里引入模板或者 DSL，这基本就是打开了一个潘多拉盒子。

短期看，它确实会让配置更灵活；但往后走，问题会不断冒出来：

1. 如何 debug？
2. 如何测试？
3. 当 DSL 需要不断增强表达能力时，边界怎么控制？

演化到后面，很可能会出现一种反转：

• 你的应用越来越像是“主要由模板语言写成的”
• 原来的业务代码反而退化成模板语言的扩展

走到这一步时，你最后大概率还会需要再发明一种新的配置模板语言，专门用来收拾原来的复杂度。

所以从系统长期演化的角度看，配置尽量保持 data-only，很多时候不是保守，而是在主动控制复杂度。