起源#

源自我在Tubi公司日常开发中使用Kustomize的痛点。某天灵光一现，想出了一个更简单的方案。于是自己在某个周末实现并开源。

痛点#

Kustomize核心要素是「转换器」（trasnformer），也就是将一个Kubernetes资源对象转换成另一个。而「补丁」是最常用的转换器。

每个项目编写一串基础Kubernetes资源文件。然后基于这些文件，针对每个执行环境加特定的补丁。这种设计看起来很简单，但当项目数量变多，或者资源文件变复杂后；编辑和理解这些「补丁」的集合会变得费时费力。例如

1. 应用根目录下有三个文件夹base，staging和production，分别存储基础Kubernetes资源文件，测试环境和生产环境的补丁。每个文件夹下面有几十独立的项目文件夹存储各自的资源。当程序员想要修改某个项目时，需要在这3个主文件夹定位到项目文件夹，并且来回跳转，从众多「补丁」文件中拼凑出最终的资源声明。
2. 基于文件和补丁的方式缺少抽象与复用能力。因此添加新应用时，程序员一般会复制另一个应用的文件，然后再修改。这种复制粘贴的方式既费时又易出错。
3. Kustomization声明文件可以引用另一个文件，并且打它当作补丁用来修改其它资源文件。这样层层嵌套，最终的声明对象是由一个「补丁」树逐层修改得来的，可想有多复杂。而且编辑器不支持跳转到被引用的文件，因此想理解整个「补丁」树更加费时费力。

总之，Kustomize的设计不适合于多团队多项目的大型编程（programming in the large）。

方案#

Kustomize本质上是在YAML文件格式的基础上，设计了一个领域内语言（DSL）用来表达更加复杂的操作。而我们直接选用一个成熟的语言TypeScript。它的表达力足够好，程序员也不需要学习新的领域内语言。更重要的是，它优良的模块设计，使它很适合大型编程。

设计#

KubeScript面向「应用层」开发者，以「应用」为中心，提供一个简单又灵活的Kubernetes部署平台。核心设计理念包括：

1. 大道至简
2. 摒弃黑魔法（hack）
3. 不重复造轮子，站在巨人肩膀上