kustomize的自述文件指出
这种类比是否超出了使用文件声明所需内容的事实呢?
或者,像make一样,kustomize向后链接是否在执行工作之前先读取所有命令输入,而不是顺序工作并像bash一样通过shell脚本逐步执行命令输入?
编辑: Google Kustomize团队的Jeff Regan解释了kustomize在他的演讲Kustomize: Kubernetes Configuration Customization开始之前的工作方式模型。他还展示了如何将kustomize菊花链式链接起来,以便一个kustomize的输出可以用作另一kustomize的输入。如下面的ITChap所指出的那样,看来kustomize首先是在基本目录的kustomization.yml文件中收集所有引用的资源。它在一系列步骤中顺序执行,以交互执行所需的替换和转换。根据需要重复完成替换/转化步骤。然后在标准输出上吐出生成的YAML。所以我想说,它不是像make那样的反向链接,而是介于两者之间的某个位置。 HTH。
最佳答案
到目前为止,我注意到kustomize将首先累积所有基本资源的内容,然后应用kustomization.yml
文件中的转换。如果您有多层叠加层,似乎不会将结果从一个层传递到下一层。
让我们考虑以下内容:./base/pod.yml
:
apiVersion: v1
kind: Pod
metadata:
name: test
spec:
containers:
- name: test
image: busybox
./base/kustomization.yml
:apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../pod.yml
./overlays/l1/kustomization.yml
:apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../base
nameSuffix: "-l1"
./overlays/l2/kustomization.yml
:apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../l1
nameSuffix: "-l2"
运行
kustomize build overlays/l2
时,您将按预期获得名为test-l1-l2
的Pod。但是,如果您尝试修补基本容器,则必须使用以下方法引用容器:
patchesJson6902:
- target:
version: v1
kind: Pod
name: test
path: patch.yml
在您的
./overlays/l1/kustomization.yml
中,也需要在./overlays/l2/kustomization.yml
中的中。在应用l2的补丁时,引用的资源仍然是test
而不是test-l1
。我不知道如何充分理解这一背后的意图,但这是我的观察。希望它能回答您的问题。
PS:这可能会随着https://github.com/kubernetes-sigs/kustomize/issues/1036而改变