cilium 网络概念

tunnel(隧道封装)

当未提供配置时，Cilium会自动以这种模式运行，因为这种模式对底层网络基础设施的要求最少。

在这种模式下，所有集群节点使用基于UDP的封装协议VXLAN或Geneve形成隧道网格。所有Cilium节点之间的流量都被封装。

对网络的要求

封装依赖于正常的节点之间的连通性。这意味着如果Cilium节点已经可以相互通信，那么所有路由要求已经得到满足。

底层网络和防火墙必须允许封装的数据包

封装方式	Port Range / Protocol
VXLAN (Default)	8472/UDP
Geneve	6081/UDP

tunnel 模型的优点

简单性
  连接集群节点的网络不需要了解PodCIDRs。集群节点可以生成多个路由或链路层域。只要集群节点可以使用IP/UDP相互访问，底层网络的拓扑结构就无关紧要。

地址空间
  由于不依赖于任何底层网络限制，可用的地址空间可能更大，并且如果配置PodCIDR大小，则允许在每个节点上运行任意数量的Pod。

自动配置
  与诸如Kubernetes之类的编排系统一起运行时，集群中所有节点的列表，包括它们各自的分配前缀节点，会自动提供给每个代理程序。加入集群的新节点将自动纳入网格。

身份上下文
  封装协议允许在网络数据包中携带元数据。Cilium利用这种能力传输元数据，如源安全标识。身份传递是一个优化设计，旨在避免在远程节点上进行一次身份查找。

tunnel 模型的缺点

由于添加封装头部，有效负载可用的MTU比原生路由低（每个网络数据包的VXLAN为50字节）。这导致特定网络连接的最大吞吐量降低。通过启用巨型帧（每1500字节额外50字节开销 vs 每9000字节额外50字节开销），可以很大程度上减轻这一问题。

两种隧道协议的区别

VXLAN（默认，8472/UDP）

RFC 7348 标准协议，Header 固定 50 字节（14+20+8+8=50），VNI 字段 24 bit 用来隔离租户 。
外层: Node IP | UDP 8472 | VXLAN Header (VNI 24bit) | 内层: Pod MAC+IP

标准协议，所有交换机/路由器/云厂商都认
Header 固定，不能塞额外信息
单 VNI 承载所有 Pod 流量，租户隔离靠上层 Cilium 身份（label）

Geneve（6081/UDP）

RFC 8926 标准协议，Header 可变长（14+20+8+8+N），Option 字段最长 252 字节 。
外层: Node IP | UDP 6081 | Geneve Header (VNI 24bit + Option Len) | Options (Cilium 塞东西) | 内层: Pod MAC+IP

灵活：Option 字段可编码任意元数据
Cilium 用它来在隧道头上捎带 security identity（即 Pod 的 label 哈希），接收端不用再查 map 就能知道这包属于哪个身份
DSR 模式下 service IP/port 也编进 Geneve Option，让 DSR 能在隧道场景下工作
代价：Header 变长，MTU 开销比 VXLAN 更大一点（但一般仍按 50 字节算）

VXLAN 和 Geneve 核心差异对照 

维度	VXLAN	Geneve
端口​	8472/UDP	6081/UDP
Header 长度​	固定 50B	可变，通常 50-70B
标准化​	RFC 7348（2014）	RFC 8926（2020）
可扩展性​	固定字段，无法扩展	Option 字段可编码任意元数据
Cilium identity 传递​	接收端需查 map 反解	直接编在 Geneve Option 里，少一次查表
DSR 跨隧道​	❌ 不支持	✅ 支持（service info 编 Geneve Option）
硬件 Offload​	广泛支持（很多 NIC 有 VXLAN offload）	较少
云厂商兼容​	所有云都放行 8472	部分云可能只认 8472
性能​	略优（header 固定，处理简单）	略逊（需解析变长 Option）

VXLAN 和 Geneve 选型决策树

你需要 Geneve 的特性吗？
├── 否 → VXLAN（默认，直接走）
│   └── 适用：绝大多数场景
│
└── 是 → Geneve
    ├── 需要 DSR + 隧道模式 → Geneve 必选（VXLAN 不支持 DSR over tunnel）
    ├── 大规模集群，想减少 identity 查表开销 → Geneve
    └── 需要隧道头携带自定义元数据 → Geneve

场景与配置

场景 1：默认选择 → VXLAN

cilium install \
  --set routingMode=tunnel \
  --set tunnel=vxlan \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=$API_SERVER_IP \
  --set k8sServicePort=6443

