kubeproxy 的三种模式

kube-proxy是对service的实现，也就是service只是用来抽象定义，真正具体化干活的是kube-proxy.它运行在每一个node节点上，负责该节点的网络代理。它是一个pod。

userspace

• 单纯的用户态 会经过内核切换存一点过的开销
• 频繁用户空间和内核空间之间切换

iptales

• 内核态直接作用Linux netfilter
• 当service或者endpoints、pod发生变化时，kube-proxy会创建对应的iptables规则
• 对于每个服务，它都安装iptables规则，该规则捕获到服务clusterIP和的port流量，并将该流量重定向到服务的后端集之一。
• 对于每个Endpoint对象，它将安装iptables规则，该规则选择一个后端Pod。
• 默认情况下，iptables模式下的kube-proxy会随机选择一个后端，所选的第一个Pod没有响应，则连接失败，无法重试
• 缺点：服务多的时候产生太多的 iptables 规则，非增量式更新会引入一定的时延，大规模情况下有明显的性能问题

ipvs

• 内核态直接作用网络协议栈
• kube-proxy监视Kubernetes服务和端点，调用netlink接口以相应地创建IPVS规则，并定期将IPVS规则与Kubernetes服务和端点同步。
• 用哈希表作为基础数据结构，访问服务时，IPVS将流量定向到后端Pod之一, 更低的延迟来重定向流量。
• 更多的轮询策略。 rr：轮循、lc：连接最少（打开的连接最少）、dh：目标哈希、sh：源哈希、sed：最短的预期延迟、nq：永不排队
• 采用增量式更新，并可以保证 service 更新期间连接保持不断开