非云环境下 Kubernetes 的负载均衡答案

【问题标题】：loadbalancing for kubernetes in non-cloud environment非云环境下 Kubernetes 的负载均衡
【发布时间】：2019-03-14 12:44:47
【问题描述】：

我看到 kubernetes 可以使用 ClusterIP 和 NodePort 和 LoadBalancing。对于负载平衡，它需要云。如果我没有有云提供商如何在节点之间对流量进行负载平衡？！ 我知道HAProxy可以负载均衡但我认为这个云负载均衡器不同于简单的 HAProxy

我想知道HAProxy和IngressController有什么不同，比如HAProxy和Nginx

我想要一个负载均衡器来对我的工作节点之间的流量进行负载均衡。 Pod 之间的服务负载均衡流量。我认为入口控制器是第 7 层负载均衡器。我想在我的节点之间进行负载平衡

【问题讨论】：

标签： kubernetes cloud load-balancing haproxy

【解决方案1】：

我看到 kubernetes 可以使用 ClusterIP 和 NodePort 以及 LoadBalancing。对于负载平衡，它需要云。如果我没有云提供商，如何在节点之间进行负载均衡？！

您可能知道，最简单的方法是将Service 设置为输入NodePort，这会向kube-proxy 发出信号，以便在 上侦听30000-32767 默认范围内的随机端口每个节点。在后台，这个随机端口将被映射（端口转发）到Service 端口。

您现在可以将流量（比如30001 的随机端口）发送到任何个节点，您将在 Pod 之间实现内部负载平衡。如果你现在启动一个例如VM 在与节点相同的网络中或在可以到达节点并跨 node-{a,b,c}:30001 设置负载平衡的网络中。

您可以，虽然不推荐有很多充分的理由，基本上只需将流量发送到多节点集群中的一个节点 (node-a:30001)，流量仍将在内部进行负载平衡.这是可能的，因为kube-proxy 的所有实例都知道所有 Pod（或 Endpoints 在Service 的上下文中）在任何给定时间的位置。

请注意，kube-proxy 和 iptables（可能会有所不同！）是在所有情况下实现 Service 对象的组件，但类型为 LoadBalancer 时除外。 LoadBalancer 请求将被分派到内置或外部云控制器管理器。

Ingress 对象的存在是为了在一个或多个 Service 的前面添加 L7 逻辑，但正如您所见，如果没有 Ingress Controller 实现它，Ingress 将毫无价值。 HAProxy 和 Nginx Ingress 控制器或多或少会为您做同样的事情，但不会在短期内解决您的问题。是的，您将拥有负载平衡，但不是您想象的那样。

如果您没有任何形式的（私有/公共）云与 k8s 集成来支持您的 k8s 集群，那么 Nginx 和 HAProxy Ingress 控制器将只是在您的集群中运行的另一个 Service。你当然可以做一些智能的事情，比如代理、URL 路由、主机名匹配等。

如果您处于非云提供商环境（例如仅裸机）中，需要回答的问题之一是：如何在 Service 类型的 EXTERNAL-IP 字段中获取 IP 地址987654348@? 请注意，我假设是 kubectl get service 命令的输出。 一个很好的答案是，正如此处的 cmets 中所述：MetalLB。

MetalLB 将让您自动化配置 Service 类型为 LoadBalancer 的外部 IP。但您也可以手动配置Service 对象的externalIPs 字段，并将其设置为在您的环境中有意义的IP 地址。感谢@danielrubambura 指出这一点！

另请参阅官方 Nginx 控制器文档中的 this 页面，该页面可以阐明在某些情况下如何以及为何使用 MetalLB。

我将放弃 Nginx 和 HAProxy 控制器之间的比较，因为我认为在这种情况下这并不重要。最后，他们会通过Ingress 对象为您提供根据需要配置的 Nginx 或 HAProxy Pod，例如根据传入请求中的Host 标头路由到不同的Service。

希望这能把事情弄清楚一点！

【讨论】：

这绝对够清楚了。我已经能够在非云环境中设置 LoadBalancer 类型的服务。在非云环境中创建 LoadBalancer 类型的服务通常会失败（假设 externalIP 仍处于挂起状态），因为不会自动为您的负载均衡器提供外部 IP，这是在云环境中完成的。为了解决这个问题，我在服务清单中手动定义了 extensalIP 类似这样的东西：externalIPs: - 172.x.x.x - 172.x.x.x
@danielrubambura 是的，你是对的，谢谢你提到这一点。这在LoadBalancer 类型的Service 的上下文中很重要！ MetalLB 为您提供了一种自动分配 IP 地址的方式（+ 一堆其他功能），例如一个范围，这在您的环境中是有意义的。但是您当然可以手动手动配置它！

【解决方案2】：

我在这里面临同样的问题。 K8s 是为云而设计的，因此在本地设置会带来一些麻烦。在下面的文章中，它对此进行了详细解释。

https://medium.com/@JockDaRock/metalloadbalancer-kubernetes-on-prem-baremetal-loadbalancing-101455c3ed48

总的来说，解决方案是使用 NodePort 或外部名称服务。我将在这里尝试的方法是使用 metalLB (https://metallb.universe.tf/, https://github.com/google/metallb) 。

【讨论】：

节点端口可以在节点和它们的 Pod 之间进行负载均衡。为什么我应该使用 metalLB？
NodePort 不平衡任何东西。那是集群IP。你应该更清楚这些概念。

【解决方案3】：

在 kubernetes 中应该不需要平衡节点之间的负载，因为对于 kubernetes，后端是一个 pod，而不是一个节点。

因此，您应该考虑使用 Ingress Controller，而不是负载均衡器，因为 Kubernetes 核心控制器没有一些控制器，IC 就是其中之一，而 ClusterIP 类型的服务已经完成了基本的负载均衡。

Nginx IC 很棒。和 Istio 一样（尽管概念不同）。 Traefik 也可能是一种选择。检查不同的 IC 选项，并明确 Ingress Controller 的概念。

【讨论】：

为了启动入口服务，您需要一个负载均衡器，AWS 在云中为您提供了一个没有摩擦的负载均衡器，您可以在本地使用 metalLB。
并非如此。云提供商设置负载平衡器以将流量发送到节点。然后它们依赖于 ClusterIP 负载平衡，如前所述。这是一个已知问题，会增加额外的跳跃。一些IC使用节点外部IP之一，作为入口点。