1. 项目概述为什么K8s集群里LoadBalancer不是“开箱即用”的魔法按钮在某次给某高校实验室做容器化教学支持时一位刚接触云原生的导师直接问我“K8s文档里写的LoadBalancer类型Service我yaml一写服务就自动有公网IP了是不是像买云服务器那样点点鼠标就行”——这个问题背后藏着一个被大量新手忽略的关键事实Kubernetes本身不提供LoadBalancer实现它只定义了一个抽象接口真正让Service暴露到集群外部、分配公网IP、配置四层转发规则的是底层云平台或你手动部署的配套组件。这就是标题里“K8S集群-------部署负载均衡LoadBlance六”中那个长长的破折号所暗示的真实含义这不是一个kubectl apply就能完成的单步操作而是一整套需要你亲手串联、验证、调优的基础设施工程。LoadBalancer Service在K8s中本质是一个“能力声明”它告诉集群“我需要一个具备L4负载分发能力的外部入口”。但K8s控制平面不会自己去阿里云控制台创建SLB也不会自动在本地机房的F5设备上配VIP。它依赖一个叫cloud-controller-managerCCM的组件来对接云厂商API或者依赖你部署的MetalLB这类开源方案来接管物理网络。如果你在自建IDC或本地虚拟机环境比如用kubeadm搭的三节点集群直接创建LoadBalancer类型的Service你会发现service状态卡在PendingEXTERNAL-IP字段永远是pending——这不是bug是设计使然。这恰恰解释了为什么这个主题必须作为系列第六篇出现它建立在前五篇已打好基础的前提下——你已经完成了集群初始化、网络插件Calico/Flannel部署、Ingress控制器安装、DNS配置和监控体系搭建。现在轮到解决“最后一公里”如何让集群外的用户通过一个稳定、可访问、带健康检查的IP地址触达你的业务。对不同场景的用户这个“部署LoadBalancer”的动作意义完全不同对公有云用户如阿里云ACK、腾讯云TKE它意味着理解CCM如何与云平台SLB联动避免因权限配置错误导致SLB创建失败对私有云/边缘场景用户如某制造企业工厂内网的K8s集群它意味着选型MetalLB并配置BGP或Layer2模式让业务能被产线PLC系统通过固定IP访问对学习者而言它是一次深入理解K8s网络模型边界的实战——从Pod IP、ClusterIP、NodePort最终抵达External IP这条链路的每一环都暴露着网络架构的决策逻辑。所以这篇内容不讲“怎么复制粘贴yaml”而是带你拆解当kubectl get svc看到EXTERNAL-IP从pending变成一个真实IP时背后发生了什么哪些组件在协作配置参数背后的网络原理是什么以及为什么你在测试环境用type: LoadBalancer一切顺利上线后却突然发现流量只打到一台节点上这些才是“部署LoadBalancer”这个动作背后真正的技术纵深。2. 核心设计思路公有云、私有云与混合环境的三套解法2.1 公有云场景云厂商CCM是默认答案但绝非“无脑启用”几乎所有主流公有云K8s托管服务EKS、AKS、GKE、ACK都预装了对应厂商的cloud-controller-manager。它的核心职责是监听K8s API Server中Service资源的变化当检测到type: LoadBalancer且status.loadBalancer.ingress为空时便调用云平台API创建负载均衡实例如AWS的ELB、阿里云的SLB并将生成的公网IP或域名写回Service的status.loadBalancer.ingress.ip字段。这个过程看似自动化但实操中90%的故障都源于CCM与云平台的“握手失败”。以阿里云ACK为例CCM需要至少两个关键权限才能完成SLB创建AliyunSLBFullAccess允许创建、删除、修改SLB实例及监听规则AliyunVPCReadOnlyAccess用于获取VPC、交换机信息确保SLB能正确挂载后端节点。提示很多团队在RAM子账号授权时只给了AliyunSLBReadOnlyAccess结果CCM日志报错AccessDeniedService状态卡在Pending。这不是K8s问题是云账号权限粒度没配对。更隐蔽的问题在于SLB规格与节点规格的匹配。CCM默认创建的是slb.s1.small共享型实例但如果你的业务需要HTTPS卸载或WAF集成就必须指定alibabacloud.com/slave-zone-id注解强制使用独享型SLB。而独享型SLB要求后端ECS必须在同可用区——这意味着你的K8s节点组如果跨了3个可用区CCM默认会随机选一个可用区创建SLB导致另外两个可用区的节点无法注册为后端。解决方案是在Service yaml中显式声明apiVersion: v1 kind: Service metadata: name: nginx-lb annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec: slb.s2.small service.beta.kubernetes.io/alibaba-cloud-loadbalancer-master-zoneid: cn-hangzhou-g service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slave-zoneid: cn-hangzhou-h这里master-zoneid和slave-zoneid必须是你节点实际分布的两个可用区ID否则CCM会静默失败。这个细节在官方文档里藏得很深但却是生产环境SLB高可用的基石。2.2 私有云/裸金属场景MetalLB是事实标准但BGP模式才是性能关键当你的K8s集群运行在VMware虚拟机、Proxmox或物理服务器上时云厂商CCM彻底失效。此时MetalLB成为最成熟的选择。它由两部分组成speaker运行在每个节点上的DaemonSet和controller单副本Deployment。controller负责监听Service变化并分配IPspeaker则负责将IP“宣告”给上游网络设备。MetalLB提供两种IP宣告模式Layer 2模式简单粗暴所有节点竞争同一个VIPVirtual IP。当主节点宕机其他节点通过ARP广播抢占VIP。优点是无需上游路由器支持缺点是单点瓶颈——所有流量都打到当前持有VIP的节点再由该节点通过kube-proxy转发到后端Pod无法利用多节点带宽。BGP模式这才是为生产环境设计的方案。每个节点运行BGP客户端主动向上游路由器如Cisco、华为或Linux的Quagga/FRR宣告自己能提供某个IP段的路由。路由器收到多条等价路径ECMP后自动将流量分发到所有健康节点。此时kubectl get nodes -o wide看到的INTERNAL-IP就是BGP会话的源地址而EXTERNAL-IP则是MetalLB分配的、由BGP宣告出去的VIP。注意BGP模式要求上游路由器必须开启BGP并配置peer关系。例如在FRR中需添加router bgp 64512 neighbor 192.168.1.10 remote-as 64513 address-family ipv4 neighbor 192.168.1.10 activate network 10.244.0.0/16其中192.168.1.10是K8s节点IP64513是MetalLB配置的ASN自治系统号。若路由器未配置BGP会话永远处于Idle状态MetalLB日志会持续报错Failed to connect to peer。2.3 混合场景Ingress NodePort是兜底方案但需规避端口冲突当上述两种方案都不可行如某些强监管行业禁止BGP协议或云平台限制SLB创建数量一个被低估的组合是Ingress Controller NodePort Service。原理很简单先创建一个type: NodePort的Service它会在每个节点的固定端口如30080暴露服务再部署Nginx Ingress Controller它本身是一个type: LoadBalancer的Service走云厂商SLB但只监听80/443端口最后通过Ingress资源定义域名路由规则将app.example.com的请求转发到NodePortService。这个方案的优势是完全绕过MetalLB或CCM的复杂性但有两个致命陷阱NodePort端口范围冲突K8s默认NodePort范围是30000-32767。如果你的节点上已有MySQL3306、Redis6379等服务在运行而NodePort恰好分配到30000-32767之外的端口如20000就会因端口被占而启动失败。解决方案是在/var/lib/kubelet/config.yaml中修改nodePort: portRange: 30000-32767并重启kubelet。健康检查穿透问题云厂商SLB对Ingress Controller的健康检查默认探测其Pod的/healthz路径。但如果Ingress Controller本身是通过NodePort暴露的SLB探测的是节点IPNodePort而节点防火墙可能未放行该端口。必须在安全组中显式开放NodePort端口否则SLB会将所有Ingress Controller节点标记为unhealthy流量中断。3. 实操全流程从零部署MetalLB BGP模式含完整配置与验证3.1 环境准备确认网络拓扑与BGP前提条件在开始部署前必须完成三项基础确认缺一不可上游路由器BGP就绪登录你的核心路由器假设是Linux服务器运行FRR执行vtysh -c show ip bgp summary确认输出中能看到State/PfxRcd列为Established且Peer IP是你K8s节点的IP。这是BGP会话建立成功的唯一证据。K8s节点网络互通所有节点必须能互相ping通且能访问上游路由器的BGP端口TCP 179。用telnet 192.168.1.1 179测试连通性。若超时检查iptables是否拦截了179端口iptables -L INPUT | grep 179。MetalLB IP地址池规划为避免与现有网络冲突建议划出一个独立网段。例如你的内网是192.168.1.0/24则MetalLB IP池可设为192.168.200.100-192.168.200.199100个IP。这个网段必须在上游路由器的BGPnetwork命令中宣告否则路由器不知道如何路由这些IP。实操心得我曾在一个客户现场踩坑IP池设为10.0.0.100-10.0.0.199但上游路由器BGP只宣告了10.0.0.0/16导致MetalLB分配的IP能被路由但10.0.0.100这个具体地址在路由器ARP表中查不到MAC流量在二层就丢弃。解决方案是在路由器上为该IP段静态绑定MAC或改用192.168.x.x这类更易管理的私有网段。3.2 部署MetalLB Controller与SpeakerMetalLB官方提供一键部署yaml但生产环境必须定制化# 下载并解压官方manifest curl -OL https://raw.githubusercontent.com/metallb/metallb/v0.13.12/config/manifests/metallb.yaml # 修改namespace为kube-system与kube-proxy一致 sed -i s/namespace: metallb-system/namespace: kube-system/g metallb.yaml # 应用部署 kubectl apply -f metallb.yaml部署后检查Pod状态kubectl -n kube-system get pods -l appmetallb # 输出应为 # NAME READY STATUS RESTARTS AGE # controller-5d8b9c7f4d-2xq9j 1/1 Running 0 2m # speaker-7f8b9c7f4d-abcde 1/1 Running 0 2m关键验证点speakerPod日志必须出现BGP session established字样。用以下命令实时跟踪kubectl -n kube-system logs -l appspeaker -f | grep BGP session # 正常输出类似 # {level:info,msg:BGP session established,peer:192.168.1.1:179,ts:2023-10-05T08:23:45Z}若长时间无此日志立即检查speakerPod的hostNetwork: true是否生效必须为true才能监听179端口节点防火墙是否放行179端口firewall-cmd --permanent --add-port179/tcp上游路由器BGP配置中neighborIP是否与节点IP完全一致注意不要写成127.0.0.1。3.3 配置IP地址池与BGP Peer创建configmap定义MetalLB行为# metallb-config.yaml apiVersion: v1 kind: ConfigMap metadata: namespace: kube-system name: config data: config: | address-pools: - name: default protocol: bgp addresses: - 192.168.200.100-192.168.200.199 auto-assign: true peers: - peer-address: 192.168.1.1 peer-asn: 64512 my-asn: 64513应用配置kubectl apply -f metallb-config.yaml此时MetalLB Controller会立即开始分配IP。创建一个测试Service验证# test-lb.yaml apiVersion: v1 kind: Service metadata: name: nginx-test namespace: default spec: type: LoadBalancer ports: - port: 80 targetPort: 80 selector: app: nginx部署后执行kubectl get svc nginx-test # 输出应为 # NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE # nginx-test LoadBalancer 10.96.123.45 192.168.200.100 80:31234/TCP 10sEXTERNAL-IP从pending变为192.168.200.100证明IP分配成功。但真正的验证在上游路由器登录FRR执行show ip bgp你应该看到类似Network Next Hop Metric LocPrf Path * 192.168.200.100/32 192.168.1.10 0 0 64513 i这表示路由器已学习到该IP的BGP路由下一跳是节点IP192.168.1.10。此时从任何能访问该路由器的设备ping192.168.200.100都应该得到响应。3.4 高级配置多节点ECMP负载与会话保持BGP模式的终极价值在于ECMP等价多路径。默认情况下上游路由器对同一目标IP只会选择一条路径导致流量集中。必须在路由器上启用ECMP# 在FRR中 router bgp 64512 maximum-paths 4然后验证ECMP是否生效在路由器上执行show ip route 192.168.200.100输出应包含多条via 192.168.1.10、via 192.168.1.11等不同下一跳。此时用iperf3从客户端并发测试# 客户端执行模拟多连接 iperf3 -c 192.168.200.100 -P 10 -t 30在各K8s节点上用iftop -P 80观察会发现流量被均匀分摊到所有节点而非集中在一台。对于需要会话保持的业务如老版本Java应用MetalLB支持sessionAffinity: ClientIP但注意这仅在Layer2模式下有效BGP模式下会破坏ECMP。生产环境更推荐在应用层实现如Spring Session Redis而非依赖L4会话保持。4. 常见问题排查从pending到192.168.200.100的12个断点分析4.1 Service状态卡在pending的根因树当kubectl get svc看到EXTERNAL-IP始终为pending按以下顺序逐层排查断点层级检查命令正常现象异常表现与修复1. MetalLB组件是否存在kubectl -n kube-system get deploy,dscontrollerDeployment和speakerDaemonSet均存在且READY为1/1若缺失重新kubectl apply -f metallb.yaml若READY为0/1检查kubectl -n kube-system describe pod speaker-pod中的Events2. Speaker网络模式kubectl -n kube-system get ds speaker -o yaml | grep hostNetwork输出hostNetwork: true若为false编辑DSkubectl -n kube-system edit ds speaker将hostNetwork设为true并删除旧Pod触发重建3. BGP会话状态kubectl -n kube-system logs -l appspeaker | grep BGP session出现BGP session established若无此日志检查上游路由器BGP配置、节点防火墙、speakerPod的hostNetwork设置4. IP池配置语法kubectl -n kube-system get cm config -o yamladdresses字段格式为- 192.168.200.100-192.168.200.199若写成192.168.200.100/24MetalLB会静默忽略该池必须用-开头的列表格式5. 路由器BGP学习vtysh -c show ip bgp 192.168.200.100输出Status: valid, best若显示not in table检查路由器network命令是否包含该IP段或BGP会话是否Established实操心得有一次客户环境pending持续2小时最终发现是speakerDaemonSet的tolerations配置了node-role.kubernetes.io/master:NoSchedule但节点标签是node-role.kubernetes.io/control-plane:NoSchedule导致speakerPod根本无法调度。用kubectl get nodes --show-labels核对标签名比看日志更快定位。4.2 分配IP后无法访问的链路诊断即使EXTERNAL-IP已分配仍可能无法访问。按数据包流向分段验证阶段1客户端→上游路由器用ping 192.168.200.100测试ICMP连通性。若不通检查客户端到路由器的路由、ACL策略。用traceroute 192.168.200.100确认最后一跳是路由器IP而非其他设备。阶段2路由器→K8s节点在路由器上ping 192.168.1.10节点IP确认二层可达。在节点上tcpdump -i any port 80同时从客户端curl http://192.168.200.100。若tcpdump无输出说明路由器未将流量转发到节点检查BGP路由表和ECMP配置。阶段3节点→Pod在节点上执行curl -v http://localhost:31234NodePort确认kube-proxy工作正常。若失败检查kubectl get endpoints nginx-test确认ENDPOINTS字段有IP:PORT如10.244.1.5:80若为空检查Service selector是否匹配Pod标签。阶段4Pod内部kubectl exec -it pod-name -- netstat -tuln \| grep :80确认应用监听0.0.0.0:80而非127.0.0.1:80。kubectl logs pod-name查看应用日志确认无启动异常。4.3 性能瓶颈识别为什么流量只打到一台节点这是BGP模式最常见的幻觉。表面看kubectl get svc显示EXTERNAL-IP但实际流量全在一台节点。原因有三路由器未启用ECMP如前所述maximum-paths未配置路由器默认只选一条路径。BGP路由权重不均在FRR中若为不同节点配置了不同weight会导致路径偏好。执行show ip bgp检查各路径的Weight列是否一致。客户端连接复用HTTP/1.1默认长连接单个客户端的所有请求都复用同一TCP连接自然只走一条路径。用curl -H Connection: close http://192.168.200.100强制短连接或用ab -n 1000 -c 100 http://192.168.200.100/并发压测才能真实反映ECMP效果。注意abApache Bench工具在macOS上需用brew install httpd安装Linux用apt install apache2-utils。别用wrk它默认启用HTTP/2连接复用更激进不利于ECMP验证。5. 生产环境加固安全、可观测性与灰度发布实践5.1 安全加固限制BGP会话与IP分配范围MetalLB默认允许任何BGP peer连接这在多租户环境中是风险。必须通过peer-asn和my-asn进行双向认证peer-asn上游路由器的ASN必须与路由器配置严格一致my-asnMetalLB的ASN必须在路由器BGP配置中声明为remote-as。此外IP地址池应遵循最小权限原则测试环境用192.168.200.100-192.168.200.109仅10个IP生产环境按业务线划分网段如app-a: 192.168.201.0/24、app-b: 192.168.202.0/24并在ConfigMap中为每个网段定义独立address-pool通过Service annotation指定metadata: annotations: metallb.universe.tf/address-pool: app-a5.2 可观测性将MetalLB指标接入PrometheusMetalLB内置Prometheus指标端点/metrics但默认未暴露。需在speakerDaemonSet中添加ports: - containerPort: 7472 name: metrics protocol: TCP并创建ServiceMonitorapiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: metallb-speaker namespace: monitoring spec: selector: matchLabels: app: speaker namespaceSelector: matchNames: - kube-system endpoints: - port: metrics interval: 30s关键指标监控metallb_bgp_peers_established_total值应为1每个speaker对应一个peermetallb_ip_address_total{pooldefault}应等于你配置的IP池总数metallb_ip_assignment_duration_seconds_bucket若99%分位耗时5s说明IP分配慢需检查etcd性能。5.3 灰度发布通过Annotation控制SLB创建时机在公有云场景SLB创建是异步的可能耗时数分钟。若Service创建后立即更新Ingress可能导致流量黑洞。MetalLB提供优雅的灰度控制metadata: annotations: metallb.universe.tf/allow-shared-ip: nginx-lb # 多个Service共享同一IP metallb.universe.tf/load-balancer-ip: 192.168.200.100 # 指定IP避免动态分配这样你可以先创建一个type: LoadBalancer的Service占住IP再逐步将Ingress规则指向它实现零中断切换。最后分享一个小技巧在CI/CD流水线中用kubectl wait --forconditionLoadBalancerReady service/nginx-lb --timeout300s等待SLB就绪后再执行后续步骤。这比sleep 60更可靠避免因SLB创建慢导致部署失败。
1. 项目概述为什么K8s集群里LoadBalancer不是“开箱即用”的魔法按钮在某次给某高校实验室做容器化教学支持时一位刚接触云原生的导师直接问我“K8s文档里写的LoadBalancer类型Service我yaml一写服务就自动有公网IP了是不是像买云服务器那样点点鼠标就行”——这个问题背后藏着一个被大量新手忽略的关键事实Kubernetes本身不提供LoadBalancer实现它只定义了一个抽象接口真正让Service暴露到集群外部、分配公网IP、配置四层转发规则的是底层云平台或你手动部署的配套组件。这就是标题里“K8S集群-------部署负载均衡LoadBlance六”中那个长长的破折号所暗示的真实含义这不是一个kubectl apply就能完成的单步操作而是一整套需要你亲手串联、验证、调优的基础设施工程。LoadBalancer Service在K8s中本质是一个“能力声明”它告诉集群“我需要一个具备L4负载分发能力的外部入口”。但K8s控制平面不会自己去阿里云控制台创建SLB也不会自动在本地机房的F5设备上配VIP。它依赖一个叫cloud-controller-managerCCM的组件来对接云厂商API或者依赖你部署的MetalLB这类开源方案来接管物理网络。如果你在自建IDC或本地虚拟机环境比如用kubeadm搭的三节点集群直接创建LoadBalancer类型的Service你会发现service状态卡在PendingEXTERNAL-IP字段永远是pending——这不是bug是设计使然。这恰恰解释了为什么这个主题必须作为系列第六篇出现它建立在前五篇已打好基础的前提下——你已经完成了集群初始化、网络插件Calico/Flannel部署、Ingress控制器安装、DNS配置和监控体系搭建。现在轮到解决“最后一公里”如何让集群外的用户通过一个稳定、可访问、带健康检查的IP地址触达你的业务。对不同场景的用户这个“部署LoadBalancer”的动作意义完全不同对公有云用户如阿里云ACK、腾讯云TKE它意味着理解CCM如何与云平台SLB联动避免因权限配置错误导致SLB创建失败对私有云/边缘场景用户如某制造企业工厂内网的K8s集群它意味着选型MetalLB并配置BGP或Layer2模式让业务能被产线PLC系统通过固定IP访问对学习者而言它是一次深入理解K8s网络模型边界的实战——从Pod IP、ClusterIP、NodePort最终抵达External IP这条链路的每一环都暴露着网络架构的决策逻辑。所以这篇内容不讲“怎么复制粘贴yaml”而是带你拆解当kubectl get svc看到EXTERNAL-IP从pending变成一个真实IP时背后发生了什么哪些组件在协作配置参数背后的网络原理是什么以及为什么你在测试环境用type: LoadBalancer一切顺利上线后却突然发现流量只打到一台节点上这些才是“部署LoadBalancer”这个动作背后真正的技术纵深。2. 核心设计思路公有云、私有云与混合环境的三套解法2.1 公有云场景云厂商CCM是默认答案但绝非“无脑启用”几乎所有主流公有云K8s托管服务EKS、AKS、GKE、ACK都预装了对应厂商的cloud-controller-manager。它的核心职责是监听K8s API Server中Service资源的变化当检测到type: LoadBalancer且status.loadBalancer.ingress为空时便调用云平台API创建负载均衡实例如AWS的ELB、阿里云的SLB并将生成的公网IP或域名写回Service的status.loadBalancer.ingress.ip字段。这个过程看似自动化但实操中90%的故障都源于CCM与云平台的“握手失败”。以阿里云ACK为例CCM需要至少两个关键权限才能完成SLB创建AliyunSLBFullAccess允许创建、删除、修改SLB实例及监听规则AliyunVPCReadOnlyAccess用于获取VPC、交换机信息确保SLB能正确挂载后端节点。提示很多团队在RAM子账号授权时只给了AliyunSLBReadOnlyAccess结果CCM日志报错AccessDeniedService状态卡在Pending。这不是K8s问题是云账号权限粒度没配对。更隐蔽的问题在于SLB规格与节点规格的匹配。CCM默认创建的是slb.s1.small共享型实例但如果你的业务需要HTTPS卸载或WAF集成就必须指定alibabacloud.com/slave-zone-id注解强制使用独享型SLB。而独享型SLB要求后端ECS必须在同可用区——这意味着你的K8s节点组如果跨了3个可用区CCM默认会随机选一个可用区创建SLB导致另外两个可用区的节点无法注册为后端。解决方案是在Service yaml中显式声明apiVersion: v1 kind: Service metadata: name: nginx-lb annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec: slb.s2.small service.beta.kubernetes.io/alibaba-cloud-loadbalancer-master-zoneid: cn-hangzhou-g service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slave-zoneid: cn-hangzhou-h这里master-zoneid和slave-zoneid必须是你节点实际分布的两个可用区ID否则CCM会静默失败。这个细节在官方文档里藏得很深但却是生产环境SLB高可用的基石。2.2 私有云/裸金属场景MetalLB是事实标准但BGP模式才是性能关键当你的K8s集群运行在VMware虚拟机、Proxmox或物理服务器上时云厂商CCM彻底失效。此时MetalLB成为最成熟的选择。它由两部分组成speaker运行在每个节点上的DaemonSet和controller单副本Deployment。controller负责监听Service变化并分配IPspeaker则负责将IP“宣告”给上游网络设备。MetalLB提供两种IP宣告模式Layer 2模式简单粗暴所有节点竞争同一个VIPVirtual IP。当主节点宕机其他节点通过ARP广播抢占VIP。优点是无需上游路由器支持缺点是单点瓶颈——所有流量都打到当前持有VIP的节点再由该节点通过kube-proxy转发到后端Pod无法利用多节点带宽。BGP模式这才是为生产环境设计的方案。每个节点运行BGP客户端主动向上游路由器如Cisco、华为或Linux的Quagga/FRR宣告自己能提供某个IP段的路由。路由器收到多条等价路径ECMP后自动将流量分发到所有健康节点。此时kubectl get nodes -o wide看到的INTERNAL-IP就是BGP会话的源地址而EXTERNAL-IP则是MetalLB分配的、由BGP宣告出去的VIP。注意BGP模式要求上游路由器必须开启BGP并配置peer关系。例如在FRR中需添加router bgp 64512 neighbor 192.168.1.10 remote-as 64513 address-family ipv4 neighbor 192.168.1.10 activate network 10.244.0.0/16其中192.168.1.10是K8s节点IP64513是MetalLB配置的ASN自治系统号。若路由器未配置BGP会话永远处于Idle状态MetalLB日志会持续报错Failed to connect to peer。2.3 混合场景Ingress NodePort是兜底方案但需规避端口冲突当上述两种方案都不可行如某些强监管行业禁止BGP协议或云平台限制SLB创建数量一个被低估的组合是Ingress Controller NodePort Service。原理很简单先创建一个type: NodePort的Service它会在每个节点的固定端口如30080暴露服务再部署Nginx Ingress Controller它本身是一个type: LoadBalancer的Service走云厂商SLB但只监听80/443端口最后通过Ingress资源定义域名路由规则将app.example.com的请求转发到NodePortService。这个方案的优势是完全绕过MetalLB或CCM的复杂性但有两个致命陷阱NodePort端口范围冲突K8s默认NodePort范围是30000-32767。如果你的节点上已有MySQL3306、Redis6379等服务在运行而NodePort恰好分配到30000-32767之外的端口如20000就会因端口被占而启动失败。解决方案是在/var/lib/kubelet/config.yaml中修改nodePort: portRange: 30000-32767并重启kubelet。健康检查穿透问题云厂商SLB对Ingress Controller的健康检查默认探测其Pod的/healthz路径。但如果Ingress Controller本身是通过NodePort暴露的SLB探测的是节点IPNodePort而节点防火墙可能未放行该端口。必须在安全组中显式开放NodePort端口否则SLB会将所有Ingress Controller节点标记为unhealthy流量中断。3. 实操全流程从零部署MetalLB BGP模式含完整配置与验证3.1 环境准备确认网络拓扑与BGP前提条件在开始部署前必须完成三项基础确认缺一不可上游路由器BGP就绪登录你的核心路由器假设是Linux服务器运行FRR执行vtysh -c show ip bgp summary确认输出中能看到State/PfxRcd列为Established且Peer IP是你K8s节点的IP。这是BGP会话建立成功的唯一证据。K8s节点网络互通所有节点必须能互相ping通且能访问上游路由器的BGP端口TCP 179。用telnet 192.168.1.1 179测试连通性。若超时检查iptables是否拦截了179端口iptables -L INPUT | grep 179。MetalLB IP地址池规划为避免与现有网络冲突建议划出一个独立网段。例如你的内网是192.168.1.0/24则MetalLB IP池可设为192.168.200.100-192.168.200.199100个IP。这个网段必须在上游路由器的BGPnetwork命令中宣告否则路由器不知道如何路由这些IP。实操心得我曾在一个客户现场踩坑IP池设为10.0.0.100-10.0.0.199但上游路由器BGP只宣告了10.0.0.0/16导致MetalLB分配的IP能被路由但10.0.0.100这个具体地址在路由器ARP表中查不到MAC流量在二层就丢弃。解决方案是在路由器上为该IP段静态绑定MAC或改用192.168.x.x这类更易管理的私有网段。3.2 部署MetalLB Controller与SpeakerMetalLB官方提供一键部署yaml但生产环境必须定制化# 下载并解压官方manifest curl -OL https://raw.githubusercontent.com/metallb/metallb/v0.13.12/config/manifests/metallb.yaml # 修改namespace为kube-system与kube-proxy一致 sed -i s/namespace: metallb-system/namespace: kube-system/g metallb.yaml # 应用部署 kubectl apply -f metallb.yaml部署后检查Pod状态kubectl -n kube-system get pods -l appmetallb # 输出应为 # NAME READY STATUS RESTARTS AGE # controller-5d8b9c7f4d-2xq9j 1/1 Running 0 2m # speaker-7f8b9c7f4d-abcde 1/1 Running 0 2m关键验证点speakerPod日志必须出现BGP session established字样。用以下命令实时跟踪kubectl -n kube-system logs -l appspeaker -f | grep BGP session # 正常输出类似 # {level:info,msg:BGP session established,peer:192.168.1.1:179,ts:2023-10-05T08:23:45Z}若长时间无此日志立即检查speakerPod的hostNetwork: true是否生效必须为true才能监听179端口节点防火墙是否放行179端口firewall-cmd --permanent --add-port179/tcp上游路由器BGP配置中neighborIP是否与节点IP完全一致注意不要写成127.0.0.1。3.3 配置IP地址池与BGP Peer创建configmap定义MetalLB行为# metallb-config.yaml apiVersion: v1 kind: ConfigMap metadata: namespace: kube-system name: config data: config: | address-pools: - name: default protocol: bgp addresses: - 192.168.200.100-192.168.200.199 auto-assign: true peers: - peer-address: 192.168.1.1 peer-asn: 64512 my-asn: 64513应用配置kubectl apply -f metallb-config.yaml此时MetalLB Controller会立即开始分配IP。创建一个测试Service验证# test-lb.yaml apiVersion: v1 kind: Service metadata: name: nginx-test namespace: default spec: type: LoadBalancer ports: - port: 80 targetPort: 80 selector: app: nginx部署后执行kubectl get svc nginx-test # 输出应为 # NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE # nginx-test LoadBalancer 10.96.123.45 192.168.200.100 80:31234/TCP 10sEXTERNAL-IP从pending变为192.168.200.100证明IP分配成功。但真正的验证在上游路由器登录FRR执行show ip bgp你应该看到类似Network Next Hop Metric LocPrf Path * 192.168.200.100/32 192.168.1.10 0 0 64513 i这表示路由器已学习到该IP的BGP路由下一跳是节点IP192.168.1.10。此时从任何能访问该路由器的设备ping192.168.200.100都应该得到响应。3.4 高级配置多节点ECMP负载与会话保持BGP模式的终极价值在于ECMP等价多路径。默认情况下上游路由器对同一目标IP只会选择一条路径导致流量集中。必须在路由器上启用ECMP# 在FRR中 router bgp 64512 maximum-paths 4然后验证ECMP是否生效在路由器上执行show ip route 192.168.200.100输出应包含多条via 192.168.1.10、via 192.168.1.11等不同下一跳。此时用iperf3从客户端并发测试# 客户端执行模拟多连接 iperf3 -c 192.168.200.100 -P 10 -t 30在各K8s节点上用iftop -P 80观察会发现流量被均匀分摊到所有节点而非集中在一台。对于需要会话保持的业务如老版本Java应用MetalLB支持sessionAffinity: ClientIP但注意这仅在Layer2模式下有效BGP模式下会破坏ECMP。生产环境更推荐在应用层实现如Spring Session Redis而非依赖L4会话保持。4. 常见问题排查从pending到192.168.200.100的12个断点分析4.1 Service状态卡在pending的根因树当kubectl get svc看到EXTERNAL-IP始终为pending按以下顺序逐层排查断点层级检查命令正常现象异常表现与修复1. MetalLB组件是否存在kubectl -n kube-system get deploy,dscontrollerDeployment和speakerDaemonSet均存在且READY为1/1若缺失重新kubectl apply -f metallb.yaml若READY为0/1检查kubectl -n kube-system describe pod speaker-pod中的Events2. Speaker网络模式kubectl -n kube-system get ds speaker -o yaml | grep hostNetwork输出hostNetwork: true若为false编辑DSkubectl -n kube-system edit ds speaker将hostNetwork设为true并删除旧Pod触发重建3. BGP会话状态kubectl -n kube-system logs -l appspeaker | grep BGP session出现BGP session established若无此日志检查上游路由器BGP配置、节点防火墙、speakerPod的hostNetwork设置4. IP池配置语法kubectl -n kube-system get cm config -o yamladdresses字段格式为- 192.168.200.100-192.168.200.199若写成192.168.200.100/24MetalLB会静默忽略该池必须用-开头的列表格式5. 路由器BGP学习vtysh -c show ip bgp 192.168.200.100输出Status: valid, best若显示not in table检查路由器network命令是否包含该IP段或BGP会话是否Established实操心得有一次客户环境pending持续2小时最终发现是speakerDaemonSet的tolerations配置了node-role.kubernetes.io/master:NoSchedule但节点标签是node-role.kubernetes.io/control-plane:NoSchedule导致speakerPod根本无法调度。用kubectl get nodes --show-labels核对标签名比看日志更快定位。4.2 分配IP后无法访问的链路诊断即使EXTERNAL-IP已分配仍可能无法访问。按数据包流向分段验证阶段1客户端→上游路由器用ping 192.168.200.100测试ICMP连通性。若不通检查客户端到路由器的路由、ACL策略。用traceroute 192.168.200.100确认最后一跳是路由器IP而非其他设备。阶段2路由器→K8s节点在路由器上ping 192.168.1.10节点IP确认二层可达。在节点上tcpdump -i any port 80同时从客户端curl http://192.168.200.100。若tcpdump无输出说明路由器未将流量转发到节点检查BGP路由表和ECMP配置。阶段3节点→Pod在节点上执行curl -v http://localhost:31234NodePort确认kube-proxy工作正常。若失败检查kubectl get endpoints nginx-test确认ENDPOINTS字段有IP:PORT如10.244.1.5:80若为空检查Service selector是否匹配Pod标签。阶段4Pod内部kubectl exec -it pod-name -- netstat -tuln \| grep :80确认应用监听0.0.0.0:80而非127.0.0.1:80。kubectl logs pod-name查看应用日志确认无启动异常。4.3 性能瓶颈识别为什么流量只打到一台节点这是BGP模式最常见的幻觉。表面看kubectl get svc显示EXTERNAL-IP但实际流量全在一台节点。原因有三路由器未启用ECMP如前所述maximum-paths未配置路由器默认只选一条路径。BGP路由权重不均在FRR中若为不同节点配置了不同weight会导致路径偏好。执行show ip bgp检查各路径的Weight列是否一致。客户端连接复用HTTP/1.1默认长连接单个客户端的所有请求都复用同一TCP连接自然只走一条路径。用curl -H Connection: close http://192.168.200.100强制短连接或用ab -n 1000 -c 100 http://192.168.200.100/并发压测才能真实反映ECMP效果。注意abApache Bench工具在macOS上需用brew install httpd安装Linux用apt install apache2-utils。别用wrk它默认启用HTTP/2连接复用更激进不利于ECMP验证。5. 生产环境加固安全、可观测性与灰度发布实践5.1 安全加固限制BGP会话与IP分配范围MetalLB默认允许任何BGP peer连接这在多租户环境中是风险。必须通过peer-asn和my-asn进行双向认证peer-asn上游路由器的ASN必须与路由器配置严格一致my-asnMetalLB的ASN必须在路由器BGP配置中声明为remote-as。此外IP地址池应遵循最小权限原则测试环境用192.168.200.100-192.168.200.109仅10个IP生产环境按业务线划分网段如app-a: 192.168.201.0/24、app-b: 192.168.202.0/24并在ConfigMap中为每个网段定义独立address-pool通过Service annotation指定metadata: annotations: metallb.universe.tf/address-pool: app-a5.2 可观测性将MetalLB指标接入PrometheusMetalLB内置Prometheus指标端点/metrics但默认未暴露。需在speakerDaemonSet中添加ports: - containerPort: 7472 name: metrics protocol: TCP并创建ServiceMonitorapiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: metallb-speaker namespace: monitoring spec: selector: matchLabels: app: speaker namespaceSelector: matchNames: - kube-system endpoints: - port: metrics interval: 30s关键指标监控metallb_bgp_peers_established_total值应为1每个speaker对应一个peermetallb_ip_address_total{pooldefault}应等于你配置的IP池总数metallb_ip_assignment_duration_seconds_bucket若99%分位耗时5s说明IP分配慢需检查etcd性能。5.3 灰度发布通过Annotation控制SLB创建时机在公有云场景SLB创建是异步的可能耗时数分钟。若Service创建后立即更新Ingress可能导致流量黑洞。MetalLB提供优雅的灰度控制metadata: annotations: metallb.universe.tf/allow-shared-ip: nginx-lb # 多个Service共享同一IP metallb.universe.tf/load-balancer-ip: 192.168.200.100 # 指定IP避免动态分配这样你可以先创建一个type: LoadBalancer的Service占住IP再逐步将Ingress规则指向它实现零中断切换。最后分享一个小技巧在CI/CD流水线中用kubectl wait --forconditionLoadBalancerReady service/nginx-lb --timeout300s等待SLB就绪后再执行后续步骤。这比sleep 60更可靠避免因SLB创建慢导致部署失败。
