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

Type NodePort
如果你选择了“NodePort”，那么 Kubernetes master 会分配一个区域范围内，（默认是30000-32767），并且，每一个node，都会代理（proxy）这个端口到你的服务中，我们可以在spec.ports[*].nodePort 找到具体的值

如果我们向指定一个端口，我们可以直接写在nodePort上，系统就会给你指派指定端口，但是这个值必须是指定范围内的。

这样的话就能够让开发者搭配自己的负载均衡器，去撘建一个kubernete不是完全支持的系统，又或者是直接暴露一个node的ip地址

Type LoadBalancer
在支持额外的负载均衡器的的平台上，将值设置为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”,
“type”: “LoadBalancer”
},
“status”: {
“loadBalancer”: {
“ingress”: [
{
“ip”: “146.148.47.155”
}
]
}
}
}

所有服务的请求均会直接到到Pod,具体是如何工作的是由平台决定的

缺点
我们希望使用IPTABLES和用户命名空间来代理虚拟IP能在中小型规模的平台上正常运行，但是可能出现问题在比较大的平台上当应对成千上万的服务的时候。

这个时候，使用kube-proxy来封装服务的请求，这使得这些变成可能

LoadBalancers 只支持TCP，不支持UDP

Type 的值是设定好的，不同的值代表不同的功能，并不是所有的平台都需要的，但是是所有API需要的

Future work

在将来，我们预想proxy的策略能够更加细致，不再是单纯的转发，比如master-elected or sharded，我们预想将来服务会拥有真正的负载均衡器，到时候虚拟IP直接转发到负载均衡器

将来有倾向与将所的工作均通过iptables来进行，从而小从用户命名空间代理，这样的话会有更好的性能和消除一些原地值IP的问题，尽管这样的会减少一些灵活性

….

将来的事将来再说好了…不翻译了
….