Kustomize如何轻松解决多环境及yaml编排文件的管理

前言

18年那会、我学习了 docker，它利用集装箱的思想，将依赖和运行环境打包成自包含、轻量级、可移植的容器，它给开发人员带来的切实好处就是一次构建、到处运行，消除了开发、测试、生产环境不一致性。看完之后，不以为然，真的可以完全消除各个环境的不一致性吗？时至今日，Kubernetes 已经上生产，但是各个环境的不一致性，仍然没有解决，大致问题就是，所有服务全部容器化不太现实，比如 MySQL、redis 等，这些服务本身已经存在现有的、稳定的部署方式，且这些服务是不怎么变动的，当然可以使用 Kubernetes 把数据库打成镜像，通过有状态服务资源对象编排，纳入到 Kubernetes 集群管理当中，实现动态扩缩容。但对于中小企业来说，最急切的还是自己业务，对于数据库服务还是使用原有服务器部署，最大程度上降低研发成本。这就带来了如下几个问题：

• 其一、开发环境和测试环境连接的数据库地址不是同一个，线上环境更是不同，每次上线都需要维护三份，甚至更多配置即 Kubernetes ConfigMap。

• 其二、通过镜像解决了各个环境的打包问题，但是随之而来的是大量 yaml 编排文件，编排文件如何管理？各个环境虽然镜像一样，但是配置参数可能不同，比如：开发一个副本，但是生产可能需要三个等等。

• 其三、yaml 配置较多，要么一个个执行，或者单独维护脚本批量执行 yaml。

为了解决不同应用在不同环境中存在使用不同配置参数的复杂问题，容器的生态系统出现了 helm，它大大简化了应用管理的难度，简单来说，helm 类似于 Kubernetes 程序包管理器，用于应用的配置、分发、版本控制、查找等操作。它的核心功能是把 Kubernetes 资源对象（Deployment、ConfigMap、Service）打包到一个 Charts 中，制作完成各个 Charts 保存到 Chart 仓库进行存储和转发，虽然 helm 可以解决 Kubernetes 资源对象生命周期管理以及通过模板的版本控制，但是 helm 使用起来复杂，只想管理几个不同环境 yaml 配置，helm 搞了很多模板渲染等概念，且不支持多租户，现在出了 helm v3 抛弃了tiller，同时引入了 lua，本想简单解决 yaml 编排文件问题，却引入更高的复杂度。

但云原生社区从来不会让我们失望，随之而来的，就是 Kustomize，只有一个 cli 工具，通过这个工具可以打包不同环境的配置，在 Kubernetes 1.14 版本之后，直接集成到 kubectl 命令中，通过执行 kubectl apply -k 命令就可以完成不同环境应用的打包，可以说相当简单。下面对 Kustomize 进行介绍。

Kustomize 设计理念

Kustomize 允许用户以一个应用描述文件 （YAML 文件）为基础（Base YAML），然后通过 Overlay 的方式生成最终部署应用所需的描述文件。两者都是由 kustomization 文件表示。基础（Base）声明了共享的内容（资源和常见的资源配置），Overlay 则声明了差异。它的设计目的是给 kubernetes 的用户提供一种可以重复使用同一套配置的声明式应用管理，从而在配置工作中用户只需要管理和维护kubernetes的API对象，而不需要学习或安装其它的配置管理工具，也不需要通过复制粘贴来得到新的环境的配置。

Kustomize 概念介绍

kustomize 中工具的声明与规范是由名为 kustomization.yaml 的文件定义，确保这三个文件与 kustomization.yaml 位于同一目录下。示例如下：

commonLabels:    app: hello    resources:    - deployment.yaml    - configMap.yaml    - service.yaml

kustomize 将会读取声明文件和 Kubernetes API 资源文件，将其组合然后将完整的资源进行标准化的输出。输出的文本可以被其他工具进一步处理(kustomize build)，或者直接通过 kubectl (kubectl apply -k .) 应用于集群，两种方式均可，不过 kubectl 要求 kubernetes 1.14 之上的版本。如果需要使用 kustomize 需要安装 cli 命令行，安装方式简单https://github.com/kubernetes-sigs/kustomize/releases、自行下载二进制命令即可。

开发、测试和生产yaml配置举例说明

具体目录如下所示：

 

• 配置修改示例

其中 base 中存放的 deployment、service 就是我们平时常见 Kubernetes 资源对象，这部分通常是不变化的部分。除了这两个之外，再加上 kustomization，它的作用是指定那些文件需要合并到一起，如下所示：

 

运行到 dev 目录，如下所示：dev 目录多出一个配置文件 yaml 这个配置适用于开发环境，执行[root@k8s-master dev]# kubectl apply -k . 既可以完成各个环境的配置和执行。其中 kustomization.yaml 内容如下所示：

其中 namePrefix 适用于资源名称前缀，根据情况自行选择是否添加。同样的道理，测试和线上环境也可以通过这个过程完成配置的执行。

• 副本数量修改示例

deployment 运行 nginx 一个副本。

通过增加patch yaml 修改副本数量，如下所示：

 

添加 patch 策略，如下：

执行如下命令，从一个副本变成三个副本,如下所示：

kustomize 基本能够满足常用配置功能，具体特性如下所示：

本文主要讲解通过使用 kustomize 就可以管理任意数量的 Kubernetes 定制配置。kustomize 的每个产物都是纯 YAML 的，这些文件可以存储到 SVN 或者 github，甚至结合 helm 进行管理，最后通过自动化工作流自动拉取配置，完成这个过程的执行。