MetalLB：裸金属集群的 LoadBalancer

Service 那节留下的问题

type: LoadBalancer 在云上一行就够——云厂商替你起一台 L4 负载均衡器。裸金属没有这个东西， 所以 Service 会一直卡在 <pending>，拿不到 EXTERNAL-IP。

MetalLB 补的就是这一段。它要解决两件事：

1. 分配：从一段你给的地址里挑一个 IP
2. 宣告：让物理网络知道"这个 IP 现在归某台节点"

第 1 件容易，第 2 件是全部难点所在——而且有两种完全不同的做法。

地址池：先把地盘划好

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: default
  namespace: metallb-system
spec:
  addresses:
    - 172.18.15.200-172.18.15.210      # 从机房网络组要一段空闲地址
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement          # 换成 BGPAdvertisement 就是 BGP 模式
metadata:
  name: default
  namespace: metallb-system
spec:
  ipAddressPools:
    - default

kubectl get ipaddresspools -n metallb-system
# 已经分出去的 VIP
kubectl get svc -A -o jsonpath='{.items[*].status.loadBalancer.ingress[*].ip}' | tr ' ' '\n' | sort -u

L2 模式：靠 gARP 抢占

一台节点上的 speaker 声称"这个 IP 是我的"。声称的方式是 gARP（无请求 ARP）—— 不等别人问，主动广播：

speaker 广播：10 网段的各位注意，172.18.15.200 的 MAC 是 b8:ce:f6:2a:1c:40
交换机与其它主机：更新 ARP 缓存
此后发往这个 VIP 的流量全部进这台节点

关键限制：这不是负载均衡

VIP 在任意时刻只落在一个节点上。 所以：

进入那台节点之后，才由 Service 的 DNAT 把流量分发到各个 Pod。 所以它提供的是高可用（故障能切换），不是负载均衡（带宽不叠加）。

VIP 现在在哪台节点

排障第一问。三种查法，按可靠性排序：

# 1. 新版本直接有 CRD（最省事）
kubectl get servicel2statuses.metallb.io -n metallb-system

# 2. 从 speaker 日志里找
kubectl logs -n metallb-system <speaker-pod> | grep serviceAnnounced | grep 172.18.15.200

# 3. 用 ARP 反查（不依赖 MetalLB 版本）
arping -c 3 172.18.15.200        # 拿到 MAC
arp -n | grep <那个 MAC>          # 通常返回两个 IP：VIP 和物理节点 IP

故障切换靠什么

原持有者挂了之后，新选出的 speaker 会再发一轮 gARP，让全网更新缓存。 中断时长取决于：选主耗时 + gARP 传播 + 各设备缓存更新。通常在秒级。

有些交换机的 ARP 缓存更新较慢或开了防 ARP 欺骗策略，会让切换更慢甚至失败—— 这也是 gARP 方案的固有弱点。

BGP 模式：真正的负载分担

换成和上游路由器建 BGP 邻居，多个节点同时宣告同一个 /32， 上游用 ECMP 把流量哈希分散到这些节点：

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: tor-switch
  namespace: metallb-system
spec:
  myASN: 64512              # 集群自己的 AS 号
  peerASN: 64513            # 上游交换机的 AS 号
  peerAddress: 10.0.12.1
---
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: default
  namespace: metallb-system
spec:
  ipAddressPools:
    - default

BGP 三个概念够用了

# 会话状态（要 Established 才算通）
kubectl logs -n metallb-system <speaker-pod> | grep -i "BGP session"
# 交换机侧：show ip bgp summary / show ip route 172.18.15.200

两种模式对照

选择逻辑很简单：能让网络组配 BGP 就用 BGP；不能就用 L2，并接受单节点带宽上限。

与 CNI 的配合：把 Pod CIDR 也宣告出去

BGP 一旦通了，就不止能宣告 VIP。CNI 那节 讲的原生路由模式 需要物理网络知道每个节点的 Pod CIDR 在哪——这正好也是 BGP 干的事。

Cilium 自带 BGP 能力，可以把 Pod CIDR 直接宣告给上游：

# 大意如此：让节点把自己的 Pod CIDR 宣告出去
apiVersion: cilium.io/v2alpha1
kind: CiliumBGPPeeringPolicy
metadata:
  name: tor
spec:
  virtualRouters:
    - localASN: 64512
      exportPodCIDR: true               # 关键：宣告 Pod CIDR
      neighbors:
        - peerAddress: 10.0.12.1/32
          peerASN: 64513

收益是免封装：Pod IP 直接在物理网络上路由，没有 VXLAN 的 50 字节开销和 MTU 折扣。 代价是要和网络组谈。

排障：四条路

VIP 不通时按顺序走：

# 1. Service 拿到 IP 了吗（pending = 地址池问题）
kubectl get svc myapp
kubectl describe svc myapp | tail -20        # Events 里会写分配失败原因

# 2. 有节点在宣告吗
kubectl get servicel2statuses -n metallb-system
kubectl logs -n metallb-system -l app.kubernetes.io/component=speaker | grep -i announc

# 3. 二层能不能看到（L2 模式）
arping -c 3 172.18.15.200
# 在宣告节点上抓 ARP
tcpdump -i bond0 -nn arp and host 172.18.15.200

# 4. Endpoint 有后端吗（VIP 通了但连接被拒）
kubectl get endpointslices -l kubernetes.io/service-name=myapp

两个高频坑

kubectl get nodes -o json | jq -r \
  '.items[] | select(.metadata.labels["node.kubernetes.io/exclude-from-external-load-balancers"]) | .metadata.name'

检查点

这节课的落点

• 裸金属没有云 LB，MetalLB 补两件事：从地址池分配 + 让物理网络知道
• 地址池要网络组分配、不能与三套地址重叠、L2 模式必须同二层
• L2 模式（gARP）= 高可用，不是负载均衡：VIP 只在一个节点，带宽上限是那台网卡
• VIP 在哪台节点：servicel2statuses → speaker 日志 → arping + arp -n 反查
• BGP 模式 = 真正分担：多节点宣告同一 /32，上游 ECMP；能配 BGP 就用 BGP
• BGP 三个概念够用：AS 号、对等会话（TCP 179）、宣告
• BGP 通了还能顺带宣告 Pod CIDR，实现原生路由免封装；但要考虑两套 BGP 是否并存
• 两个高频坑：exclude-from-external-load-balancers 标签、 externalTrafficPolicy: Local 缩小宣告范围