Cilium 官方文档翻译(11) BGP-结合BIRD运行BGP协议边界路由传播

本文介绍如何在CentOS 7.x上安装和配置BIRD路由守护进程,使其与Cilium协作,确保集群pod CIDR范围在外部可路由可访问。文章详细介绍了基本配置步骤及高级配置选项。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

BIRD是在Internet网络中路由数据包协议在类UNIX系统上的开源实现,它是一个守护进程。

BIRD BIRD Internet Routing Daemon。它是一个程序(一个守护进程),它在互联网类型的网络(即,运行IPv4或IPv6协议的网络)中充当动态路由器。路由器是在互连网络之间转发数据包的设备,以便允许未直接连接到同一局域网的主机相互通信。它们还与互联网中的其他路由器进行通信,以发现网络拓扑结构,从而允许它们找到用于转发数据包(称为路由表)的最佳(根据某些度量)规则,并适应不断变化的条件,如网络链路中断、建立新连接等。这些路由器大多是昂贵的专用设备,运行不透明的固件,难以配置,且不易更改(另一方面,其特殊的硬件设计使其能够跟接近线速在高速网络接口之间转发数据,比通用计算机更好)。UNIX系列的大多数操作系统允许普通计算机充当路由器并转发属于其他主机的数据包,但只能静态配置路由表。

BIRD提供了一种使用传统网络协议发布路由的方法,以允许在集群外部访问Cilium管理的结点。本文档假设Cilium已经部署在集群中,问题是如何确保集群pod CIDR范围在外部可路由可访问。

BIRD目前维护两个版本系列:1.x和2.x,它们之间的配置格式差异很大。除非您已经大量部署了1.x,否则建议直接使用2.x,因为2.x的维护周期更长。以下示例将bird表示为bird2软件,并以bird2理解的格式使用配置。
本文档介绍如何在CentOS 7.x上安装和配置bird,使其与Cilium协作。其他平台上的安装和配置bird也是类似的。

安装 bird

$ yum install -y bird2

$ systemctl enable bird
$ systemctl restart bird
验证安装:
$ birdc show route
BIRD 2.0.6 ready.

$ birdc              # interactive shell
BIRD 2.0.6 ready.
bird> show bfd sessions
There is no BFD protocol running
bird>
bird> show protocols all
Name       Proto      Table      State  Since         Info
device1    Device     ---        up     10:53:40.147

direct1    Direct     ---        down   10:53:40.147
  Channel ipv4
    State:          DOWN
    Input filter:   ACCEPT
    Output filter:  REJECT
...

基础配置

