Kubernetes 资源编排系列之三: Kustomize 篇

作者 艄公(杨京华) 雪尧(郭耀星)

这是我们的《Kubernetes 资源编排系列》的第三篇——Kustomize 篇，在上篇（《Kubernetes 资源编排系列之二: Helm 篇》，可从文末链接直达）我们见识到了 Helm 强大的管理能力，但是 Helm 对于服务的定制仅限于预置变量，那么如果需要更多更灵活的 YAML 定制，有什么办法吗？于是本篇我们来介绍一下 Kustomize。

Kustomize 是什么

Kustomize 是一套采用合并思想，对 Kubernetes 原生配置进行管理的工具，使用无模板的方案定义应用配置。允许用户使用一系列的描述文件为基础，然后通过 overlay 的方式生成最终部署应用所需的描述文件。

Kustomize 通过 Base&Overlays 方式维护不同环境的应用配置，在 Overlay 中描述差异来实现资源复用，管理的是 Kubernetes 原生 YAML 文件，不需要学习额外的 DSL 语法。

Kustomize 是怎么做的

Kustomize 的文件结构如下：

app├── base│   ├── deployment.yaml│   ├── service.yaml│   └── kustomization.yaml└── overlays    ├── production    │   └── kustomization.yaml    ├── staging    │   └── kustomization.yaml    └── production-large        └── kustomization.yaml

app/base/kustomization.yaml 声明资源及要应用于它们的一些自定义，如添加一个通用的标签，其内容如下。kustomization 还提供了 namePrefix、commonAnnoations、images 等配置项。

commonLabels:  name: appresources:- deployment.yaml- service.yaml

可以通过 kustomize build 命令来看完整的配置，build 出来的每个资源对象上都会存在通用的标签 name: app。

kustomize build app/base  # 构建kustomize build app/base | kubectl apply -f -  # 构建并部署kubectl apply -k app/base # 1.14及更新的版本可以使用该命令直接部署

app/overlays/staging/kustomization.yaml 中可以为演示环境定义不同的名称前辍、标签，通过 patch 的方案将副本数设置为 1

bases:- ../../basecommonLabels:  env: stagingnamePrefix: staging-patches:  - target:      kind: Deployment      name: app    patch: |      [        {"op":"replace","path":"/spec/replicas","value":1}      ]

app/overlays/production/kustomization.yaml 中可以为生产环境定义不同的名称前辍、标签，通过 patch 的方案将副本数设置为 2

bases:- ../../basecommonLabels:  env: productionnamePrefix: production-patches:  - target:      kind: Deployment      name: app    patch: |      [        {"op":"replace","path":"/spec/replicas","value":2}      ]

app/overlays/production-large/kustomization.yaml 中可以继承生产环境的定义，同时将副本数设置为 10 支撑大规模场景需求。

bases:- ../productionpatches:  - target:      kind: Deployment      name: app    patch: |      [        {"op":"replace","path":"/spec/replicas","value":10}      ]

通过不同的部署路径，指定不同的环境部署

kustomize build app/overlays/production | kubectl apply -f -kustomize build app/overlays/staging | kubectl apply -f -kustomize build app/overlays/production-large | kubectl apply -f -

通过上面的例子我们可以看出，通过 kustomization.yaml 来声明继承和 patch，可以为各种场景构造不同的 YAML 输出，同时保持底座 YAML 不变化。

Kustomize 的特点

Kustomize 的 Overlay 可以在 Base 的基础上，通过对 resource / generator / transformer 等的定义，形成新的应用定义，不管是 Base 还是 Overlay，都可以通过 kustomize build 生成有效的 YAML。

• 功能简单清晰，kubectl 直接内部支持

• 不考虑派生，仅仅作为组件的 YAML 组织方式也很有帮助

• 也有自己的插件系统，例如可以用简单的 YAML 定义，使用文件生成 ConfigMap / Secret 等

• 允许注入 K8S 运行时数据

Kustomize 和 Helm 的对比

Kustomize 相对于 Helm 而言，更加的轻量，只有一个 CLI 工具。也集成到了 kubectl 自身，使用及配置成本接近于 0。Kustomize 放弃了对模板的要求，改为参考 Docker 镜像的形式，通过 Base + Overlay 的方式对应用的原始 YAML 进行派生。

• Base YAML 管控：Helm 最大的特点是定制仅限于预先存在的配置选项。不仅如此，Chart 作者还必须用有点麻烦的模板化方式实现这些定制选项。这个时候 Kustomize 不受限制的 Overlay 会更加灵活，想怎么覆盖就怎么覆盖。所以 Helm 对 Base YAML 强管控；而 Kustomize 虽然也有 Base，但 Overlay 的存在让这个限制几乎不存在。

