在 腾讯云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,具备很好的可扩展性。其特点如下:
在不改变 IDC 机房内部网络拓扑的情况下,接入层交换机和核心层交换机建立 BGP 连接,借助于机房内部已有的路由策略实现。针对 Node 所处的物理位置分配 PodCIDR,每个节点将 PodCIDR 通过 BGP 协议宣告给接入层交换机,实现全网通信的能力。
在 BGP 实现的集群网络中,经常存在节点新增和删除的情形,如果采用静态配置对等体的方式,需要频繁的操作交换机进行对等体增删的操作,维护工作量很大,不利于集群的横向扩展。为了避免手动对交换机进行操作,我们支持基于配置接入层交换机和软件层面实现的路由反射器这两种模式来动态发现 BGP 邻居。
接入层交换机充当边界路由器,并开启 Dynamic Neighbors 功能,H3C、Cisco以及华为的路由器具体开启 Dynamic Neighbors 配置请参考官方文档。Node上的 BGP 服务主动与接入层交换机建立 iBGP 连接,并宣告本地路由,接入层交换机将学习到的路由宣告给整个数据机房内部。
物理交换机或者 Node 节点充当反射路由器 RR,反射路由器与接入层交换机建立 iBGP 连接,Node 节点上的 BGP 服务与反射路由器建立连接。Node上的BGP服务将本地路由宣告给 RR,RR 反射到接入层交换机,接入层交换机接着宣告给整个数据机房内部。
每个 Node 上跑 BGP 服务,将本节点的上的 PodCIDR 宣告给接入层交换机,每个接入层交换机可以感知到直连的所有 Node 上的 PodCIDR。接入层交换机下的 Node 之间相互学习路由下发到本地,流量经过接入层交换机二层转发。跨接入层交换机的节点之间通信下一跳指向接入层交换机,同一个接入层交换机下的节点之间通信下一跳指向对端节点。下图展示了同一个接入层交换机下以及跨接入层交换机下节点的路由学习情况,可以直观的根据路由表判定下一跳地址。
基于 BGP Monitoring Protocol 开发 BMP Server,用于对 BGP 会话的运行状态进行实时监控,包括对等体关系的建立与关闭、路由信息等。利用收集到的BMP Message直接定位故障。
BGP 是基于 TCP 实现的路由协议,TCP 连接异常断开后,开启 Graceful Restart 功能的交换机不会删除 RIB 和 FIB,仍然按照原有的转发表项转发报文,并启动 RIB 路由老化定时器。BGP Peer 需要两端同时开启 Graceful Restart 功能才能生效,Graceful Restart可以有效防止BGP链路震荡,提升底层网络的可用性。
在 Kubernetes 常见配置中,会通过 kube-controller-manager 的 allocate-node-cidrs
和 configure-cloud-routes
等参数来为节点分配 PodCIDR 并配置路由。然而,社区的这种方案限制了节点只能有一段 PodCIDR,并且不能动态扩充。这种一个节点一个 PodCIDR 的策略太简单,导致 IP 资源利用率太低,某些节点规格小可能用不完,某些节点规格大却不够。
在混合云场景下,我们发现客户对于 IPAM 提出了更高的要求:
为了解决这个问题,我们使用了自己的 tke-ipamd
组件来实现自定义的 IPAM 功能,原理如下图所示:
tke-ipamd
组件统一给节点分配 PodCIDRtke-ipamd
分配的 PodCIDR,响应 CNI 请求给 Pod 分配 IPtke-ipamd
通过 list-watch 机制监听节点 IP 资源使用情况,当节点 IP 资源使用率过高时动态扩充节点的 PodCIDR为了对 TKE 混合云 Underlay 容器网络的性能有更好的了解,我们使用 netperf 工具对其进行了性能测试,可以看到,Underlay 在网络吞吐和带宽上基本没有性能损耗。
在介绍了混合云场景下,TKE 基于 Cilium 的混合云容器网络的互联方案和 Overlay 网络方案后,本文重点介绍了基于 BGP 路由的 Underlay 网络方案。TKE 混合云 Underlay 容器网络方案利用了 BGP 的扩展性,能够满足大规模集群横向扩展的需求,同时也能在性能上相对于节点网络做到基本无损,为客户提供更高的数据面转发性能。此网络方案在 TKE 公有云上线前,已经过腾讯云专有云敏捷 PaaS 平台 TCNS 私有化环境的大规模实践,并在 腾讯云 TKEStack 中得到了集成和开源。
混合云与容器结合正在吸引越来越多企业客户的目光,其在资源扩容、多活备灾、业务分布式部署等场景可以提高企业现有计算资源利用率,给客户带来显著受益。腾讯云容器团队打通公有云与 IDC 环境差异,为客户提供统一管理视图,实现多云场景、IDC 场景以及边缘场景的统一。除了单集群能力的统一,腾讯云容器团队在集群注册、多集群管理、跨云跨集群互访等方面也有统一的方案,欢迎关注与体验。
容器服务(Tencent Kubernetes Engine,TKE)是腾讯云提供的基于 Kubernetes,一站式云原生 PaaS 服务平台。为用户提供集成了容器集群调度、Helm 应用编排、Docker 镜像管理、Istio服务治理、自动化DevOps以及全套监控运维体系的企业级服务。
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯,扫码关注同名公众号,及时获取更多干货!!
Redis 官方在 2020 年 5 月正式推出 6.0 版本,提供很多振奋人心的新特性,所以...
1.HTML5的内容类型 内容类型 描述 内嵌 向文档中添加其他类型的内容,例如audio...
先点赞再看,养成好习惯 前言 这两天在另一个社区看到了一个关于 Tomcat 的提问...
注释1:上图整个大背景是这个网页的全部尺寸,中间的小框才是浏览器中的可见尺寸...
John Au-Yeung 来源:medium 译者:前端小智 有梦想,有干货,微信搜索 【大迁世...
解决方法如下: 第一种 使用iframe,但是目前使用iframe的人已经越来越少了,而...
content属性一般用于::before、::after伪元素中,用于呈现伪元素的内容。平时con...
复制代码 代码如下: !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional...
简介: 企业上云多账号架构中,如何做到从上到下管理的同时,处理好员工的权限边...
data URI scheme 允许我们使用内联(inline-code)的方式在网页中包含数据,可以...