Kustonmize 为何会出现
在 kustomize 出现之前，Kubernetes 管理应用的方式主要是通过 Helm 或者上层 Paas 来完成。
这些工具通常通过特定领域配置语言(DSL，如Go template、jsonnet) 来维护并管理应用，
并且需要参数化模板方式(如 helm) 来自定义配置，这需要学习复杂的 DSL 语法及容易出错。
根据官网的描述：kustomize 是 kubernetes 原生的配置管理，以无模板方式来定制应用的配置。
kustomize 使用 k8s 原生概念帮助创建并复用资源配置(YAML)，允许用户以一个应用描述文件 （YAML 文件）为基础（Base YAML）
然后通过 Overlay 的方式生成最终部署应用所需的描述文件。
Kustomize 是一个独立的工具，用来通过 kustomization 文件 定制 Kubernetes 对象。
从 1.14 版本开始，kubectl 也开始支持使用 kustomization 文件来管理 Kubernetes 对象。 要查看包含 kustomization 文件的目录中的资源，执行下面的命令：
kubectl kustomize <kustomization_directory>
要应用这些资源，使用参数 --kustomize 或 -k 标志来执行 kubectl apply：
kubectl apply -k <kustomization_directory>
官网地址：
https://github.com/kubernetes-sigs/kustomize
kustomize 解决了什么痛点
1.如何管理不同环境或不同团队的应用的 Kubernetes YAML 资源
2.如何以某种方式管理不同环境的微小差异，使得资源配置可以复用，减少 copy and change 的工作量
3.如何简化维护应用的流程，不需要额外学习模板语法
kustomize 通过 Base & Overlays 方式(下文会说明)方式维护不同环境的应用配置
kustomize 使用 patch 方式复用 Base 配置，并在 Overlay 描述与 Base 应用配置的差异部分来实现资源复用
kustomize 管理的都是 Kubernetes 原生 YAML 文件，不需要学习额外的 DSL 语法
Kustomize安装
安装文档
https://kubectl.docs.kubernetes.io/zh/installation/
我这边选用二进制安装
官方提供的安装方式
cd /usr/bin/
curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash
Kustomize 命令行包含build diff edit version h等子命令，其中最常使用的是build子命令
kustomize 官方实例
https://github.com/kubernetes-sigs/kustomize
更多官方的给的实例
https://github.com/kubernetes-sigs/kustomize/tree/master/examples
Kustomize 术语
参考文档：
https://kubectl.docs.kubernetes.io/zh/api-reference/kustomization/
kustomization 指的是 kustomization.yaml 文件，或者指的是包含 kustomization.yaml 文件的目录以及它里面引用的所有相关文件路径
base
是一个 kustomization , 任何的 kustomization 包括 overlay (后面提到)，都可以作为另一个 kustomization 的 base (简单理解为基础目录)。base 中描述了共享的内容，如资源和常见的资源配置
overlay
一个 kustomization它修改(并因此依赖于)另外一个 kustomization. overlay 中的 kustomization指的是一些其它的 kustomization, 称为其 base. 没有 base, overlay 无法使用，并且一个 overlay 可以用作 另一个 overlay 的 base(基础)。简而言之，overlay 声明了与 base 之间的差异。通过 overlay 来维护基于 base 的不同 variants(变体)，例如开发、QA 和生产环境的不同 variants
variant
在集群中将 overlay 应用于 base 的结果。例如开发和生产环境都修改了一些共同 base 以创建不同的 variant。这些 variant 使用相同的总体资源，并与简单的方式变化，例如 deployment 的副本数、ConfigMap使用的数据源等。简而言之，variant 是含有同一组 base 的不同 kustomization
resource
在 kustomize 的上下文中，resource 是描述 k8s API 对象的 YAML 或 JSON 文件的相对路径。即是指向一个声明了 kubernetes API 对象的 YAML 文件
patch
修改文件的一般说明。文件路径，指向一个声明了 kubernetes API patch 的 YAML 文件
Kustomize 中有（bases） 和 （overlays） 的概念区分：
base 是包含 kustomization.yaml 文件的一个目录，其中包含一组资源及其相关的定制。 基准可以是本地目录或者来自远程仓库的目录，只要其中存在 kustomization.yaml 文件即可。
overlays 也是一个目录，其中包含将其他 kustomization 目录当做 bases 来引用的 kustomization.yaml 文件。 基准不了解覆盖的存在，且可被多个覆盖所使用。 覆盖则可以有多个基准，且可针对所有基准中的资源执行组织操作，还可以在其上执行定制。
这边测试的一个实例
两个不同的环境(开发，生产)
一个 deployments 资源和 service 资源为基础资源
先看下目录结构
当前文件夹下面添加一个名为kustomization.yaml的文件
可以用kustomizaton init生成
cat kustomizaton.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- service.yaml
- deployment.yaml
cat base/deployment.yaml
cat base/service.yaml
cat demo/overlays/pro/kustomization.yaml
cat demo/overlays/pro/limit.yaml
cat demo/overlays/pro/values.yaml
dev 相关的配置这里就不贴了
为了了解将安装什么资源到集群中，我们在本文中主要使用kustomize build命令来代替kubectl apply -k命令。当然使用kubectl kustomize命令也是可以的，因为我们说了 kubectl 1.14 版本以后就已经集成了 kustomize。
在 kubectl 命令中使用 --kustomize 或 -k 参数来识别被 kustomization.yaml 所管理的资源。 注意 -k 要指向一个 kustomization 目录。例如：
kubectl apply -k <kustomization 目录>
kustomize build /usr/local/src/demo/overlays/pro/
如果想要直接部署
kustomize build /usr/local/src/demo/overlays/pro/ | kubectl apply -f -
或者
kubectl apply -k /usr/local/src/demo/overlays/pro/
定制配置
在这个工作流中，所有的配置（YAML 文件）都属于用户所有
现成配置
在这个工作流方式中，可从别人的 repo 中 fork kustomize 配置，并根据自己的需求来配置
通过上面两种工作流方式，可以实现自定义管理应用的声明式资源文件，或者基于别人的应用声明式资源进行自定义修改
如果你经常使用 Kubernetes，那么应该对 Helm 和 Kustomize 不陌生，这两个工具都是用来管理 Kubernetes 的资源清单的，但是二者有着不同的工作方式。
kustomize vs Helm
Helm 使用的是模板，一个 Helm Chart 包中包含了很多模板和值文件，当被渲染时模板中的变量会使用值文件中对应的值替换。而 Kustomize 使用的是一种无模板的方式，它对 YAML 文件进行修补和合并操作，此外 Kustomize 也已经被原生内置到 kubectl 中了。这两个工具在 Kubernetes 的生态系统中都被广泛使用，而且这两个工具也可以一起结合使用
通过上面对 kustomize 的讲解，可能已经有人注意到它与 Helm 有一定的相似。先来看看 Helm 的定位：Kubernetes 的包管理工具，而 kustomize 的定位是：Kubernetes 原生配置管理。两者定位领域有很大不同，Helm 通过将应用抽象成 Chart 来管理, 专注于应用的操作、复杂性管理等, 而 kustomize 关注于 k8s API 对象的管理：
- Helm 提供应用描述文件模板(Go template)，在部署时通过字符替换方式渲染成 YAML，对应用描述文件具有侵入性。Kustomize 使用原生 k8s 对象，无需模板参数化，无需侵入应用描述文件(YAML), 通过 overlay 选择相应 patch 生成最终 YAML
- Helm 专注于应用的复杂性及生命周期管理(包括 install、upgrade、rollback)，kustomize 通过管理应用的描述文件来间接管理应用
- Helm 使用 Chart 来管理应用，Chart 相对固定、稳定，相当于静态管理，更适合对外交付使用，而 kustomize 管理的是正在变更的应用，可以 fork 一个新版本，创建新的 overlay 将应用部署在新的环境，相当于动态管理，适合于 DevOps 流程
- Helm 通过 Chart 方式打包并管理应用版本，kustomize 通过 overlay 方式管理应用不同的变体，通过 Git 来版本管理
- Helm 在v3 版本前有 Helm 和 Tiller 两组件，需要一定配置，而 kustomize 只有一个二进制，开箱即用
总的来说，Helm 有自己一套体系来管理应用，而 kustomize 更轻量级，融入Kubernetes 的设计理念，通过原生 k8s API 对象来管理应用
总结
Kustomize 给 Kubernetes 的用户提供一种可以重复使用配置的声明式应用管理，从而在配置工作中用户只需要管理和维护 Kubernetes 的原生 API 对象，而不需要使用复杂的模版。同时，使用 kustomzie 可以仅通过 Kubernetes 声明式 API 资源文件管理任何数量的 kubernetes 定制配置，可以通过 fork/modify/rebase 这样的工作流来管理海量的应用描述文件。