• 模板语法层面：Kustomize 相较于 Helm 去掉了模板语法，入门门槛更低，更易使用。当然如果玩的高阶，两者都要学习很多东西。

• 部署层面：虽然 Kustomize 最为轻量，但因为 Helm3 取消了 Tiller 依赖，所以差别也不是很大，两者都是二进制命令工具生成 YAML 后直接下发。

• 工作流程上：

• Helm: 定义 Chart -> 填充 -> 运行。在 Chart 中没有定义的内容是无法更改的

• Kustomize: Base 和 Overlay 都是可以独立运作的，增加新对象，或者对编写 Base 时未预料到的内容进行变更，都非常简单

基于上述工作流程的对比，如果是要公开发布一个复杂的组件，编写一个复杂而设计良好的 Helm Chart 可以给用户很大帮助。用户在缺失了自由性之下，仅仅通过 values.yaml 的阅读和配置就可以对这种复杂的部署产生一个较为深入的认知。

如果是常见的业务应用，虽然不同的部署之间差异不大（比如日常预发生产），但是因为快速迭代及需求变化，未必可以一开始就做好相关的变化限制，用 Kustomize 是更好的选择。

对于承载应用 (Application) 这个概念而言，Kustomize 和 Helm 的短板是一致的，都没有进一步提供包之间的依赖处理、外部资源申请及维护、变量间传递等能力。

对于承载组件 (Component) 这个概念而言，Kustomize 和 Helm 类似，都是合适的工具。虽然 Helm 和 Kustomize 在自身的能力和流程上有着很多区别，但最终流程都是：开发者(一堆 YAML) -> 合适的参数映射及渲染方式 -> 使用者(填参/覆盖) -> apply 到目标 K8S 中。萝卜青菜，各有所爱。

SREWorks 的 Kustomize 组件实践

在 SREWorks 的 appmanager 中，将 Kustomize 与 Helm 并列放在一起成为一种组件类型，当前这种组件类型还未内置到出厂组件中，后续会上架到云端市场，供用户插拔安装。

- revisionName: "CHART|sreworks@management-controlplane@1.0|_"  parameterValues:    - name: Map      value:        clusterId: "{{ Global.clusterId }}"        product: es        userID: "{{ Global.uid }}"        vpcID: "{{ Global.vpcID }}"        vswitchID: "{{ Global.vswitchID }}"        namespaceRegexes: "^(essen|es)$"- revisionName: KUSTOMIZE|elasticsearch-repos@2.0.1@test|_  parameterValues:    - name: kubeconfig      value: "{{ Global.kubeconfig }}"      toFieldPaths:        - spec.base64Kubeconfig    - name: path      value: "./"      toFieldPaths:        - spec.path  dependencies:    - component: "CHART|sreworks@management-controlplane@1.0"- revisionName: "STATUS|KUSTOMIZE@esonack-cluster-baselines|_"  dependencies:    - component: KUSTOMIZE|es-cluster-baselines@3.1.0@test  parameterValues:    - name: kubeconfig      value: "{{ Global.kubeconfig }}"      toFieldPaths:        - spec.base64Kubeconfig    - name: options      value:        groups:          - namespace: sreworks-system            labels:              app: sreworks            resources:              - v1/pods      toFieldPaths:        - spec.options

如上面所示，在 appmanager 中的 OAM YAML 中，插入 Helm 和 Kustomize 两种组件，并且设置依赖关系，在 Helm 组件下发完成后，再进行 Kustomize 组件的下发；在 Kustomize 组件下发完成后，对核心 Pod 进行状态探测，待 Pod 正常之后才算作部署完成。

总结

Kustomize 是一个通用工具，它的作用是对 Kubernetes 资源进行定制后产生新的 YAML 文件，并保持原始的 YAML 文件不变。从这个意义上来说，你可以把 Kustomize 看成是 Kubernetes YAML 文件的转换工具，类似 XML 和 XSLT 的关系。

Kustomize 的一个重要特征是不使用模板，而是直接工作在原始的 YAML 文件上。这一点与 Helm 是不同的。不使用模板好处在于简单易懂，不需要掌握复杂的模板语法，而 Helm 的 YAML 文件基本都被预置变量抠得毫无可读性。

Kustomize 的另外一个优势是集成在 kubectl 中，这就意味着不需要安装额外的工具就可以进行定制。需要注意的是，由于实现上的原因，kubectl 自带的 kustomize 的版本比较低，目前仍然需要安装单独的 Kustomize 工具。这个问题要到 1.20 版本才会解决。

后续文章我们会分享更多的 Kubernetes 组件和应用管理工具，均会发布在我们的公众号“阿里智能运维”上，请大家持续关注～也欢迎大家在公众号后台留言想了解的内容和感兴趣的相关话题，与 SREWorks 团队进行交流。