BGP 深入理解与云原生网络实践¶

这篇文章解决什么问题¶

在 Kubernetes CNI、裸金属集群、IDC 网络、专线/VPN 和多云互联场景里，经常会看到 BGP 这个词。

很多人第一次接触 BGP，是在 Calico 文档里看到：

Calico can use BGP to advertise Pod routes.

或者在 MetalLB 里看到：

MetalLB supports BGP mode.

这时候最容易产生一个误解：BGP 好像只是 Kubernetes CNI 的一个可选功能。

其实不是。

BGP 是互联网和大型数据中心最核心的路由协议之一。Kubernetes 只是把它借过来，用于解决“Pod 网段、Service IP、LoadBalancer IP 如何被集群内外网络知道”的问题。

这篇文章按下面顺序展开：

BGP 到底是什么
BGP 和普通路由、静态路由、OSPF 有什么区别
BGP 的核心概念：AS、ASN、Peer、Prefix、Next Hop、路由属性
BGP 如何选路
eBGP、iBGP、Route Reflector 是什么
BGP 在 Kubernetes CNI 里的典型用法
Calico、Cilium、MetalLB 为什么会用 BGP
生产环境使用 BGP 要注意哪些风险
面试里怎么把 BGP 讲清楚

BGP 是什么¶

BGP，全称 Border Gateway Protocol，中文通常叫“边界网关协议”。

一句话解释：

BGP 是一种用于在不同自治系统之间交换路由信息的动态路由协议。

更工程化一点说：

BGP 用来告诉别的网络：“某个网段可以从我这里到达。”

例如：

路由器 A 宣告：
10.10.0.0/16 这个网段从我这里走

路由器 B 宣告：
172.16.20.0/24 这个网段从我这里走

其他路由器收到这些信息后，会根据 BGP 路由属性、本地策略和路由表计算结果，决定访问某个目标网段时下一跳走哪里。

BGP 不负责真正“搬运数据包”。它负责传播路由信息。真正转发数据包的是内核路由表、交换机、路由器 FIB 或云厂商底层网络。

可以这样理解：

BGP：负责告诉大家路怎么走
FIB/路由表：负责按这条路转发数据包

为什么需要 BGP¶

如果网络规模很小，静态路由就够了。

比如只有两台机器：

Node A: 192.168.1.10
Node B: 192.168.1.11

你可以手工写：

ip route add 10.244.2.0/24 via 192.168.1.11

意思是：访问 10.244.2.0/24 这个 Pod 网段时，下一跳走 192.168.1.11。

但如果集群有 100 台节点，每台节点都有自己的 Pod CIDR，静态路由就很难维护：

Node 1: 10.244.1.0/24
Node 2: 10.244.2.0/24
Node 3: 10.244.3.0/24
...
Node 100: 10.244.100.0/24

节点扩容、缩容、迁移、故障、Pod CIDR 变化时，人工维护路由会非常痛苦，也容易出事故。

BGP 的价值就在这里：

自动发布路由
自动撤销路由
支持大规模路由传播
支持策略控制
支持多路径和高可用
适合跨网络边界交换可达性信息

在 Kubernetes 里，BGP 可以让每个节点自动告诉其他节点或上游网络设备：

我这里有 10.244.1.0/24
要访问这个 Pod 网段，请把流量发给我

BGP 和静态路由的区别¶

静态路由是人手工写死的：

ip route add 10.244.1.0/24 via 192.168.1.10

BGP 是路由器或网络组件之间动态交换的：

Peer A -> Peer B:
我可以到达 10.244.1.0/24，下一跳是 192.168.1.10

对比如下：

维度	静态路由	BGP
配置方式	手工配置	动态学习
适合规模	小规模、固定网络	中大型、动态网络
故障收敛	依赖人工或脚本	协议自动撤销/切换
策略能力	弱	强
复杂度	低	高
典型场景	简单内网路由	IDC、云专线、互联网、K8s 裸金属网络

静态路由像“手工贴路牌”，BGP 像“路由器之间自动交换地图”。

BGP 和 OSPF 的区别¶

BGP 和 OSPF 都是动态路由协议，但定位完全不同。

OSPF 属于 IGP，主要用于一个组织内部网络，比如一个机房、一个企业内网、一个园区网。

BGP 属于 EGP，主要用于不同自治系统之间交换路由，比如运营商之间、企业和云厂商之间、数据中心和数据中心之间。

对比如下：

