腾讯云TKE-基于 Cilium 统一混合云容器网络（下）

前言

在腾讯云TKE – 基于 Cilium 统一混合云容器网络（上）中，我们介绍 TKE 混合云的跨平面网络互通方案和 TKE 混合云 Overlay 网络方案。公有云 TKE 集群添加第三方 IDC 节点服务中，为了应对客户不同使用场景的需求（特别是对于网络性能损耗的低容忍度要求），TKE 混合云网络方案同时提出了基于 BGP 直接路由的 Underlay 网络方案。该网络模型采用 GoBGP 实现，基于 Cilium 打通了 Node-Pod 以及 Pod-Pod 之间网络，能够保证较高的网络性能，并且支持大规模集群扩展。

此网络方案在 TKE 公有云上线前，已经过腾讯云专有云敏捷PaaS平台 TCNS 私有化环境的大规模实践，并在腾讯云 TKEStack 中得到了集成和开源。本文将详细介绍 TKE 混合云基于 BGP 直接路由的 Underlay 容器网络方案的设计与实现。

背景介绍

客户需求的多样性，特别是对网络性能损耗的容忍程度决定了 Underlay 网络方案势在必行。为什么选择 BGP 协议呢？ 相较于 OSPF、RIP 这些内部网关协议，BGP 着眼于控制路由的传播以及选择最佳路径。BGP 最大的优势在于具有较强的可扩展性，能够满足大规模集群横向扩展的需求。另一方面，BGP 足够简单稳定，并且业内也有着基于 BGP 落地生产环境的成功案例。

根据集群规模大小的不同，BGP 路由模式有着不同的方案。当集群规模较小时，可以使用 Full Mesh 互联模式，它要求同一个 AS 内的所有 BGP Speaker 全连接，并且所有外部路由信息必须重新分发到同一个 AS 的其他路由器。随着集群规模扩大，Full Mesh 模式效率将急剧降低，Route Reflection 模式是一种成熟的替代方案。RR 方案下允许一个 BGP Speaker （也即是 Route Reflector）向其他 BGP Peer 广播学习到的路由信息，大大减少了 BGP Peer 连接数量。

与已有方案相比，腾讯混合云采用基于 GoBGP 实现 Cilium 的 Underlay 方案，该方案基于 GoBGP 提供的良好的编程接口实现了自己的 BGP Agent，具备很好的可扩展性。其特点如下：

支持大规模集群的扩展
支持 BGP 邻居发现
支持网络可视化
支持 VIP 和 PodCIDR 路由宣告
支持 ECMP 等高级路由协议
实现 Cilium native-routing 功能
支持 L3 层网络通信

腾讯混合云 Underlay 容器网络方案

在不改变 IDC 机房内部网络拓扑的情况下，接入层交换机和核心层交换机建立 BGP 连接，借助于机房内部已有的路由策略实现。针对 Node 所处的物理位置分配 PodCIDR，每个节点将 PodCIDR 通过 BGP 协议宣告给接入层交换机，实现全网通信的能力。

每个接入层交换机与其管理的 Node 二层联通，共同构成一个 AS。每个节点上跑 BGP 服务，用于宣告本节点路由信息。
核心层交换机和接入层交换机之间的每个路由器单独占用一个 AS，物理直连，跑 BGP 协议。核心层交换机可以感知到全网的路由信息，接入层交换机可以感知与自己直连的 Node 上的路由信息。
每个 Node 上只有一条默认路由，直接指向接入层交换机。同一个接入层交换机下的 Node 通信下一跳指向对端。

邻居发现

在 BGP 实现的集群网络中，经常存在节点新增和删除的情形，如果采用静态配置对等体的方式，需要频繁的操作交换机进行对等体增删的操作，维护工作量很大，不利于集群的横向扩展。为了避免手动对交换机进行操作，我们支持基于配置接入层交换机和软件层面实现的路由反射器这两种模式来动态发现 BGP 邻居。

通过接入层交换机实现动态邻居发现

接入层交换机充当边界路由器，并开启 Dynamic Neighbors 功能，H3C、Cisco以及华为的路由器具体开启 Dynamic Neighbors 配置请参考官方文档。Node上的 BGP 服务主动与接入层交换机建立 iBGP 连接，并宣告本地路由，接入层交换机将学习到的路由宣告给整个数据机房内部。

通过RR实现动态邻居发现

物理交换机或者 Node 节点充当反射路由器 RR，反射路由器与接入层交换机建立 iBGP 连接，Node 节点上的 BGP 服务与反射路由器建立连接。Node上的BGP服务将本地路由宣告给 RR，RR 反射到接入层交换机，接入层交换机接着宣告给整个数据机房内部。

