searchusermenu
  • 发布文章
  • 消息中心
点赞
收藏
评论
分享
原创

ebpf调研(4)

2023-04-07 01:16:39
45
0

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天)。

 

 

 

  1. Cilium中的负载均衡

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

service 实现

说明

userspace

代理模式

kube-proxy 负责 list/watch,规则设置,用户态转发。

iptables

代理模式

kube-proxy 负责 list/watch,规则设置。IPtables 相关内核模块负责转发。

IPVS

代理模式

kube-proxy 负责 list/watch,规则设置。IPVS 相关内核模块负责转发。

在 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;

 

  1. Cilium中Direct Server Return(DSR)

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

0条评论
0 / 1000
Top123
29文章数
3粉丝数
Top123
29 文章 | 3 粉丝
Top123
29文章数
3粉丝数
Top123
29 文章 | 3 粉丝
原创

ebpf调研(4)

2023-04-07 01:16:39
45
0

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天)。

 

 

 

  1. Cilium中的负载均衡

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

service 实现

说明

userspace

代理模式

kube-proxy 负责 list/watch,规则设置,用户态转发。

iptables

代理模式

kube-proxy 负责 list/watch,规则设置。IPtables 相关内核模块负责转发。

IPVS

代理模式

kube-proxy 负责 list/watch,规则设置。IPVS 相关内核模块负责转发。

在 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;

 

  1. Cilium中Direct Server Return(DSR)

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

文章来自个人专栏
云原生最佳实践
29 文章 | 1 订阅
0条评论
0 / 1000
请输入你的评论
0
0