如何在GKE Nginx Ingress Controller前部署Global Load Balancer

完全可以在保留Nginx Ingress Controller全部能力的前提下，对接Global Load Balancer并接入Cloud Armor，不需要替换为GKE原生Ingress处理业务路由，以下是经过生产验证的落地方式：

推荐方案：GLB前置对接Nginx Ingress（NEG模式） #

这是GCP官方支持的架构，流量路径最短、配置最简单，完全匹配你的需求：

• 架构逻辑：全局HTTP(S)负载均衡作为公网入口，先经过Cloud Armor做安全防护，再把所有流量转发给集群内部的Nginx Ingress Controller，由Nginx完成后续的七层路由、请求头重写、限流等所有你需要的自定义逻辑。
• 配置要点：
  • 调整现有Nginx Ingress的Service配置：将原来的type: LoadBalancer改为type: ClusterIP，移除原来绑定区域静态IP的相关注解，给Service添加注解cloud.google.com/neg: '{"ingress": true}'，让GCP自动创建网络端点组，直接对接Nginx Pod的IP，跳过额外的L4负载均衡转发。
  • 修改Nginx Ingress的启动参数，添加use-forwarded-headers: "true"，同时配置信任GLB的IP地址段，保证Nginx可以正确获取真实客户端IP，避免自身的访问控制、限流规则因为识别到代理IP失效。
  • 创建一个BackendConfig资源，在spec中关联你提前创建好的Cloud Armor安全策略，把这个BackendConfig通过注解绑定到Nginx Ingress的Service上。
  • 创建一个极简的GKE原生Ingress资源，不需要配置任何细粒度的业务路由规则，只把Nginx Ingress的Service设置为默认后端，给这个Ingress添加两个核心注解：
    • kubernetes.io/ingress.global-static-ip-name: "你提前预留的全局静态IP名称"
    • cloud.google.com/backend-config: '{"default": "你刚创建的BackendConfig名称"}'
      这个原生Ingress的作用只是拉起Global Load Balancer、绑定静态IP和Cloud Armor策略，所有七层流量处理逻辑全部交给后端的Nginx Ingress，你之前写的所有Nginx Ingress资源、注解配置完全不需要改动，可以直接复用。
• 方案优势：
  • 没有额外转发跳数，GLB通过NEG直接和Nginx Pod通信，延迟比多层LB架构低
  • Cloud Armor在GLB层生效，恶意流量在到达集群之前就会被拦截，不占用集群计算资源
  • 可以同时复用GLB的其他原生能力，比如Google托管SSL证书、全球Anycast路由、CDN缓存等，和Nginx的能力不冲突

不推荐方案：手动在现有L4 LB前叠加GLB #

如果你暂时不想改动现有Nginx Ingress的LoadBalancer配置，也可以手动创建Global HTTP(S) Load Balancer，把现有Nginx绑定的区域L4 LB公网IP作为GLB的后端端点。但这个方案存在明显缺陷：

• 多了一层L4 LB转发，增加网络延迟和故障点
• 后端健康检查配置复杂度高，区域级L4 LB的故障会直接影响全局流量可用性
• 无法使用容器原生负载均衡的能力，流量转发效率低于NEG模式

配置注意事项 #

• 前置的GKE原生Ingress不要配置任何路径匹配规则，所有路径全部转发给Nginx处理，避免路由规则冲突
• 预留静态IP时必须选择全局范围，不能选区域范围，否则无法绑定到GLB
• HTTPS证书可以选择卸载在GLB层，使用Google托管免费证书，GLB到Nginx之间用HTTP回源即可，简化证书运维；如果需要端到端加密，也可以在Nginx侧配置证书，GLB配置HTTPS回源。

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