运行于Pod中的部分容器应用是向客户提供服务的守护进程，例如Nginx、Tomcat和etcd等，控制器所管控着这些Pod中的容器，它们存在生命周期，这类Pod在自愿或者非自愿中断后只能被重构和新的Pod对象所取代，属于不可再生类的组件，它们每次被重构或者被新的Pod对象取代，就意味着它们的IP地址发生变化，所以直接通过Pod IP无法为客户端提供一个稳定的访问入口，于是有了Service的出现，Service为这类Pod提供一个固定、统一的访问入口及负载均衡的能力，并借助于CoreDNS系统的服务发现功能，解决客户端发现并访问容器应用的难题。

Service资源介绍

Service是Kubernetes的核心资源类型之一，事实上它是一种抽象；通过规则定义出由多个Pod对象组合而成的逻辑集合，以及访问这组Pod的策略。Service关联Pod资源的规则要借助于标签选择器来完成。

Service资源概述

在我们的传统模式中，一般把Nginx或者HAProxy等应用去代理后端的应用服务器，我们只需要在代理配置文件中写入后端应用的IP地址以及Port即可，因为后端应用服务器的IP地址和端口通常不会发生变化。
但我们由Kubernetes所编排的Pod IP可是会经常发生变化，如Pod对象中断后控制器会为其新建资源对象所取代，Pod被取代之后Pod IP就会发生变化；Pod扩缩容后也会发生变动，那么Kubernetes则是通过Service资源来解决此类问题。

Service资源基于标签选择器将一组Pod定义成一个逻辑组合，并通过自己的IP地址和端口转发请求到组内的Pod对象之上，这一切对客户端来说都是透明的。

Service对象的IP地址被称为Cluster IP，是Kubernetes集群配置所指定的专用IP地址范围之内，而且是一种虚拟IP地址，它在Service对象创建后则保持不变，还能够被同一个集群中的Pod资源访问，Service端口用于接收客户端请求并将请求转发至后端Pod相应端口之上，因此，这种代理机制也被称为“端口代理” (port proxy)或者四层代理，Service资源工作于TCP/IP协议栈的传输层。

当Service代理的一组逻辑组合Pod对象有多个时，Service资源能够以负载均衡的方式进行流量调度。Service资源会通过API Server持续watch着标签选择器匹配到的后端Pod对象，并且实时跟中Pod对象的变动，例如，IP地址变动，Pod对象增加或者减少等。

Service并不直接连接到Pod对象，它们之间还有一个中间层Endpoints资源对象，它是一个由IP地址和端口组成的列表，这些IP地址和端口则来自于由Service的标签选择器匹配到的Pod资源。这也是很多场景中会使用"Service的后端端点"(Endpoints)这一术语的原因。默认情况下，创建Service资源对象时，其关联的Endpoints对象会自动创建。