能否通过Kustomize为未声明base的任意Kubernetes资源打补丁？

这不是Kustomize的固有局限，属于操作逻辑遗漏。

核心原因 #

Kustomize的补丁机制只会作用于当前kustomization.yaml中resources字段显式声明的基础资源。你当前的配置没有定义resources指向要修改的ebs-csi-controller Deployment，Kustomize没有可处理的基础对象，自然执行kustomize build没有输出，和你使用YAML格式补丁还是JSON格式补丁无关。
你之前手动添加Deployment文件作为base引用后补丁生效，恰好符合Kustomize的工作逻辑：它基于你给出的基础资源，叠加补丁后生成最终配置。

另外你当前的kustomization.yaml里设置了namespace: flux-system，如果保留该配置，会强制将所有处理后的资源的命名空间改为flux-system，和你目标资源所在的kube-system冲突，建议删除该配置。

适配场景的解决方案 #

你使用FluxCD做资源协调，不需要手动维护Kops生成的Deployment本地base文件，有两种可行方案：

• 方案1：直接使用Flux Kustomization CR的原生补丁能力
  你可以直接在对应协调集群资源的Flux Kustomization自定义资源中添加补丁配置，Flux会直接匹配集群中已存在的目标资源应用补丁，不需要你将资源加入Kustomize的resources列表。示例配置如下：

  apiVersion: kustomize.toolkit.fluxcd.io/v1
  kind: Kustomization
  metadata:
    name: cluster-addons
    namespace: flux-system
  spec:
    interval: 10m0s
    path: ./clusters/my-cluster/addons
    prune: true
    sourceRef:
      kind: GitRepository
      name: flux-system
    # 直接添加补丁配置
    patches:
      - target:
          kind: Deployment
          name: ebs-csi-controller
          namespace: kube-system
        patch: |-
          apiVersion: apps/v1
          kind: Deployment
          metadata:
            name: ebs-csi-controller
            namespace: kube-system
            labels:
              super: patched
  

• 方案2：Kustomize目录引用远程base
  如果你坚持要在本地Kustomize目录中管理补丁，可以在kustomization.yaml的resources字段中直接引用Kops对应版本aws-ebs-csi-driver addon的官方部署清单作为远程base，不需要本地维护Deployment文件。

内容的提问来源于stack exchange，提问作者H. Tazi