维度	OSPF	BGP
协议类型	IGP	EGP
常见范围	一个组织内部	不同组织/自治系统之间
选路依据	链路开销	路由属性和策略
收敛速度	通常更快	相对更慢，但更可控
策略能力	相对有限	非常强
典型场景	企业内网、机房内部	互联网、云专线、多数据中心、K8s BGP 网络

简单说：

OSPF 更像“内部道路导航”
BGP 更像“不同城市、不同运营商之间的交通规则协商”

在 Kubernetes 场景里，Calico/Cilium/MetalLB 通常不会使用 OSPF，而是选择 BGP，因为它们更需要的是“把某些网段发布给别的节点或外部网络”，并且希望通过策略控制哪些路由能发布、哪些不能发布。

BGP 的核心概念¶

AS¶

AS 全称 Autonomous System，中文叫“自治系统”。

一个 AS 可以理解为一个由同一组织管理、使用统一路由策略的网络集合。

例如：

运营商 A 的网络：一个 AS
云厂商 B 的网络：一个 AS
企业 IDC 网络：一个 AS
Kubernetes 集群网络：也可以抽象成一个 AS

ASN¶

ASN 是 AS 的编号。

例如：

AS 64512
AS 65001
AS 4200000000

公网 ASN 需要申请，私有网络里可以使用私有 ASN。常见私有 ASN 范围包括：

64512-65534
4200000000-4294967294

在实验环境或 Kubernetes 内部 BGP 场景里，经常会看到 64512、65000、65001 这类 ASN。

Peer¶

Peer 是 BGP 邻居。

BGP 不是广播协议，它不会像某些二层协议一样自动发现邻居。BGP 邻居通常需要显式配置。

例如：

Node A 和 Node B 建立 BGP Peer
Node A 和 ToR 交换机建立 BGP Peer
MetalLB Speaker 和上游路由器建立 BGP Peer

两个 BGP Peer 建立 TCP 连接后，才能交换路由信息。

BGP 使用 TCP 179 端口。

BGP Peer A <---- TCP/179 ----> BGP Peer B

Prefix¶

Prefix 就是被发布的网段，也叫路由前缀。

例如：

10.244.1.0/24
172.16.10.0/24
192.168.100.0/24

在 Kubernetes 里，一个 Prefix 可能是：

某个节点上的 Pod CIDR
某个 Service CIDR
某个 LoadBalancer IP 段
某个对外暴露的 VIP

Next Hop¶

Next Hop 是下一跳。

比如：

目标网段：10.244.1.0/24
下一跳：192.168.1.10

意思是访问 10.244.1.0/24 时，流量应该先发给 192.168.1.10。

在 Kubernetes 节点路由里，你可能会看到类似：

ip route

输出：

10.244.1.0/24 via 192.168.1.10 dev eth0
10.244.2.0/24 via 192.168.1.11 dev eth0

这背后可能就是 BGP 学到的路由。

RIB 和 FIB¶

RIB 是 Routing Information Base，路由信息库。

FIB 是 Forwarding Information Base，转发表。

可以简单理解为：

RIB：控制面看到的所有候选路由
FIB：真正用于转发数据包的最佳路由

BGP 学到很多路由后，不是所有路由都会直接进入转发表。系统会先根据策略和选路规则选出最佳路由，再下发到内核或设备的转发表。

BGP 消息类型¶

BGP 建邻和交换路由，主要靠几类消息。

OPEN¶

建立 BGP 会话时发送，里面包含 ASN、BGP 版本、Hold Time、Router ID 等信息。

KEEPALIVE¶

用于保持会话存活。如果一段时间没有收到对端消息，会话会被认为异常。

UPDATE¶

用于发布或撤销路由。

例如：

发布：我可以到达 10.244.1.0/24
撤销：我不再提供 10.244.1.0/24

NOTIFICATION¶

用于通知错误并关闭会话。

比如 ASN 不匹配、认证失败、协议参数错误，都可能触发 NOTIFICATION。

BGP 会话状态¶

BGP 建邻不是一上来就 Established，而是会经过状态机。

常见状态：

Idle
Connect
Active
OpenSent
OpenConfirm
Established

最重要的是 Established。

只有进入 Established，BGP Peer 才能正常交换路由。

排障时，如果 BGP 一直卡在 Active 或 Connect，通常要检查：

对端 IP 是否可达
TCP 179 是否被防火墙拦截
ASN 是否配置正确
Peer 地址是否写错
BGP 认证是否一致
是否存在路由回程问题

eBGP 和 iBGP¶

BGP 分为 eBGP 和 iBGP。

eBGP¶

