关于容器技术:腾讯云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 容器平台。