网络代理组件，运行在每个节点上。
Kube-proxy维护节点上的网络规则，实现了Kubernetes Service 概念的一部分 。它的作用是使发往 Service 的流量（通过ClusterIP和端口）负载均衡到正确的后端Pod。
工作原理
kube-proxy 监听 API server 中 资源对象的变化情况，包括以下三种：
- service
- endpoint/endpointslices
- node
然后根据监听资源变化操作代理后端来为服务配置负载均衡。
kube-proxy会监听EndpointSlice，否则会监听Endpoint。
服务拓扑，那么 kube-proxy 也会监听 node 信息 。服务拓扑（Service Topology）可以让一个服务基于集群的 Node 拓扑进行流量路由。 例如，一个服务可以指定流量是被优先路由到一个和客户端在同一个 Node 或者在同一可用区域的端点。
代理模式
目前 Kube-proxy 支持4中代理模式：
- userspace
- iptables
- ipvs
- kernelspace
其中 kernelspace 专用于windows，userspace 是早期版本的实现，本文我们不作过多阐述。
iptables(通过apiserver监听svc和endpoints/endpointslices资源生成iptables规则——nat表)
规则序列附加到内核的数据包处理管道中的各种钩子上。
在iptables模式下，kube-proxy将规则附加到“ NAT预路由”钩子上，以实现其NAT和负载均衡功能。这种方法很简单，使用成熟的内核功能，并且可以与通过iptables实现网络策略的组件“完美配合”。
默认的策略是，kube-proxy 在 iptables 模式下随机选择一个后端。
如果 kube-proxy 在 iptables 模式下运行，并且所选的第一个 Pod 没有响应， 则连接失败。 这与用户空间模式不同：在这种情况下，kube-proxy 将检测到与第一个 Pod 的连接已失败， 并会自动使用其他后端 Pod 重试。
集群大小(或更确切地说，服务的数量和每个服务背后的后端Pod的数量）成比例地增长)。
ipvs(通过apiserver监听svc和endpoints/endpointslices资源生成ipvs和iptables规则)
顺序规则。 结果是IPVS模式下kube-proxy的连接处理的计算复杂度为O(1)。换句话说，在大多数情况下，其连接处理性能将保持恒定，而与集群大小无关。
与 iptables 模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy 重定向通信的延迟要短，并且在同步代理规则时具有更好的性能。 与其他代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。
IPVS提供了更多选项来平衡后端Pod的流量。 这些是：
-
rr: round-robin -
lc: least connection (smallest number of open connections) -
dh: destination hashing -
sh: source hashing -
sed: shortest expected delay -
nq: never queue
IPVS的一个潜在缺点是，与正常情况下的数据包相比，由IPVS处理的数据包通过iptables筛选器钩子的路径不同。如果打算将IPVS与其他使用iptables的程序一起使用，则需要研究它们是否可以一起正常工作。 不过Ipvs代理模式已经推出很久了，很多组件已经适配的很好了，比如Calico。
性能对比
客户端节点上的性能。
Round-Trip 响应时间
- 在超过1,000个服务（10,000个后端Pod）之前，iptables和IPVS之间的平均往返响应时间之间的差异微不足道。
- keepalive连接时，平均往返响应时间才有差异。
CPU消耗
- iptables和IPVS之间的CPU使用率差异不明显，直到超过1,000个服务（带有10,000个后端Pod）为止。
- 在10,000个服务（具有100,000个后端pod）的情况下，使用iptables的CPU的增加量约为内核的35％，而使用IPVS的CPU的增加量约为内核的8％。
总结
数据包与现有连接进行匹配。如果数据包在conntrack中匹配，则无需检查kube-proxy的iptables或IPVS规则即可确定该如何处理。
在集群中不超过1000个服务的时候，iptables 和 ipvs 并无太大的差异。而且由于iptables 与网络策略实现的良好兼容性，iptables 是个非常好的选择。（通过与其他公司k8s运维人员交流，大部分都会选择使用ipvs模式）
当你的集群服务超过1000个时，而且服务之间链接大多没有开启keepalive，IPVS模式可能是一个不错的选择。
发展趋势
个人总结 kube-proxy 未来发展可能会朝着以下两个方向：
- 接口化，类似于cni。kube-proxy 只实现主体框架和接口规范，社区可以有iptables，ipvs，ebpf，nftables等具体实现。
pr 至今没有被merge。
nftables是一个新式的数据包过滤框架，旨在替代现用的iptables、ip6tables、arptables和ebtables的新的包过滤框架。
nftables旨在解决现有{ip/ip6}tables工具存在的诸多限制。相对于旧的iptables，nftables最引人注目的功能包括：改进性能、支持查询表、事务型规则更新、所有规则自动应用等等。
- 容器网络框架实现。
践行该观点的容器网络框架非cilium莫属。
Cilium 正在通过 ebpf 实现 kube-proxy 提供的功能。不过由于 ebpf 对 os 内核版本要求比较高，所以一些低版本内核是无法支持的。
CNI chaining 允许cilium 和其他cni容器网络组建结合使用。通过Cilium CNI chaining ，基本网络连接和IP地址管理由非Cilium CNI插件管理，但是Cilium将eBPF程序附加到由非Cilium插件创建的网络设备上，以提供L3 / L4 / L7网络可见性和策略强制执行和其他高级功能，例如透明加密。
而且该趋势已经被多家公有云厂商认可和支持。比如阿里云结合 terway CNI 和 Cilium，使用cilium提供Kubernetes的Service和NetworkPolicy实现。
转自：https://zhuanlan.zhihu.com/p/337806843