适用：
    95% 的集群都该用这个
    开发/测试/生产通用
    云环境（AWS/Azure/GCP 都放行 8472/UDP）
    不想折腾 Geneve 的可变长 Header
配套：
    防火墙放行 8472/UDP
    MTU 设为 1450（1500-50），或底层开 Jumbo Frame 9000 → 8950 缓解

场景 2：要 DSR + 隧道 → Geneve

cilium install \
  --set routingMode=tunnel \
  --set tunnel=geneve \
  --set loadBalancer.mode=dsr \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=$API_SERVER_IP \
  --set k8sServicePort=6443

适用：
    想用 DSR 模式（保留客户端 IP、降低延迟）
    又必须用隧道（底层网络不能 native-routing）
    跨子网 + 要 DSR → 这是唯一组合：VXLAN 不支持隧道 DSR
    
原理：Geneve Option 字段编码 service IP/port，backend 收到后能直接回客户端，不用经过 LB 节点反向 SNAT

配套：
    防火墙放行 6081/UDP
    MTU 1450（Geneve header 可能比 VXLAN 多几个字节）

场景 3：大规模集群性能优化 → Geneve

超大规模（千节点+）集群，VXLAN 每次接收都要从 VNI 反查 Cilium identity map，Geneve 直接把 identity 编码在隧道头里，接收端零查表

cilium install \
  --set routingMode=tunnel \
  --set tunnel=geneve \
  --set kubeProxyReplacement=true \
  ...

适用：
    千节点以上
    Service / Endpoint 数量巨大
    对数据路径延迟极端敏感

决策速查

你的场景	tunnel 协议	理由
通用默认	VXLAN​	标准、兼容好、性能略优
DSR + 隧道（跨子网要 DSR）	Geneve​	VXLAN 不支持隧道 DSR
千节点+大规模	Geneve​	免 identity 查表
云环境（AWS/Azure/GCP）	VXLAN​	云厂商 8472 放行普遍
裸金属 + 要 DSR + 跨子网	Geneve​	唯一可行组合
同 L2 + 要 DSR	不用隧道，走 native + DSR OPT	见前一轮 routingMode 讨论
开发测试	VXLAN​	省事

 

Native-Routing(原生路由 or 本地路由)

本地路由数据路径通过设置 routing-mode: native 启用，并启用本机数据包转发模式。本机数据包转发模式利用Cilium所在网络的路由能力，而不是执行封装。

在本地路由模式下，Cilium将把所有未寻址给另一个本地端点的数据包委托给Linux内核的路由子系统。这意味着该数据包将被路由，就像一个本地进程发出了数据包一样。因此，连接集群节点的网络必须能够路由 PodCIDRs。

当配置本机路由时，Cilium会自动在Linux内核中启用IP转发。

对网络的要求

为了运行本地路由模式，运行Cilium的宿主之间的网络必须能够使用分配给Pod或其他工作负载的地址转发IP流量。

节点上的Linux内核必须知道如何转发所有运行Cilium的节点的Pod或其他工作负载的数据包。这可以通过两种方式实现：

  1. 节点本身不知道如何路由所有Pod的IP，但网络上存在一个路由器，该路由器知道如何到达所有其他Pod。在这种情况下，配置Linux节点包含一条默认路由，指向这样的路由器。此模型用于云提供商网络集成。
  2. 每个单独的节点被告知所有其他节点的所有Pod IP，并将路由插入Linux内核路由表以表示这一点。如果所有节点共享单一的L2网络，那么通过启用选项auto-direct-node-routes: true可以解决这个问题。否则，必须运行额外的系统组件（例如BGP守护进程）来分发路由。

配置

routing-mode: native: 启用本地路由模式。
ipv4-native-routing-cidr: x.x.x.x/y: 设置可以执行本地路由的CIDR。

Masquerading(地址伪装)

将来自集群外部流量转发至集群上的Pod时依赖的功能，传统方式是使用iptables nat机制(称为iptables mode)。

eBPF提供了更加高效的masquerading机制(eBPF mode)，但仅在4.19及以上版本的Linux内核上支持。

此行为可以通过选项 enable-ipv4-masquerade: false（对于IPv4流量）和 enable-ipv6-masquerade: false（对于IPv6流量）来禁用，从而离开主机的流量不再进行伪装。

基于 eBPF-based 实现

