为何GKE中必须使用负载均衡器？与裸金属K8s差异解析

这个问题的核心在于托管Kubernetes（比如GKE）和自建裸金属集群的网络架构本质差异，我来一步步拆解清楚：

1. GKE的集群网络基础限制 #

GKE默认基于Google Cloud VPC构建，集群节点（GCE虚拟机）默认是仅私网可达的——它们没有直接绑定公网IP（除非你在创建集群/节点池时手动开启公网访问）。这和你的裸金属环境完全不同：裸金属节点通常直接接入公网，或者可以直接暴露端口到公网，流量能直接打到节点上。

在GKE里，要让公网流量进入集群，必须有一个“桥梁”把公网流量转发到私网内的节点/服务。而Kubernetes的LoadBalancer类型Service在云厂商托管集群中，默认会触发云控制器创建对应的云原生负载均衡器（GCE LB），这就是你看到计费项的直接原因。

2. 为什么nginx-ingress在GKE也会产生LB？ #

当你在GKE部署标准的nginx-ingress chart时，默认的Service类型是LoadBalancer。Kubernetes会通过GCP的云提供商插件自动请求创建GCE外部负载均衡器，用来把公网流量转发到nginx-ingress的Pod上。

如果不想产生这个计费LB，你可以调整nginx-ingress的部署配置：

• 把Service类型改成NodePort，然后确保你的集群节点有公网IP（创建节点池时勾选“允许节点访问公网”，或者给节点分配静态公网IP），之后用户可以通过节点公网IP:NodePort访问服务，或者配置DNS解析到这些节点IP。
• 或者用HostNetwork模式部署nginx-ingress Pod，让nginx直接监听节点的80/443端口，同样需要节点有公网IP，这样流量可以直接打到节点的80/443端口，完全不需要额外LB。

不过要注意：这种方式会失去GCE LB的高可用能力——如果某个节点宕机，指向该节点的流量会中断，你需要自己做健康检查和故障转移（比如DNS轮询、第三方监控工具）。

3. GKE原生Ingress（L7负载均衡器）的本质 #

GKE提供的原生Ingress资源，本身就是深度绑定GCE L7负载均衡器设计的。它的核心作用是把Kubernetes的Ingress规则转换成GCE LB的配置，自动创建和管理GCE LB，所以使用它必然会产生GCE LB的计费项——这是它的工作机制，没办法绕过。

总结对比 #

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