eBGP 是 External BGP，用于不同 AS 之间。

例如：

Node AS 64512 <---- eBGP ----> ToR AS 65001

典型场景：

企业 IDC 和运营商
企业 IDC 和云厂商专线
Kubernetes 节点和机房 ToR 交换机
MetalLB Speaker 和外部路由器

eBGP 的特点是边界清晰、策略明确，常用于对外发布路由。

iBGP¶

iBGP 是 Internal BGP，用于同一个 AS 内部。

例如：

Node A AS 64512 <---- iBGP ----> Node B AS 64512

iBGP 有一个重要特点：

iBGP 从一个 iBGP Peer 学到的路由，默认不会再转发给另一个 iBGP Peer。

这会带来一个问题：如果所有节点都在同一个 AS 里，想让每个节点都学到其他节点路由，传统 iBGP 需要全互联。

例如 5 个节点：

Node A <-> Node B
Node A <-> Node C
Node A <-> Node D
Node A <-> Node E
Node B <-> Node C
...

节点少时还行，节点多时连接数量会爆炸。

Route Reflector¶

Route Reflector 中文常叫“路由反射器”。

它的作用是解决 iBGP 全互联问题。

不用 Route Reflector 时：

Node A <-> Node B
Node A <-> Node C
Node A <-> Node D
Node B <-> Node C
Node B <-> Node D
Node C <-> Node D

使用 Route Reflector 后：

        Route Reflector
        /      |      \
     Node A  Node B  Node C

各节点只需要和 Route Reflector 建邻，由 Route Reflector 负责反射路由。

在 Calico 大规模集群里，如果使用 BGP Node-to-Node Mesh，小规模还可以；节点多了以后，常见优化就是关闭全互联，改用 Route Reflector。

BGP 路由属性¶

BGP 强大的地方不只是能发布路由，更重要的是能通过属性和策略影响选路。

AS_PATH¶

AS_PATH 记录路由经过了哪些 AS。

例如：

10.10.0.0/16 via AS_PATH: 65001 65002 65003

通常 AS_PATH 越短，路径越优。

AS_PATH 还有一个重要作用：防环。

如果一个 BGP 路由器收到的路由里已经包含自己的 ASN，它会认为这条路由可能形成环路，通常会拒绝。

NEXT_HOP¶

NEXT_HOP 表示下一跳地址。

数据包真正转发时，需要能到达这个下一跳。如果 NEXT_HOP 不可达，即使 BGP 学到了路由，流量也可能不通。

Kubernetes BGP 排障里，经常会遇到：

BGP route learned, but next-hop unreachable.

这时候要查的不只是 BGP 邻居，还要查底层节点网络、路由回程和防火墙。

LOCAL_PREF¶

LOCAL_PREF 是本 AS 内部使用的本地优先级。

值越大越优。

它通常用于控制出方向流量从哪里走。

例如企业有两条出口：

主出口 LOCAL_PREF 200
备出口 LOCAL_PREF 100

这样内部网络会优先走主出口。

MED¶

MED 可以理解为告诉外部 AS：“如果你要进我这里，建议从哪条链路进。”

值越小越优。

它常用于影响入方向流量，但是否采纳取决于对端策略。

Community¶

Community 是 BGP 路由的标签。

它可以给路由打上某种策略标记。

例如：

这条路由不要发布给上游
这条路由只在本地域内传播
这条路由走低优先级链路

在运营商、云厂商和大型数据中心网络里，Community 非常常见。

BGP 如何选路¶

不同设备厂商的 BGP 选路细节会有差异，但常见思路大致如下：

优先选择本地优先级更高的路由
优先选择 AS_PATH 更短的路由
优先选择 Origin 类型更优的路由
优先选择 MED 更小的路由
优先选择 eBGP 学到的路由，而不是 iBGP
优先选择到 NEXT_HOP 的 IGP 成本更低的路由
仍然相同则按 Router ID、邻居地址等规则继续比较

不用死背所有细节，运维排障时更重要的是理解：

BGP 不是只看“距离最近”，它更看“策略”。

这也是 BGP 和很多内部路由协议的核心区别。

BGP 在 Kubernetes 里的作用¶

Kubernetes 默认要求：

Pod IP 可以直接访问 Pod IP
Node 可以访问 Pod IP
Service 可以被正确转发

但 Kubernetes 自己不负责底层路由实现，CNI 插件必须解决 Pod 网段可达性。

BGP 在 Kubernetes 里常见用途有三类。

发布 Pod CIDR¶