基于eBPF的实现是最高效的实现方式。它需要Linux内核版本4.19，并可以通过 bpf.masquerade=true Helm选项进行启用。

当前的实现依赖于BPF NodePort功能。这种依赖关系将在将来移除。

伪装只能在运行eBPF伪装程序的设备上进行。这意味着如果输出设备运行该程序，那么从Pod发送到外部地址的数据包将被伪装（转换为输出设备的IPv4地址）。如果未指定，程序将自动附加到由BPF NodePort设备检测机制选择的设备上。要手动更改此设置，请使用devices Helm选项。使用cilium status 命令确定程序正在哪些设备上运行。

基于eBPF的伪装可以伪装以下L4协议的报文：

  传输控制协议
  UDP协议
  ICMP

默认情况下，所有从Pod发送到ipv4-native-routing-cidr范围之外的IP地址的数据包都会进行伪装，除了发送到其他集群节点的数据包（就像对于IPv6的情况，使用ipv6-native-routing-cidr）。

为了实现更加精细的控制，Cilium在eBPF中实现了ip-masq-agent，可以通过 ipMasqAgent.enabled=true Helm选项启用。

基于eBPF的ip-masq-agent支持在配置文件中设置nonMasqueradeCIDRs、masqLinkLocal和masqLinkLocalIPv6选项。从Pod发送到属于nonMasqueradeCIDRs中任何CIDR的目标的数据包不会被伪装。如果配置文件为空，代理将提供以下非伪装CIDRs：
  10.0.0.0/8
  172.16.0.0/12
  192.168.0.0/16
  100.64.0.0/10
  192.0.0.0/24
  192.0.2.0/24
  192.88.99.0/24
  198.18.0.0/15
  198.51.100.0/24
  203.0.113.0/24
  240.0.0.0/4

此外，如果masqLinkLocal未设置或设置为false，则将169.254.0.0/16附加到非伪装CIDRs列表中。对于IPv6，如果masqLinkLocalIPv6未设置或设置为false，则会附加fe80::/10。

基于iptables

这是适用于所有内核版本的遗留实现。

这意味着，可以通过指定特定的网络接口（例如eth0），来限制仅在这些接口上进行源地址伪装（MASQUERADE）。这种做法通常在想要限定出站流量伪装发生在特定网络路径上时非常有用。例如，在有多个出口接口的复杂网络环境中，或者在仅希望对外部（Internet）出站流量进行伪装，而保持内部网络流量原始源地址不变的场景下。

对于路由层根据目标CIDR选择不同源地址的高级情况，可以使用选项 enable-masquerade-to-route-source: "true"，以便对源地址进行伪装，而不是对主接口地址进行伪装。然后，后者仅被视为通用的备用选项，用于默认路由。对于这些高级情况，用户需要确保在相关的伪装接口上没有重叠的目标CIDR作为路由。

这意味着允许在路由级别上根据目标CIDR选择不同的源地址。通过设置 enable-masquerade-to-route-source: "true"，数据包将根据目标CIDR对源地址进行伪装。这种灵活性可在需要更复杂路由选择行为的场景下使用，但要注意确保没有在相关伪装接口上设置重叠目标CIDR，以避免路由冲突。

IP 地址管理 (IPAM)

IP 地址管理 (IPAM) 负责 Cilium 管理的网络端点（容器等）使用的 IP 地址的分配和管理。支持多种IPAM模式，满足不同用户的需求。

不要更改现有集群的 IPAM 模式。在现有环境中更改 IPAM 模式可能会导致现有工作负载的连接持续中断。更改 IPAM 模式的最安全方式是使用新的 IPAM 配置安装新的 Kubernetes 集群。

Feature	Kubernetes 主机范围	集群范围（默认）	Multi-Pool	CRD 支持	AWS ENI	Azure IPAM	GKE
Tunnel routing	✅	✅	❌	❌	❌	❌	❌
Direct routing	✅	✅	✅	✅	✅	✅	✅
CIDR Configuration	Kubernetes	Cilium	Cilium	External	External (AWS)	External (Azure)	External (GCP)
Multiple CIDRs per cluster	❌	✅	✅	N/A	N/A	N/A	N/A
Multiple CIDRs per node	❌	❌	✅	N/A	N/A	N/A	N/A
Dynamic CIDR/IP allocation	❌	❌	✅	✅	✅	✅	❌

集群范围（默认）

