Service资源会通过API Server持续监视着(watch)标签选择器匹配到的后端Pod对象，并实时跟踪各对象的变动，例如IP地址变动、对象增加或减少等。不过，需要特别说明的是，Service并不直接链接至Pod对象，它们之间还有一个中间层——Endpoints资源对象，它是一个由IP地址和端口组成的列表，这些IP地址和端口则来自于由Service的标签选择器匹配到的pod资源。默认情况下，创建Service资源对象时，其关联的Endpoints对象会自动创建。

服务暴露

Sevice的IP地址仅在集群内可达，但是，总会有些服务需要暴露到外部网络中接受各类客户端的访问。为此，就需要在集群的边缘为其添加一层转发机制，以实现将外部请求流量接入到集群的Service资源之上。

虚拟IP和服务代理

一个Service对象就是工作节点上的一些iptables或ipvs规则，用于将到达service对象IP地址的流量调度转发至相应的EndPOINTS对象指向的IP地址和端口之上。工作于每个工作节点的kube-proxy组件通过API Server持续监控着各Service及与其关联的Pod对象，并将其创建或变动实时反映至当前工作节点上相应的iptables或ipvs规则上。

kube-proxy将请求代理至相应端点的方式有三种：userspace、iptables、ipvs。

userspace代理模式

kube-proxy负责跟踪API Server上Service和Endpoints对象的变动，并据此调整Service资源的定义。对于每个Service对象，它会随机打开一个本地端口（运行于用户空间的kube-proxy进程负责监听），任何到达此代理端口的连接请求都将被代理至当前Service资源后端的各Pod对象上，至于会挑选哪个Pod对象则取决于当前Service资源的调度方式，默认的调度算法是轮询。另外，此类的Service对象还会创建iptables规则以捕获任何到达ClusterIP和端口的流量。

iptables代理模型

kube-proxy负责跟踪API Server上service和Endpoints对象的变动，并据此做出Service资源定义的变动。同时，对于每个Service，它都会创建iptables规则直接捕获到达ClusterIP和Port的流量，并将其重定向到当前Serivce后端。对于每个EndPoints对象，Service资源会为其创建iptables规则并关联至挑选的后端Pod资源，默认算法是随机调度。

ipvs代理模型

kube-proxy跟踪API Server上Service和Endpoints对象的变动，据此来调用netlink接口创建ipvs规则，并确保与API Server中的变动保持同步。它与iptables规则的不同之处仅在于其请求流量的调度功能由ipvs实现，余下的其他功能仍由iptables完成。