Introduction

When you want to change only the host field of a Kubernetes Ingress in Kustomize, the cleanest solution is usually a targeted patch. That keeps the base manifest unchanged and avoids copying the full Ingress definition into every overlay.

Start With a Simple Base Ingress

Assume the base resource looks like this:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: web
5spec:
6  rules:
7    - host: old.example.com
8      http:
9        paths:
10          - path: /
11            pathType: Prefix
12            backend:
13              service:
14                name: web
15                port:
16                  number: 80

The goal is to replace only spec.rules[0].host in an overlay while leaving paths, backend service, annotations, and other fields untouched.

Use a JSON 6902 Patch for Precision

For a single field inside a list item, a JSON patch is often the most precise option.

overlays/prod/kustomization.yaml

1resources:
2  - ../../base
3
4patches:
5  - target:
6      kind: Ingress
7      name: web
8    patch: |-
9      - op: replace
10        path: /spec/rules/0/host
11        value: prod.example.com

Running kubectl kustomize overlays/prod or kubectl apply -k overlays/prod produces the same Ingress as the base except for that host value.

This approach is explicit and easy to review because the patch tells you exactly which field changed.

Remember Related Host Fields

Ingress resources sometimes repeat the hostname in more than one place. For example, if TLS is configured, the same host may also appear under spec.tls[].hosts[].

1patches:
2  - target:
3      kind: Ingress
4      name: web
5    patch: |-
6      - op: replace
7        path: /spec/rules/0/host
8        value: prod.example.com
9      - op: replace
10        path: /spec/tls/0/hosts/0
11        value: prod.example.com

If you update only the rule host and forget the TLS host list, the rendered manifest may be internally inconsistent.

When a Strategic Merge Patch Is Enough

You can also use a YAML patch file when the resource shape is simple and stable.

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: web
5spec:
6  rules:
7    - host: prod.example.com

This can work, but arrays are the tricky part. JSON patch is usually safer when you want to say "change only this exact host field at this exact path."

Why a Patch Is Better Than Duplicating the Whole Ingress

Copying the full Ingress into every overlay makes later maintenance harder. A small patch is easier to review, less likely to drift from the base, and clearer about intent. Someone reading the overlay can immediately see that the environment-specific change is just the hostname.

That is exactly the sort of change Kustomize overlays are good at expressing.

Validate the Rendered Manifest

Before applying the overlay, render it locally and inspect the output. That step confirms the host changed where you expected and nowhere else.

kubectl kustomize overlays/prod

It is a small step, but it catches bad patch paths before deployment. That saves cluster debugging time later. It is worth doing every time.

Common Pitfalls

• If the host also appears in spec.tls, patch both places.
• JSON patch paths are index-based, so changing rule order in the base may require updating the patch.
• A broad YAML patch can accidentally replace more than you intended if the list structure changes.
• Always inspect the rendered output with kubectl kustomize before applying it to the cluster.

Summary

• Use a targeted Kustomize patch when you only need to replace the Ingress host.
• JSON 6902 patches are usually the most precise way to update spec.rules[0].host.
• Patch related TLS host entries too if they exist.
• Keep the base manifest generic and put environment-specific hostnames in overlays.