外部HTTP负载均衡器配置TCP 80端口VPC防火墙规则的必要性

核心原因 #

• GCP VPC默认存在隐式拒绝所有入站流量的规则，没有显式放通的流量会在网卡层直接被丢弃，和上层负载均衡、K8s Service的配置是否正确无关。
• GCP外部HTTP负载均衡器是谷歌托管的全球资源，不属于你租户VPC内的资源，不会默认获得VPC内部流量的信任权限。它转发业务流量、发送健康检查到后端GKE节点/Pod的请求，都属于进入VPC的入站流量，必须匹配放通规则才能正常到达后端。
• 很多人实操时踩的典型坑：配完公网LB、Ingress规则、Nginx工作负载就以为链路通了，结果因为防火墙拦截，出现LB健康检查失败、公网访问返回502/连接超时的问题。
• 配置这条规则不需要把80端口对所有公网IP开放，你可以直接指定源范围为GCP官方公布的负载均衡转发、健康检查专用地址段，或者直接引用GCP预置的负载均衡相关源标签，完全符合最小权限安全原则，不会造成节点端口的公网暴露风险。

对你的架构设计思路的反馈 #

• 你梳理的「公网用户→外部HTTP负载均衡器→GKE集群工作负载→Nginx容器」主流量路径是正确的，但遗漏了VPC防火墙的生效位置：它是在VPC边界、每台GKE节点的虚拟网卡层面做流量过滤的，不是部署在负载均衡器侧的组件。
• 两个你目前架构理解里可以补充的细节：
  • 如果你用LoadBalancer类型Service暴露Nginx服务，LB的流量会先打到GKE节点对应的NodePort上，再经过节点上的kube-proxy组件转发到运行Nginx的Pod，这一段到节点NodePort的流量同样受VPC防火墙管控。
  • 如果你开了容器原生负载均衡能力（LB直接把流量转发到Pod IP，不经过NodePort转发），Pod虚拟网卡的流量同样受VPC防火墙规则约束，依然需要放通对应80端口的入站规则。
• 架构优化建议：配置防火墙规则时不要用0.0.0.0/0作为源地址，优先使用GCP托管的系统源标签限定流量仅来自官方负载均衡组件，在满足连通性要求的前提下最大程度收敛攻击面。

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