Jelastic托管Kubernetes集群LoadBalancer外部IP pending问题求解

LoadBalancer类型的Service一直卡在pending状态，和你当前把公网IP部署在前置Nginx节点上的架构没有直接因果关系，根本原因是当前集群没有对接可响应LoadBalancer创建请求的外部控制器。
Kubernetes本身不会凭空为Service分配外部IP，LoadBalancer类型的Service的地址分配流程必须依赖云平台/自定义扩展的云控制器管理器（CCM）完成：没有对应控制器介入的情况下，集群会永远停在“等待外部负载均衡创建完成、回传分配IP”的流程里，不管worker节点有没有配置公网IPv4，状态都不会发生变化。

1. 核查集群的CCM组件状态 #

• 如果你是用Jelastic官方K8s一键部署模板创建的集群，直接在Jelastic控制台检查「LoadBalancer插件」是否处于启用状态。如果是自己通过kubeadm等工具手动搭建的K8s集群，大概率完全没有部署Jelastic对应的平台适配插件，这是最常见的pending问题触发原因。
• 可以在集群内执行命令验证组件状态：kubectl get pods -n kube-system | grep cloud-controller-manager，如果没有查到处于Running状态的对应Pod，说明集群缺失核心的LB供应能力，自然无法响应Service的IP分配请求。

2. 适配现有前置Nginx架构完成流量接入 #

你当前已经把所有公网IPv4绑定在前置Nginx节点上，完全没必要强行让K8s平台给每个Service单独分配公网IP，有两种低改动成本的调整方案：

• 低改动快速上线方案：把对应Service的类型从LoadBalancer调整为ClusterIP，通过kubectl get svc <目标Service名称>获取其集群内部的ClusterIP和暴露端口，直接在前置Nginx的配置中新增转发规则，把公网IP上对应端口的流量直接转发到ClusterIP:Port地址即可，这种模式不需要K8s层面提供任何外部IP能力。
• 原生LoadBalancer能力适配方案：如果确实需要保留K8s原生LoadBalancer类型的Service定义，在集群内部署MetalLB组件，采用二层通告模式把你持有的公网IP段纳入集群可分配地址池，组件会自动响应LoadBalancer类型Service的地址分配请求，解决pending卡住的问题。

3. 规避无效配置操作 #

完全不需要给worker节点单独配置外部IPv4地址：给worker绑定公网IP既无法解决LoadBalancer的pending问题，还会打破你当前由前置Nginx统一管控公网入口的流量链路设计，引入额外的安全暴露风险和流量绕行问题。

• 不要误以为只要worker节点有公网IP，LoadBalancer就会自动获取地址：没有LB供应控制器的介入，哪怕所有worker都绑定满公网IP，LoadBalancer的外部IP状态依然会卡在pending。
• 不要认为“公网IP集中在前置Nginx”的架构是设计缺陷：这种统一入口的架构在PaaS平台上是非常成熟的部署模式，只需要调整集群内Service的暴露方式，完全可以稳定承载所有业务访问，不需要推翻现有架构重做。

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