集群范围的IPAM模式为每个节点分配节点范围的PodCIDR，并使用每个节点上的主机范围分配器分配IP地址。因此，它类似于Kubernetes的Host Scope模式。不同之处在于，Cilium操作员将通过v2.CiliumNode资源管理每个节点的PodCIDR，而不是Kubernetes通过Kubernetes v1.Node资源分配每个节点的PodCIDR。这种模式的优势在于它不依赖于Kubernetes配置为分配每个节点的PodCIDR。

架构

扩展 cluster pool

在clusterPoolIPv4PodCIDRList列表中不要更改任何现有元素，因为更改会导致意外行为。如果池耗尽了，应该向列表添加新元素。最小掩码长度为/30，建议最小掩码长度至少为/29。之所以添加新元素而不更改现有元素的原因是分配器为每个CIDR块保留了2个IP地址，用于网络地址和广播地址。不能更改clusterPoolIPv4MaskSize。

Kubernetes 主机范围

Kubernetes 主机范围 IPAM 模式通过 ipam: kubernetes 启用，并将地址分配委托给集群中的每个单独节点。 IP 是由 Kubernetes 在与每个节点关联的 PodCIDR 范围之外分配的。

架构

annotation 设置

Annotation	Description
network.cilium.io/ipv4-pod-cidr	IPv4 PodCIDR range
network.cilium.io/ipv6-pod-cidr	IPv6 PodCIDR range
network.cilium.io/ipv4-cilium-host	IPv4 address of the cilium host interface
network.cilium.io/ipv6-cilium-host	IPv6 address of the cilium host interface
network.cilium.io/ipv4-health-ip	IPv4 address of the cilium-health endpoint
network.cilium.io/ipv6-health-ip	IPv6 address of the cilium-health endpoint

配置

通过 ConfigMap 选项来配置 Kubernetes 主机范围：

ipam: kubernetes：启用 Kubernetes IPAM 模式。如果enable-ipv4为true，启用此选项将自动启用k8s-require-ipv4-pod-cidr；如果enable-ipv6为true，则启用k8s-require-ipv6-pod-cidr。

k8s-require-ipv4-pod-cidr: true：指示 Cilium 代理等待，直到通过 Kubernetes 节点资源提供 IPv4 PodCIDR。

k8s-require-ipv6-pod-cidr: true：指示 Cilium 代理等待，直到通过 Kubernetes 节点资源提供 IPv6 PodCIDR。

通过 helm 选项来配置 Kubernetes 主机范围：

ipam: kubernetes: --set ipam.mode=kubernetes.

k8s-require-ipv4-pod-cidr: true: --set k8s.requireIPv4PodCIDR=true，仅适用于 --set ipam.mode=kubernetes

k8s-require-ipv6-pod-cidr: true: --set k8s.requireIPv6PodCIDR=true，仅适用于 --set ipam.mode=kubernetes

routingMode 的本质区别

routingMode: tunnel（默认）

不配置 Cilium 就自动跑这个模式 。所有节点之间建立 UDP 隧道网格（VXLAN 默认 8472/UDP，或 Geneve 6081/UDP），Pod 包在外面套一层节点 IP/UDP 头 。

Pod A (10.244.1.1) → Pod B (10.244.2.1)
外层: Node1 IP → Node2 IP, UDP 8472, VXLAN header
内层: 10.244.1.1 → 10.244.2.1

底层网络只需要一件事：节点 IP 之间能互通 。PodCIDR 不需要告诉路由器，防火墙放行 8472/6081 UDP 即可。

routingMode: native

设置 routingMode=native 后，Cilium 不做封装，把非本机 Pod 的包直接交给 Linux 内核路由子系统，包原样从网卡出去，源/目 IP 就是 Pod IP 。

Pod A (10.244.1.1) → Pod B (10.244.2.1)
外层: 10.244.1.1 → 10.244.2.1   （没有任何封装）

底层网络必须：路由器/交换机知道怎么到达 10.244.0.0/16 这个 PodCIDR——要么静态路由，要么 BGP 动态通告，要么云厂商 VPC 路由表 。

routingMode 总结

维度	tunnel（封装）	native（原生路由）
底层网络要求​	只需节点 IP 互通	必须能路由 PodCIDR
性能​	VXLAN 每包 +50 字节开销，有效 MTU 1450	无封装开销，全 MTU
延迟​	封包/解包 CPU 开销	接近裸金属线速
可调试性​	包被封装，抓包难看内层	抓包直接看到 Pod IP，清晰
部署复杂度​	极低，默认就能跑	需配 autoDirectNodeRoutes 或 BGP CP （需要网络组配合）
可移植性​	跨云/跨机房都行	受限——云厂商不一定让播路由
地址空间​	不受底层网络限制	受底层路由表容量限制

