为何需要 Service
Kubernetes 中 Pod 是随时可以消亡的（节点故障、容器内应用程序错误等原因）。如果使用 Deployment 运行您的应用程序，Deployment 将会在 Pod 消亡后再创建一个新的 Pod 以维持所需要的副本数。每一个 Pod 有自己的 IP 地址，然而，对于 Deployment 而言，对应 Pod 集合是动态变化的。
这个现象导致了如下问题：
- 如果某些 Pod（假设是 'backends'）为另外一些 Pod（假设是 'frontends'）提供接口，在 'backends' 中的 Pod 集合不断变化（IP 地址也跟着变化）的情况下，'frontends' 中的 Pod 如何才能知道应该将请求发送到哪个 IP 地址？
Service 存在的意义，就是为了解决这个问题。
# Kubernetes Service
Kubernetes 中 Service 是一个 API 对象，通过 kubectl + YAML 或者 Kuboard，定义一个 Service，可以将符合 Service 指定条件的 Pod 作为可通过网络访问的服务提供给服务调用者。
Service 是 Kubernetes 中的一种服务发现机制：
- Pod 有自己的 IP 地址
- Service 被赋予一个唯一的 dns name
- Service 通过 label selector 选定一组 Pod
- Service 实现负载均衡，可将请求均衡分发到选定这一组 Pod 中
例如，假设有一个无状态的图像处理后端程序运行了 3 个 Pod 副本。这些副本是相互可替代的（前端程序调用其中任何一个都可以）。在后端程序的副本集中的 Pod 经常变化（销毁、重建、扩容、缩容等）的情况下，前端程序不应该关注这些变化。
Kubernetes 通过引入 Service 的概念，将前端与后端解耦。
在 Kuboard 中使用 Service
从 Kuboard 工作负载编辑器的视角来看，Service 与其他重要的 Kubernetes 对象之间的关系如下图所示：
图中，Service 先连线到 Controller，Controller 在连线到容器组，这种表示方式只是概念上的，期望用户在使用 Kubernetes 的时候总是通过 Controller 创建 Pod，然后再通过 Service 暴露为网络服务，通过 Ingress 对集群外提供互联网访问。
事实上，Service 与 Controller 并没有直接联系，Service 通过 label selector 选择符合条件的 Pod，并将选中的 Pod 作为网络服务的提供者。从这个意义上来讲，您可以有很多种方式去定义 Service 的 label selector，然而，最佳的实践是，在 Service 中使用与 Controller 中相同的 label selector。如上图所示。
TIP
使用 Kubernetes 的最佳实践：
Service 与 Controller 同名
Service 与 Controller 使用相同的 label selector
在 Kuboard 中创建工作负载时，工作负载的名字（服务名称字段）将作为 Deployment（StatefulSet/DaemonSet）的名字，也将作为 Service、Ingress 的名字
[root@master ~]# kubectl get pods -n ocp -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
cloud-eureka-0 1/1 Running 1 22h 10.100.171.102 worker <none> <none>
cloud-eureka-1 1/1 Running 1 22h 10.100.171.97 worker <none> <none>
cloud-eureka-2 1/1 Running 1 22h 10.100.171.75 worker <none> <none>
cloud-redis-0 1/1 Running 1 24h 10.100.171.90 worker <none> <none>
db-auth-center-0 1/1 Running 1 24h 10.100.171.70 worker <none> <none>
db-log-center-0 1/1 Running 1 24h 10.100.171.99 worker <none> <none>
db-user-center-0 1/1 Running 1 24h 10.100.171.73 worker <none> <none>
gateway-api-55d8f876f5-wjbks 1/1 Running 1 22h 10.100.171.91 worker <none> <none>
svc-auth-server-6cd596f4cc-sslzj 1/1 Running 1 22h 10.100.171.103 worker <none> <none>
svc-user-center-5f8bb5c4c4-hq7sr 1/1 Running 1 22h 10.100.171.77 worker <none> <none>
web-back-center-665f59cbbc-vh7ck 1/1 Running 1 23h 10.100.171.72 worker <none> <none>
[root@master ~]# kubectl get service -n ocp -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
cloud-eureka NodePort 10.96.150.116 <none> 1111:31111/TCP 25h k8s.eip.work/layer=cloud,k8s.eip.work/name=cloud-eureka
cloud-redis ClusterIP 10.96.242.0 <none> 6379/TCP 24h k8s.eip.work/layer=cloud,k8s.eip.work/name=cloud-redis
db-auth-center ClusterIP 10.96.62.160 <none> 3306/TCP 24h k8s.eip.work/layer=db,k8s.eip.work/name=db-auth-center
db-log-center ClusterIP 10.96.70.39 <none> 3306/TCP 24h k8s.eip.work/layer=db,k8s.eip.work/name=db-log-center
db-user-center ClusterIP 10.96.71.151 <none> 3306/TCP 24h k8s.eip.work/layer=db,k8s.eip.work/name=db-user-center
gateway-api ClusterIP 10.96.10.43 <none> 9200/TCP 23h k8s.eip.work/layer=gateway,k8s.eip.work/name=gateway-api
svc-auth-server ClusterIP 10.96.238.226 <none> 8000/TCP 24h k8s.eip.work/layer=svc,k8s.eip.work/name=svc-auth-server
svc-user-center ClusterIP 10.96.209.141 <none> 7000/TCP 23h k8s.eip.work/layer=svc,k8s.eip.work/name=svc-user-center
web-back-center ClusterIP 10.96.7.72 <none> 80/TCP 23h k8s.eip.work/layer=web,k8s.eip.work/name=web-back-center
[root@master ~]# kubectl get ingress -n ocp -o wide
NAME CLASS HOSTS ADDRESS PORTS AGE
cloud-eureka <none> cloud-eureka.ocp.demo.kuboard.cn 80 25h
gateway-api <none> api-gateway.ocp.demo.kuboard.cn 80 23h
svc-auth-server <none> svc-auth-server.ocp.demo.kuboard.cn 80 24h
svc-user-center <none> svc-user-center.ocp.demo.kuboard.cn 80 24h
web-back-center <none> back-center.ocp.demo.kuboard.cn 80 23h