共计 2576 个字符，预计需要花费 7 分钟才能阅读完成。
前言
Kubernetes 曾经成为容器治理畛域的事实标准，而网络系统是 Kubernetes 外围局部，随着越来越多的业务部署在 Kubernetes，对容器网络也提出了一些新的需要
- 怎么晋升网络的可观测性，serverless 类产品该需要尤为突出
- 怎么尽可能减少容器引入的网络性能损耗
上述需要冲击了 iptables，IPVS 等传统防火墙，负载均衡器技术。也促使咱们思考容器网络拜访链路是否不依赖于节点，进而缩短容器拜访链路，晋升网络性能
eBPF 是一项革命性技术，它能够以一种平安的形式在内核中许多 hook 点执行程序，该项技术可编程能力强，并且也无需保护内核模块，可维护性好，该项技术为满足上述需要提供了可能。Cilium 则是基于 eBPF 技术的容器网络开源我的项目，提供了网络互通，服务负载平衡，平安和可观测性等解决方案
由此，腾讯云容器服务 TKE 基于 Cilium 和 eBPF 实现了独立网卡模式下的高性能 ClusterIP Service 计划。TKE 致力于提供更高性能、更平安和更易用的容器网络，也因而会一直关注 Cilium 等前沿的容器网络技术计划，后续会推出更多更欠缺的 Cilium 产品化能力。
独立网卡 Service 计划
TKE 于去年推出了新一代容器网络计划，该计划实现了一个 Pod 独占一张弹性网卡，不再通过节点网络协议栈（default namespace）。而以后的 kube-proxy 实现 ClusterIP 的计划都依赖于在节点侧的网络协议栈里设置相应的 iptables 规定，也因而该计划对于独立网卡计划不再实用。
其中一个解决方案便是 Cilium，Cilium 提供了基于 eBPF 的地址转换能力，从而可反对 ClusterIP Service。但其原生计划仅反对 veth pair 和 ipvlan l3 的数据面，并不反对 Pod 齐全不通过节点网络协议栈的数据面，因而不能原生解决独立网卡 ClusterIP 的拜访问题。
TKE 由此对 Cilium 加以革新，使其反对了除原生反对的 veth 和 ipvlan l3 的第三种数据面计划，如图（假如 pod 拜访 Service IP 为 172.16.0.2），数据面上，将本来挂载到节点侧的 veth 上的 bpf 程序，挂载到 pod 内的独立网卡（同时也是弹性网卡）上，使得 Pod 的网络报文在收回的时候做 DNAT（目标地址转换），而回报文在网卡接管的时候做反向 DNAT，从而反对 ClusterIP 的拜访。该数据面计划 可作为一个通用计划适配 Ipvlan l2、SRIOV 等数据面场景。
而管制面上，将 Cilium 与 TKE 的 VPC-CNI 模式（含共享网卡模式和独立网卡模式）深度集成，用户无需对业务代码逻辑做任何批改，即可应用 Cilium 的性能个性。
性能比照
本文应用 wrk 工具对 Cilium 的产品化解决方案进行了性能压测，测试保障 Client Pod 和 Server Pod 散布在不同节点。
测试环境：TKE 集群，4 个 CVM 节点，配置为 Server S5.2XLARGE8，Client S5.SMALL2。
测试数据表明，基于 Cilium 的独立网卡 ClusterIP 拜访计划性能最好。在短连贯场景下，其 QPS 相比共享网卡的 iptables 和 ipvs 计划晋升 48% 和 74%，相比全局路由的 iptables 和 ipvs 计划晋升了 62% 和 91%。在长连贯场景下，其 QPS 相比共享网卡的 iptables 和 ipvs 计划晋升了 33% 和 57%，而相比全局路由的 iptables 和 ipvs 计划晋升了 49% 和 66%。iptables 的性能较 ipvs 性能较好是因为测试环境中 Service 数量还不够多，ipvs 的劣势在于大量 Service 的场景。
产品化过程中的相干问题
TKE 团队在实现 Cilium 产品化解决方案过程中，也发现了 Cilium 我的项目中一些问题，相应的解决方案和 Cilium 反对新数据面计划将于近日以 pr 的模式整顿提交给 Cilium 社区。
独立网卡计划下的 ClusterIP 自拜访不通
以上计划其实不能齐全解决 ClusterIP 拜访问题，存在一类非凡的场景会拜访不通。这类场景就是 Pod 拜访的 ClusterIP，其后端包含其本身。这类场景下，独立网卡的 Pod 收回的网络报文会间接达到 IAAS 层，不合乎预期。
因为独立网卡 Pod 内，其实只有两个网络设备：回环设施（lo）和弹性网卡，因而一个简略的思路就是在出报文之前，对自拜访流量，通过 bpf_redirect 调用将报文间接转发（redirect）到回环（lo）设施。基于此，TKE 团队批改了 cilium 的相干 bpf 代码，提供了一个解决方案。通过测试，该计划能够解决独立网卡计划下的 ClusterIP 自拜访问题。
Cilium 加载 bpf 程序的名字缺失
Cilium 我的项目的可调试性存在一个问题，其 bpf 程序开发得比拟早，底层用了很多老的工具集，例如 tc，来加载 bpf 代码。
老的 tc 基于老的内核版本 (<4.15) 设计的，它在加载 bpf 程序时，将 bpf 程序的名字疏忽了，导致 Cilium 加载的 bpf 程序都是无名字的。这影响了对代码的了解，追踪和调试。
对此 TKE 团队联合较新的内核对 tc 工具进行了修改，使得它加载 bpf 程序时，会正确的传入名字。通过这名字，能够搞清楚理论运行的 bpf 函数具体是哪一个，从而进步 Cilium 的可调试性。
用法
申请 Cilium 反对 ClusterIP 产品化内测开明后，创立 TKE 集群时高级设置中关上 ClusterIP 加强 即可：
总结与瞻望
本文介绍了 TKE 团队实现的基于 Cilium 和 eBPF 的独立网卡模式下高性能 ClusterIP service 计划，该计划相比以后基于 iptables 和 ipvs 的传统网络计划大量的晋升了性能（33%-91%）。
显然，Cilium 提供的能力还不止于此，其基于 eBPF 这项革命性的技术，还提供了平安、可观测性、QoS 等方面的能力，而提供更高性能、更平安和更易用的容器网络正是 TKE 的服务指标，因而，后续 TKE 将会积极参与 Cilium 社区，与社区一道独特推出更弱小、更欠缺的容器网络能力。
参考资料
- Cilium 我的项目官网
- eBPF 介绍和参考指南
- 腾讯云容器服务 TKE 推出新一代零损耗容器网络
- Kubernetes Service
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！
