关于Kubernetes的一些困惑


最近在学习magnum和kubernetes。有一些疑问,发在这里,请大家帮忙来解答,一起讨论。
  1. 比如minionA/B上分别有serviceA的podA/B。那么访问minionA的kube-proxy是不是也会被导流到minionB上的podB上?
  2. service的重要部件proxy就是起到了个负载均衡和反向代理的作用。这个角色是不是直接可以用haproxy/nginx这样的软件代替呢?
已邀请:

杨章显 - 思科系统运维工程师

赞同来自: xiaolunsanguo wangzi19870227 FanLin MapleWang aidenzhang styshoo shenlanse更多 »


hi ,
1. 比如minionA/B上分别有serviceA的podA/B。那么访问minionA的kube-proxy是不是也会被导流到minionB上的podB上?
由于通过Service IP + Service Port访问Service,Service不关心Pod运行在哪个节点上,所以Proxy可能分发到minionB。
2. service的重要部件proxy就是起到了个负载均衡和反向代理的作用。这个角色是不是直接可以用haproxy/nginx这样的软件代替呢?
直接替代应该不行,proxy除了代理,还做了一些其他工作,如初始化iptables,service注册到proxy,更新service的podlist更新等,所以如果要替换,这部分工作得自己实现。

hjianhao

赞同来自: xiaolunsanguo FanLin styshoo


可以参考一下我翻译的这篇文章,里面有比较清楚的介绍:http://dockone.io/article/520

另外haproxy/nginx代替是比较麻烦的,这个涉及到整个Kubernetes的架构。需要做修改。我们自己的实现中是通过nginx来做的。

在微服务架构中,后台服务的交互可以使用Kubernetes这套机制来完成,比通过nginx来说避免了集中转发。

jolestar

赞同来自: xiaolunsanguo YoungLiu


我补充下

第一. 会
直接访问service的clusterIP, 由于clusterIP是虚IP,会被iptables 的nat策略转发到当前minion的kube-proxy监听的端口上
比如这条kube-proxy的iptables
Chain KUBE-PORTALS-HOST (1 references)
pkts bytes target     prot opt in     out     source               destination
0     0 DNAT       tcp  --  *      *       0.0.0.0/0            10.254.0.10          /* kube-system/kube-dns:dns-tcp */ tcp dpt:53 to:10.0.3.11:40995


netstat -ntpl|grep 40995
tcp6       0      0 :::40995                :::*                    LISTEN      904/kube-proxy

kube-proxy监听的端口是40995, 对service 10.254.0.10:50 的请求 被转发到 10.0.3.11:40995。 然后kube-proxy会通过内置的loadbalancer转发请求给后面的endpoint,默认策略是round-robin。

第二. kube-proxy 是内置LB的,不过kube-proxy提供的功能要超越单纯的LB,同意 @FanLin 的说法。但这个LB和k8s的 external LB 需要解决的问题不一样,并且这种tcp代理模式对性能影响是比较大的。 最新的k8s中正在将tcp代理完全用 iptables 实现:https://github.com/kubernetes/ ... /3760

MapleWang

赞同来自: xiaolunsanguo lyn


关于kube-proxy或者service的load balance功能,我有一点想说一下。我觉得kube-proxy应该是自己没有LB的,请看下面一段官方对于service的描述:


On cloud providers which support external load balancers, this should
be as simple as setting thecreateExternalLoadBalancer flag of the
Service to true. This sets up a cloud-specific load balancer and
populates thepublicIPs field (see below). Traffic from the external
load balancer will be directed at the backend Pods, though exactly how
that works depends on the cloud provider. For cloud providers which do
not support external load balancers, there is another approach that is
a bit more "do-it-yourself" - the publicIPs field. Any address you put
into the publicIPs array will be handled the same as the portal IP -
the kube-proxy will install iptables rules which proxy traffic through
to the backends. You are then responsible for ensuring that traffic to
those IPs gets sent to one or more Kubernetes Nodes. As long as the
traffic arrives at a Node, it will be be subject to the iptables
rules.
对于支持kubenetes并且有自己load balancer的云平台比如GCE或者AWS,那么不用你费心,只要稍作配置就可以了。
但是如果没有这样的平台,那么对不起,你需要自己设置一个external LB了,上文中提到的的在service中设置public IP,kube-proxy只是在iptable里面做了一点手脚,确保每一个minion上的pod都可以被某一个public IP所访问到,但是如何把traffic均匀分布到这些pod上,kube-proxy是不管的,你需要额外的部件去实现它。

当然上面的描述不是最新的,你可以参考最新的文档,查看“external service”这一节:
https://github.com/GoogleCloud ... es.md

就我看来本质上这个情况仍然没有改变,还是需要自己设置LB。

所以对于你的两个问题:

1 traffic一旦到达minion A,它是不会被forward到其他minion B上去的,因为kube-proxy没有这样的功能,traffic被forward到哪一个node上是你设置的外部load balancer要做的事情

2 这里已经不是一个替代的问题,而是你必须要有一个像haproxy这样的东西来帮你做load balance,这里有篇实践的文章供你参考,用的是haproxy来为kubenetes的replicationcontroller中 replca pod做LB:

http://www.dasblinkenlichten.c ... 93353

FanLin - Docker&CoreOS爱好者

赞同来自: xiaolunsanguo


其实说来,Proxy的主要功能并不是负载均衡,而是为Service找到真正的后端服务容器提供一个渠道,只不过因为同时存在多个容器支持一个Service的情况,因此从外部看起来就相当于实现负载均衡的效果。

杨章显老师在InfoQ的文章对Proxy的介绍也写得很好:


Proxy提供TCP/UDP sockets的proxy,每创建一种Service,Proxy主要从etcd获取Services和Endpoints的配置信息,然后根据配置信息在Minion上启动一个Proxy的进程并监听相应的服务端口,当外部请求发生时,Proxy会根据Load Balancer将请求分发到后端正确的容器处理。
Proxy不但解决了同一主宿机相同服务端口冲突的问题,还提供了Service转发服务端口对外提供服务的能力。

_Tube_

赞同来自:


欢迎加入kubernets技术讨论qq群:Google/Kubernetes技术 319807078

要回复问题请先登录注册