kustomize:如何在没有loadRestrictionsnone的情况下在多个覆盖层中应用相同的补丁
我有一个像这样的布局:
├──release
│ ├──VariantA
│ │ └──kustomization.yaml
│ │ cluster_a.yaml
| └──VariantB
│ └──kustomization.yaml
│ cluster_b.yaml
└──test
├──TestVariantA
│ └──kustomization.yaml; resources=[VariantA]
│ common_cluster_patch.yaml
└──TestVariantB
└──kustomization.yaml; resources=[VariantB]
common_cluster_patch.yaml
我的问题是common_cluster_patch.yaml
的重复。这是一个常见的补丁,我需要将其应用于不同的基本群集对象。我希望不必为每个测试变体维护其相同的副本。
我尝试过的2个失败的解决方案是:
一个常见的补丁资源
├──release
│ ├──VariantA
│ │ └──kustomization.yaml
│ │ cluster_a.yaml
| └──VariantB
│ └──kustomization.yaml
│ cluster_b.yaml
└──test
├──TestVariantA
│ └──kustomization.yaml; resources=[VariantA, TestPatch]
├──TestVariantB
│ └──kustomization.yaml; resources=[VariantB, TestPatch]
└──TestPatch
└──kustomization.yaml
common_cluster_patch.yaml
这是没有ID群集的匹配...
,大概是因为testPatch试图修补一个对象, t包含。
公共补丁目录
├──release
│ ├──VariantA
│ │ └──kustomization.yaml
│ │ cluster_a.yaml
| └──VariantB
│ └──kustomization.yaml
│ cluster_b.yaml
└──test
├──TestVariantA
│ └──kustomization.yaml; resources=[VariantA]; patches=[../TestPatch/common_cluster_patch.yaml]
├──TestVariantB
│ └──kustomization.yaml; resources=[VariantB]; patches=[../TestPatch/common_cluster_patch.yaml]
└──TestPatch
└──common_cluster_patch.yaml
这会失败:'/path/to/test/testpatch/common_cluster_patch.yaml'不在或以下'/path/path/path/to/tot to/test/testvarianta'
。
我可以在此过程中进行工作,并成功地使用kustomize build-load-restrictor loadRestrictionsNOne
来成功生成我的模板,但这带有可怕的警告和预期。我希望有一些更好的方法来组织我的资源,而这些方法不需要解决方法或重复。
I have a kustomize layout something like this:
├──release
│ ├──VariantA
│ │ └──kustomization.yaml
│ │ cluster_a.yaml
| └──VariantB
│ └──kustomization.yaml
│ cluster_b.yaml
└──test
├──TestVariantA
│ └──kustomization.yaml; resources=[VariantA]
│ common_cluster_patch.yaml
└──TestVariantB
└──kustomization.yaml; resources=[VariantB]
common_cluster_patch.yaml
My issue is the duplication of common_cluster_patch.yaml
. It is a common patch which I need to apply to the the different base cluster objects. I would prefer not to have to maintain identical copies of it for each test variant.
The 2 unsuccessful solutions I tried are:
A common patch resource
├──release
│ ├──VariantA
│ │ └──kustomization.yaml
│ │ cluster_a.yaml
| └──VariantB
│ └──kustomization.yaml
│ cluster_b.yaml
└──test
├──TestVariantA
│ └──kustomization.yaml; resources=[VariantA, TestPatch]
├──TestVariantB
│ └──kustomization.yaml; resources=[VariantB, TestPatch]
└──TestPatch
└──kustomization.yaml
common_cluster_patch.yaml
This fails with no matches for Id Cluster...
, presumably because TestPatch is trying to patch an object it doesn't contain.
A common patch directory
├──release
│ ├──VariantA
│ │ └──kustomization.yaml
│ │ cluster_a.yaml
| └──VariantB
│ └──kustomization.yaml
│ cluster_b.yaml
└──test
├──TestVariantA
│ └──kustomization.yaml; resources=[VariantA]; patches=[../TestPatch/common_cluster_patch.yaml]
├──TestVariantB
│ └──kustomization.yaml; resources=[VariantB]; patches=[../TestPatch/common_cluster_patch.yaml]
└──TestPatch
└──common_cluster_patch.yaml
This fails with: '/path/to/test/TestPatch/common_cluster_patch.yaml' is not in or below '/path/to/test/TestVariantA'
.
I can work round this and successfully generate my templates with kustomize build --load-restrictor LoadRestrictionsNone
, but this comes with dire warnings and portents. I am hoping that there is some better way of organising my resources which doesn't require either workarounds or duplication.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
感谢Criztovyl的答案!该解决方案为 kustomize组件。目前仅在
kustomize.config.k8s.io/v1alpha1
和参考文档是一个存根,但它们包含在kustomize的当前版本中。我的解决方案现在看起来像:
where
test/testCommon/kustomization.yaml
具有标头:组件和资源之间的关键差异是在其他处理后将应用组件。这意味着它可以修补包含它的资源中的对象。
Thanks to criztovyl for this answer! The solution is kustomize components. Components are currently only defined in
kustomize.config.k8s.io/v1alpha1
and the reference documentation is a stub, but they are included in current release versions of kustomize.My solution now looks like:
where
test/TestCommon/kustomization.yaml
has the header:The crucial difference between a component and a resource is that a component is applied after other processing. This means it can patch an object in the resource which included it.