首页 » 翻译 » Kubernetes » 正文

Kubernetes系列翻译05 Services in Kubernetes 第五部分

原文地址: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的问题,尽管这样的会减少一些灵活性

….

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

发表评论