GKE集群内部HTTPS负载均衡器与Ingress流量转发机制咨询

你的猜想流量路径是完全正确的：
USER -> 内部LB(RFC1918地址，SSL终止) -> Nginx Ingress Controller DaemonSet -> ClusterIP Service -> Pod

下面详细拆解你疑惑的各个环节：

一、LB.IP -> Controller Daemon链路的具体工作机制 #

这部分核心是GCP内部LB与GKE节点、Ingress Controller的联动逻辑：

1. 实例组的角色：同事在GCP UI配置LB时指定的实例组，就是GKE集群自动创建的节点管理实例组，它包含了集群中所有运行Ingress Controller DaemonSet的节点（DaemonSet确保每个符合调度条件的节点上都跑一个Ingress Controller Pod）。
2. LB的流量转发规则：内部LB收到客户端请求后，会按预设的负载均衡算法（如轮询）从实例组中选一个健康节点，将流量转发到该节点的指定端口——这个端口是Ingress Controller Pod通过hostPort配置直接占用的节点端口，或是通过hostNetwork: true复用节点网络栈的端口。
3. 节点到Pod的流量传递：因为Ingress Controller Pod已经绑定了节点的对应端口，节点的网络栈会直接把LB发来的流量转发到本地的Ingress Controller Pod，不需要额外经过kube-proxy转发（这也是DaemonSet模式Ingress Controller的高效之处）。
4. VPC/VPN的路由支持：内部LB的RFC1918地址属于VPC子网，VPN接入VPC的客户端可以直接通过VPC路由访问该地址，流量会被导向LB的后端实例组。

二、负责暴露Pod流量到集群外部的Kubernetes对象 #

核心是两个组件的配合：

• Ingress对象：定义流量路由规则，告诉Ingress Controller如何将不同路径、域名的请求转发到对应的ClusterIP Service。它是路由策略的声明层，本身不处理流量。
• Ingress Controller DaemonSet：实际的流量处理入口，通过hostPort/hostNetwork配置在节点上暴露端口，接收来自LB的流量，并严格按照Ingress对象的规则将请求转发到后端Service。

如果你的Ingress Controller是通过NodePort Service暴露的（而非直接绑定节点端口），那么NodePort Service也会起到将Pod端口映射到节点端口的作用，但DaemonSet模式下通常直接用hostPort/hostNetwork来减少kube-proxy的转发开销。

三、为什么“仅配置LB到实例组”就能正常运行 #

这是因为GKE和Ingress Controller的默认配置已经完成了剩下的联动：

1. DaemonSet确保每个节点都运行Ingress Controller Pod，实例组自然包含所有能接收流量的节点。
2. LB的健康检查会自动过滤掉Ingress Controller Pod未正常运行的节点，只将流量发到健康节点。
3. Ingress Controller会自动监听Kubernetes API，同步Ingress对象的路由规则，无需手动配置转发逻辑。
4. GKE节点的网络策略默认允许LB实例组的流量访问节点上的Ingress Controller端口。

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