场景决策树

你的底层网络能不能路由 PodCIDR？
├── 不能 / 不知道 / 跨云跨复杂网络
│   └── routingMode: tunnel（默认）
│       配 tunnel=vxlan 或 tunnel=geneve
│       场景：开发测试、混合云、托管 K8s、快速起步
│
└── 能（同 L2 或能跑 BGP 或云 VPC 路由可控）
    └── routingMode: native + tunnel=disabled
        ├── 同 L2 单机柜 / 同广播域
        │   └── autoDirectNodeRoutes=true
        │       Cilium 自己加直连路由，不用 BGP
        │       场景：裸金属小集群、同 rack 百节点内
        │
        ├── 跨子网 / 多 rack / 多机房
        │   └── autoDirectNodeRoutes=false + bgpControlPlane.enabled=true
        │       Cilium BGP CP 把 PodCIDR /32 宣告给 TOR
        │       场景：裸金属跨子网百/千节点
        │
        └── 公有云（AWS/GCP/Azure）
            └── 用云厂商原生路由集成（eni/azure 模式）
                场景：EKS/AKS/GKE 的高性能档

四种主场景完整对照

路径选择的硬判据

问网络组一个问题：能不能在 TOR 上开 BGP，让 K8s 节点跟 TOR 建 eBGP？
├── 能 → 路径 A：native + BGP CP
│   ├── 优点：无封装、全 MTU、线速、可观测性强
│   ├── 缺点：需要网络组配合，TOR 配置 BGP
│   └── 适用：裸金属数据中心、Spine-Leaf 架构
│
└── 不能 → 路径 B：tunnel
    ├── 优点：零网络耦合，跨云/跨复杂网络都能跑
    ├── 缺点：MTU 1450、封包 CPU 开销
    └── 适用：快速起步、网络组不配合、混合云

场景 A：tunnel + vxlan（默认，最通用）

Pod A (10.244.1.1) ──封装──▶ Node1 ══UDP 8472══▶ Node2 ──解封──▶ Pod B (10.244.2.1)
外层: Node1 IP → Node2 IP | VXLAN Header (VNI) | 内层: 10.244.1.1 → 10.244.2.1

cilium install \
  --set routingMode=tunnel \
  --set tunnel=vxlan \
  --set tunnelPort=8472 \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=$API_SERVER_IP \
  --set k8sServicePort=6443

适用场景：
    ✅ 95% 的集群——开发测试、生产、云、跨云、混合云
    ✅ 底层网络不能/不想改路由表
    ✅ 防火墙只能放开 8472/UDP
    ✅ 快速起步，零网络耦合
    ✅ 公有云默认选择（AWS/Azure/GCP 都放行 8472）
代价：
    MTU 1450（1500-50），Jumbo Frame 9000→8950 可缓解
    封包/解包 CPU 开销
    抓包看到的是外层 IP，需 tcpdump -i eth0 udp port 8472 -x 才能看内层

场景 B：tunnel + geneve（DSR over 隧道的唯一选择）

Pod A ──封装──▶ Node1 ══UDP 6081══▶ Node2 ──解封──▶ Pod B
外层: Node1 IP → Node2 IP | Geneve Header (VNI + Option: Cilium Identity / DSR Service Info) | 内层: Pod IP

SEED=$(head -c12 /dev/urandom | base64 -w0)
echo "Save this Maglev hashSeed: $SEED"   # 集群内固定，重启/升级都不能变

export API_SERVER_VIP=10.0.3.10
export DEVICE=eth0

cilium install \
  --version 1.19.6 \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=$API_SERVER_VIP \
  --set k8sServicePort=6443 \
  --set routingMode=tunnel \
  --set tunnel=geneve \                      # ⭐ 不是 vxlan
  --set tunnelPort=6081 \
  --set ipam.mode=cluster-pool \
  --set ipam.operator.clusterPoolIPv4PodCIDRList="{10.244.0.0/16}" \
  --set ipam.operator.clusterPoolIPv4MaskSize=24 \
  --set bpf.masquerade=true \
  --set devices={$DEVICE} \
  --set loadBalancer.mode=hybrid \           # ⭐ TCP DSR + UDP SNAT
  --set loadBalancer.dsrDispatch=geneve \    # ⭐ 隧道 DSR 的唯一 dispatch
  --set loadBalancer.algorithm=maglev \      # ⭐ Maglev 一致性哈希
  --set maglev.tableSize=65521 \
  --set maglev.hashSeed=$SEED \
  --set loadBalancer.acceleration=native \   # 网卡支持 XDP 时开启
  --set bpf.lbModeAnnotation=true \          # 允许 Service 级覆盖 mode
  --set bpf.lbAlgorithmAnnotation=true \     # 允许 Service 级覆盖 algorithm
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

