[Argo] 02 - Kustomize
Ref: Kubernetes native configuration management
Kustomize introduces a template-free way to customize application configuration that simplifies the use of off-the-shelf applications. Now, built into kubectl as apply -k.
痛点
Ref: Kustomize 和 Helm 之间，我为什么选择了 Kustomize？
我们虽然不是个大公司，可是这代码也是越敲越多，服务也是越做越全。零零总总也有十几个项目要管理了。然后我们同样有多套部署环境：内网环境，预生产环境，生产环境。那么针对每一个环境几乎都要有一套 Kubernetes 的 YAML 文件，但是各个仅仅是稍有不同。
Helm 是 Deis 开发的一个用于 Kubernetes 应用的包管理工具，主要用来管理 Charts。有点类似于 Ubuntu 中的 APT 或 CentOS 中的 YUM。
Helm Chart 是用来封装 Kubernetes 原生应用程序的一系列 YAML 文件。可以在你部署应用的时候自定义应用程序的一些 Metadata，以便于应用程序的分发。
对于应用发布者而言，可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库。
对于使用者而言，使用 Helm 后不用需要编写复杂的应用部署文件，可以以简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序。
-
Helm 不太合适
在 kustomize 出现之前，Kubernetes 管理应用的方式主要是通过 Helm 或者上层 Paas 来完成。
它更像是对外提供一个复杂的可以依据各种配置信息生成适合于不同环境的软件发布包，而不是用于我们这种轻量级的部署配置管理的。所以我就放弃使用 Helm 了。
-
Kustomize 更合适
[ 资源文件中的模板字段 ----> [K8S] 03 - k8s YAML, NameSpace & Pod ]
Kubernetes 配置的工具 Kustomize。简单的说，它就是一个简化 Kubernetes YAML 编写的工具。
Kustomize 放弃了对模板的要求，改用 Base + Overlay 的方式对应用的原始 YAML 进行派生。
Overlay，顾名思义，就是覆盖。Kustomize 的 Overlay 可以在 Base 的基础上，通过对 resource、generator、transformer 等的定义，形成新的应用定义，不论 Base 还是 Overlay，都可以通过 kustomize build 生成有效的 YAML
术语
在 kustomize 项目的文档中，经常会出现一些专业术语，这里总结一下常见的术语，方便后面讲解
- kustomization
kustomization.yaml 文件，或者指的是包含 kustomization.yaml 文件的目录以及它里面引用的所有相关文件路径
- base
base 指的是一个 kustomization , 任何的 kustomization 包括 overlay (后面提到)，都可以作为另一个 kustomization 的 base (简单理解为基础目录)。base 中描述了共享的内容，如资源和常见的资源配置。
比较类似Django html template。
- overlay
overlay 是一个 kustomization, 它修改(并因此依赖于)另外一个 kustomization。
overlay 中的 kustomization指的是一些其它的 kustomization, 称为其 base，没有 base, overlay 无法使用，并且一个 overlay 可以用作 另一个 overlay 的 base(基础)。
简而言之，overlay 声明了与 base 之间的差异。通过 overlay 来维护基于 base 的不同 variants(变体)，例如开发、QA 和生产环境的不同 variants
- variant
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 文件。
官方示例
kubectl -k 命令使用 kustomizedemo
├── base # ----> (2)
│ ├── configMap.yaml
│ ├── deployment.yaml
│ ├── kustomization.yaml # ----> (1)
│ └── service.yaml
└── overlays
├── production
│ ├── deployment.yaml # ----> (5)
│ └── kustomization.yaml # ----> (4)
└── staging
├── kustomization.yaml # ----> (3)
└── map.yaml
(1)
commonLabels: app: hello resources: - deployment.yaml - service.yaml - configMap.yaml
(2)
$ kustomize build demo/base # build 出来的 YAML 太长就不贴处理了
$ kustomize build demo/base | kubectl apply -f - # 这种方式直接部署在集群中 $ kubectl apply -k # 1.14 版本可以直接使用该命令部署应用于集群中
(3)
namePrefix: staging- commonLabels: variant: staging org: acmeCorporation commonAnnotations: note: Hello, I am staging! bases: - ../../base patchesStrategicMerge: - map.yaml
执行：
$ kustomize build demo/overlays/staging | kubectl apply -f - # 或者 kubectl apply -k
(4)
namePrefix: production- commonLabels: variant: production org: acmeCorporation commonAnnotations: note: Hello, I am production! bases: - ../../base patchesStrategicMerge: - deployment.yaml
执行：
$ kustomize build demo/overlays/production | kubectl apply -f - # 或者 kubectl apply -k
(5) We can see only the updated part as follows.
apiVersion: apps/v1 kind: Deployment metadata: name: the-deployment spec: replicas: 10
GitOps可行性
# 定制工作流步骤如下： 1、创建一个目录用于版本管理 git init ~/ldap 2、创建一个 base mkdir -p ~/ldap/base # 在这个目录中创建并提交 kustomization.yaml 文件和一组资源，例如 deployment、service 3、创建 overlays mkdir -p ~/ldap/overlays/staging mkdir -p ~/ldap/overlays/production 4、生成 variants kustomize build ~/ldap/overlays/staging | kubectl apply -f - kustomize build ~/ldap/overlays/production | kubectl apply -f - kubectl v1.14 版使用下面： kubectl apply -k ~/ldap/overlays/staging kubectl apply -k ~/ldap/overlays/production
# 现成配置工作流步骤如下： 1、通过 fork 方式获得现成配置 2、clone 作为你的 base mkdir ~/ldap git clone https://github.com/$USER/ldap ~/ldap/base cd ~/ldap/base git remote add upstream git@github.com:$USER/ldap 3、创建并填充 overlays mkdir -p ~/ldap/overlays/staging mkdir -p ~/ldap/overlays/production 4、生成 variants kustomize build ~/ldap/overlays/staging | kubectl apply -f - kustomize build ~/ldap/overlays/production | kubectl apply -f - 5、(可选)更新上游配置，用户可以定期更新他的 base, 以更新上游所做的修改 cd ~/ldap/base git fetch upstream git rebase upstream/master
End.
