kustomize:如何在没有loadRestrictionsnone的情况下在多个覆盖层中应用相同的补丁

发布于 2025-02-11 02:01:38 字数 1844 浏览 3 评论 0原文

我有一个像这样的布局:

├──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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

玻璃人 2025-02-18 02:01:38

感谢Criztovyl的答案!该解决方案为 kustomize组件。目前仅在kustomize.config.k8s.io/v1alpha1参考文档是一个存根,但它们包含在kustomize的当前版本中。

我的解决方案现在看起来像:

├──release
│  ├──VariantA
│  │  └──kustomization.yaml
│  │     cluster_a.yaml
|  └──VariantB
│     └──kustomization.yaml
│        cluster_b.yaml
└──test
   ├──TestVariantA
   │  └──kustomization.yaml; resources=[VariantA]; components=[../TestCommon]
   ├──TestVariantB
   │  └──kustomization.yaml; resources=[VariantB]; components=[../TestCommon]
   └──TestCommon
      └──kustomization.yaml; patches=[common_cluster_patch.yaml]
         common_cluster_patch.yaml

where test/testCommon/kustomization.yaml具有标头:

apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Component

组件和资源之间的关键差异是在其他处理后将应用组件。这意味着它可以修补包含它的资源中的对象。

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:

├──release
│  ├──VariantA
│  │  └──kustomization.yaml
│  │     cluster_a.yaml
|  └──VariantB
│     └──kustomization.yaml
│        cluster_b.yaml
└──test
   ├──TestVariantA
   │  └──kustomization.yaml; resources=[VariantA]; components=[../TestCommon]
   ├──TestVariantB
   │  └──kustomization.yaml; resources=[VariantB]; components=[../TestCommon]
   └──TestCommon
      └──kustomization.yaml; patches=[common_cluster_patch.yaml]
         common_cluster_patch.yaml

where test/TestCommon/kustomization.yaml has the header:

apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Component

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文