kustomize 颤抖吧helm!

前言

本人是helm的重度用户，但是吧越用越不爽。。。 helm v2版本三大弊病：

• 多租户支持不了
• 搞个tiller服务端，鸡肋
• 扯出自己很多概念

v3版本抛弃tiller算是个进步，但是听说要上撸啊（lua）我就瞬间崩溃了，我只是想渲染个yaml文件而已。好在好多chart包貌似生态很繁荣。。。

今天给大家介绍kustomize是如何让helm寝食难安，做梦都在颤抖的。

1.

安装

kustomize已经集成在高版本(1.14+)的kubectl里了，可以使用 kubectl apply -k [目录] 来执行

安装太低级不说了，装不上的智商估计就不用往下继续看了。。。

2.

快速开始

$ mkdir ~/hello
$ DEMO_HOME=~/hello

$ BASE=$DEMO_HOME/base
$ mkdir -p $BASE

$ curl -s -o "$BASE/#1.yaml" "https://raw.githubusercontent.com\
/kubernetes-sigs/kustomize\
/master/examples/helloWorld\
/{configMap,deployment,kustomization,service}.yaml"

看下目录结构：

base
    ├── configMap.yaml
    ├── deployment.yaml
    ├── kustomization.yaml
    └── service.yaml

configmap deployment service 里就是我们普通的 yaml 文件，再加个 kustomizeation 文件：

文件中指定了一些配置，指定我们把哪些个文件进行合并

build 一下就会输出整个 yaml 了：

很简单吧，是不是发现没什么卵用，咱再继续。

3.

预上线配置与生产配置

我们经常会遇到如开发环境与生产环境的配置文件不一样的情况，典型的配额与副本数不一样。 我们现在就来处理这种场景：staging 环境与 production 环境。

$ OVERLAYS=$DEMO_HOME/overlays
$ mkdir -p $OVERLAYS/staging
$ mkdir -p $OVERLAYS/production

如两个环境的 configmap 不一样的场景：

这样我们用下面的 configmap 去更新 base 中的，这里相当于增加了俩字段。

再 build 一下观察 configmap 变化：

production 同理不再赘述了， 然后就可以部署到 k8s 集群中：

$ kustomize build $OVERLAYS/staging | kubectl apply -f -

或者：

$ kubectl apply -k $OVERLAYS/staging

4.

设置字段，如镜像tag

我们 yaml 文件中镜像有 tag，每次版本更新都去修改文件比较麻烦。特别是在 CI/CD 时有可能取的是类似 DRONE_TAG 的环境变量用作镜像 tag。

$ cd base
$ kustomize edit set image monopole/hello=alpine:3.6

kustomization.yaml 中就可以看到：

再 build 时 deployment 中镜像就变了：

这样在 CI/CD 时以 drone 为例就可以直接这样：

这样你代码的 tag 与构建镜像的 tag 以及 yaml 文件中的 tag 就完美保持一致了，再也不用担心上错版本了。

5.

注入 k8s 运行时数据

kustomize 有个很强大的特性就是允许注入 k8s 运行时的一些数据，举个栗子：

假设部署个 php 要去连 mysql，但是只知道 mysql 的 Service name，并不知道端口号是啥，那么 kustomize 就可以帮你解决这个问题：

这里给个获取 metadata.name 的例子，其它运行时数据一个理

php 的 yaml 文件可以这样写：

然后配置下 kusztomize：

这是个十分强大的特性，比如有时我们觉得 DNS 不够稳定或者短链接多不想走 DNS 服务发现，A 访问 B 时想直接用 B 的 clusterip，但是 B 部署之前又不知道 IP 是啥，就可以通过这种方式获取到 clusterip，理解了这个原理就可以随意发挥了。

6.

json patch

同样可以通过指定 json patch 对 yaml 进行修改, yaml 和 json 格式都支持：

还可以把一个 patch 打到多个对象上，比如我们给所有 Deployment 加探针啥的：

7.

总结

个人是不太喜欢重的东西的，只是管理个 yaml 文件而已真的不用搞那么复杂。当初 helm v2 时想通过程序去调用时发现非常麻烦，还得找个 swift 项目中转，结果 swift 有些返回值非常之不友好，还需要自己去解析一波，还是挺痛苦的回忆。

我觉得简单 yaml kustomize 很够用,需要复杂精细的控制时 helm 也无可奈何还得靠 operator 发挥，这上下一挤压让 helm 处境就比较尴尬了。。。 kustomize 还被集成到 kubectl 里了这样确实更方便了。