在Kubernetes系统中，Pod是对一组容器的抽象，是最小调度单元。如果将Kubernetes看成一个服务大厅，Pods就是内部一个个服务窗口。如果来办业务的用户能均匀分散在各个窗口，无疑要比都聚在同一个窗口的办事效率更高。

因此， Kubernetes系统就需要当好这个“大堂经理”的角色，制定好分配规则，将外部对一个固定虚拟IP 地址的访问，均衡分配到不同IP对应的Pod上，实现”负载均衡“，这个过程就叫Service。

kube-proxy的局限性：高延迟、易丢包

早期的Kubernetes使用kube-proxy组件来实现Service功能。由于该组件重度依赖 iptables，在 Kubernetes中，对每个 Service 及其 Pods都会生成很多 iptables 规则，这导致了以下后果：

不可预测的高转发延迟：因为每个包都要遍历所有规则，直到匹配某条规则；

规则更新缓慢：只能将全部规则读出来，更新整个集合，无法单独更新某条 iptables 规则。 

可靠性不稳定：iptables依赖Netfilter和conntrack，在大流量场景下可能会出现竞争，导致丢包等问题。

上述问题严重制约了Kubernetes Service的扩展，因此急需新技术来打破困境。在这样的”乱世“中，eBPF技术横空出世。由于它能从根本上改变内核处理流程，一经问世，便被公认为解决上述问题的利器。

eBPF出世，重新定义Kubernetes Service

那么eBPF技术究竟是怎样解决上述问题的呢？自2018年首个版本问世，eBPF技术实现的Cilium容器网络解决方案很快成为Kubernetes系统的标配。其通过直接在流量出入口实现东西流量的IP:Port 映射、以及南北流量的NAT操作，不再依赖iptables，省去了 kube-proxy 路径中的很多中间节点，从而大幅提升了负载均衡效率。

eBPF的出现，就相当于为Kubernetes这个“服务大厅”安装上了智能办公系统，彻底改变以往的办事规则，大大提高服务效率。

据测试，基于eBPF的Cilium容器网络解决方案性能比传统的kube-proxy方案提升了5倍以上。在某些极限压力下，传统方案的CPU已基本跑满，新方案下的CPU还能保持相当大的空闲率。可以说，是eBPF的诞生，帮助我们拥抱云原生。