共计 3625 个字符，预计需要花费 10 分钟才能阅读完成。
前言
在 腾讯云 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 以及全套监控运维体系的企业级服务。
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！
