kube-proxy 三种模式分析
kubernetes 上面的 service 资源的实现方式是由 kube-proxy 提供的模式决定的
kube-proxy 提供三种模式：userspace （Kubernetes1.2版本之前）、iptables、ipvs（推荐的）
如果不满足ipvs时，会自动降为iptables模式
再讲三种模式前，先简单说下Service的工作原理；
在 kubernetes 平台之上,Pod 是由生命周期的，为了给客户端提供一个固定的访问端点，因此我们在客户端与服务端（pod）之间加了一层固定的中间层，这个中间层，我们称它为 Service，当某个 service 服务背后资源发生了改变时，service 根据标签选择器，会立即判断是 pod 多了一个还是少了一个，这种信息会立即反应到 API server 上，因为多个 pods 的信息是需要存在 kube-apiserver 的 etcd 中的，而 kube-proxy 能够 watch（监控） 到这种变化，并立即将其转化为 ipvs 规则或者 iptables 规则 ，它的转换是动态的，并且是实时的，同理如果一个pod 被删除了，它的状态信息也会反馈到 kube-apiserver 的 etcd 当中，而后这种变化会被kube-proxy watch监控到，它会立即将其转化为 iptables 或者 IPVS 规则，基本上都是立即同步的。
userspace
当client pod 访问某个服务时，会先到达当前节点的内核空间 iptables 规则（我们知道 iptables规则就是 service 的规则），这个 service 规则的工作方式是 ，请求到达 service 以后，由 service 把它转化为本地监听到某个套接字上面的用户空间程序 kube-proxy，然后由它来处理，处理完以后再转给 service IP，最终代理到这个 service 关联和各个 pod, 实现调度，大家发现，这个请求由 client Pod 发给 service，service 还要回到监听这个端口的 kube-proxy, 再由 kube-proxy 再进行分发，kube-proxy 是工作在用户空间的进程，所以被称为userspace，这种方式，效率很低，原因在于，先要到内核空间，回到 kube-proxy 的用户空间，由各种 kube-proxy 封装成报文代理完成以后，再推到内核空间，然后有 iptables 规则进行转发，需要在内核空间与用户空间来回转换 2 次，效率低下。
iptables
IPVS
IPVS 知识点可以查看另外一篇文章：xxxxx客户端 client Pod 的请求到达内核空间以后，由 ipvs 规则来调度，内核空间直接调度给 pod 资源，所以第三种模型叫 IPVS 模型，ipvs 的工作过程上面已经讲的很清楚。
由于 kube-proxy 的 ipvs 模式需要提供 iptables 包过滤、SNAT、masquared(伪装)等，具体来说，ipvs 将使用 ipset 来存储需要 DROP 或 masquared 的流量的源或目标地址的规则集，以确保 iptables 规则的数量是恒定的，不会因为集群规模的扩大，而 iptables 条目增加，这里有一个关键是 SNAT，端口转换，通过上面的分析，我们只能使用 ipvs 的 NAT 模式。
很显然我们在安装并配置 kubernetes 的时候，你设定service工作在什么模式下，它就应该会生成对应的模式的规则，kubernetes 1.10 之前的版本，使用的是 iptables 规则，Kubernetes 1.2 版本之前是使用的 userspace 的模式，kubernetes 1.11 及以后默认使用的是 ipvs，如果ipvs 没有被激活，它将自动降级为 iptables 模式。
ipvs与iptables模式对比
ipvs 在大型集群规模部署时，性能更好；
ipvs 可以动态修改 ipset 集合；
ipvs 支持更为复杂的调度算法（最小负载、最少连接、加权等）；
ipvs 支持服务器健康检查和连接重试等；
ipvs 是否可以满足所有场景
从上面看 ipvs 有这么多的好处？
那么是 ipvs 是否可以满足所有场景呢？答案是否定的？
因为 ipvs 无法提供包过滤、SNAT、masquared等功能，在某些场景下，还是需要与 iptables 搭配使用（如 Service 类型为 NodePort 时），ipvs 使用 ipset 来存储需要 DROP 或 masquared 的流量的源或目标地址，以确保 iptables 规则的数量是恒定不变的。