Kubernetes的Pod的寿命是有限的，它们不会复活，因此尽管每个Pod都有自己的IP地址，但是这些IP地址是不可靠的，会随着Pod的消亡而消失。
这就带来一个问题，如果一些Pod的集合（称之为backends）为集群的其他的Pod(称之为frontends)，这些frontends应该如何找到并一直知道哪些backends在这样的集合中呢？
这就需要引入Service, 一个kubernetes的service是一种抽象，它定义了一个Pod的逻辑集合和一个用于访问它们的策略。一个Service的目标Pod的集合通常是由Label Selector来决定的。
举个例子，想象一个处理图片的后端运行了三个副本。这些副本都是可以替代的，前端不关心它们使用的是哪一个后端。尽管实际组成后端集合的Pod可能会变化，前端的客户端却不需要知道这个变化，也不需要自己有一个列表来记录这些后端服务。Service抽象能让你达到这种解耦。
对于那些Kubernetes原生的应用，Kubernetes提供了一个简单的Endpoints API，会在Service中的Pod集合发生改变的时候更新。对于非Kubernetes原生的应用，Kubernetes为Service提供了一种基于虚拟IP的桥接方式使其重定向到后端的Pods。
定义一个Service
Kubernetes中的Service是一个REST对象，这点与Pod类似。正如所有的REST对象一样，向apiserver POST一个Service的定义就能创建一个新的实例。例如，假设你有一组Pods，每一个Pod都开放了9376端口，并且都有一个"app=MyApp"的标签。
{ "kind": "Service", "apiVersion": "v1", "metadata": { "name": "my-service" }, "spec": { "selector": { "app": "MyApp" }, "ports": [ { "protocol": "TCP", "port": 80, "targetPort": 9376 } ] } }
这个定义会创建一个新的Service对象，名字为”my-service”，它指向所有带有”app=MyApp”标签的Pod上面的9376端口。这个Service同时也会被分配一个IP地址（有时被称作”cluster ip”），它会被服务的代理所使用（见下面）。这个Service的选择器，会不断的对Pod进行筛选，并将结果POST到名字同样为“my-service”的Endpoints对象。
注意一个Service能将一个来源的端口映射到任意的targetPort。默认情况下，targetPort会被设置成与port字段一样的值。可能更有意思的地方在于，targetPort可以是一个字符串，能引用一个后端Pod中定义的端口名。实际指派给该名称的端口号在每一个Pod中可能会不同。这为部署和更新你的Service提供了很大的灵活性。例如，你可以在你的后端的下一个版本中更改开放的端口，而无需导致客户出现故障。
Kubernetes的Service支持TCP和UDP协议。默认是TCP。
发布 services - service的类型
Kubernetes的ServiceTypes能让你指定你想要哪一种服务。默认的和基础的是ClusterIP，这会开放一个服务可以在集群内部进行连接。NodePort 和LoadBalancer是两种会将服务开放给外部网络的类型。
ServiceType字段的合法值是：
l ClusterIP: 仅仅使用一个集群内部的IP地址 - 这是默认值。选择这个值意味着你只想这个服务在集群内部才可以被访问到。
l NodePort: 在集群内部IP的基础上，在集群的每一个节点的端口上开放这个服务。你可以在任意<NodeIP>:NodePort地址上访问到这个服务。
l LoadBalancer: 在使用一个集群内部IP地址和在NodePort上开放一个服务之外，向云提供商申请一个负载均衡器，会让流量转发到这个在每个节点上以<NodeIP>:NodePort的形式开放的服务上。
在使用一个集群内部IP地址和在NodePort上开放一个Service的基础上，还可以向云提供者申请一个负载均衡器，将流量转发到已经以NodePort形式开发的Service上。
注意尽管NodePort可以是TCP或者UDP的，对于Kubernetes 1.0来说，LoadBalancer还支持TCP。
NodePort类型
如果你把type字段设置为"NodePort"，Kubernetes的master就会从由启动参数配置的范围（默认是：30000-32767）中分配一个端口，然后每一个Node都会将这个端口（在每一个Node上相同的端口）代理到你的Service。这个端口会被写入你的Service的spec.ports[*].nodePort字段中。
如果你想要一个特定的端口号，你可以在nodePort字段中指定一个值，确保系统能为你分配这个端口，否则API请求将会失败（例如你需要自己处理可能出现的端口冲突）。你指定的值必须在节点端口配置的范围内。
这给了开发者了设置他们自己的负载均衡器的自由，配置那些没有被Kubernetes完全支持的云环境，或者甚至可以直接开放一个或者多个节点的IP。
这种Service可以同时以<NodeIP>:spec.ports[*].nodePort和spec.clusterIp:spec.ports[*].port的形式访问。
LoadBalancer类型
在那些支持外部负载均衡器的云提供者上面，将type字段设置为"LoadBalancer"会为你的Service设置好一个负载均衡器。该负载均衡器的实际的创建是异步进行的，并且该设置好均衡器会在该Service的status.loadBalancer字段中显示出来。例如：
{ "kind": "Service", "apiVersion": "v1", "metadata": { "name": "my-service" }, "spec": { "selector": { "app": "MyApp" }, "ports": [ { "protocol": "TCP", "port": 80, "targetPort": 9376, "nodePort": 30061 } ], "clusterIP": "10.0.171.239", "loadBalancerIP": "78.11.24.19", "type": "LoadBalancer" }, "status": { "loadBalancer": { "ingress": [ { "ip": "146.148.47.155" } ] } }
从外部负载均衡器的流量将会被引到后端的Pod，然而具体这个如何实现则要看云提供商。一些云提供商允许指定loadBalancerIP。在这种场景，负载均衡器将随用户指定的loadBalancerIP一起创建。如果字段loadBalancerIP没有指定，该负载均衡器会被指定一个短暂性的IP。如果指定了loadBalancerIP，但是云提供商不支持这个特性，这个字段会被忽略。