如果不考虑特定的BGP方案,很难讨论bird配置。然而,BGP方案设计超出了本指南的范围。如果您对此主题感兴趣,请参考数据中心的BGP(O’Reilly,2017)。
下面我们将限制BGP场景如下:
![](https://img-blog.csdnimg.cn/img_convert/556744f59698e52447304f0b8499fb9f.png#clientId=u4fadd8d1-7686-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=ueb20208e&margin=[object Object]&originHeight=569&originWidth=484&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u54a36267-4aff-442b-84f6-4fd357db7e7&title=)

  • 物理网络: 简单的3层分词体系架构
  • 节点通过l2交换机连接物理网络
  • 每个节点通过bird向物理网络宣告PodCIDR
  • 节点不从物理网络导入路由宣告

这种设计下的BGP连接如下图所示:
![](https://img-blog.csdnimg.cn/img_convert/83171f7a1fc468a3e5cbdc0d358d4af2.png#clientId=u4fadd8d1-7686-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u640a6f74&margin=[object Object]&originHeight=569&originWidth=484&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u315d9c2e-721b-4e9f-9037-d92b9231d24&title=)
这种方案简单在:

  • 核心路由器通过bird学习PodCIDR,使pod IP地址在全局网络中变得可路由。
  • bird不从核心路由器或其它节点学习路由,每个节点的内核路由表都保持足够小和清洁,不至于产生性能问题。

在该方案中,每个节点只向节点的默认网关(核心路由器)发送pod出口流量,并让后者进行路由。
下面给出实现上述设计的参考配置:

$ cat /etc/bird.conf
log syslog all;

router id {{ NODE_IP }};

protocol device {
        scan time 10;           # Scan interfaces every 10 seconds
}

# Disable automatically generating direct routes to all network interfaces.
protocol direct {
        disabled;               # Disable by default
}

# Forbid synchronizing BIRD routing tables with the OS kernel.
protocol kernel {
        ipv4 {                    # Connect protocol to IPv4 table by channel
                import none;      # Import to table, default is import all
                export none;      # Export to protocol. default is export none
        };
}

# Static IPv4 routes.
protocol static {
      ipv4;
      route {{ POD_CIDR }} via "cilium_host";
}

# BGP peers
protocol bgp uplink0 {
      description "BGP uplink 0";
      local {{ NODE_IP }} as {{ NODE_ASN }};
      neighbor {{ NEIGHBOR_0_IP }} as {{ NEIGHBOR_0_ASN }};
      password {{ NEIGHBOR_PWD }};

      ipv4 {
              import filter {reject;};
              export filter {accept;};
      };
}

protocol bgp uplink1 {
      description "BGP uplink 1";
      local {{ NODE_IP }} as {{ NODE_ASN }};
      neighbor {{ NEIGHBOR_1_IP }} as {{ NEIGHBOR_1_ASN }};
      password {{ NEIGHBOR_PWD }};

      ipv4 {
              import filter {reject;};
              export filter {accept;};
      };
}

将上面的配置保存到文件/etc/bird.conf,并替换其中变量:

sed -i 's/{{ NODE_IP }}/<your node ip>/g'                /etc/bird.conf
sed -i 's/{{ POD_CIDR }}/<your pod cidr>/g'              /etc/bird.conf
sed -i 's/{{ NODE_ASN }}/<your node asn>/g'              /etc/bird.conf
sed -i 's/{{ NEIGHBOR_0_IP }}/<your neighbor 0 ip>/g'    /etc/bird.conf
sed -i 's/{{ NEIGHBOR_1_IP }}/<your neighbor 1 ip>/g'    /etc/bird.conf
sed -i 's/{{ NEIGHBOR_0_ASN }}/<your neighbor 0 asn>/g'  /etc/bird.conf
sed -i 's/{{ NEIGHBOR_1_ASN }}/<your neighbor 1 asn>/g'  /etc/bird.conf
sed -i 's/{{ NEIGHBOR_PWD }}/<your neighbor password>/g' /etc/bird.conf

重启bird并检查日志:

$ systemctl restart bird

# check logs
$ journalctl -u bird
-- Logs begin at Sat 2020-02-22 16:11:44 CST, end at Mon 2020-02-24 18:58:35 CST. --
Feb 24 18:58:24 node systemd[1]: Started BIRD Internet Routing Daemon.
Feb 24 18:58:24 node systemd[1]: Starting BIRD Internet Routing Daemon...
Feb 24 18:58:24 node bird[137410]: Started
验证变更,你应该得到类似下面的日志:
$ birdc show route
BIRD 2.0.6 ready.
Table master4:
10.5.48.0/24         unicast [static1 20:14:51.478] * (200)
        dev cilium_host
这说明了节点上的PodCIDR `10.5.48.0/24`已经成功导入到BIRD。
$ birdc show protocols all uplink0 | grep -A 3 -e "Description" -e "stats"
  Description:    BGP uplink 0
  BGP state:          Established
    Neighbor address: 10.4.1.7
    Neighbor AS:      65418
--
    Route change stats:     received   rejected   filtered    ignored   accepted
      Import updates:              0          0          0          0          0
      Import withdraws:           10          0        ---         10          0
      Export updates:              1          0          0        ---          1
在这里,我们看到上行链路0 BGP会话已建立,我们的PodCIDR已从上面导出并被BGP对等方接受。

监控

bird_exporter收集bird 守护进程指标,并导出为prometheus格式的度量指标。
它还提供了一个简单的Grafana仪表板,但您也可以创建自己的仪表板,例如Trip.com看起来像这样:
![](https://img-blog.csdnimg.cn/img_convert/f41837cb77e24ceefea75b50636be4a1.png#clientId=u4fadd8d1-7686-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u59711597&margin=[object Object]&originHeight=588&originWidth=1885&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=ubee7da36-05f7-4b74-9db3-f9ce71568ee&title=)

更多配置

您可能需要一些高级配置,以使BGP方案更好的生产就绪。本节列出了其中一些参数,但我们不会深入讨论细节,如需帮助请参考BIRD用户指南

BFD

Bidirectional Forwarding Detection (BFD) 双向转发检测是一种用于加速路径故障检测的检测协议。该特性需要在双端都做以下配置:

protocol bfd {
      interface "{{ grains['node_mgnt_device'] }}" {
              min rx interval 100 ms;
              min tx interval 100 ms;
              idle tx interval 300 ms;
              multiplier 10;
              password {{ NEIGHBOR_PWD }};
      };

      neighbor {{ NEIGHBOR_0_IP] }};
      neighbor {{ NEIGHBOR_1_IP] }};
}

protocol bgp uplink0 {
            ...

        bfd on;
}
通过以下日志验证是否配置成功:
$ birdc show bfd sessions
BIRD 2.0.6 ready.
bfd1:
IP address                Interface  State      Since         Interval  Timeout
10.5.40.2                 bond0      Up         20:14:51.479    0.300    0.000
10.5.40.3                 bond0      Up         20:14:51.479    0.300    0.000

ECMP

出于某些特殊需求(例如L4LB),您可以在多个节点上配置相同的CIDR。在这种情况下,您需要配置 Equal-Cost Multi-Path (ECMP)等成本多路径路由。该功能也需要在双端都做配置:

protocol kernel {
        ipv4 {                    # Connect protocol to IPv4 table by channel
                import none;      # Import to table, default is import all
                export none;      # Export to protocol. default is export none
        };

        # Configure ECMP
        merge paths yes limit {{ N }} ;
}
您需要检查物理网络上的ECMP正确性(上述场景中的核心路由器):
CORE01# show ip route 10.5.2.0
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.5.2.0/24, ubest/mbest: 2/0
    *via 10.4.1.7, [200/0], 13w6d, bgp-65418, internal, tag 65418
    *via 10.4.1.8, [200/0], 12w4d, bgp-65418, internal, tag 65418

优雅重启

该功能也需要在每个bird节点上配置。

protocol bgp uplink0 {
            ...

        graceful restart;
}

参考资料

  1. 原文链接: https://docs.cilium.io/en/stable/gettingstarted/bird/
<think>好的,我需要解释Cilium中的Native-Routing和Host-Routing的区别。首先,我应该回忆一下Cilium的基本网络机制,它通常基于eBPF来实现网络策略和负载均衡。用户可能是在部署或优化Kubernetes网络时遇到选择路由模式的问题,所以需要了解这两种模式的适用场景和工作原理。 首先,Native-Routing,这个词听起来像是直接利用宿主机的现有路由设施,比如Linux内核的路由表,而不是通过覆盖网络(如VXLAN)。这可能意味着数据包在节点之间直接路由,不需要封装,适合在底层网络支持Pod IP直接可达的环境中,比如云提供商的VPC或本地数据中心的BGP网络。这种情况下,Cilium可能不创建额外的隧道,而是依赖底层网络路由能力。 然后是Host-Routing,这可能指的是每个节点上的路由表处理Pod之间的流量。在传统的Kubernetes网络模型中,每个节点上的CNI插件负责设置路由规则,将Pod的流量导向正确的节点。Host-Routing可能指的是这种基于主机路由表的方式,可能使用主机的网络命名空间来处理流量转发,比如通过veth pair连接Pod和主机网络,然后依靠主机的路由规则进行转发。这种情况下,流量可能经过主机的网络栈,可能涉及iptables或eBPF的处理。 需要确认这两种模式的具体定义。查阅Cilium文档,Native-Routing通常指不使用覆盖网络,直接利用底层网络路由能力,而Host-Routing可能更侧重于节点内部的路由处理,比如Pod到Pod在同一节点或跨节点的通信通过主机的路由表进行,可能结合eBPF优化。 可能存在的混淆点在于,Native-Routing可能属于Host-Routing的一种情况,或者两者是不同的层面。比如,Native-Routing涉及跨节点的路由方式,而Host-Routing涉及节点内部的路由机制。或者Host-Routing是Cilium在特定配置下的路由模式,比如当隧道模式关闭时,使用主机路由表进行跨节点通信。 另外,Cilium的隧道模式(如VXLAN)和路由模式(如Native-Routing)是两种不同的跨节点通信方式。当启用Native-Routing时,Cilium假设网络层能够正确处理Pod IP的路由,因此无需封装,直接发送原始IP包。而Host-Routing可能更强调使用主机的路由表,而不是覆盖网络,这可能包括Native-Routing的情况,但Host-Routing也可能指节点内部的路由处理,比如通过主机的网络接口转发Pod流量。 需要进一步区分两者的具体应用场景。例如,Native-Routing适合网络基础设施支持Pod IP路由的环境,而Host-Routing可能更通用,可以结合不同的底层路由机制,包括Native-Routing或其他方式。 可能还需要考虑性能差异。Native-Routing由于无需封装和解封装,可能具有更低的延迟和更高的吞吐量,但要求底层网络支持。而Host-Routing如果指的是基于主机路由表的处理,可能在某些场景下效率稍低,但兼容性更好。 总结来说,用户需要明确Native-Routing和Host-Routing在Cilium中的具体定义、工作机制、适用场景以及配置方式。需要确保回答中准确区分两者,避免混淆,并提供实际用例或配置示例帮助理解。</think>### Cilium 的 Native-Routing 与 Host-Routing 模式详解 Cilium 的 **Native-Routing** 和 **Host-Routing** 是两种不同的网络流量转发机制,均用于优化 Kubernetes 集群内外的通信效率。以下是两者的核心区别与应用场景分析: --- ### 一、**Native-Routing(原生路由)** #### 1. **核心原理** - **直接利用底层网络路由**: Native-Routing 模式下,Cilium **不依赖覆盖网络(如 VXLAN、IPIP)**,而是直接使用底层网络(如云厂商 VPC、物理机 BGP 路由)的现有路由能力转发数据包。 - **无封装开销**: Pod 发出的数据包以**原始 IP 格式**传输,无需添加隧道头部,减少带宽消耗和延迟。 #### 2. **适用条件** - **底层网络需支持 Pod IP 路由**: 集群所有节点的底层网络(如 AWS VPC、GCP VPC)必须能识别并正确转发 Pod IP 的流量。 - **Pod IP 可达性**: Pod IP 必须在集群外部网络中可路由(例如通过 BGP 宣告或静态路由配置)。 #### 3. **典型场景** - **云环境 VPC 网络**: 云厂商的 VPC 支持直接路由 Pod IP,无需额外隧道。 - **混合云/本地数据中心**: 通过 BGP 协议将 Pod IP 路由通告到物理网络。 #### 4. **配置示例** ```yaml # 启用 Native-Routing(禁用隧道) tunnel: disabled ipam: mode: kubernetes enableIPv4Masquerade: false # 假设底层网络已支持 Pod IP 路由 ``` --- ### 二、**Host-Routing(主机路由)** #### 1. **核心原理** - **依赖节点路由表**: Host-Routing 模式下,Cilium 通过配置**节点的 Linux 内核路由表**,实现跨节点 Pod 流量的转发。 - **可能结合隧道或直接路由**: Host-Routing 既可以与 Native-Routing 配合使用(无隧道),也可与覆盖网络(如 VXLAN)结合。 #### 2. **工作模式** - **同节点 Pod 通信**: 通过 `veth pair` 直接连接 Pod 与主机网络命名空间,流量经主机网络栈转发。 - **跨节点 Pod 通信**: - **无隧道(Native-Routing)**:依赖底层网络路由 Pod IP。 - **有隧道(如 VXLAN)**:封装流量后通过隧道传输。 #### 3. **典型场景** - **通用 Kubernetes 网络**: 作为 Cilium 的默认路由基础,兼容各类网络拓扑。 - **边缘计算/资源受限环境**: 通过优化主机路由表减少性能开销。 #### 4. **配置示例** ```yaml # 启用 Host-Routing(默认行为,通常无需显式配置) enableHostReachableServices: true # 优化主机服务可达性 ``` --- ### 三、**Native-Routing 与 Host-Routing 的对比** | **特性** | **Native-Routing** | **Host-Routing** | |------------------------|----------------------------------------|---------------------------------------| | **依赖隧道** | 否 | 可选(可结合 VXLAN 或直接路由) | | **封装开销** | 无 | 若有隧道则存在封装开销 | | **底层网络要求** | 必须支持 Pod IP 路由 | 无特殊要求(依赖主机路由表配置) | | **性能** | 更高(无封装、路径更短) | 取决于是否启用隧道 | | **适用场景** | 云 VPC、BGP 网络 | 通用场景,兼容复杂网络拓扑 | | **配置复杂度** | 高(需确保路由可达性) | 低(Cilium 自动管理路由表) | --- ### 四、**组合使用场景** #### 1. **Native-Routing + Host-Routing** - **原理**: 利用底层网络路由跨节点流量(Native-Routing),同时依赖节点路由表处理本地转发(Host-Routing)。 - **优势**: 兼具高性能和灵活性,适合云环境与混合云部署。 - **配置**: ```yaml tunnel: disabled enableHostReachableServices: true ``` #### 2. **Host-Routing + VXLAN 隧道** - **原理**: 通过 Host-Routing 管理节点内流量,跨节点流量使用 VXLAN 封装。 - **适用场景**: 底层网络不支持 Pod IP 路由(如传统 IDC 网络)。 - **配置**: ```yaml tunnel: vxlan ``` --- ### 五、**验证与调试** #### 1. **检查 Native-Routing 状态** ```bash # 查看路由表是否包含 Pod CIDR 路由 $ ip route show | grep <pod-cidr> # 确认隧道接口不存在(如 cilium_vxlan) $ ip link show | grep cilium_ ``` #### 2. **分析 Host-Routing 路径** ```bash # 跟踪跨节点 Pod 流量路径 $ kubectl exec -it <pod-name> -- traceroute <target-pod-ip> # 检查主机路由表 $ ip route list table all ``` --- ### 六、**性能优化建议** 1. **Native-Routing 场景**: - 启用 **eBPF Host-Routing(Kernel ≥ 5.10)** 绕过 iptables: ```yaml enableBPFHostRouting: true ``` - 使用 **XDP 加速**(需网卡支持): ```yaml bpf: lbBypassFIBLookup: true ``` 2. **Host-Routing 场景**: - 禁用 `kube-proxy`,使用 **Cilium eBPF 替代**: ```yaml kubeProxyReplacement: strict ``` - 优化主机路由缓存: ```bash sysctl -w net.ipv4.route.gc_timeout=300 ``` --- ### 总结 - **Native-Routing**: 适用于底层网络支持 Pod IP 路由的高性能场景,**避免隧道开销**,但对网络基础设施要求较高。 - **Host-Routing**: Cilium 的默认路由基础机制,**灵活兼容各类网络**,可结合隧道或直接路由,适合通用 Kubernetes 集群。 实际部署时,若云环境或数据中心支持 Pod IP 直接路由(如 AWS VPC 路由表自动同步 Pod CIDR),优先选择 **Native-Routing + Host-Routing** 组合以最大化性能;若网络条件受限,则通过 **Host-Routing + 隧道** 实现跨节点通信。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值