kustomize 颤抖吧helm!

前言

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

• 多租户支持不了

• 搞个tiller服务端，鸡肋

• 扯出自己很多概念

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

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

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

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

$ 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 了：

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

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

我们 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 就完美保持一致了，再也不用担心上错版本了。

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

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

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

php 的 yaml 文件可以这样写：

然后配置下 kusztomize：

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

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

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

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

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

云原生是一种信仰 

扫码关注公众号

回复 「电子书」下载 Kubernetes 指南

如需商业合作，请发邮件至领导邮箱： [email protected] ，这是领导的照片

给个[在看]，是对我最大的支持