---
title: Kubernetes 为什么会坚持 Configuration 应该是 data-only
date: '2017-09-05 17:59:38'
draft: false
summary: 配置里一旦引入模板逻辑或 DSL，短期看起来灵活，长期往往会把调试、测试和演化复杂度一起放大。
slug: kubernetes-configuration-should-be-data-only
syndication:
- platform: Weibo
  url: https://weibo.com/1648815335/4148678845160822
tags:
- kubernetes
- configuration
- software-design
topics:
- software-engineering
type: post
---

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

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

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

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

为什么？

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

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

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

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

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

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

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