如何通过kustomize overlays修改GKE Ingress多host且不丢失原有配置

你遇到的配置丢失问题，根源是Kubernetes 对内置 Ingress 资源的 spec.rules 字段，默认定义了 patchStrategy: replace 的合并策略——只要补丁中包含 spec.rules 字段，不管你写的内容多简单，整个 spec.rules 数组都会被补丁里的内容完全替换，不会逐字段、逐元素合并。这就是为什么你只写了两个带 host 的条目，原配置里的 http 路径、后端服务等所有同数组下的内容会全部丢失。
结合你当前使用的 Kustomize v4.1.2、kubectl v1.21.0 版本，以下是两个可直接落地的解决方案： #

这种方式绕开 Kubernetes 内置的 strategic merge 逻辑，直接按精确路径修改指定的 host 字段，完全不会触碰其他配置，在你当前版本上可以零改造运行，是仅需替换host值、其余配置完全复用base场景的最优解。

1. 在 dev overlay 目录下新建补丁文件 ingress-host-patch.yaml，按数组索引定位要修改的 host 位置：

   # overlays/dev/ingress-host-patch.yaml
   - target:
       group: networking.k8s.io
       version: v1beta1
       kind: Ingress
       name: my-ingress
     patch: |-
       # 替换数组索引0位置的host（对应原配置的 myfirstdomain 条目）
       - op: replace
         path: /spec/rules/0/host
         value: dev1.example.com
       # 替换数组索引1位置的host（对应原配置的 myseconddomain 条目）
       - op: replace
         path: /spec/rules/1/host
         value: dev2.example.com
   

2. 在 dev 环境的 kustomization.yaml 中注册这个补丁：

   # overlays/dev/kustomization.yaml
   resources:
     - ../../base  # 指向你基础Ingress配置的路径
   patches:
     - ingress-host-patch.yaml
   

3. 执行 kustomize build overlays/dev 后，生成的配置会完整保留原有的所有 http 路径、后端服务配置，仅对应位置的 host 字段会被替换为dev环境的域名。

注意： 补丁里的索引值需要和 base 配置中 spec.rules 的数组顺序严格一一对应，如果后续 base 调整了 rules 的排列顺序，记得同步修改补丁里的索引路径，避免改错位置。

如果不同环境的路径、后端配置本身就有比较大的差异，不需要继承 base 的路径配置，可以直接在 overlay 中把对应 host 的完整规则块写全，放在 patches 字段中做整体替换。这种方式不需要担心索引匹配的问题，但要求你把所有需要保留的路径、后端配置在补丁里完整写出来，避免遗漏。示例补丁内容：

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: dev1.example.com
    http:
      paths:
      - path: /abc
        backend:
          serviceName: abc
          servicePort: abc
      - path: /def
        backend:
          serviceName: def
          servicePort: def
      - path: /ghi
        backend:
          serviceName: ghi
          servicePort: ghi
  - host: dev2.example.com
    http:
      paths:
      - backend:
          serviceName: xyz
          servicePort: xyz

这种方式的缺点是：如果后续base的Ingress路径、后端配置有调整，所有环境的overlay补丁都需要同步修改，维护成本较高，因此仅推荐在环境配置和base差异较大的场景使用。 #

内容的提问来源于stack exchange，提问作者Rakib