Introduction

Deleting an environment variable with Kustomize is usually a patching problem, not a special Kustomize command. The safest approach is to patch the target Deployment and remove the matching env entry by name, ideally with a strategic merge patch instead of deleting by array index.

Start from the base manifest

Suppose the base deployment contains this container configuration:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: api
5spec:
6  template:
7    spec:
8      containers:
9        - name: api
10          image: my-api:latest
11          env:
12            - name: LOG_LEVEL
13              value: debug
14            - name: FEATURE_X
15              value: "true"

If an overlay should remove FEATURE_X, you should patch that list entry rather than rewrite the whole deployment.

Prefer a strategic merge patch for named env entries

For env lists, Kubernetes understands the name field as the merge key. That means you can delete one specific variable cleanly:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: api
5spec:
6  template:
7    spec:
8      containers:
9        - name: api
10          env:
11            - name: FEATURE_X
12              $patch: delete

Reference that file from kustomization.yaml:

1resources:
2  - deployment.yaml
3
4patchesStrategicMerge:
5  - remove-env.yaml

This is usually the best answer because it is stable and readable. You are deleting by semantic identity, not by list position.

JSON patch also works, but index-based deletes are fragile

You can also use a JSON 6902 patch:

1patches:
2  - target:
3      kind: Deployment
4      name: api
5    patch: |-
6      - op: remove
7        path: /spec/template/spec/containers/0/env/1

This works only if you know the exact array index of the container and the environment variable entry. That makes it fragile. If someone reorders the env list later, the patch may delete the wrong item or fail.

That is why strategic merge is usually preferred when the target list has a clear merge key such as name.

Deleting from envFrom is a different case

If the container uses envFrom to load values from a ConfigMap or Secret, there may not be an individual env entry to delete. In that case, your real options are:

• stop importing that whole source
• split the source so only needed variables are imported
• replace envFrom with explicit env entries for fine-grained control

Trying to delete one variable from inside a referenced ConfigMap through the consuming Deployment will not work, because the variable is not declared there individually.

Preview the rendered result before applying

Always check the overlay output:

kubectl kustomize overlays/prod

Or with standalone Kustomize:

kustomize build overlays/prod

This helps you confirm that the env entry is actually gone before applying the changes to the cluster.

Choose the least brittle patch style

As a rule:

• use strategic merge when deleting a named env entry
• use JSON patch only when strategic merge cannot express the change cleanly

Kustomize is easiest to maintain when patches describe intent in domain terms such as resource name and environment-variable name rather than positional list indices.

Common Pitfalls

• Using a JSON patch with hard-coded list indexes that break when the manifest order changes.
• Trying to delete a variable loaded through envFrom as if it were a direct env entry.
• Patching the wrong container when a pod has more than one container.
• Forgetting to preview the rendered manifest before applying it.
• Replacing the whole env list when only one variable needs to be removed.

Summary

• Removing an environment variable in Kustomize is usually done with a patch.
• A strategic merge patch with $patch: delete is the cleanest option for named env entries.
• JSON 6902 remove operations work, but index-based paths are fragile.
• 'envFrom imports need a different strategy because the variable is not declared individually.'
• Always inspect the rendered output before applying the overlay.