Kubernetes Service从逻辑上代表了一组Pod(通常称为微服务)，具体是哪些Pod则是由label来挑选的(selector)。Service有自己的IP，而且这个IP是不变的。客户端只需要访问Service的IP，Kubernetes则负责
Blog：自由互联 个人
参考：Service | Kubernetes、《Kubernetes进阶实战》
有了 Workload，我们可以方便地管理多实例的应用，但是要想能够方便地访问应用，我们还需要一个类似于 负载均衡 的资源来分发请求，在 kubernetes 中，有两个资源负责这个功能，分别是 Service 以及 Ingress。其中 Service 主要负责集群内部的访问，而 Ingress 主要负责来自集群外部的访问。
Kubernetes Service从逻辑上代表了一组Pod(通常称为微服务)，具体是哪些Pod则是由label来挑选的(selector)。Service有自己的IP，而且这个IP是不变的。客户端只需要访问Service的IP，Kubernetes则负责建立和维护Service与Pod的映射关系。无论后端Pod如何变化，对客户端不会有任何影响，因为Service没有变。
举个例子，考虑一个图片处理后端，它运行了 3 个副本。这些副本是可互换的 —— 前端不需要关心它们调用了哪个后端副本。 然而组成这一组后端程序的 Pod 实际上可能会发生变化， 前端客户端不应该也没必要知道，而且也不需要跟踪这一组后端的状态。
Service 定义的抽象能够解耦这种关联。
Service类型Service有4种类型：
- ClusterIP：通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。 这也是默认的
ServiceType。 - NodePort：通过每个节点上的 IP 和静态端口（
NodePort）暴露服务。NodePort服务会路由到自动创建的ClusterIP服务。 通过请求<节点 IP>:<节点端口>，你可以从集群的外部访问一个NodePort服务。 - LoadBalancer：使用云提供商的负载均衡器向外部暴露服务。 外部负载均衡器可以将流量路由到自动创建的
NodePort服务和ClusterIP服务上。 - ExternalName：通过返回
CNAME和对应值，可以将服务映射到externalName字段的内容（例如，foo.bar.example.com）。 无需创建任何类型代理。
总体来说，若需要将Service资源发布至集群外部，应该将其配置为NodePort或Load-Balancer类型，而若要把外部的服务发布于集群内部供Pod对象使用，则需要定义一个ExternalName类型的Service资源，只是这种类型的实现要依赖于v1.7及更高版本的Kubernetes。