适用场景：
    ✅ 跨子网 + 需要 DSR（保留客户端 IP + 最低延迟）
    ✅ VXLAN 不支持隧道 DSR，Geneve 是唯一组合​
    ✅ 千节点+ 大规模集群：Geneve Option 携带 Cilium identity，接收端免查表
    ✅ 需要在隧道头携带自定义元数据
    
代价：
    防火墙必须放行 6081/UDP（部分老旧云环境可能只认 8472）
    Header 变长，MTU 开销略大于 VXLAN（仍按 50B 算）
    硬件 offload 支持不如 VXLAN 广泛
    底层网络需关闭源 IP 校验（AWS/Azure 默认开启会丢 DSR 包）
    
Geneve 的两个独特价值：
    Identity 传递：Cilium security identity 直接编在 Geneve Option 里，接收端不用查 map 反解
    DSR over 隧道：service IP/port 编在 Option 里，backend 直接回客户端

场景 C：native + autoDirectNodeRoutes（同 L2 最优）

Pod A (10.244.1.1) ──直出──▶ Node1 ──L2 转发──▶ Node2 ──直入──▶ Pod B (10.244.2.1)
外层: 10.244.1.1 → 10.244.2.1   （无任何封装，全 MTU）

cilium install \
  --set routingMode=native \
  --set tunnel=disabled \
  --set autoDirectNodeRoutes=true \
  --set ipv4NativeRoutingCIDR="10.244.0.0/16" \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=$API_SERVER_IP \
  --set k8sServicePort=6443 \
  --set devices={eth0}

适用场景：
    ✅ 裸金属同 L2 广播域（同交换机/同柜顶）
    ✅ 节点 Underlay IP 在同一网段
    ✅ 1+2 / 3+3 / 小集群（≤100 节点）最省事
    ✅ 追求裸金属线速性能
    ✅ 可调试性要求高（抓包直接看 Pod IP）
    原理：Cilium 自动在本机路由表加 10.244.x.0/24 via <node-underlay-ip> dev eth0，节点间走 L2 转发。

代价：
    跨子网不可用（L2 出不去）
    不封装，所以也没有"隧道"概念

场景 D：native + BGP CP（跨子网生产级）

Pod A (10.244.1.1) ──直出──▶ Node1 ──L3 路由──▶ TOR ──BGP──▶ Spine ──▶ Node2 ──▶ Pod B (10.244.2.1)

cilium install \
  --set routingMode=native \
  --set tunnel=disabled \
  --set autoDirectNodeRoutes=false \     # ⭐ 跨子网必须关
  --set ipv4NativeRoutingCIDR="10.244.0.0/16" \
  --set bgpControlPlane.enabled=true \   # ⭐ 开 BGP CP
  --set loadBalancer.mode=hybrid \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=$API_SERVER_IP \
  --set k8sServicePort=6443 \
  --set devices={eth0}

适用场景：
    ✅ 裸金属跨子网 / 多 rack / 多机房
    ✅ Spine-Leaf 架构数据中心
    ✅ 百/千节点生产集群
    ✅ 需要 BGP ECMP 对外暴露 LoadBalancer

代价：
    需要网络组配合开 BGP peer（TOR IP + AS）
    配置复杂度最高

routingMode × tunnel 组合矩阵

routingMode	tunnel	底层网络要求	性能	典型场景
tunnel​	vxlan​	节点 IP 互通即可	中（封装开销）	通用默认、云、跨云
tunnel​	geneve​	节点 IP 互通 + 放 6081/UDP	中（略逊 vxlan）	DSR over 隧道、千节点+
native​	disabled + autoDirectNodeRoutes=true	同 L2 + Cilium 自管路由	最高（无封装）	裸金属同 rack 小集群
native​	disabled + BGP CP	跨子网 + TOR 支持 BGP	最高（无封装）	裸金属跨子网生产

 

参考文档

https://docs.cilium.io/en/stable/network/concepts/