kube-proxy 原理分析和技术演进

一、引言

       谈到 kube-proxy，就不得不提到 k8s 中的 Service，下面就对二者的关系作简单介绍：

• kube-proxy 其实就是管理 Service 的访问入口，包括集群内 Pod 到 Service 的访问和集群外访问 Service；
• kube-proxy 管理 Service 的 Endpoints，该 Service 对外暴露一个 Virtual IP，也称为 Cluster IP, 集群内通过访问这个  Cluster IP:Port 就能访问到集群内对应的 Serivce 下的 Pod；
• Service 是通过 Selector 选择的一组 Pods 的服务抽象，其实就是一个微服务，提供了服务的 LB 和反向代理的能力，而 kube-proxy 的主要作用就是负责 Service 的实现；
• Service 一个重要作用就是，一个服务后端的 Pods 可能会随着生存灭亡而发生 IP 的改变，Service 的出现，给服务提供了一个固定的 IP，而无视后端 Endpoint 的变化，而这种关联的维护主要依赖 kube-proxy 实现；

二、kube-proxy 内部原理

       kube-proxy 当前实现了三种代理模式：userspace、iptables 以及 ipvs。

2.1  userspace 模式

       在这种模式下，kube-proxy 持续监听 Service 以及 Endpoints 对象的变化；

       对每个 Service，它都为其在本地节点开放一个端口，作为其服务代理端口；

       发往该端口的请求会采用一定的策略转发给与该服务对应的后端 Pod 实体。

       kube-proxy 同时会在本地节点设置 iptables 规则，配置一个 Virtual IP，

       把发往 Virtual IP 的请求重定向到与该 Virtual IP 对应的服务代理端口上。

       其工作流程大体如下：

       

       分析：该模式请求在到达 iptables 进行处理时就会进入内核，而 kube-proxy 监听则是在用户态，

                  请求就形成了从用户态到内核态再返回到用户态的传递过程，一定程度降低了服务性能。

2.2  iptables 模式

       与 userspace 相同，kube-proxy 持续监听 Service 以及 Endpoints 对象的变化；

       但它并不在本地节点开启反向代理服务，而是把反向代理全部交给 iptables 来实现；

       即 iptables 直接将对 VIP 的请求转发给后端 Pod，通过 iptables 设置转发策略。

       其工作流程大体如下：

       

       分析：该模式相比 userspace 模式，克服了请求在用户态-内核态反复传递的问题，性能上有所提升，

                  但使用 iptables NAT 来完成转发，存在不可忽视的性能损耗，而且在大规模场景下，

                  iptables 规则的条目会十分巨大，性能上还要再打折扣。

2.3  ipvs 模式

       与 iptables、userspace 模式一样，kube-proxy 依然监听 Service 以及 Endpoints 对象的变化；

       不过它并不创建反向代理，也不创建大量的 iptables 规则；

       而是通过 netlink 创建 ipvs 规则，并使用 k8s Service 与 Endpoints 信息，

       对所在节点的 ipvs 规则进行定期同步；

       netlink 与 iptables 底层都是基于 netfilter 钩子，

       但是 netlink 由于采用了 hash table 而且直接工作在内核态，在性能上比 iptables 更优。

       

      分析：ipvs 是目前 kube-proxy 所支持的最新代理模式，

                相比使用 iptables，使用 ipvs 具有更高的性能。