这在从某个基础类继承并想要对该基础进行部分更改时非常方便。这样,您可以拥有一个源YAML文件,并根据其执行不同的自定义操作,而无需重新创建整个资源。这是kustomize的一个关键卖点。
策略合并补丁
的目的是能够部分地修补丰富对象,而不是完全替换它们。
想象一下,您有一个对象列表。
mylist:
- name: foo
- name: bar
- name: baz
如何更改列表中的一个项目?使用标准合并补丁,您只能替换整个列表。但是,使用战略合并补丁,您可以基于某些属性针对列表中的一个元素进行定位,这种情况下仅名称有意义,因为它是唯一的属性。
mylist:
- $patch: delete
name: foo
在上面的例子中,我使用了策略性合并补丁来删除名为foo的列表项。
以下是另一个例子,假设我有以下项目结构。
sample
├── base
│ ├── kustomization.yaml
│ └── pod.yaml
└── layers
└── dev
├── kustomization.yaml
└── patch.yaml
在基础部分,是我的完整的 Pod 定义。而在层级中,我可以为不同的环境创建多个层级,在这种情况下,我只有一个用于开发的层级。
base 文件夹中的 kustomization.yaml 如下所示。
resources:
- pod.yaml
如果我执行基本的dry run,我会得到这个。
kubectl apply -k sample/base --dry-run=client -o yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp
namespace: default
spec:
containers:
- image: nginx
name: nginx
- command:
- sleep
- infinity
- image: busybox
name: sidecar
在 dev 目录中,kustomization.yaml 文件看起来是这样的。
bases:
- ../../base
patchesStrategicMerge:
- patch.yaml
补丁看起来像这样。我想为旁路启用调试日志记录。因此,我使用合并指令来更改其参数而不更改图像。我还想保留nginx容器。
apiVersion: v1
kind: Pod
metadata:
name: myapp
spec:
containers:
- $patch: merge
name: sidecar
args: [log-level, debug]
kubectl apply -k sample/layers/dev/ --dry-run=client -o yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp
namespace: default
spec:
containers:
- args:
- log-level
- debug
command:
- sleep
- infinity
image: busybox
name: sidecar
- image: nginx
name: nginx
注意:命令和参数并没有太多意义,只是为了说明策略性合并补丁。