ebpf调研(4)

Cilium调研(3)

1. Cilium中的Sidecar（Envoy） 优化

Sidecar 优化本质上是流量劫持。在cilium中基于eBPF-socketmap 实现流量劫持，和 iptables 不同，iptables 可以针对每个 netns (net namespace )单独设置规则，eBPF 程序 attach 到指定 hook 点后，会对整个系统都生效，例如 attach 到 bind 系统调用后，所有 Pod 内以及节点上进程调用 bind 都会触发 eBPF 程序，我们需要区分哪些调用是来自需要由 eBPF 完成流量劫持的 Pod。 【这是一个显著的区别!】

使用 sockmap 优化服务网格性能的方案最早由 cilium 提出，我们的方案也参考了 cilium，这里借用 cilium 的两张图来说明下优化效果。

优化前 Sidecar 代理与应用程序间的网络通信都需要经过 TCP/IP 协议栈处理。 而优化后 Sidecar 代理与应用程序间的网络通信绕过了 TCP/IP 协议栈，如果两个 Pod 在同一节点上，两个 Pod 间的网络通信也可以被优化。

其实我想说，tcp/udp socket ---> unix socket ---> epbf socket-map ， 一步又一步的优化转发效率。

纸上得来终觉浅 绝知此事要躬行。所以要手动验证一下：

基于sockmap原理，来模拟一下它的代理转发功能:

1. 先启动2个服务端 nc -l 127.0.0.1:1234 和 nc -l 127.0.0.1:4321
2. 再启动sockemap劫持程序
3. 两个服务的互相发送消息
4. 服务端B（nc -l 127.0.0.1:4321）发送消息aaaa, 则经过socketmap之后，服务端A接收到该消息。同理服务端A发送消息bbbb，则则经过socketmap之后，服务端B接收到该消息 ， 能相互收发消息，说明验证成功。这个验证花了很长时间(2天)。

2. Cilium中的负载均衡

Kubernetes 中的网络功能，主要包括 pod网络，service 网络和网络策略组成。其中 POD 网络和网络策略，都是规定了模型，没有提供默认实现。而 service 网络作为 Kubernetes 的特色部分，官方版本持续演进了多种实现：

在 Kubernetes 中先后出现的几种 Service 实现中，整体都是为了提供更高的性能和扩展性。Service 网络，本质上是一个分布式的服务器负载均衡，通过 daemonset 方式部署的 kube-proxy，监听 endpoint 和 service 资源，并在 node 本地生成转发表项。目前在生产环境中主要是 iptables 和 IPVS 方式。 不管如何优化，每个从 pod  发出网络请求都必然经过 IPVS ，即 POD <--> Service <--> POD。所以cilium在也实现了cgroup级别的负载均衡。也是利用Linux 内核中 BPF_PROG_TYPE_CGROUP_SOCK 类型的 eBPF hook 可以针对 socket 系统调用挂接 hook，插入必要的 EBPF 程序。

• 通过 attach 到特定的 cgroup 的文件描述符，可以控制 hook 接口的作用范围。
• 利用 sock eBPF hook，我们可以在 socket 层面劫持特定的 socket 接口，来完成完成负载均衡逻辑。
• pod-service-pod 的转发行为转换成 pod-pod 的转发行为，在 socket 层面完成负载均衡的逻辑， 消除了每个报文都需要进行 NAT 转换的处理，进一步提升 Service 网络的转发性能。

补充说明: cilium中负载均衡算法采用的Maglev 一致性Hash。Maglev是Google开发的基于kernal bypass技术实现的4层负载均衡，Maglev在负载均衡算法上采用自行开发的一致性哈希算法被称为Maglev Hashing;

3. Cilium中Direct Server Return(DSR)

DSR直翻为,直接服务器返回， 它引入了一项优化机制，即直接在本地节点上选择后端进行通信。这种方式与常规kube-proxy有所区别：后者需要在网络进行NAT处理，才能达服务的对应节点地址。