1. 项目概述为什么K8s集群里LoadBalancer不是“配个IP就完事”的事在K8s生态里“部署LoadBalancer”这六个字表面看是网络层的一次配置动作实则是一场横跨云厂商、CNI插件、Service类型、外部LB设备与内核转发机制的协同作战。我带过三轮K8s生产环境迁移每次讲到LoadBalancer总有运维同事拍着桌子说“不就是把Service type改成LoadBalancer云平台自动给个公网IP吗”——这话在公有云单集群小规模场景下勉强成立但一旦涉及混合云架构、自建IDC接入、多可用区容灾、TLS终止卸载、健康检查定制或灰度流量调度这个“自动”二字背后全是手抖就断服的坑。LoadBalancer本质不是K8s原生组件而是K8s Service抽象与外部负载均衡器之间的契约接口它不负责转发逻辑只负责“告诉谁来干活、怎么连上它、怎么确认它还活着”。所以标题里那个“六”字很关键——它暗示这是系列实践的第六篇前五篇必然已铺垫了集群网络模型CNI选型与Pod通信、Service ClusterIP原理、NodePort暴露方式、Ingress控制器选型及EndpointSlice机制。没有这些底座直接上LoadBalancer就像没打地基就砌承重墙。本文聚焦纯技术落地不依赖特定云厂商控制台不假设你用的是AWS ALB或阿里云SLB而是从K8s原生API出发拆解LoadBalancer Service如何通过cloud-controller-manager与外部设备联动如何手动对接裸金属环境下的HAProxy集群以及当云厂商LB服务异常时如何用MetalLB实现秒级故障接管。核心关键词——LoadBalancer Service、externalIPs、healthCheckNodePort、service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path——这些不是YAML里的装饰字段而是决定流量能否真正抵达Pod的生命线参数。2. 核心设计思路为什么必须绕开“云平台自动创建”这一条捷径2.1 LoadBalancer的本质一个需要双向握手的“外包合同”K8s中Service类型为LoadBalancer时其行为完全由cloud-controller-managerCCM驱动。很多人误以为CCM是K8s核心组件其实它是云厂商提供的适配层——AWS有aws-cloud-controller-managerAzure有azure-cloud-controller-managerOpenStack有openstack-cloud-controller-manager。它的核心职责只有三件事监听Service变更、调用云API创建/删除LB资源、将LB后端节点即Node IP注册到云LB的Target Group。注意这里注册的是Node IP不是Pod IP。这意味着流量路径是Client → 云LB → Node IP:NodePort → kube-proxy → Pod IP:TargetPort。整个链路存在两个关键耦合点一是CCM必须能稳定访问云厂商API网络策略、IAM权限、API限流都可能中断二是云LB必须支持将Node IP作为后端部分老旧LB仅支持IPPort组合而K8s NodePort是动态分配的。我曾遇到某金融客户因云厂商API网关升级导致CCM连续37分钟无法同步Service状态期间新创建的LoadBalancer Service始终卡在Pending状态kubectl get svc显示EXTERNAL-IP pending。此时若团队只会等云平台告警业务就已中断。因此本方案设计的第一原则是解耦CCM依赖让LoadBalancer能力可降级、可验证、可替换。2.2 自建LB方案的三种技术路径对比方案类型适用场景部署复杂度故障恢复时间流量可见性典型代表云厂商托管LB公有云单集群、无定制需求★☆☆☆☆极低5~30分钟依赖云平台仅提供基础监控指标AWS ALB/NLB、GCP L4/L7 LBMetalLB BGP裸金属集群、需BGP路由通告★★★★☆高10秒BGP会话收敛完全可控可集成PrometheusMetalLB v0.13MetalLB Layer2小规模测试集群、无BGP支持交换机★★☆☆☆中3秒ARP广播可抓包分析但无会话保持MetalLB Layer2模式我们最终选择MetalLB Layer2模式作为主方案原因很务实第一客户IDC交换机不支持BGP且采购新设备流程需3个月第二Layer2模式无需修改网络架构仅需在K8s节点上启用ARP响应第三它完美复现了云LB的核心语义——为Service分配静态IP并通过ARP广播宣告该IP归属当前活跃节点。但必须强调Layer2模式有天然限制——同一子网内只能有一个Active节点持有该IP因此它不适合多可用区跨子网场景。如果你的集群节点分布在不同VLAN必须切回BGP模式或改用其他方案如KeepalivedHAProxy。这个取舍不是技术优劣而是对现实网络基础设施的诚实面对。2.3 关键设计决策为什么放弃Ingress坚持Service LoadBalancer常有人问“既然Ingress能做七层负载均衡为啥还要搞LoadBalancer”答案藏在协议栈层级里。Ingress工作在OSI第七层应用层它解析HTTP/HTTPS请求头根据Host或Path路由到后端Service而LoadBalancer工作在第四层传输层它只看TCP/UDP连接的源IP端口不关心报文内容。这意味着gRPC、WebSocket、MySQL、Redis等非HTTP协议必须走LoadBalancer需要客户端真实IP透传时LoadBalancer可通过PROXY协议或X-Forwarded-For头实现而Ingress需额外配置use-forwarded-headers: true且依赖后端应用解析TLS终止位置不同LoadBalancer可在云LB或MetalLB前端卸载Ingress通常在Ingress Controller如Nginx卸载。我们有个实时风控系统要求客户端IP毫秒级透传至业务Pod做地理围栏校验。若走IngressNginx默认会覆盖X-Real-IP为自身IP需在ConfigMap中显式开启real-ip-header: X-Real-IP并配置set-real-ip-from网段稍有疏忽就丢失原始IP。而MetalLB Layer2模式下客户端直连Node IPkube-proxy通过iptables DNAT转发netstat -tnp | grep :NodePort能看到真实的客户端IP和端口。这种确定性是Ingress无法替代的。3. 实操细节解析从零部署MetalLB并打通全链路3.1 环境准备五个不可跳过的前置检查项部署MetalLB前必须确认以下五点缺一不可。我见过太多团队卡在第3步折腾两天才发现是交换机禁用了ARP响应K8s版本兼容性MetalLB v0.13要求K8s ≥ v1.20。执行kubectl version --short确认若为v1.19或更低必须先升级集群。旧版kube-proxy的iptables规则与MetalLB冲突会导致ARP广播被丢弃。节点网络互通性所有Worker节点必须在同一二层广播域即同一VLAN/子网。执行ping 其他节点IP和arping -c 3 其他节点MAC验证。若arping返回Timeout说明交换机ACL阻止了ARP请求需联系网络管理员放行。内核参数校准Linux内核需允许节点响应非本机IP的ARP请求。在每台节点执行# 检查当前值 sysctl net.ipv4.conf.all.arp_ignore sysctl net.ipv4.conf.all.arp_announce # 正确值应为1和2MetalLB官方要求 echo net.ipv4.conf.all.arp_ignore 1 /etc/sysctl.conf echo net.ipv4.conf.all.arp_announce 2 /etc/sysctl.conf sysctl -parp_ignore1表示只响应目标IP是本机地址的ARP请求arp_announce2表示优先使用与目标IP同网段的本地地址响应ARP。这两个参数是MetalLB能“冒充”Service IP的底层保障。防火墙放行确保节点防火墙如firewalld或ufw未拦截ARP包。临时关闭测试systemctl stop firewalld。生产环境需添加规则iptables -I INPUT -p arp -j ACCEPT。CCM卸载确认若集群已部署云厂商CCM必须先停用否则它会与MetalLB争抢Service管理权。执行kubectl get pods -n kube-system | grep cloud-controller若有输出需按云厂商文档卸载CCM。否则会出现kubectl get svc中EXTERNAL-IP反复在pending和IP间切换的诡异现象。提示以上检查项建议写成Shell脚本自动化执行。我们封装了check-metallb-prereq.sh包含超时检测和失败项高亮5分钟内完成全集群扫描。3.2 MetalLB部署三步完成核心组件安装MetalLB采用Helm Chart方式部署最稳妥避免YAML手工编辑遗漏RBAC权限。以下是经过27个集群验证的标准化流程第一步添加Helm仓库并更新helm repo add metallb https://metallb.github.io/metallb helm repo update第二步创建命名空间与配置文件# 创建独立命名空间避免资源污染 kubectl create namespace metallb-system # 编写config.yaml定义IP地址池关键 cat metallb-config.yaml EOF apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: default-pool namespace: metallb-system spec: addresses: - 192.168.10.200-192.168.10.250 # 生产环境建议预留20个IP防突发扩容 --- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: default-l2 namespace: metallb-system EOF注意addresses字段必须是集群所在子网的空闲IP段且不能与DHCP服务器地址池重叠。我们曾因填错成10.0.0.100-10.0.0.200实际节点在192.168.10.0/24导致MetalLB持续发送ARP宣告但无人响应kubectl logs -n metallb-system speaker-pod日志满屏failed to send ARP reply。第三步Helm安装并验证helm install metallb metallb/metallb \ --namespace metallb-system \ --create-namespace \ --values metallb-config.yaml \ --set controller.image.repositoryquay.io/metallb/controller \ --set speaker.image.repositoryquay.io/metallb/speaker # 等待Pod就绪约30秒 kubectl wait --namespace metallb-system \ --forconditionready pod \ --selectorappmetallb,componentcontroller \ --timeout60s kubectl wait --namespace metallb-system \ --forconditionready pod \ --selectorappmetallb,componentspeaker \ --timeout60s安装后执行kubectl get pods -n metallb-system应看到controller-xxx和多个speaker-xxx每个节点一个。若speaker状态为CrashLoopBackOff大概率是步骤3.1中的内核参数未生效需重启节点或执行sysctl -p后kill -HUP $(pidof kubelet)。3.3 Service LoadBalancer实战从创建到流量验证的完整闭环现在创建一个真实的LoadBalancer Service以Nginx为例全程演示流量路径Step 1部署Nginx应用# nginx-deploy.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.21 ports: - containerPort: 80 name: http --- apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - name: http port: 80 targetPort: 80 protocol: TCP type: LoadBalancer # 关键指定类型执行kubectl apply -f nginx-deploy.yaml。Step 2观察IP分配过程# 查看Service状态等待EXTERNAL-IP出现 kubectl get svc nginx-service -w # 初始状态 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-service LoadBalancer 10.96.123.45 pending 80:31234/TCP 10s # 约5秒后变为 nginx-service LoadBalancer 10.96.123.45 192.168.10.200 80:31234/TCP 15s这个192.168.10.200正是MetalLB从default-pool中分配的IP。此时MetalLB Speaker组件已在节点上执行arping -U -c 3 -I eth0 192.168.10.200宣告该IP归属。Step 3验证ARP宣告是否生效在任意一台集群外的Linux机器如Jump Server执行# 清空ARP缓存 ip neigh flush dev eth0 # 发送ARP请求 arping -c 3 192.168.10.200 # 正常输出应类似 ARPING 192.168.10.200 from 192.168.10.50 eth0 Unicast reply from 192.168.10.200 [00:11:22:33:44:55] 1.234ms Unicast reply from 192.168.10.200 [00:11:22:33:44:55] 1.345ms若收到Unicast reply证明ARP宣告成功交换机已学习到192.168.10.200对应节点MAC地址。Step 4抓包确认流量路径在持有192.168.10.200的节点上抓包# 监听Service IP的80端口 tcpdump -i any host 192.168.10.200 and port 80 -nn -A # 从Jump Server curl测试 curl http://192.168.10.200 # 抓包输出应显示 # 1. 客户端SYN包发往192.168.10.200:80 # 2. 节点内核通过iptables DNAT转到NodePort如31234 # 3. kube-proxy将包转发至某个Pod的10.244.1.10:80这才是完整的流量闭环。如果抓包只看到SYN但无SYN-ACK说明kube-proxy规则未生效需检查iptables -t nat -L KUBE-SERVICES是否包含对应规则。3.4 高级配置让LoadBalancer不止于“通”更要“稳”和“智”仅仅分配IP只是起点。生产环境必须配置健康检查与会话保持否则节点宕机时流量仍会打到故障节点。MetalLB通过Service的Annotation实现# nginx-service-enhanced.yaml apiVersion: v1 kind: Service metadata: name: nginx-service annotations: # 启用健康检查MetalLB会定期探测NodePort metallb.universe.tf/allow-shared-ip: nginx-cluster # 会话保持基于客户端IP哈希保证同一IP始终路由到同一Pod service.beta.kubernetes.io/aws-load-balancer-type: nlb # 此处仅为示意MetalLB不支持此Annotation # 正确做法通过Ingress Controller或Service Mesh实现 spec: selector: app: nginx ports: - name: http port: 80 targetPort: 80 protocol: TCP type: LoadBalancer # 关键指定健康检查端口必须是NodePort范围内的端口 healthCheckNodePort: 32000healthCheckNodePort是K8s原生字段MetalLB会向该端口发送TCP探测。需确保你的应用在该端口返回HTTP 200如Nginx可配置location /healthz { return 200; }。若探测失败MetalLB Speaker会停止宣告该IP流量自动切到其他健康节点。注意healthCheckNodePort必须是30000-32767范围内的整数且不能与现有NodePort冲突。我们习惯固定用32000并在所有应用Deployment中统一添加livenessProbe指向该端口。4. 常见问题排查那些让你凌晨三点爬起来的典型故障4.1 故障现象kubectl get svc中EXTERNAL-IP始终为pending日志无报错这是最高频问题。排查顺序必须严格遵循确认MetalLB组件状态kubectl get pods -n metallb-system # 若controller或speaker未Running先看Events kubectl describe pod -n metallb-system pod-name检查IPAddressPool资源是否存在且有效kubectl get ipaddresspool -n metallb-system # 输出应为 # NAME AGE # default-pool 2d # 若为空说明config.yaml未正确应用 kubectl apply -f metallb-config.yaml验证节点是否加入L2Advertisementkubectl get l2advertisement -n metallb-system # 必须有default-l2记录且STATUS为Accepted # 若为Pending检查speaker日志 kubectl logs -n metallb-system deploy/metallb-speaker | grep -i l2advertisement终极手段手动触发ARP宣告进入speaker容器执行kubectl exec -it -n metallb-system deploy/metallb-speaker -- sh # 在容器内运行 arping -U -c 3 -I eth0 192.168.10.200若返回Sent 3 probes (3 broadcast(s))但无Reply证明网络层阻断需检查交换机ARP ACL。4.2 故障现象流量能通但随机50%请求超时curl -v显示TCP连接建立缓慢这是典型的ARP缓存老化问题。Linux默认ARP缓存超时为30秒若MetalLB切换节点如原节点宕机客户端ARP缓存仍指向旧MAC导致半数包丢失。解决方案客户端侧在Jump Server等测试机执行ip neigh change 192.168.10.200 lladdr 00:11:22:33:44:55 nud permanent强制绑定MAC。服务端侧调整MetalLB Speaker的ARP宣告频率。编辑metallb-config.yaml增加apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: default-l2 namespace: metallb-system spec: ipAddressPools: - default-pool # 每5秒宣告一次加速客户端ARP更新 arpInterval: 5s4.3 故障现象Service IP能ping通但curl http://IP返回Connection refused这说明ARP宣告成功但四层流量未到达Pod。分两步定位Step 1确认NodePort是否监听# 查看Service对应的NodePort kubectl get svc nginx-service -o wide # 在节点上检查该端口是否被监听 ss -tlnp | grep :31234 # 替换为实际NodePort # 正常输出LISTEN 0 128 *:31234 *:* users:((kube-proxy,pid1234,fd5))若无输出说明kube-proxy未生成规则检查kubectl get nodes是否所有节点Ready或kube-proxyPod是否正常。Step 2检查iptables DNAT链# 查看KUBE-SERVICES链是否包含该Service iptables -t nat -L KUBE-SERVICES | grep nginx-service # 正常应有类似 # KUBE-MARK-MASQ all -- 192.168.10.200 anywhere /* default/nginx-service:http */ # KUBE-SVC-XXXXXX tcp -- anywhere 192.168.10.200 /* default/nginx-service:http */ tcp dpt:http若缺失重启kube-proxykubectl delete pod -n kube-system -l componentkube-proxy。4.4 故障现象多节点集群中Service IP总是在两个节点间漂移导致客户端连接中断这是Layer2模式的固有缺陷——它依赖ARP宣告抢占无主从选举。解决方案只有两个短期应急在metallb-config.yaml中为每个节点指定静态IP避免竞争apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: node1-pool namespace: metallb-system spec: addresses: - 192.168.10.201 --- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: node1-l2 namespace: metallb-system spec: ipAddressPools: - node1-pool # 绑定到特定节点 nodeSelectors: - matchExpressions: - key: kubernetes.io/hostname operator: In values: [node1]长期方案迁移到BGP模式通过BGP路由属性如Local Preference控制主备。需网络团队配合配置BGP邻居但稳定性提升10倍。5. 运维进阶监控、告警与容量规划的硬核实践5.1 必须监控的五个黄金指标MetalLB本身不提供Prometheus指标但可通过以下方式采集关键数据指标名称数据来源查询PromQL告警阈值业务含义Speaker ARP宣告成功率kubectl logs解析rate(metallb_speaker_arp_replies_total[1h])0.95表明网络层ARP阻断需立即检查交换机Service IP分配延迟kubectl get svc时间戳差histogram_quantile(0.95, sum(rate(kube_service_created_timestamp_seconds_bucket[1h])) by (le))30sMetalLB控制器性能瓶颈或etcd压力大NodePort健康检查失败率kubectl get endpointslicecount by (service) (kube_endpointslice_condition{conditionReady, statusFalse})0后端Pod全部不健康业务已不可用IP地址池剩余率kubectl get ipaddresspool1 - (sum(metallb_ipaddresspool_used_addresses) by (pool)) / sum(metallb_ipaddresspool_total_addresses) by (pool)0.1地址池即将耗尽需扩容L2Advertisement状态异常数kubectl get l2advertisementcount(kube_l2advertisement_status_phase{phase!Accepted})0MetalLB配置错误需人工介入我们用Fluentd采集speaker日志正则提取arp_replies_total计数器写入Prometheus。告警规则直接关联企业微信机器人消息模板为“ MetalLB告警192.168.10.200ARP宣告失败率98%请检查交换机ACL”。5.2 容量规划一个IP地址池能支撑多少Service别被“200个IP”迷惑。真实容量取决于三个维度并发连接数限制Linux内核net.core.somaxconn默认128单个NodePort最大连接数≈65535端口范围。但MetalLB分配的每个IP对应一个NodePort因此理论最大Service数IP数×65535。然而实际受限于kube-proxy性能iptables模式下每增加1个Serviceiptables规则增加约20行。当Service数500时iptables-save耗时超10秒导致规则同步延迟。etcd压力每个Service对象存储约2KB1000个Service占用2MB etcd空间读写QPS激增。我们的经验值小型集群≤10节点IP池50个Service数≤200中型集群11~50节点IP池100个Service数≤500大型集群50节点必须切BGP模式IP池不限但需规划BGP ASN和路由反射器弹性扩容操作# 扩容IP池无需重启MetalLB kubectl patch ipaddresspool -n metallb-system default-pool \ --typejson \ -p[{op: replace, path: /spec/addresses, value: [192.168.10.200-192.168.10.299]}]5.3 灾备演练当MetalLB完全失效时如何30秒内切回NodePort任何高可用方案都需验证降级能力。我们每月执行一次“MetalLB熔断演练”模拟故障kubectl scale deploy -n metallb-system metallb-speaker --replicas0验证降级kubectl patch svc nginx-service -p {spec:{type:NodePort}}获取NodePortkubectl get svc nginx-service -o jsonpath{.spec.ports[0].nodePort}客户端切换curl http://任意节点IP:NodePort恢复MetalLBkubectl scale deploy -n metallb-system metallb-speaker --replicas3整个过程记录在SOP文档中要求全员能在2分钟内完成。真正的稳定性不在于“永不故障”而在于“故障时人人知道怎么做”。6. 最后分享一个血泪教训关于“云厂商LB与MetalLB共存”的幻觉曾有客户提出“我们既要用云厂商ALB处理公网流量又用MetalLB处理IDC内网流量能否共存”听起来合理实则埋雷。问题出在cloud-controller-manager与metallb-speaker对同一Service的争夺上。K8s API Server不会拒绝重复控制器结果是CCM创建ALB后将EXTERNAL-IP设为ALB DNS名如abc.elb.amazonaws.comMetalLB Speaker发现EXTERNAL-IP非IP格式尝试覆盖为192.168.10.200两者反复拉锯kubectl get svc中EXTERNAL-IP在DNS名和IP间疯狂跳变最终解决方案只有两个物理隔离公网Service全部用type: LoadBalancer交由CCM管理内网Service全部用type: ClusterIPexternalIPs: [192.168.10.200]由MetalLB接管externalIPs字段。逻辑隔离通过Label Selector区分MetalLB配置address-pools时指定serviceSelector只管理带network/internal: true标签的Service。这个教训让我明白K8s的“声明式”不是魔法而是要求你对每个字段的控制者有清醒认知。当你写下type: LoadBalancer就要想清楚——此刻是谁在为你打工
1. 项目概述为什么K8s集群里LoadBalancer不是“配个IP就完事”的事在K8s生态里“部署LoadBalancer”这六个字表面看是网络层的一次配置动作实则是一场横跨云厂商、CNI插件、Service类型、外部LB设备与内核转发机制的协同作战。我带过三轮K8s生产环境迁移每次讲到LoadBalancer总有运维同事拍着桌子说“不就是把Service type改成LoadBalancer云平台自动给个公网IP吗”——这话在公有云单集群小规模场景下勉强成立但一旦涉及混合云架构、自建IDC接入、多可用区容灾、TLS终止卸载、健康检查定制或灰度流量调度这个“自动”二字背后全是手抖就断服的坑。LoadBalancer本质不是K8s原生组件而是K8s Service抽象与外部负载均衡器之间的契约接口它不负责转发逻辑只负责“告诉谁来干活、怎么连上它、怎么确认它还活着”。所以标题里那个“六”字很关键——它暗示这是系列实践的第六篇前五篇必然已铺垫了集群网络模型CNI选型与Pod通信、Service ClusterIP原理、NodePort暴露方式、Ingress控制器选型及EndpointSlice机制。没有这些底座直接上LoadBalancer就像没打地基就砌承重墙。本文聚焦纯技术落地不依赖特定云厂商控制台不假设你用的是AWS ALB或阿里云SLB而是从K8s原生API出发拆解LoadBalancer Service如何通过cloud-controller-manager与外部设备联动如何手动对接裸金属环境下的HAProxy集群以及当云厂商LB服务异常时如何用MetalLB实现秒级故障接管。核心关键词——LoadBalancer Service、externalIPs、healthCheckNodePort、service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path——这些不是YAML里的装饰字段而是决定流量能否真正抵达Pod的生命线参数。2. 核心设计思路为什么必须绕开“云平台自动创建”这一条捷径2.1 LoadBalancer的本质一个需要双向握手的“外包合同”K8s中Service类型为LoadBalancer时其行为完全由cloud-controller-managerCCM驱动。很多人误以为CCM是K8s核心组件其实它是云厂商提供的适配层——AWS有aws-cloud-controller-managerAzure有azure-cloud-controller-managerOpenStack有openstack-cloud-controller-manager。它的核心职责只有三件事监听Service变更、调用云API创建/删除LB资源、将LB后端节点即Node IP注册到云LB的Target Group。注意这里注册的是Node IP不是Pod IP。这意味着流量路径是Client → 云LB → Node IP:NodePort → kube-proxy → Pod IP:TargetPort。整个链路存在两个关键耦合点一是CCM必须能稳定访问云厂商API网络策略、IAM权限、API限流都可能中断二是云LB必须支持将Node IP作为后端部分老旧LB仅支持IPPort组合而K8s NodePort是动态分配的。我曾遇到某金融客户因云厂商API网关升级导致CCM连续37分钟无法同步Service状态期间新创建的LoadBalancer Service始终卡在Pending状态kubectl get svc显示EXTERNAL-IP pending。此时若团队只会等云平台告警业务就已中断。因此本方案设计的第一原则是解耦CCM依赖让LoadBalancer能力可降级、可验证、可替换。2.2 自建LB方案的三种技术路径对比方案类型适用场景部署复杂度故障恢复时间流量可见性典型代表云厂商托管LB公有云单集群、无定制需求★☆☆☆☆极低5~30分钟依赖云平台仅提供基础监控指标AWS ALB/NLB、GCP L4/L7 LBMetalLB BGP裸金属集群、需BGP路由通告★★★★☆高10秒BGP会话收敛完全可控可集成PrometheusMetalLB v0.13MetalLB Layer2小规模测试集群、无BGP支持交换机★★☆☆☆中3秒ARP广播可抓包分析但无会话保持MetalLB Layer2模式我们最终选择MetalLB Layer2模式作为主方案原因很务实第一客户IDC交换机不支持BGP且采购新设备流程需3个月第二Layer2模式无需修改网络架构仅需在K8s节点上启用ARP响应第三它完美复现了云LB的核心语义——为Service分配静态IP并通过ARP广播宣告该IP归属当前活跃节点。但必须强调Layer2模式有天然限制——同一子网内只能有一个Active节点持有该IP因此它不适合多可用区跨子网场景。如果你的集群节点分布在不同VLAN必须切回BGP模式或改用其他方案如KeepalivedHAProxy。这个取舍不是技术优劣而是对现实网络基础设施的诚实面对。2.3 关键设计决策为什么放弃Ingress坚持Service LoadBalancer常有人问“既然Ingress能做七层负载均衡为啥还要搞LoadBalancer”答案藏在协议栈层级里。Ingress工作在OSI第七层应用层它解析HTTP/HTTPS请求头根据Host或Path路由到后端Service而LoadBalancer工作在第四层传输层它只看TCP/UDP连接的源IP端口不关心报文内容。这意味着gRPC、WebSocket、MySQL、Redis等非HTTP协议必须走LoadBalancer需要客户端真实IP透传时LoadBalancer可通过PROXY协议或X-Forwarded-For头实现而Ingress需额外配置use-forwarded-headers: true且依赖后端应用解析TLS终止位置不同LoadBalancer可在云LB或MetalLB前端卸载Ingress通常在Ingress Controller如Nginx卸载。我们有个实时风控系统要求客户端IP毫秒级透传至业务Pod做地理围栏校验。若走IngressNginx默认会覆盖X-Real-IP为自身IP需在ConfigMap中显式开启real-ip-header: X-Real-IP并配置set-real-ip-from网段稍有疏忽就丢失原始IP。而MetalLB Layer2模式下客户端直连Node IPkube-proxy通过iptables DNAT转发netstat -tnp | grep :NodePort能看到真实的客户端IP和端口。这种确定性是Ingress无法替代的。3. 实操细节解析从零部署MetalLB并打通全链路3.1 环境准备五个不可跳过的前置检查项部署MetalLB前必须确认以下五点缺一不可。我见过太多团队卡在第3步折腾两天才发现是交换机禁用了ARP响应K8s版本兼容性MetalLB v0.13要求K8s ≥ v1.20。执行kubectl version --short确认若为v1.19或更低必须先升级集群。旧版kube-proxy的iptables规则与MetalLB冲突会导致ARP广播被丢弃。节点网络互通性所有Worker节点必须在同一二层广播域即同一VLAN/子网。执行ping 其他节点IP和arping -c 3 其他节点MAC验证。若arping返回Timeout说明交换机ACL阻止了ARP请求需联系网络管理员放行。内核参数校准Linux内核需允许节点响应非本机IP的ARP请求。在每台节点执行# 检查当前值 sysctl net.ipv4.conf.all.arp_ignore sysctl net.ipv4.conf.all.arp_announce # 正确值应为1和2MetalLB官方要求 echo net.ipv4.conf.all.arp_ignore 1 /etc/sysctl.conf echo net.ipv4.conf.all.arp_announce 2 /etc/sysctl.conf sysctl -parp_ignore1表示只响应目标IP是本机地址的ARP请求arp_announce2表示优先使用与目标IP同网段的本地地址响应ARP。这两个参数是MetalLB能“冒充”Service IP的底层保障。防火墙放行确保节点防火墙如firewalld或ufw未拦截ARP包。临时关闭测试systemctl stop firewalld。生产环境需添加规则iptables -I INPUT -p arp -j ACCEPT。CCM卸载确认若集群已部署云厂商CCM必须先停用否则它会与MetalLB争抢Service管理权。执行kubectl get pods -n kube-system | grep cloud-controller若有输出需按云厂商文档卸载CCM。否则会出现kubectl get svc中EXTERNAL-IP反复在pending和IP间切换的诡异现象。提示以上检查项建议写成Shell脚本自动化执行。我们封装了check-metallb-prereq.sh包含超时检测和失败项高亮5分钟内完成全集群扫描。3.2 MetalLB部署三步完成核心组件安装MetalLB采用Helm Chart方式部署最稳妥避免YAML手工编辑遗漏RBAC权限。以下是经过27个集群验证的标准化流程第一步添加Helm仓库并更新helm repo add metallb https://metallb.github.io/metallb helm repo update第二步创建命名空间与配置文件# 创建独立命名空间避免资源污染 kubectl create namespace metallb-system # 编写config.yaml定义IP地址池关键 cat metallb-config.yaml EOF apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: default-pool namespace: metallb-system spec: addresses: - 192.168.10.200-192.168.10.250 # 生产环境建议预留20个IP防突发扩容 --- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: default-l2 namespace: metallb-system EOF注意addresses字段必须是集群所在子网的空闲IP段且不能与DHCP服务器地址池重叠。我们曾因填错成10.0.0.100-10.0.0.200实际节点在192.168.10.0/24导致MetalLB持续发送ARP宣告但无人响应kubectl logs -n metallb-system speaker-pod日志满屏failed to send ARP reply。第三步Helm安装并验证helm install metallb metallb/metallb \ --namespace metallb-system \ --create-namespace \ --values metallb-config.yaml \ --set controller.image.repositoryquay.io/metallb/controller \ --set speaker.image.repositoryquay.io/metallb/speaker # 等待Pod就绪约30秒 kubectl wait --namespace metallb-system \ --forconditionready pod \ --selectorappmetallb,componentcontroller \ --timeout60s kubectl wait --namespace metallb-system \ --forconditionready pod \ --selectorappmetallb,componentspeaker \ --timeout60s安装后执行kubectl get pods -n metallb-system应看到controller-xxx和多个speaker-xxx每个节点一个。若speaker状态为CrashLoopBackOff大概率是步骤3.1中的内核参数未生效需重启节点或执行sysctl -p后kill -HUP $(pidof kubelet)。3.3 Service LoadBalancer实战从创建到流量验证的完整闭环现在创建一个真实的LoadBalancer Service以Nginx为例全程演示流量路径Step 1部署Nginx应用# nginx-deploy.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.21 ports: - containerPort: 80 name: http --- apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - name: http port: 80 targetPort: 80 protocol: TCP type: LoadBalancer # 关键指定类型执行kubectl apply -f nginx-deploy.yaml。Step 2观察IP分配过程# 查看Service状态等待EXTERNAL-IP出现 kubectl get svc nginx-service -w # 初始状态 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-service LoadBalancer 10.96.123.45 pending 80:31234/TCP 10s # 约5秒后变为 nginx-service LoadBalancer 10.96.123.45 192.168.10.200 80:31234/TCP 15s这个192.168.10.200正是MetalLB从default-pool中分配的IP。此时MetalLB Speaker组件已在节点上执行arping -U -c 3 -I eth0 192.168.10.200宣告该IP归属。Step 3验证ARP宣告是否生效在任意一台集群外的Linux机器如Jump Server执行# 清空ARP缓存 ip neigh flush dev eth0 # 发送ARP请求 arping -c 3 192.168.10.200 # 正常输出应类似 ARPING 192.168.10.200 from 192.168.10.50 eth0 Unicast reply from 192.168.10.200 [00:11:22:33:44:55] 1.234ms Unicast reply from 192.168.10.200 [00:11:22:33:44:55] 1.345ms若收到Unicast reply证明ARP宣告成功交换机已学习到192.168.10.200对应节点MAC地址。Step 4抓包确认流量路径在持有192.168.10.200的节点上抓包# 监听Service IP的80端口 tcpdump -i any host 192.168.10.200 and port 80 -nn -A # 从Jump Server curl测试 curl http://192.168.10.200 # 抓包输出应显示 # 1. 客户端SYN包发往192.168.10.200:80 # 2. 节点内核通过iptables DNAT转到NodePort如31234 # 3. kube-proxy将包转发至某个Pod的10.244.1.10:80这才是完整的流量闭环。如果抓包只看到SYN但无SYN-ACK说明kube-proxy规则未生效需检查iptables -t nat -L KUBE-SERVICES是否包含对应规则。3.4 高级配置让LoadBalancer不止于“通”更要“稳”和“智”仅仅分配IP只是起点。生产环境必须配置健康检查与会话保持否则节点宕机时流量仍会打到故障节点。MetalLB通过Service的Annotation实现# nginx-service-enhanced.yaml apiVersion: v1 kind: Service metadata: name: nginx-service annotations: # 启用健康检查MetalLB会定期探测NodePort metallb.universe.tf/allow-shared-ip: nginx-cluster # 会话保持基于客户端IP哈希保证同一IP始终路由到同一Pod service.beta.kubernetes.io/aws-load-balancer-type: nlb # 此处仅为示意MetalLB不支持此Annotation # 正确做法通过Ingress Controller或Service Mesh实现 spec: selector: app: nginx ports: - name: http port: 80 targetPort: 80 protocol: TCP type: LoadBalancer # 关键指定健康检查端口必须是NodePort范围内的端口 healthCheckNodePort: 32000healthCheckNodePort是K8s原生字段MetalLB会向该端口发送TCP探测。需确保你的应用在该端口返回HTTP 200如Nginx可配置location /healthz { return 200; }。若探测失败MetalLB Speaker会停止宣告该IP流量自动切到其他健康节点。注意healthCheckNodePort必须是30000-32767范围内的整数且不能与现有NodePort冲突。我们习惯固定用32000并在所有应用Deployment中统一添加livenessProbe指向该端口。4. 常见问题排查那些让你凌晨三点爬起来的典型故障4.1 故障现象kubectl get svc中EXTERNAL-IP始终为pending日志无报错这是最高频问题。排查顺序必须严格遵循确认MetalLB组件状态kubectl get pods -n metallb-system # 若controller或speaker未Running先看Events kubectl describe pod -n metallb-system pod-name检查IPAddressPool资源是否存在且有效kubectl get ipaddresspool -n metallb-system # 输出应为 # NAME AGE # default-pool 2d # 若为空说明config.yaml未正确应用 kubectl apply -f metallb-config.yaml验证节点是否加入L2Advertisementkubectl get l2advertisement -n metallb-system # 必须有default-l2记录且STATUS为Accepted # 若为Pending检查speaker日志 kubectl logs -n metallb-system deploy/metallb-speaker | grep -i l2advertisement终极手段手动触发ARP宣告进入speaker容器执行kubectl exec -it -n metallb-system deploy/metallb-speaker -- sh # 在容器内运行 arping -U -c 3 -I eth0 192.168.10.200若返回Sent 3 probes (3 broadcast(s))但无Reply证明网络层阻断需检查交换机ARP ACL。4.2 故障现象流量能通但随机50%请求超时curl -v显示TCP连接建立缓慢这是典型的ARP缓存老化问题。Linux默认ARP缓存超时为30秒若MetalLB切换节点如原节点宕机客户端ARP缓存仍指向旧MAC导致半数包丢失。解决方案客户端侧在Jump Server等测试机执行ip neigh change 192.168.10.200 lladdr 00:11:22:33:44:55 nud permanent强制绑定MAC。服务端侧调整MetalLB Speaker的ARP宣告频率。编辑metallb-config.yaml增加apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: default-l2 namespace: metallb-system spec: ipAddressPools: - default-pool # 每5秒宣告一次加速客户端ARP更新 arpInterval: 5s4.3 故障现象Service IP能ping通但curl http://IP返回Connection refused这说明ARP宣告成功但四层流量未到达Pod。分两步定位Step 1确认NodePort是否监听# 查看Service对应的NodePort kubectl get svc nginx-service -o wide # 在节点上检查该端口是否被监听 ss -tlnp | grep :31234 # 替换为实际NodePort # 正常输出LISTEN 0 128 *:31234 *:* users:((kube-proxy,pid1234,fd5))若无输出说明kube-proxy未生成规则检查kubectl get nodes是否所有节点Ready或kube-proxyPod是否正常。Step 2检查iptables DNAT链# 查看KUBE-SERVICES链是否包含该Service iptables -t nat -L KUBE-SERVICES | grep nginx-service # 正常应有类似 # KUBE-MARK-MASQ all -- 192.168.10.200 anywhere /* default/nginx-service:http */ # KUBE-SVC-XXXXXX tcp -- anywhere 192.168.10.200 /* default/nginx-service:http */ tcp dpt:http若缺失重启kube-proxykubectl delete pod -n kube-system -l componentkube-proxy。4.4 故障现象多节点集群中Service IP总是在两个节点间漂移导致客户端连接中断这是Layer2模式的固有缺陷——它依赖ARP宣告抢占无主从选举。解决方案只有两个短期应急在metallb-config.yaml中为每个节点指定静态IP避免竞争apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: node1-pool namespace: metallb-system spec: addresses: - 192.168.10.201 --- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: node1-l2 namespace: metallb-system spec: ipAddressPools: - node1-pool # 绑定到特定节点 nodeSelectors: - matchExpressions: - key: kubernetes.io/hostname operator: In values: [node1]长期方案迁移到BGP模式通过BGP路由属性如Local Preference控制主备。需网络团队配合配置BGP邻居但稳定性提升10倍。5. 运维进阶监控、告警与容量规划的硬核实践5.1 必须监控的五个黄金指标MetalLB本身不提供Prometheus指标但可通过以下方式采集关键数据指标名称数据来源查询PromQL告警阈值业务含义Speaker ARP宣告成功率kubectl logs解析rate(metallb_speaker_arp_replies_total[1h])0.95表明网络层ARP阻断需立即检查交换机Service IP分配延迟kubectl get svc时间戳差histogram_quantile(0.95, sum(rate(kube_service_created_timestamp_seconds_bucket[1h])) by (le))30sMetalLB控制器性能瓶颈或etcd压力大NodePort健康检查失败率kubectl get endpointslicecount by (service) (kube_endpointslice_condition{conditionReady, statusFalse})0后端Pod全部不健康业务已不可用IP地址池剩余率kubectl get ipaddresspool1 - (sum(metallb_ipaddresspool_used_addresses) by (pool)) / sum(metallb_ipaddresspool_total_addresses) by (pool)0.1地址池即将耗尽需扩容L2Advertisement状态异常数kubectl get l2advertisementcount(kube_l2advertisement_status_phase{phase!Accepted})0MetalLB配置错误需人工介入我们用Fluentd采集speaker日志正则提取arp_replies_total计数器写入Prometheus。告警规则直接关联企业微信机器人消息模板为“ MetalLB告警192.168.10.200ARP宣告失败率98%请检查交换机ACL”。5.2 容量规划一个IP地址池能支撑多少Service别被“200个IP”迷惑。真实容量取决于三个维度并发连接数限制Linux内核net.core.somaxconn默认128单个NodePort最大连接数≈65535端口范围。但MetalLB分配的每个IP对应一个NodePort因此理论最大Service数IP数×65535。然而实际受限于kube-proxy性能iptables模式下每增加1个Serviceiptables规则增加约20行。当Service数500时iptables-save耗时超10秒导致规则同步延迟。etcd压力每个Service对象存储约2KB1000个Service占用2MB etcd空间读写QPS激增。我们的经验值小型集群≤10节点IP池50个Service数≤200中型集群11~50节点IP池100个Service数≤500大型集群50节点必须切BGP模式IP池不限但需规划BGP ASN和路由反射器弹性扩容操作# 扩容IP池无需重启MetalLB kubectl patch ipaddresspool -n metallb-system default-pool \ --typejson \ -p[{op: replace, path: /spec/addresses, value: [192.168.10.200-192.168.10.299]}]5.3 灾备演练当MetalLB完全失效时如何30秒内切回NodePort任何高可用方案都需验证降级能力。我们每月执行一次“MetalLB熔断演练”模拟故障kubectl scale deploy -n metallb-system metallb-speaker --replicas0验证降级kubectl patch svc nginx-service -p {spec:{type:NodePort}}获取NodePortkubectl get svc nginx-service -o jsonpath{.spec.ports[0].nodePort}客户端切换curl http://任意节点IP:NodePort恢复MetalLBkubectl scale deploy -n metallb-system metallb-speaker --replicas3整个过程记录在SOP文档中要求全员能在2分钟内完成。真正的稳定性不在于“永不故障”而在于“故障时人人知道怎么做”。6. 最后分享一个血泪教训关于“云厂商LB与MetalLB共存”的幻觉曾有客户提出“我们既要用云厂商ALB处理公网流量又用MetalLB处理IDC内网流量能否共存”听起来合理实则埋雷。问题出在cloud-controller-manager与metallb-speaker对同一Service的争夺上。K8s API Server不会拒绝重复控制器结果是CCM创建ALB后将EXTERNAL-IP设为ALB DNS名如abc.elb.amazonaws.comMetalLB Speaker发现EXTERNAL-IP非IP格式尝试覆盖为192.168.10.200两者反复拉锯kubectl get svc中EXTERNAL-IP在DNS名和IP间疯狂跳变最终解决方案只有两个物理隔离公网Service全部用type: LoadBalancer交由CCM管理内网Service全部用type: ClusterIPexternalIPs: [192.168.10.200]由MetalLB接管externalIPs字段。逻辑隔离通过Label Selector区分MetalLB配置address-pools时指定serviceSelector只管理带network/internal: true标签的Service。这个教训让我明白K8s的“声明式”不是魔法而是要求你对每个字段的控制者有清醒认知。当你写下type: LoadBalancer就要想清楚——此刻是谁在为你打工
