原文地址：http://kubernetes.io/v1.0/docs/user-guide/services.html

Defining a service(定义一个服务)

一个Kubernete服务是一个最小的对象，类似pod,和其它的终端对象一样，我们可以朝paiserver发送请求来创建一个新的实例，比如，假设你拥有一些Pod,每个pod都开放了9376端口，并且均带有一个标签app=MyApp


{
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "my-service"
},
"spec": {
"selector": {
"app": "MyApp"
},
"ports": [
{
"protocol": "TCP",
"port": 80,
"targetPort": 9376
}
]
}
}


这段代码会创建一个新的服务对象，名称为：my-service，并且会连接目标端口9376，并且带有label app=MyApp的pod,这个服务会被分配一个ip地址，这个ip是给服务代理使用的（下面我们会看到），服务的选择器会持续的评估，并且结果会被发送到一个Endpoints 对象，这个Endpoints的对象的名字也叫“my-service”.

服务可以将一个“入端口”转发到任何“目标端口”，默认情况下targetPort的值会和port的值相同，更有趣的是，targetPort可以是字符串，可以指定到一个name,这个name是pod的一个端口。并且实际指派给这个name的端口可以是不同在不同的后台pod中，这样让我们能更加灵活的部署我们的服务，比如；我们可以在下一个更新版本中修改后台pod暴露的端口而不会影响客户的使用（更新过程不会打断）

服务支持tcp和UDP，但是默认的是TCP

Services without selectors（没有选择器的服务）
服务总体上抽象了对Pod的访问，但是服务也抽象了其它的内容，比如：

1：比如你希望有一个额外的数据库云在生产环境中，但是在测试的时候，我们希望使用自己的数据库
2：我们希望将服务指向其它的服务或者其它命名空间或者其它的云平台上的服务
3：我们正在向kubernete迁移，并且我们后台并没有在Kubernete中

如上的情况下，我们可以定义一个服务没有选择器

{
“kind”: “Service”,
“apiVersion”: “v1″,
“metadata”: {
“name”: “my-service”
},
“spec”: {
“ports”: [
{
“protocol”: “TCP”,
“port”: 80,
“targetPort”: 9376
}
]
}
}

因为没有选择器，所以相应的Endpoints对象就不会被创建，但是我们手动把我们的服务和Endpoints对应起来

{
“kind”: “Endpoints”,
“apiVersion”: “v1″,
“metadata”: {
“name”: “my-service”
},
“subsets”: [
{
“addresses”: [
{ “IP”: “1.2.3.4” }
],
“ports”: [
{ “port”: 80 }
]
}
]
}

这样的话，这个服务虽然没有selector，但是却可以正常工作，所有的请求都会被转发到1.2.3.4：80