在之前的文章中,我曾经说过,相对于 Helm Chart,Kustomize 具有更平缓的学习曲线,更灵活的派生方式,当然这也不是没有代价的,Kustomize 的分享方式和规范性都弱于 Helm Chart,而且上游对下游也是相当缺乏控制能力的。
本文会从实际出发,列出一系列的场景,看看拿到一个上游应用的标准 YAML 之后,如何使用 Kustomize 对其进行增删改查,形成新的 Kubernetes 资源组,完成对派生应用的定义。
准备工作
首先我们创建实验目录 lab/base
,在其中生成一组 YAML 文件,作为后续实验的基础(base
),这是一个很简单的应用,只有一个 Deployment:
deploy.yaml:
代码语言:javascript复制apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: flaskapp
spec:
replicas: 1
template:
metadata:
labels:
app: flaskapp
version: v1
spec:
containers:
- name: flaskapp
image: dustise/flaskapp
imagePullPolicy: IfNotPresent
env:
- name: version
value: v1
ports:
- containerPort: 80
如果使用 Kubectl 提交,会在当前命名空间中新建一个 Deployment 和一个 Pod,当然我们暂时不会这么做。
接下来是创建一个 Kustomize 的定义,作为后续实验的基础,基础定义很简单,它甚至可能不会由上游应用的开发者编写,而是下游的定制者用它来做一个基础。
kustomization.yaml
:
resources:
- deploy.yaml
对它进行渲染,会毫无意外的出现一个和 deploy.yaml
一样的输出内容:
kubectl kustomize base
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: flaskapp
spec:
replicas: 1
template:
metadata:
labels:
app: flaskapp
...
增
创建一个新的工作目录,
lab/overlays/c
,本节的内容都会使用这个目录来完成。
在继承上游应用的 YAML 时,经常需要向其中加入定制元素,比如加入新的 Ingress、Service、Configmap 等,还有可能新增一些对象内的定义。下面的两个例子分别展示了 Kustomize 完成这类任务的方法。
加入新对象
上面的 Base 中,有了一个孤零零的 Deployment,多数的业务应用还是需要有个 Service 提供服务的,我们就给它加入一个新对象。
在 c
目录中,新建一个 service.yaml
:
apiVersion: v1
kind: Service
metadata:
name: flaskapp
labels:
app: flaskapp
spec:
selector:
app: flaskapp
version: v1
ports:
- name: http
port: 80
targetPort: 80
然后新建一个 kustomization.yaml
:
bases:
- ../../base
resources:
- service.yaml
执行命令 kustomize build overlays/c
,可以看到,在原有 Deployment
的基础上,新增了一个服务。
新增字段
很多应用都会声明运行时的资源需求,但是我们的 base
中并没有这个字段,Kustomize 可以用补丁的方式加入这个字段。
首先创建一个补丁文件 overlays/c/resource-patch.yaml
:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: flaskapp
spec:
replicas: 1
template:
spec:
containers:
- name: flaskapp
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "64Mi"
cpu: "250m"
上面的补丁文件用最简单的字段赋值标识出了要打补丁的位置,并加入了资源限制。
修改 overlays/c/kustomization.yaml
,加入补丁:
bases:
- ../../base
resources:
- service.yaml
patchesStrategicMerge:
- resource-patch.yaml
再次使用 kustomize build overlays/c
,或者直接使用 kubectl apply -k overlays/c
,都能看到,资源限制已经应用。
创建 Configmap 并加载
在 overlays/c
下面新建一个配置文件 config.ini
:
key=value
新增的 configMapGenerator
要求使用 config.ini
生成一个 ConfigMap。
然后再做一个补丁文件 env-patch.yaml
,用来加载 Config:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: flaskapp
spec:
replicas: 1
template:
spec:
containers:
- name: flaskapp
env:
- name: CONFIG
valueFrom:
configMapKeyRef:
name: config-ini
key: config.ini
修改 kustomization.yaml
,加入我们的 Configmap 和补丁,结果为如下内容:
bases:
- ../../base
resources:
- service.yaml
configMapGenerator:
- name: config-ini
files:
- config.ini
patchesStrategicMerge:
- resource-patch.yaml
- env-patch.yaml
generatorOptions:
disableNameSuffixHash: true
kubectl apply -k overlays/c
之后,会看到 Pod 中加入了对 Configmap 的引用,进入 Pod 也能看到新增的环境变量,例如:
$ kubectl exec -it flaskapp-5b886b8dfc-qq68w env | grep CONFIG
CONFIG=key=value
删
创建一个新的工作目录,
lab/overlays/d
,本节的内容都会使用这个目录来完成。
使用 patchesStrategicMerge
的特定语法,可以删除指定内容。
删除一个对象
在 c
案例中新建的 Service 对象,我并不想要,如何通过 Kustomize
删掉?同样也使用打补丁的方式来解决。首先创建一个继承自 overlays/c
的 Kustomization,在 overlays/d
中创建 kustomization.yaml
:
bases:
- ../c
patchesStrategicMerge:
- remove-svc.yaml
以及 remove-svc.yaml
:
kind: Service
apiVersion: v1
metadata:
name: flaskapp
$patch: delete
运行 kustomize build overlays/d
,可以看到,输出内容中的 Service 不见了。
删除一个字段
接下来我们用类似的方法,删除前面设置的环境变量:
新建一个 remove-field.yaml
:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: flaskapp
spec:
replicas: 1
template:
metadata:
labels:
app: flaskapp
version: v1
spec:
containers:
- name: flaskapp
image: dustise/flaskapp
env:
- name: CONFIG
$patch: delete
再把补丁加入 kustomization.yaml
:
bases:
- ../c
patchesStrategicMerge:
- remove-svc.yamlƒ
- remove-field.yaml
再次 kustomize build overlays/d
,可以看到新的环境变量已经被删除。
改
创建一个新的工作目录,
lab/overlays/u
,本节的内容都会使用这个目录来完成。
除了 patchesStrategicMerge
之外,kustomize
还提供了一些方便快捷的方式能够对特定内容进行修改。
修改名字
可以用 namePrefix 和 nameSuffix 修改对象的名字,例如我们要给所有名字加上 overlay-u
:
kustomization.yaml
:
bases:
- ../c
namePrefix: overlay-u
接下来可以看看结果:
代码语言:javascript复制$ kubectl apply -k overlays/u --dry-run -o yaml | grep -E "^s name:"
name: overlay-u-config-ini
name: overlay-u-flaskapp
name: overlay-u-flaskapp
name: overlay-u-config-ini
name: flaskapp
输出内容中,前三个分别是 ConfigMap、Service 以及 Deployment,第四行中对 Configmap 的引用也修改成了新的名字。
除了修改名字之外,还有以下几个暴力的修改功能:
- 命名空间: namespaces
- 注解: commonAnnotations
- 标签: commonLabels
说这几个东西比较野蛮的原因是:他们的应用范围是整个 Kustomization,例如下面的定制:
代码语言:javascript复制bases:
- ../c
namePrefix: overlay-u
commonLabels:
auto: label
生成之后会发现,从 Service、Deployment、Configmap 一直到 Pod,都会打上新标签。
修改镜像
修改镜像也是个常见任务,相对上面的几个暴力修改,镜像的修改相对精确一点——从一种镜像修改为另一种,例如我们把 flaskapp 的镜像更换为 nginx:alpine
:
kustomization.yaml
:
bases:
- ../c
namePrefix: overlay-u
commonLabels:
auto: label
images:
- name: dustise/flaskapp
newName: nginx
newTag: alpine
修改副本数量
修改副本数量,指定资源名称以及副本数量即可:
例如如下的 kustomization.yaml
:
bases:
- ../c
replicas:
- name: flaskapp
count: 2
使用 kustomize build overlays/u
,会看到 Deployment 的该字段已经改为 2。
查
创建一个新的工作目录,
lab/overlays/r
,本节的内容都会使用这个目录来完成。
前面提到,namePrefix
修改了 ConfigMap 的名称之后,加载这个 CM 的 Deployment 也会修改引用的名称,然而如果在其它位置,例如命令行参数或者环境变量中引用的服务名称之类,就无法完成修改了。假设我们给 Deployment 中加入一个新的环境变量,叫 deploy
,用如下的 kustomization.yaml
实现:
bases:
- ../../base
namePrefix: overlay-r-
patchesStrategicMerge:
- env-patch.yaml
其中引用的 env-patch.yaml
:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: flaskapp
spec:
replicas: 1
template:
spec:
containers:
- name: flaskapp
env:
- name: deploy
value: flaskapp
kustomize build overlays/r
渲染出来之后,很明显的 value 已经无法对应:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: overlay-r-flaskapp
...
- env:
- name: svc
value: flaskapp
- name: version
在 kustomization.yaml
中加入 vars
,用一系列条件选择一个对象来进行引用,为变量赋值:
...
vars:
- name: DEPLOY_NAME
objref:
kind: Deployment
name: flaskapp
apiVersion: extensions/v1beta1
把 env-patch.yaml
中的环境变量定义修改为引用新变量:
...
- name: deploy
value: $(DEPLOY_NAME)
再次 kustomize build overlays/r
,会看到符合预期的输出内容:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: overlay-r-flaskapp
...
- name: deploy
value: overlay-r-flaskapp
命令行
除了上面说的这些声明式的用法之外,kustomize
还提供了更为即兴的 edit
命令,可以进行现场修改,进一步的提高了灵活(混乱)程度,有兴趣的读者可以自行摸索。