每个节点有自己的 Pod CIDR：

Node A: 10.244.1.0/24
Node B: 10.244.2.0/24
Node C: 10.244.3.0/24

使用 BGP 后，每个节点可以发布自己的 Pod CIDR：

Node A 宣告：10.244.1.0/24 via Node A
Node B 宣告：10.244.2.0/24 via Node B
Node C 宣告：10.244.3.0/24 via Node C

这样跨节点 Pod 通信就可以走三层路由。

发布 Service 或 LoadBalancer IP¶

在裸金属集群里，如果要暴露一个 LoadBalancer IP，例如：

172.16.100.10

可以让 MetalLB 通过 BGP 把这个 IP 宣告给上游路由器。

上游网络收到后，就知道访问 172.16.100.10 应该把流量发到哪些 Kubernetes 节点。

和物理网络打通¶

在 IDC 或裸金属环境中，Pod 网段如果想被外部系统直接访问，需要让机房路由器或 ToR 交换机知道这些 Pod 网段在哪里。

BGP 可以把 Kubernetes 网络纳入现有三层网络体系：

Pod CIDR
  |
Kubernetes Node / CNI
  |
BGP
  |
ToR / Router
  |
IDC Network

Calico 的 BGP 模式¶

Calico 是最典型的 Kubernetes BGP CNI。

Calico 可以让每个节点运行 BGP 组件，把本节点上的 Pod 路由发布出去。

简化拓扑：

Pod A 10.244.1.10
  |
Node A 192.168.1.10
  |  BGP announces 10.244.1.0/24
  |
Node B 192.168.1.11
  |
Pod B 10.244.2.20

Node A 发布：

10.244.1.0/24 via 192.168.1.10

Node B 发布：

10.244.2.0/24 via 192.168.1.11

这样 Node A 访问 Node B 上的 Pod 时，流量可以直接按路由走，不需要 VXLAN/IPIP 封装。

Node-to-Node Mesh¶

Calico 小规模集群里常见 Node-to-Node Mesh。

意思是每个节点和其他节点都建立 BGP Peer。

Node A <-> Node B
Node A <-> Node C
Node B <-> Node C

优点：

部署简单
不依赖外部路由器
适合小中规模集群

缺点：

节点越多，BGP 连接越多
路由更新压力增大
大规模集群维护性下降

Route Reflector 模式¶

大规模集群更适合 Route Reflector。

        RR-1      RR-2
       / | \      / | \
    Node Node  Node Node

节点只和 RR 建邻，RR 负责反射路由。

优点：

减少 BGP Peer 数量
更适合大规模集群
拓扑更清晰

注意点：

RR 本身要高可用
RR 故障会影响路由收敛
需要规划节点标签、Peer 关系和 ASN

和 ToR 建邻¶

在裸金属数据中心里，Calico 也可以让节点和 ToR 交换机建立 BGP Peer。

        ToR Switch
       /    |    \
   Node A Node B Node C

这样 Pod 路由可以发布到物理网络，外部服务器就能通过路由访问 Pod IP。

这个模式性能好、路径直接，但对网络团队协作要求更高。

Cilium 的 BGP 能力¶

Cilium 的核心是 eBPF，但它也支持 BGP 控制面。

这里要注意：

eBPF 主要解决节点内和节点间的数据转发路径，BGP 主要解决路由发布问题。

两者不是同一层能力。

Cilium 可以通过 BGP 把下面这些地址发布出去：

Pod CIDR
LoadBalancer IP
Service VIP

典型场景是裸金属集群对外暴露服务：

Client
  |
Router / ToR
  |
BGP learned LoadBalancer IP
  |
Cilium Node
  |
Service -> Pod

如果你的环境里已经使用 Cilium，并希望和外部网络用路由方式打通，BGP 控制面就是一个重要选项。

MetalLB 的 BGP 模式¶

MetalLB 常用于裸金属 Kubernetes 的 LoadBalancer 实现。

云上创建 Service type=LoadBalancer 时，云厂商会帮你分配负载均衡器。

裸金属环境没有云厂商负载均衡器，就需要自己解决：

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: LoadBalancer

MetalLB 的 BGP 模式会把分配出来的 LoadBalancer IP 发布给上游路由器。

例如：

Service IP: 172.16.100.10

MetalLB Speaker 通过 BGP 宣告：

172.16.100.10/32 is reachable via Node A
172.16.100.10/32 is reachable via Node B

上游路由器可以通过 ECMP 把流量分发到多个节点。

