Kubernetes详解（三十）——Service代理方式分类

今天继续给大家介绍Linux运维相关知识，本文主要内容是Service代理方式分类。
Service资源对象存在端口代理的功能，能够实现对Pod资源访问进行代理。kube-proxy将请求代理至相应端点的方式有以下三种：userspace代理、iptables代理和ipvs代理。下面，我就对这三种代理模式进行详细讲解。

一、userspace代理模式

userspace是Linux操作系统的用户空间。在这种模式下，kube-proxy负责跟踪API Server上Service和Endpoints对象的变动，并据此调节Service资源。对于每个Service对象，kube-proxy会随机打开一个本地端口，任何到此端口的链接请求都会被代理至当前Service资源的后端Pod上。具体发送至哪个Pod由Service的调度算法决定，其默认的调度算法是轮询。
userspace模式下的Service代理图如下所示：

从上图可以看出，请求到达Service后，会被转发到内核空间，经由套接字传送至用户空间的kube-proxy，然后又会被其送回内核空间，并调度到Pod上。这种转发方式在Kubernetes1.1版本之前是默认的转发策略，但是由于其传输效率太低，因此被后续的版本弃用。

二、iptables代理模式

在iptables代理模式中，也是kube-proxy负责跟踪API Server上Service和Endpoints对象的变动，并据此作出Service资源的变动。对于每个Service对象，会创建Iptables规则直接捕获到达Cluster IP和Port的流量，并将其发送到Service的后端。对于每个Endpoints对象，Service资源会为其创建iptables规则并关联至挑选的后端Pod资源。
iptables模式的代理规则是请求到达service后，被service的iptables规则进行调度和目标地址转换后发送至集群的Pod对象上。iptables代理图如下所示：

相对于namespace模式来说，iptables模式无需将流量在用户空间和内核空间之间来回切换，因此更加高效和可靠。但是其缺点在于iptables模型不会在Pod资源无响应时进行重定向，而userspace模式可以。

三、ipvs代理模式

在ipvs代理模式下，kube-proxy负责跟踪API Server上的Endpoints资源对象的变动，据此来调动netlink接口来创建ipvs规则，并确保和API Server中的变动保持同步。在这种模式下流量的调度功能由ipvs实现，其余的功能由iptables实现。ipvs代理模式图如下所示：

原创不易，转载请说明出处：https://blog.csdn.net/weixin_40228200