Introduction

Kustomize does not have a standard excludeResource field that you can drop into kustomization.yaml to remove an inherited manifest. The normal way to exclude something is to structure your base and overlays so the resource is omitted, or to delete it in an overlay with a patch.

Start With the resources List

Kustomize only builds what you include under resources, plus anything generated by transformers and generators. If a manifest should not appear in a given environment, the cleanest solution is often to keep it out of that overlay's resources list in the first place.

resources:
  - deployment.yaml
  - service.yaml

This is preferable when the resource is optional by design. A staging overlay and a production overlay can each include only the files they actually need instead of adding everything and trying to subtract later.

Remove an Inherited Resource With a Delete Patch

If the resource comes from a shared base and you need to remove it only in one overlay, use a patch with a target selector and a delete directive.

1resources:
2  - ../base
3
4patches:
5  - target:
6      group: batch
7      version: v1
8      kind: Job
9      name: seed-data
10    patch: |-
11      $patch: delete
12      apiVersion: batch/v1
13      kind: Job
14      metadata:
15        name: seed-data

This tells Kustomize to match the Job named seed-data and remove it from the rendered output of that overlay.

Prefer Overlay Design Over Negative Configuration

Delete patches are useful, but they are still a workaround for the fact that the base contains more than a particular environment needs. If several environments need different subsets of resources, a more maintainable structure is to split optional pieces into smaller bases or components and compose them where needed.

That approach makes the inclusion rule obvious. Instead of asking "how do I exclude this thing," the overlay answers "which building blocks belong here."

Verify the Rendered Output

When using delete patches, inspect the final build rather than trusting the file layout by eye. Kustomize applies multiple transformations, so the only reliable answer is the rendered manifest.

kubectl kustomize overlays/dev

If the object is still present, the target selector probably does not match the resource you think it does. Check the exact group, version, kind, and name that exist in the rendered build.

Use Components or Smaller Bases for Reuse

If you keep writing delete patches for the same kinds of resources, that is usually a sign that the base is too broad. Splitting shared resources into smaller bases or components often produces a cleaner long-term setup. Then each overlay adds the pieces it wants instead of carrying extra manifests only to delete them again later.

Common Pitfalls

• Looking for a built-in excludeResource key in the standard Kustomize schema when the usual solution is overlay composition or a delete patch.
• Putting every manifest into a base and then relying on many delete patches instead of designing smaller reusable bases.
• Writing a delete patch with a target that is too broad or too narrow, so the wrong object is matched or nothing is matched at all.
• Forgetting to inspect the final kubectl kustomize output after adding the patch.
• Trying to delete generated resources whose names change, without giving yourself a stable way to target them.

Summary

• Standard Kustomize does not use an excludeResource field for this job.
• Omit resources at the overlay level when possible.
• Use a targeted delete patch when a shared base includes something one environment must remove.
• Keep bases modular so overlays express inclusion rather than subtraction.
• Always verify the rendered manifest after changing kustomization.yaml.