6.1.2 虚拟IP和服务代理
简单来讲，一个Service对象就是工作节点上的一些iptables或ipvs规则，用于将到达Service对象IP地址的流量调度转发至相应的Endpoint对象指向的IP地址和端口之上。工作于每个工作节点的kube-proxy组件通过API Server持续监控着各Service及于其关联的Pod对象，并将其创建或变动实时反映至当前工作节点上相应的iptables或ipvs规则上。客户端、Service及其Pod对象的关系如图6-4所示。
Netfilter是Linux内核中用于管理网络报文的框架，它具有网络地址转换（NAT）、报文改动和报文过滤等防火墙功能，用户借助于用户空间的iptables等工具可按需自由定制规则使用其各项功能。ipvs是借助于Netfilter实现的网络请求报文调度框架，支持rr、wrr、lc、wlc、sh、sed和nq等十余种调度算法，用户空间的命令行工具是ipvsadm，用于管理工作于ipvs之上的调度规则。
Service IP事实上是用于生成iptables或ipvs规则时使用的IP地址，它仅用于实现Kubernetes集群网络的内部通讯，并且仅能够将规则中定义的转发服务的请求作为目标地址予以响应，这也是它被称为虚拟IP的原因之一。kube-proxy将请求代理至相关端点的方式有三种：userspace（用户空间）、iptables和ipvs。
userspace代理模型
此处的userspace是指Linux操作系统的用户空间。这种模型中，kube-proxy负责跟踪API Server上的Service和Endpoint对象的变动（创建或删除），并根据此调整Service资源的定义。对于每个Service对象，它会随机打开一个本地端口（运行于用户空间的kube-proxy进程负责监听），任何到达此代理端口的请求都将被代理至的当前Service资源后端的各Pod对象上，至于会挑中哪个Pod对象则取决于的当前Service资源的调度方式，默认的调度算法是轮询（round-robin），其工作逻辑如图6-5所示。另外，此类的Service对象还会创建iptables规则以捕获任何到达ClusterIP的端口的流量。在Kubernetes1.1版本之前，userspace是默认的代理模型。
这种代理模型中，请求流量到达内核空间后经由套接字送往用户空间kube-proxy，而后再有它送回内核空间，并调度至后端Pod。这种方式中，请求在内核空间和用户空间来回转发必然会导致效率不高。
iptables代理模型
同前一种代理模型类似，iptables代理模型中，kube-proxy负责跟踪API Server上Service和Endpoint对象的变动（创建或删除），并据此做出Service资源定义的变动。同时，对于每个Service，它都会创建iptables规则直接捕获到达ClusterIP和Port的流量，并将其重定向至当前Service后端，如图6-6所示。对于每个Endpoint对象，Service资源会为其创建iptables规则并关联至挑选的后端Pod资源，默认算法是随即调度（random）。iptables代理模式由Kubernets1.1版本引入，并自1.2版本开始成为默认的类型。
在创建Service资源时，集群中每个节点上的kube-proxy都会收到通知并将其定义为当前节点上的iptables规则，用于转发工作接口接收到的与此Service资源的ClusterIP和端口的相关流量。客户端发来的请求被相关的iptables规则进行调度和目标地址转换（DNAT）后再转发至集群内的Pod对象上。
相对于用户空间模型来说，iptables模型无须将流量在用户空间和内核空间来回切换，因而更加高效和可靠。不过，其缺点是iptables代理模型不会在被挑中的后端Pod资源无响应时自动进行重定向，而userspace模型则可以。
ipvs代理模型
Kubernetes自1.9-alpha版本引入了ipvs代理模型，且自1.11版本起成为默认设置。此中模型中，kube-proxy跟踪API Server上Service和Endpoint对象的变动，据此来调用netlink接口创建ipvs规则，并确保与API Server中的变动保持同步，如图6-7所示。它与iptables规则的不同之处仅在于其请求流量的调度功能由ipvs实现，余下的其他功能仍由iptables完成。
类似于iptables模型，ipvs构建于netfilter的钩子函数之上，但它使用hash作为底层数据结构并工作于内核空间，因此具有流量转发速度快、规则同步性能好的特性。另外，ipvs支持众多调度算法，例如rr、lc、dh、sh、sed和nq等。
