Nginx Ingress Controller在Kubernetes中的工作原理及GKE双外部IP疑问

让我帮你把这两个问题拆解清楚，都是GKE上使用Nginx Ingress Controller时的常见疑问：

简单来说，它就是集群里的「流量调度员」，核心工作流程是这样的：

• 它以Pod的形式运行在集群中，会持续监听Kubernetes API Server里的Ingress资源变化——比如你新增、修改了域名转发规则，它都会第一时间感知到。
• 一旦Ingress资源有变动，它会自动生成对应的Nginx配置文件（包含域名路由、TLS证书配置、路径转发规则等），然后重新加载Nginx服务，让新规则生效。
• 要让外部流量能打到这个Nginx Pod，我们通常会给它绑定一个LoadBalancer类型的Service——这个Service会请求GCP创建一个公网负载均衡器，把外部流量转发到Nginx Pod上。
• 当用户的请求到达Nginx后，它就会根据配置好的规则，把请求转发到对应的后端Service，最终到达业务Pod。

先补全你给出的命令输出（应该是漏写了Nginx相关的Service条目）：

kubectl get ingress
NAME HOSTS ADDRESS PORTS AGE
nginx-ingress example.com 1.1.1.1 80,443 1d
kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-ingress-controller LoadBalancer 10.31.245.123 2.2.2.2 80:30080/TCP,443:30443/TCP 1d
hello-app ClusterIP 10.31.251.77 8080/TCP 1d
kubernetes ClusterIP 10.31.240.1 443/TCP 1d

这两个IP的身份和作用完全不同：

• LoadBalancer Service的外部IP（2.2.2.2）：这是GCP为你创建的**Network Load Balancer（NLB）**的公网IP。它的作用是把外部的TCP流量（80/443端口）直接转发到运行Nginx Ingress Controller的Pod上。如果你的Nginx Service配置了externalTrafficPolicy: Local，这个NLB还会直接把流量打到有Nginx Pod的节点，避免额外的节点间转发损耗。
• Ingress资源的外部IP（1.1.1.1）：这个情况分两种可能：
  1. 正常同步延迟：Nginx Ingress Controller会自动把LoadBalancer Service的外部IP同步到Ingress资源的ADDRESS字段里。如果刚部署完就查看，可能因为同步延迟出现两个不同的IP，等几分钟再看就会一致了。
  2. 误触发了GKE默认Ingress Controller：GKE本身自带一个默认的Ingress Controller（基于GCP的HTTP(S) Load Balancer），如果你创建Ingress资源时没有添加kubernetes.io/ingress.class: nginx注解，GKE的默认Controller会同时处理这个Ingress，创建一个HTTP(S) LB并分配一个IP（就是1.1.1.1），而你部署的Nginx Service的NLB是另一个IP，就会出现两个独立的公网IP。

解决办法也很简单：给你的Ingress资源加上ingress.class注解，确保只有Nginx Ingress Controller处理它，过一会儿Ingress的ADDRESS就会和Service的外部IP同步了。

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