本文主要会阐述 kube-proxy 目前几种代理模式。

userspace 模式

客户端访问 service-ip （clusterIP）请求会先从用户态切换到内核的 iptables ，然后回到用户态 kube-proxy，kube-proxy 负责代理转发工作，具体的细节如下：

每个 service 都会由 kube-proxy 在 node 节点上起一个随机的代理端口，iptables 会捕获 clusterIP 上的端口（targetPort）流量重定向到代理端口，任何访问代理端口的流量都会被代理到 service 后端的一个 Pod 上，默认情况下，对后端 Pod 的选择是轮询的。

userspace 模式，所有的转发都是通过 kube-proxy 软件来实现，如下所示：

用户模式.png

iptables 模式

客户端访问 service-ip ( clusterIP ) 请求会由 iptables 直接重定向到后端对应的 Pod 上，具体的细节如下：

每个 service 都会由 kube-proxy 生成对应的 iptables 规则，iptables 会捕获 clusterIP 上的端口 （targetPort ) 流量重定向到后端的一个 Pod 上，默认情况下，对后端 Pod 的选择是随机的，也可以设置会话保持。

iptables 模式，所有的转发都是通过 iptables 内核模块来实现的，而 kube-proxy 只负责生成相应的 iptables 规则，如下所示：

iptables模式.png

userspace 模式 和 iptables 模式，很显然 iptables 性能和可靠性更好，iptables 模式不需要 userspace 和 kernal space 的切换，在数据转发上有更高的效率。

ipvs 模式

从 k8s 1.8 版本之后，新增 kube-proxy 对 ipvs 的支持，并且在新版本的 k8s 1.11 版本中被纳入 GA。之所以会有 ipvs 这种模式，是因为 iptables 添加规则是不增量的，先把当前的 iptables 规则都拷贝出现，再做修改，然后再把修改后的 iptables 规则保存回去，这样一个过程的结果就是，iptables 在更新一条规则时，会把 iptables 锁住，这样的结果在服务数量达到一定量级时，性能基本上是不可接受的。

关于 ipvs 模式的介绍可以参考以下这篇博客：
ipvs 模式