首页 » 翻译 » Kubernetes » 正文

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

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

Virtual IPs and service proxies(虚拟IP和服务代理)
每一个节点上都运行了一个kube-proxy,这个应用监控着Kubermaster增加和删除服务,对于每一个服务,kube-proxy会随机开启一个本机端口,任何发向这个端口的请求都会被转发到一个后台的Pod当中,而如何选择是哪一个后台的pod的是基于SessionAffinity进行的分配。kube-proxy会增加iptables rules来实现捕捉这个服务的Ip和端口来并重定向到前面提到的端口。

最终的结果就是所有的对于这个服务的请求都会被转发到后台的Pod中,这一过程用户根本察觉不到
services-overview

默认的,后台的选择是随机的,基于用户session机制的策略可以通过修改service.spec.sessionAffinity 的值从NONE到ClientIP

Multi-Port Services(多端口服务)
可能很多服务需要开发不止一个端口,为了满足这样的情况,Kubernetes允许在定义时候指定多个端口,当我们使用多个端口的时候,我们需要指定所有端口的名称,这样endpoints才能清楚,例如


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

选择自己的IP地址
我们可以在创建服务的时候指定IP地址,将spec.clusterIP的值设定为我们想要的IP地址即可。例如,我们已经有一个DNS域我们希望用来替换,或者遗留系统只能对指定IP提供服务,并且这些都非常难修改,用户选择的IP地址必须是一个有效的IP地址,并且要在API server分配的IP范围内,如果这个IP地址是不可用的,apiserver会返回422http错误代码来告知是IP地址不可用

为什么不使用循环的DNS
一个问题持续的被提出来,这个问题就是我们为什么不使用标准的循环DNS而使用虚拟IP,我们主要有如下几个原因

1:DNS不遵循TTL查询和缓存name查询的问题由来已久(这个还真不知道,就是DNS更新的问题估计)
2:许多的应用的DNS查询查询一次后就缓存起来
3:即使如上亮点被解决了,但是不停的进行DNS进行查询,大量的请求也是很难被管理的

我们希望阻止用户使用这些可能会“伤害”他们的事情,但是如果足够多的人要求这么作,那么我们将对此提供支持,来作为一个可选项

发表评论