这就是裸金属 LoadBalancer 的常见实现方式。

BGP 和 Overlay 网络的区别¶

Kubernetes CNI 常见两种思路：

Overlay：通过 VXLAN、IPIP、Geneve 等隧道封装
Routing：通过三层路由直接转发，BGP 用于动态发布路由

Overlay 模式¶

Overlay 的典型路径：

Pod A packet
  -> Node A 封装成 VXLAN/IPIP
  -> 底层网络转发到 Node B
  -> Node B 解封装
  -> Pod B

优点：

对底层网络要求低
跨网段、跨三层网络更容易跑起来
云环境兼容性好

缺点：

有封装开销
MTU 更容易出问题
排障要同时看内层和外层包

BGP 路由模式¶

BGP 路由模式的典型路径：

Pod A packet
  -> Node A 查路由
  -> 底层网络按 Pod CIDR 路由转发
  -> Node B
  -> Pod B

优点：

路径更直接
少一层封装
性能和可观测性更清晰
适合裸金属和可控 IDC 网络

缺点：

需要底层网络支持或配合
路由规划要求高
BGP 配错影响面更大

BGP 和 ECMP¶

ECMP 是 Equal-Cost Multi-Path，等价多路径。

如果同一个目标前缀有多条等价路径，路由器可以把流量分散到多个下一跳。

例如 MetalLB 宣告同一个 LoadBalancer IP：

172.16.100.10/32 via Node A
172.16.100.10/32 via Node B
172.16.100.10/32 via Node C

上游路由器可以使用 ECMP：

Client traffic
  -> Node A
  -> Node B
  -> Node C

这样既能实现负载分担，也能在某个节点异常时撤销路由。

注意：

ECMP 通常按五元组哈希，不是严格轮询
单条 TCP 连接通常只走一条路径
后端会话保持、源地址保留、Local/Cluster 流量策略都要一起考虑

BGP 和 BFD¶

BGP 本身依赖 Hold Timer 发现邻居故障。如果定时器配置较大，故障收敛会比较慢。

BFD 是 Bidirectional Forwarding Detection，用来快速检测链路或邻居故障。

简单说：

BGP 负责交换路由
BFD 负责快速发现对端是否还活着

在对收敛时间要求高的场景，可以用 BFD 辅助 BGP。

例如：

ToR 和 Kubernetes 节点之间
双出口链路
专线主备链路
LoadBalancer IP 高可用

生产环境使用 BGP 的注意事项¶

网段规划必须清楚¶

BGP 发布的是路由。路由一旦冲突，影响可能很隐蔽。

必须确认：

Pod CIDR 不和节点网段冲突
Pod CIDR 不和 Service CIDR 冲突
Pod CIDR 不和 IDC/VPC/专线/VPN 对端网段冲突
LoadBalancer IP 段不和已有业务网段冲突

不要无脑发布全部路由¶

BGP 最重要的是策略。

生产环境应该使用：

Prefix Filter
Route Map
Community
Max Prefix
Import/Export Policy

目标是：

只发布该发布的路由
只接收该接收的路由
发现异常路由立即阻断

控制路由规模¶

如果每个 Pod 都发布一个 /32 路由，路由规模会非常大。

更常见的是发布节点级 Pod CIDR：

Node A: 10.244.1.0/24
Node B: 10.244.2.0/24

LoadBalancer IP 才更常见发布 /32。

注意故障收敛¶

BGP 路由撤销和重新收敛需要时间。

要关注：

Hold Time
Keepalive
BFD
Graceful Restart
节点异常时路由是否及时撤销
上游设备是否正确清理旧路由

注意安全¶

BGP 建邻要考虑安全边界。

常见措施：

限制 Peer 源地址
防火墙只允许可信 Peer 访问 TCP 179
使用 BGP 认证
配置 TTL Security
配置 Max Prefix，防止异常路由打爆设备
做路由过滤，防止错误前缀外泄

BGP 排障思路¶

第一步：确认 Peer 是否 Established¶

如果 BGP Peer 没有 Established，先不要看路由。

先检查：

对端 IP 是否能 ping 通
TCP 179 是否能连通
ASN 是否一致或符合 eBGP/iBGP 设计
Router ID 是否冲突
认证参数是否一致
防火墙、安全组、ACL 是否拦截

第二步：确认是否收到路由¶

Peer Established 后，要看有没有收到目标 Prefix。

如果没有收到，检查：

对端是否真的发布了这条路由
Export Policy 是否阻断
Import Policy 是否过滤
Prefix Filter 是否过严
Community 是否触发特殊策略

