在kustomization.yaml中排除资源

Question

我有一个 Kustomize 的基础配置，希望能够在不编辑它的情况下重复使用。但很遗憾，它会创建一个我不想要的命名空间。 我希望在编译清单时简单地将该资源从考虑范围内移除，并添加一个我的资源，因为我无法补丁命名空间以更改名称。

这能做到吗？ 如何操作？

- Josiah

---

你能提供更多的信息吗？比如你使用的教程、配置文件，以及你正在使用的开发环境。 - Malgorzata

不是很确定，这是内部事情。我会尝试模拟一个例子。 - Josiah

Answer 1

您可以通过使用战略合并补丁的删除指令来省略特定资源，就像这样。

文件夹结构

$ tree .
.
├── base
│   ├── kustomization.yaml
│   └── namespace.yaml
└── overlays
    ├── dev
    │   └── kustomization.yaml
    └── prod
        ├── delete-ns-b.yaml
        └── kustomization.yaml

文件内容

$ cat base/kustomization.yaml
resources:
  - namespace.yaml

$  cat base/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: ns-a
---
apiVersion: v1
kind: Namespace
metadata:
  name: ns-b

$ cat overlays/dev/kustomization.yaml
bases:
  - ../../base

$ cat overlays/prod/delete-ns-b.yaml
$patch: delete
apiVersion: v1
kind: Namespace
metadata:
  name: ns-b

$ cat overlays/prod/kustomization.yaml
bases:
  - ../../base
patches:
  - path: delete-ns-b.yaml

行为的kustomize

$ kustomize build overlays/dev
apiVersion: v1
kind: Namespace
metadata:
  name: ns-a
---
apiVersion: v1
kind: Namespace
metadata:
  name: ns-b

$ kustomize build overlays/prod
apiVersion: v1
kind: Namespace
metadata:
  name: ns-a

在这种情况下，我们在基础文件夹中有两个命名空间。在开发环境中，Kustomize生成2个命名空间，因为没有补丁。但是，在生产环境中，Kustomize仅生成一个命名空间，因为删除补丁删除了命名空间ns-b。

- Toshinori Sugita

---

Toshinori先生，感谢您提供的解决方案，太棒了！ - JamesD

不客气！！ :) - Toshinori Sugita

当我使用 kind: CronJob 尝试时，编译的清单中出现了一堆空对象。 - inostia

这太棒了。它甚至可以在数组内部工作，允许您删除或替换例如副车，而无需使用json6902补丁。不过真的需要更好地记录文档。 - autarch princeps

有没有办法在 kustomization 文件中内联定义此路径？我尝试了几种方法，但只有在补丁指向文件时才能使其正常工作。 - Héctor

这种方法适用于我们的情况 - 通过Argo CD部署OPA Gatekeeper而不使用其Secret。 OPA Gatekeeper的清单附带了一个空的Secret，可以稍后填充。 由于是空的，将其检入Git并不是一个问题。 但是，我们限制了Argo CD，使其不会干扰或监视Secrets，并且具有Secrets的项目在Argo CD中显示警告。 通过在Git中过滤掉空的Secret，Kustomize项目在Argo CD中看起来干净整洁。 - undefined

Answer 2

我遇到了这个问题，最终采用了不同的解决方法。值得思考的是，回顾您的要求并问问自己为什么要让kustomize省略资源？在我的情况下-我想象这是最常见的用例-我希望kustomize省略资源，因为我不想将其应用于目标Kubernetes集群，但是kustomize没有提供一种简单的方法来实现此目的。将过滤功能放在将资源应用于集群时而不是生成它们时进行是否更好？我最终采用的解决方案是，在应用到集群时通过标签对资源进行过滤。您可以在覆盖中添加一个排除标签以防止该资源被应用。

例如：

$ kustomize build . | kubectl apply -l apply-resource!=no -f -

- Ben Davies

---

这是一个快速部署的简洁解决方案，但它能在Flux或ArgoCD的GitOps使用中工作吗？我也倾向于尽可能接近原始结果进行更改，以减少在过程中的混淆。对于一些简单的一次性情况，我不需要自动化和复制我的结果，这是优雅而快速的。 - Josiah

我也喜欢这个解决方案用于快速测试。但是我不喜欢VCS中缺少“-l”过滤器。 - Datz

非常好用，但更短的版本是“kubectl apply -k . -l apply-resource！= no”。 - stackoverflowed

@stackoverflowed 并非所有的 kustomize 功能都有 kubectl 的原生支持，因此我们中遇到这种情况的人通常会使用管道并保存脑细胞来弄清楚我们处于哪种情况。 - Josiah

Answer 3

我发现我的理解，不能更改命名空间名称是不正确的。使用修补程序功能，您实际上可以更改资源的名称，包括命名空间。

这就是我最终使用的：

patches:
- target:
    kind: Namespace
    name: application
  patch: |-
    - op: replace
      path: /metadata/name
      value: my-application

- Josiah