Service是一种抽像资源，用于暴露运行在Pod中的服务并提供一定的负载均衡能力。
Service的出现背景
通常，我们希望把服务部署在Pod中，往往会通过Pod控制器（如Deployment）来创建并管理多个Pod副本，例如，我们通过Deployment创建了3个Pod副本，每个Pod中均运行一个nginx服务，如下所示：
[root@ecs-d8b6 manifests]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-5f67bd6bb-bvx2w 1/1 Running 0 10s 172.17.0.5 127.0.0.1 <none> <none>
nginx-deployment-5f67bd6bb-g9kkp 1/1 Running 0 10s 172.17.0.4 127.0.0.1 <none> <none>
nginx-deployment-5f67bd6bb-sr2w4 1/1 Running 0 10s 172.17.0.6 127.0.0.1 <none> <none>Kubernetes会为每个Pod分配一个IP地址，Pod使用该IP地址与外界通信，在上面的例子中三个Pod的IP地址分别为172.17.0.5、172.17.0.4和172.17.0.6。用户或集群中的其他Pod都可以使用这些IP地址访问nginx服务，如下所示：
[root@ecs-d8b6 manifests]# curl 172.17.0.4
<!DOCTYPE html>
<html>
<head>
...
</head>
<body>
<h1>Welcome to nginx!</h1>
...
</body>
</html>这样的部署方式仅仅可以保证基础的服务能力，从实际的用户体验角度来看，存在一些无法回避的问题。
首先，Pod的IP地址是随机分配的，其他Pod无法提前知晓服务的IP地址。
其次，Pod是一种“易逝”的资源，它随时都有可能被重新创建或被调度到其他节点，而每次都会获得一个新的随机IP地址。
再次，多个Pod副本之间没有联系，如果用户需要为服务提供负载均衡的能力，用户需要动态地管理这些Pod并处理流量分发。
Service正是为了解决这些痛点而推出的一种解决方案，它管理一组Pod副本，为这些副本提供可靠的访问入口以及负载均衡能力。
Service配置
像其他对象（如Pod）一样，Service也是一个REST对象，你可以通过相应的API或配置文件来创建Service对象，一个简单的Service配置文件如下所示：
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80这份配置将创建一个名为nginx-service的Service对象，其主要配置如下：
spec.selector：指定Pod选择器，该Service将查找包含app: nginx标签的Pod作为流量分发对象；spec.ports：该Service对外暴露的端口列表，支持暴露多个端口；spec.ports.protocol：该端口对应的IP协议，支持TCP、UDP和SCTP;spec.ports.port：该端口对外暴露的端口号；spec.ports.targetPort：后端Pod暴露的端口；
简单地说，Service通过spec.selector来查找Pod，并把这些Pod提供的服务“聚合”起来，对外提供一个统一入口。创建Service对象时，Kubernetes默认会给Service分配一个IP（称为Cluster IP），例如10.0.0.165，Service通过该IP对外提供服务，当请求流量到来时，再把流量转发到后端的Pod，并提供一定的负载均衡能力。整体工作流程如下所示：
访问Service的Cluster IP，效果与直接访问Pod的IP地址一样，但使用Service可以屏蔽后端Pod细节，对外提供固定的访问入口，当后端的Pod有变动时，Service会自动更新转发列表。