下一跳

每个 Node 上跑 BGP 服务，将本节点的上的 PodCIDR 宣告给接入层交换机，每个接入层交换机可以感知到直连的所有 Node 上的 PodCIDR。接入层交换机下的 Node 之间相互学习路由下发到本地，流量经过接入层交换机二层转发。跨接入层交换机的节点之间通信下一跳指向接入层交换机，同一个接入层交换机下的节点之间通信下一跳指向对端节点。下图展示了同一个接入层交换机下以及跨接入层交换机下节点的路由学习情况，可以直观的根据路由表判定下一跳地址。

同一个接入层交换机下通信链路：10.2.0.2节点与10.2.0.3节点处在同一个接入层交换机下，具备二层连通，报文经过封装后不经过三层转发直接被送到对端。
不同接入层交换机之间通信链路：10.2.0.2节点与10.3.0.3节点处在不同的接入层交换机下，报文需要经过接入层交换机和核心交换机路由后才能到达对端。

BMP 监控

基于 BGP Monitoring Protocol 开发 BMP Server，用于对 BGP 会话的运行状态进行实时监控，包括对等体关系的建立与关闭、路由信息等。利用收集到的BMP Message直接定位故障。

优雅重启

BGP 是基于 TCP 实现的路由协议，TCP 连接异常断开后，开启 Graceful Restart 功能的交换机不会删除 RIB 和 FIB，仍然按照原有的转发表项转发报文，并启动 RIB 路由老化定时器。BGP Peer 需要两端同时开启 Graceful Restart 功能才能生效，Graceful Restart可以有效防止BGP链路震荡，提升底层网络的可用性。

自定义 IPAM

在 Kubernetes 常见配置中，会通过 kube-controller-manager 的

allocate-node-cidrs

和

configure-cloud-routes

等参数来为节点分配 PodCIDR 并配置路由。然而，社区的这种方案限制了节点只能有一段 PodCIDR，并且不能动态扩充。这种一个节点一个 PodCIDR 的策略太简单，导致 IP 资源利用率太低，某些节点规格小可能用不完，某些节点规格大却不够。

在混合云场景下，我们发现客户对于 IPAM 提出了更高的要求：

希望节点的 PodCIDR 可以是多段的
希望节点的 PodCIDR 可以支持按需动态扩充和回收

为了解决这个问题，我们使用了自己的

tke-ipamd

组件来实现自定义的 IPAM 功能，原理如下图所示：

不再由 kube-controller-manager 组件来分配节点 PodCIDR，而是由
```
tke-ipamd
```
组件统一给节点分配 PodCIDR
Cilium Agent 通过 CiliumNode 对象读取
```
tke-ipamd
```
分配的 PodCIDR，响应 CNI 请求给 Pod 分配 IP
```
tke-ipamd
```
通过 list-watch 机制监听节点 IP 资源使用情况，当节点 IP 资源使用率过高时动态扩充节点的 PodCIDR

性能测试

为了对 TKE 混合云 Underlay 容器网络的性能有更好的了解，我们使用 netperf 工具对其进行了性能测试，可以看到，Underlay 在网络吞吐和带宽上基本没有性能损耗。

总结与展望

在介绍了混合云场景下，TKE 基于 Cilium 的混合云容器网络的互联方案和 Overlay 网络方案后，本文重点介绍了基于 BGP 路由的 Underlay 网络方案。TKE 混合云 Underlay 容器网络方案利用了 BGP 的扩展性，能够满足大规模集群横向扩展的需求，同时也能在性能上相对于节点网络做到基本无损，为客户提供更高的数据面转发性能。此网络方案在 TKE 公有云上线前，已经过腾讯云专有云敏捷 PaaS 平台 TCNS 私有化环境的大规模实践，并在腾讯云 TKEStack 中得到了集成和开源。

混合云与容器结合正在吸引越来越多企业客户的目光，其在资源扩容、多活备灾、业务分布式部署等场景可以提高企业现有计算资源利用率，给客户带来显著受益。腾讯云容器团队打通公有云与 IDC 环境差异，为客户提供统一管理视图，实现多云场景、IDC 场景以及边缘场景的统一。除了单集群能力的统一，腾讯云容器团队在集群注册、多集群管理、跨云跨集群互访等方面也有统一的方案，欢迎关注与体验。

参考资料

Using BIRD to run BGP

容器服务（Tencent Kubernetes Engine，TKE）是腾讯云提供的基于 Kubernetes，一站式云原生 PaaS 服务平台。为用户提供集成了容器集群调度、Helm 应用编排、Docker 镜像管理、Istio服务治理、自动化DevOps以及全套监控运维体系的企业级服务。

前言