2.1.3 Service

尽管 Pod 对象可以拥有 IP 地址，但此地址无法确保在 Pod 对象重启或被重建后保持不变，这会为集群中的 Pod 应用间依赖关系的维护带来麻烦：前端 Pod 应用（依赖方）无法基于固定地址持续跟踪后端 Pod 应用（被依赖方）。于是，Service 资源被用于在被访问的 Pod 对象中添加一个有着固定 IP 地址的中间层，客户端向此地址发起访问请求后由相关的 Service 资源调度并代理至后端的 Pod 对象。

换言之，Service 是“微服务”的一种实现，事实上它是一种抽象：通过规则定义出由多个 Pod 对象组合而成的逻辑集合，并附带访问这组 Pod 对象的策略。Service 对象挑选，关联 Pod 对象的方式和 Pod 控制器一样，都是要基于 Label Selector 进行定义，其示意图如下图所示。

Service IP 是一种虚拟 IP，也称为 Cluster IP，它专用于集群内通信，通常使用专用的地址段，如 “10.96.0.0/12” 网络，各 Service 对象的 IP 地址在此范围内由系统动态分配。

集群内的 Pod 对象可直接请求此类的 Cluster IP，例如，上图中来自 pod client 的访问请求即可以 Service 的 Cluster IP 作为目标地址，但集群网络属于私有网络地址，它们仅在集群内部可达。将集群外部的访问流量引入集群内部的常用方法是通过节点网络进行，实现方法是通过工作节点的 IP 地址和某端口（NodePort）接入请求并将其代理至相应的 Service 对象的 Cluster IP 上的服务端口，而后由 Service 对象的 Cluster IP 上的服务端口，而后由 Service 对象将请求代理至后端的 Pod 对象的 Pod IP 及应用程序监听的端口。因此，诸如上图中 External Clients 这种来自集群外部的客户端无法直接请求此 Service 提供的服务，而是需要事先经由某一个工作节点（如 Node Y）的 IP 地址进行，这类请求需要两次转发才能到达目标 Pod 对象，因此在通信效率上必然存在负面影响。

事实上，NodePort 会部署于集群中的每一个节点，这就意味着，集群外部的客户端通过任何一个工作节点的 IP 地址来访问定义好的 NodePort 都可以到达相应的 Service 对象。此种场景中，如果存在集群外部的一个负载均衡器，即可将用户请求负载均衡至集群中的部分或者所有节点。这是一种称为 “LoadBalancer” 类型的 Service，它通常是由 Cloud Provider 自动创建并提供的软件负载均衡器，不过，也可以是由管理员手工配置的诸如 F5 Big-IP 一类的硬件设备。

简单来说，Service 主要由三种常用类型：第一种是仅用与集群内部通信的 ClusterIP 类型：第二种是接入集群外部请求的 NodePort 类型，它工作于每个节点的主机 IP 之上；第三种是 LoadBalacer 类型，它可以把外部请求负载均衡至多个 Node 的主机IP的 NodePort 之上。此三种类型中，每一种都以前一种为基础才能实现，而且第三种类型中的 LoadBalacer 需要协同集群外部的组建才能实现，并且此外部组建并不接受 Kubernetes 的管理。