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

作者

魏后民，腾讯云后台开发工程师，关注容器、Kubernetes、Cilium等开源社区，负责腾讯云 TKE 混合云容器网络等相关工作。

赵奇圆，腾讯云高级工程师，主要负责腾讯云容器网络设计和研发工作。

前言

混合云 并不是一个新鲜的概念，但随着容器技术的发展，混合云与容器的结合正在得到越来越多的关注。通过容器等云原生技术，可以屏蔽混合云异构集群底层计算资源基础设施的差异，实现多云场景、IDC 场景乃至边缘等场景的统一。混合云将不再是公有云和私有云的简单结合，而是计算负载无处不在的分布式云，可以充分发挥其在资源扩容、多活容灾、多集群混合部署等场景的优势。

腾讯云 TKE 容器服务推出公有云集群添加第三方 IDC 计算节点服务，该服务可以让客户复用 IDC 计算资源，免去在本地搭建、运维 Kubernetes 集群的成本，最大化提高计算资源使用率。

在这个方案的底层实现中，打通 IDC 和公有云之间的网络是重要的一环。一个 Kubernetes 集群中可能包含众多不同网络环境的计算节点，比如 IDC 网络环境和公有云 VPC 网络环境的计算节点。为了屏蔽底层不同网络环境的差异，TKE 提出了混合云容器网络方案，在容器层面看到的是统一的网络平面，使得 Pod 无需感知其是运行在 IDC 的计算节点还是公有云的计算节点。

TKE 混合云容器网络同时支持基于 VxLAN 隧道模式的 Overlay 网络和基于直接路由的 Underlay 网络。当客户不希望改变其 IDC 基础网络设施时，可以使用 Overlay 网络；当客户对于混合云容器网络的性能有很高的要求时，可以使用基于直接路由的 Underlay 网络。本文将详述混合云中容器网络面临的挑战与解决方案，并介绍 TKE 混合云容器 Overlay 网络的实现。接下来还会有文章单独介绍 TKE 混合云容器 Underlay 网络的实现，敬请期待。

混合云容器网络面临的挑战

在混合云场景下，一个 Kubernetes 集群的各个组件可能分布在不同的网络平面：

• Master Network：运行着 ApiServer 等控制面组件的网络平面
• VPC Network：包含有 TKE 公有云集群计算节点的网络平面
• IDC Network：包含有客户 IDC 计算节点的网络平面

混合云复杂的场景下，如何打通不同网络平面的链路，对容器网络设计提出了挑战：

VPC Network 和 IDC Network 互相访问

混合云场景下，一个 Kubernetes 集群可能既包含 VPC Network 下的公有云计算节点，也包含 IDC Network 下的计算节点。打通这些处于不同网络环境下的节点网络，是上层容器网络互通的基础。

IDC Network 主动访问 Master Network

Kubernetes 环境下最常见的一个场景是计算节点的 Kubelet 会连接处于 Master Network 的 ApiServer，用于获取集群相关的状态和上报节点信息，这就要求 IDC Network 能够主动访问 Master Network。

Master Network 主动访问 IDC Network

Kubernetes 环境下为了调试，我们常常使用 kubectl logs 和 kubectl exec 等命令实现获取应用 Pod 的日志和直接登陆到应用 Pod 的运行环境。以 kubectl exec 为例，下图展示了这类命令的实现原理：执行 kubectl exec 时首先会向 ApiServer 发起请求，由 ApiServer 转发给 Pod 所在节点上的 kubelet 进程，然后再转发给 runtime 的 exec 接口。

上述机制如果想要成功运行，要求处于 Master Network 的 ApiServer 与计算节点上的 kubelet 之间存在一条网络通路，允许 ApiServer 能够主动访问 kubelet。除了 kubectl exec 和 kubectl log 等命令，kube-scheduler 的 extender 机制 和 ApiServer 的 Admission Webhook 机制 都依赖于 Master Network 与计算节点的网络打通。

如何屏蔽底层网络差异，统一容器网络

混合云场景下，一个 Kubernetes 集群可能既包含 VPC Network 下的公有云节点，也包含 IDC Network 下的 IDC 节点，甚至是其他云厂商的公有云节点，乃至环境场景的边缘节点。客户有时候并不想改变自己 IDC 环境的基础网络设置，却希望能有一套统一的容器网络。

TKE 混合云网络方案

为了解决混合云场景下容器网络所面临的挑战，腾讯云容器团队设计了以 Cilium 作为集群网络底座的 TKE 混合云容器网络方案。Cilium 基于 eBPF 技术为云原生网络重新设计，绕开 iptables，提供了网络、可观测性和安全等方面的一整套解决方案。Cilium 能够支持基于隧道的 Overlay 网络和基于直接路由的 Underlay 网络，并且在大规模扩展 Service 等性能上有优越的表现 。腾讯云容器团队很早即开始基于 eBPF 技术对 Kubernetes 网络进行优化，本次将混合云网络与 Cilium 结合也是对 eBPF 技术的进一步探索。

TKE 混合云容器网络主要特点如下：

• 实现全链路容器网络的打通，屏蔽底层网络差异
• 同时支持基于 VxLAN 隧道模式的 Overlay 网络和基于直接路由的 Underlay 网络
• 基于 eBPF 技术实现 Service 和 NetworkPolicy，优化 Kubernetes 网络性能
• 支持自定义容器 IPAM，可实现节点多段 PodCIDR 和 PodCIDR 按需动态分配
• 支持网络链路的可观测性

TKE 混合云容器网络使用方法