第三步：确认路由是否进入 FIB¶

收到 BGP 路由，不代表系统一定用它转发。

要继续查：

是否有更优路由
NEXT_HOP 是否可达
路由是否被策略拒绝安装
是否进入内核路由表

Linux 节点上可以看：

ip route
ip route get 10.244.2.20

第四步：确认回程路由¶

网络不通经常不是去程问题，而是回程问题。

比如：

Client -> Pod 能到
Pod -> Client 回不去

这种情况要查对端是否知道 Pod CIDR 或 LoadBalancer IP 的回程路径。

第五步：抓包确认真实路径¶

必要时用抓包确认。

tcpdump -i eth0 host 10.244.2.20
tcpdump -i any port 179

看两个方向：

BGP 控制面：TCP 179 是否正常
业务数据面：业务包是否走到了预期节点

Kubernetes 场景常用检查命令¶

不同 CNI 命令不完全一样，但思路类似。

查看节点路由¶

ip route
ip route get <pod-ip>

查看 Calico BGP 状态¶

calicoctl node status

如果使用的是 BIRD，也可能查看：

birdcl show protocols
birdcl show route

查看 FRR BGP 状态¶

如果组件使用 FRR：

vtysh -c "show bgp summary"
vtysh -c "show ip bgp"

查看 CNI 组件日志¶

kubectl -n kube-system get pod -o wide
kubectl -n kube-system logs <cni-pod-name>

查看 Service 暴露策略¶

kubectl get svc -A
kubectl describe svc <service-name> -n <namespace>

如果是 LoadBalancer IP 不通，要同时查：

Service 是否分配到 IP
BGP 是否发布该 IP
上游路由器是否学到该 IP
流量是否到达节点
节点是否正确转发到 Pod

一个典型 BGP + Kubernetes 通信过程¶

假设有三台节点：

Node A: 192.168.1.10, Pod CIDR 10.244.1.0/24
Node B: 192.168.1.11, Pod CIDR 10.244.2.0/24
Node C: 192.168.1.12, Pod CIDR 10.244.3.0/24

Calico 发布路由：

10.244.1.0/24 via 192.168.1.10
10.244.2.0/24 via 192.168.1.11
10.244.3.0/24 via 192.168.1.12

Pod A 访问 Pod B：

Pod A 10.244.1.20
  |
Node A 查路由：10.244.2.0/24 via 192.168.1.11
  |
底层网络转发到 Node B
  |
Node B 转发到 Pod B 10.244.2.30

如果路由都正确，整个过程不需要 VXLAN/IPIP 封装。

这就是 BGP 路由模式的核心价值。

面试里怎么讲 BGP¶

可以这样回答：

BGP 是边界网关协议，主要用于不同自治系统之间交换路由信息。它的核心作用是发布和学习网段可达性，比如告诉对端某个网段可以通过我到达。和静态路由相比，BGP 能动态发布和撤销路由；和 OSPF 这类内部路由协议相比，BGP 更强调策略控制。

在 Kubernetes CNI 场景里，BGP 常用于 Calico、Cilium、MetalLB 等组件。比如 Calico 可以让每个 Node 发布自己的 Pod CIDR，让跨节点 Pod 通信通过三层路由完成；MetalLB 可以通过 BGP 把 LoadBalancer IP 发布给上游路由器，解决裸金属集群 Service 暴露问题。

生产使用 BGP 时，我会重点关注 ASN、Peer、Prefix、Next Hop、路由过滤、故障收敛、回程路由和路由规模，避免错误路由扩散影响生产网络。

这个回答比单纯说“BGP 是边界网关协议”更有工程味，也能自然引出 CNI、Calico、MetalLB、路由排障这些实践点。

总结¶

BGP 的本质不是 Kubernetes 专属能力，而是一套成熟的动态路由协议。

在云原生网络里，它的价值主要是：

动态发布 Pod CIDR
动态发布 LoadBalancer IP
打通 Kubernetes 和物理网络
减少 Overlay 封装带来的性能和 MTU 问题
支持裸金属、IDC、多云和专线场景下的网络可达性管理

但 BGP 不是“银弹”。它带来性能和网络可控性的同时，也带来了更高的规划、策略和排障要求。

如果只是普通云上托管 Kubernetes，使用云厂商默认 CNI 往往更省心。如果是裸金属、IDC、自建 Kubernetes、跨网络互联或需要把 Service/Pod 路由发布到外部网络，BGP 就是必须认真掌握的核心能力。