Kubernetes之service服务代理

Service是Kubernetes的一个重要资源类型，它通常可以理解为一种微服务。通过规则定义出多个Pod的逻辑组合，service可以通过标签选择器来访问到对应的pod。

概述

既然Service是一种核心资源，那为什么会出现service资源类型呢？它的具体意义又在哪里呢？

Service资源是在pod的访问基础上产生的，例如，当我们使用Deployment创建多个副本的pod资源后，如果出现pod资源的扩缩容操作，随之变化的是pod的IP地址访问接口，那整个pod的访问必然会受到影响，也就无法有效使用应用，为此，Kubernetes特意设计了Service资源来解决该问题。

总的来说Service资源就是基于标签选择器将一组pod定义为一个逻辑组合，并通过自己的IP地址和端口调度代理至组内的Pod对象上，它向客户端隐藏了真实处理用户请求的Pod资源，使得客户端看上去就像由Service提供处理。

那既然真实的服务响应是由pod来执行，那service和pod之间由是怎样有效转发连接的呢？

虚拟IP

service对象一般会提供一个虚拟IP（Virtual IP），它在service创建之后就保持不变，并且能够被同一集群中的Pod资源所访问。Service端口用于接收客户端请求并将其转发给后端的pod应用的相应端口，这种代理机制称为“端口代理”或四层代理，工作于TCP/IP协议栈的传输层。

一般通过标签选择器匹配到的后端pod不止一个，Service资源会通过API Server持续监听（watch）匹配到的后端pod对象，并实时更新各对象的变动。不过需要特殊说明的是，Service并不是直接链接到pod对象，它们中间还有一个Endpoints资源对象，它是一个由IP地址和端口组成的列表，这些IP地址和端口都来自于Service的标签选择器匹配到的Pod资源。

在众多的Pod对象中，Service资源总是能够已正确的方式进行流量调度，它们之间由是如何实现的呢？

服务代理

这就是我们要具体介绍的Kubernetes提供的服务端口代理的几种不同方式。

简单来说，一个Service对象就是工作节点上的一些iptables或ipvs规则，用于将到达Service对象IP地址的流量调度转发至相应的Endpoints对象指向的IP地址和端口之上。Kubernetes集群中的每个节点都会有产生一个Kube-proxy对象，它通过API-Server持续监控各Service及其关联的Pod对象，并将其变化实时反映至当前节点的iptables或ipvs规则上。
Kube-proxy、service、pod的关系如下图所示：
在这里插入图片描述

Kube-Proxy将请求代理至相应端点的方式有三种：userspace（有户空间）、iptables、ipvs。

userspace代理模型

这里的userspace是指Linux操作系统的用户空间。这种模型中，Kube-proxy负责跟踪API Server上的service和Endpoints对象的的变动（创建或移除）。对于每个service对象它会打开一个本地端口（运行于用户空间的Kube-proxy进程负责监听），任何到达此代理端口的连接请求都会被代理至当前Service资源后端的各Pod对象上，至于会挑选哪个pod取决于service资源的调度方式，默认为轮询（roundrobin），如下图所示：

在这里插入图片描述

这种代理模式请求流量到达内核空间后经由套接字送往用户空间的Kube-proxy，而后由它送回内核空间，并调度至后端pod。这种方式请求会在内核和用户空间之间来回转发导致效率不高。

iptables代理模型

iptables代理模式和前一种代理模式是类似的，都是由Kube-proxy来跟踪监听API-server上的service和Endpoints的变更。但是有一点不同的是iptables规则直接捕获到达cluster IP和port的流量，并将其重定向至当前Service的后端，对于每个Endpoints对象，Service资源会为其创建iptables规则并关联至挑选的后端pod资源，默认算法是随机调度（random）。iptables代理模式在Kubernetes1.1版本引入，并在1.2版开始成为默认类型。
在这里插入图片描述