在 TKE 集群基本信息页面，点击开启「支持导入第三方节点」后，需要选择混合云容器网络模式。这里我们可以选择 Cilium VxLAN 来使用混合云 Overlay 容器网络，也可以选择 Cilium BGP 来混合云 Underlay 容器网络：

TKE 混合云网络互通方案

VPC Network 和 IDC Network 互相访问

为了打通 VPC Network 和 IDC Network，我们推荐使用腾讯云的云联网服务，云联网服务能够实现云上 VPC 之间、VPC 与 IDC 网络的互通，具备全网多点互联、路由自学习、链路选优及故障快速收敛等能力。

IDC Network 主动访问 Master Network

为了打通 IDC Network 主动访问 Master Network 的网络链路，我们基于腾讯云 PrivateLink，实现 IDC Network 中的 Kubelet 主动访问处于 Master Network 的 ApiServer。

Master Network 主动访问 IDC Network

为了打通 Master Network 主动访问 IDC Network 的网络链路，我们选择了基于社区的 apiserver-network-proxy 项目 来实现。具体的原理实现如下：

• 在 Master Network 创建 Konnectivity Server，作为代理服务器
• 在 IDC Network 创建 Konnectivity Agent，通过 PrivateLink 与 Master Network 中的代理服务器创建长连接
• 当 Master Network 中的 ApiServer 主动访问 IDC Network 的 Kubelet 时，会复用 Agent 与 Server 之间的长连接

至此，Master Network 主动访问 IDC Network 的网络打通需求也得到了解决。进一步地，基于相同的方案，我们可以将多云 VPC 的计算节点和边缘场景的边缘节点纳管到同一控制平面，实现真正的分布式云。

TKE 混合云 Overlay 容器网络方案

Master Network 与 IDC Network 网络打通之后，我们即可在此基础上通过隧道模式来构建 Overlay 网络。VxLAN 是在数据中心网络中获得广泛使用的隧道封装协议，它通过 MAC in UDP 对数据包进行封装，在对端解封。Cilium 的隧道封装协议支持 VxLAN 和 Geneve，默认采用 VxLAN。基于 VxLAN 的高度可扩展性，只需要打通节点之间的网络，就可在此之上实现统一的容器网络。

跨节点 Pod 互相访问

当数据包从 Pod 的网口发出时，经过 veth pair 到达 lxc00aa 网口。在 lxc00aa 网口上挂载的 eBPF 程序发现数据包目的地址为远端 endpoint，转发给 cilium_vxlan 进行封包。封包之后，外层地址为节点的 IP，内层地址为 Pod IP，经过节点上物理网口转发给对端节点。到达对端节点后，同样经过 cilium_vxlan 解封包，并将数据包转发给对端 Pod。

节点访问远端 Pod

对于从本地节点访问远端节点的 Pod，在本机上会通过节点路由转发给 cilium_host 网口，在 cilium_host 上挂载的 eBPF 程序会将数据包转发到 cilium_vxlan 进行隧道封包，然后转发到对端。可以看到，封包之后，外层地址为节点的 IP，内层源 IP 地址为 CiliumHostIP，目的 IP 地址为目标Pod IP 地址。后面链路与前面一致，不再赘述。

Pod访问非 ClusterCIDR 的网络

对于计算节点上的 Pod 访问非容器 ClusterCIDR 的网络地址时，数据包从 Pod 网口到达 lxc00aa 网口后，eBPF 程序发现目标地址不是容器网络的 ClusterCIDR，则不会进行 Overlay 封包，而是转给协议栈走节点路由。通过设置 cilium 的 masquerade 参数，数据包到达节点物理网口后，对于这种目的地址的数据包会执行 masquerade，替换数据包的源地址为节点 IP，从而之后数据包能够返回到节点，并最终返回给 Pod。

总结与展望

本文介绍了 TKE 混合云场景下公有云集群添加第三方 IDC 节点服务下，混合云容器网络所面临的复杂场景和性能的挑战，并提出了基于 Cilium 的 Overlay 的容器网络解决方案。可以看到，这套方案不仅适用于添加IDC节点，对于混合云下的异构集群（多云、边缘场景）都适用，可以解决混合云下集群网络插件不一带来的管理问题和体验问题。由此，混合云与容器的结合已经不再仅仅是混合云，而是可以实现多云场景、IDC 场景以及边缘场景的统一，是实实在在、无处不在的分布式云。

Overlay 的混合云容器网络可以通过隧道模式屏蔽底层不同网络环境的差异，实现容器层面看到的是统一的网络层面。对于另一部分客户来说，他们对于混合云容器网络的性能有很高的要求，不希望引入因为 Overlay 的封解包过程带来的性能折损。这种情况下，客户希望直接基于 Underlay 网络，通过直接路由来打通容器网络。接下来还会介绍 TKE 混合云容器网络基于 BGP 直接路由的 Underlay 网络的方案实现，敬请期待。

参考资料

1. Mind the Gap: Here Comes Hybrid Cloud
2. Kubernetes scheduler extender
3. Kubernetes addmision controllers
4. CNI Benchmark: Understanding Cilium Network Performance
5. 腾讯云绕过 conntrack，使用 eBPF 增强 IPVS 优化 K8s 网络性能
6. 腾讯云云联网服务 CCN
7. Kubernetes apiserver-network-proxy
8. RFC 7348: Virtual eXtensible Local Area Network (VXLAN)

容器服务 TKE：无需自建，即可在腾讯云上使用稳定， 安全，高效，灵活扩展的 Kubernetes 容器平台。