【问题标题】:Queries about LoadBalancing in Kubernetes clusterKubernetes集群负载均衡查询
【发布时间】:2017-03-13 08:15:49
【问题描述】:

我刚开始接触 Kubernetes,对 kubernetes 负载均衡方法有一些疑问,无法在 kubernetes 文档中找到明确的答案。

首先,假设我们创建了一个部署“iis”,并将其扩展为 3 个副本。现在不创建服务我们如何访问这些端点?

现在,我们使用 ClusterIP 为这个部署(有 3 个副本)创建了一个服务,因此它只在集群中公开。现在,该服务将如何对集群内进入该服务的流量进行负载均衡?它是使用循环还是随机选择端点?根据 kubernetes 的文档,有 2 个服务代理,用户空间或 iptables,我怎么知道我的服务正在使用哪一个?

接下来,我们使用 LoadBalancer 公开了该服务。它在云提供商上创建一个负载均衡器并使用它。我的问题是这个外部负载均衡器如何平衡 Pod 的流量?它是平衡到服务的流量并且服务将其重定向到端点,还是直接平衡到端点(pod)的流量?此外,在这个 LoadBalancer 案例中,到此服务的内部流量(来自集群内部)如何进行负载平衡?

请尽量给出详细的答案。

【问题讨论】:

    标签: docker kubernetes load-balancing


    【解决方案1】:

    首先,假设我们创建了一个部署“iis”,并将其扩展为 3 个副本。现在不创建服务我们如何访问这些端点?

    除非您对此有带外解决方案(例如您在其中注册 POD ips 的标准负载平衡器)您不能。。服务可以简化 pod 之间的连接。使用它们!

    现在,该服务将如何对集群内进入该服务的流量进行负载均衡?

    为了理解这一点,有必要了解一下服务在 Kubernetes 中是如何工作的。

    服务由 kube-proxy 处理。 Kube-proxy(现在默认)创建的 iptables 规则看起来有点像这样:

    -A KUBE-SERVICES ! -s 192.168.0.0/16 -d <svc-ip>/32 -p tcp -m comment --comment "namespace/service-name: cluster IP" -m tcp --dport svc-port -j KUBE-MARK-MASQ
    

    发生的情况是,iptables 会查看所有发往 svc-ip 的数据包,然后将它们定向到产生服务的 pod IP

    如果您进一步查看 iptables 规则并搜索“概率” - 您会看到如下内容:

    -A KUBE-SVC-AGR3D4D4FQNH4O33 -m comment --comment "default/redis-slave:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-25QOXGEMBWAVOAG5
    -A KUBE-SVC-GYQQTB6TY565JPRW -m comment --comment "default/frontend:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-JZXZFA7HRDMGR3BA
    -A KUBE-SVC-GYQQTB6TY565JPRW -m comment --comment "default/frontend:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-ZW5YSZGA33MN3O6G
    

    所以答案是,它是随机的,带有一些概率加权。在github comment

    中可以看到对概率如何加权的更全面的解释

    根据 kubernetes 的文档,有 2 个服务代理,用户空间或 iptables,我如何知道我的服务正在使用哪一个?

    同样,这是由 kube-proxy 决定的,是在 kube-proxy 启动时决定的。它是 kube-proxy 进程上的命令行标志。默认情况下,它将使用 iptables,强烈建议您坚持使用它,除非您知道自己在做什么。

    我的问题是这个外部负载均衡器如何平衡 Pod 的流量?

    这完全取决于您的云提供商和您选择的 LoadBalance。 LoadBalancer 服务类型是什么,它在 NodePort 上公开服务,然后将负载平衡器上的外部端口映射回该端口。 所有 LoadBalancer 类型的不同之处在于在外部提供者的负载均衡器中注册服务服务的节点 IP,例如:ELB,而不是在内部 clusterIP 服务中。我建议您阅读云提供商的文档来确定这一点。

    另外,在这个 LoadBalancer 案例中,到该服务的内部流量(来自集群内部)如何进行负载平衡?

    再次,请参阅您的云提供商的文档。

    【讨论】:

    • 根据 azure load balancer 的描述“您可以配置负载均衡器来负载均衡跨虚拟机的传入流量。”那么,如果负载均衡器只是将流量重定向到其中一个节点上的 NodePort,那么运行在该节点上的 kube-proxy 是选择在其自己的空间内运行的 pod,还是从运行在不同节点上的所有可用 pod 中选择节点?
    • 由于 azure 负载均衡器只是将流量重定向到服务端口,而 kube-proxy 决定了 pod 的选择,那么负载均衡器的目的是什么?实际的负载均衡仍然由 kube-proxy 完成。