非云环境中kubernetes的负载平衡

Question

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

我想知道HAProxy和IngressController（例如HAProxy和Nginx）之间有什么区别

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

Answer 1

我在这里面临着同样的问题。 K8s是专为云计算而设计的，因此在本地安装会带来一些麻烦。在下面的文章中，对此进行了详细说明。

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

总而言之，解决方案是使用NodePort或外部名称服务。我将在这里尝试的方法是使用metalLB（https://metallb.universe.tf/，https://github.com/google/metallb）。

Answer 2

我看到kubernetes可以使用ClusterIP以及NodePort和LoadBalancing。为了实现负载平衡，需要云。如果我没有云提供商，如何在节点之间负载均衡流量？！

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

现在，您可以将流量发送到Service的随机端口，发送到任何个节点，您将在Pod内部进行负载均衡。如果现在旋转，例如与节点位于同一网络中或可以到达节点并在30001之间建立负载平衡的网络中的VM。

尽管有很多很好的理由，您仍然可以虽然不被推荐 ，但是基本上只是将流量发送到多节点集群中的一个节点（node-{a,b,c}:30001），而流量仍然会被负载内部平衡。之所以可能这样做，是因为node-a:30001的所有实例都知道在任何给定时间所有Pod（或kube-proxy上下文中的Endpoints）都位于哪里。

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

存在LoadBalancer对象，以便在一个或多个Ingress的前面添加L7逻辑，但是正如您所见，如果没有Ingress Controller实现，Service毫无用它。 HAProxy和Nginx Ingress控制器或多或少会为您做同样的事情，但短期内不会解决您的问题。是的，您将具有负载平衡能力，但可能会遇到您想不到的方式。

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

如果您处于非云提供商环境（例如，仅限裸机）中，要回答的问题之一是：如何在{{1}的Service字段中获取IP地址}类型为EXTERNAL-IP的}？ 请注意，我假设使用Service命令的输出。一个很好的答案是，如此处的评论所述：MetalLB。

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

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

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

希望这可以清除一切！

Answer 3

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

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

Nginx IC很棒。就像Istio（虽然概念不同）。 Traefik也可能是一个选择。检查不同的IC选项，并明确Ingress Controller概念。

Answer 4

您想使用nginx入口控制器或istio或linkerd之类的服务网格来在kubernetes中进行内部负载平衡。 在Nginx情况下发生的是，您在Pod顶部创建了一个服务。该服务是可以实现负载平衡的抽象，但仍需要负载平衡器来实现。 Nginx可以在内部完全用于此目的。 正如您可以想象的那样，这并不完美或太棒了，这意味着结账并不是一个坏主意。看一下envoy（https://blog.turbinelabs.io/a-basic-service-mesh-with-envoy-71d16bb7347d），istio（https://istio.io/）和linkerd（https://linkerd.io/） 尽管完全有可能自己动手，但这些都是解决许多缺少功能的解决方案，因此一开始它也可以使您的生活变得更加轻松。 还有MetalLB（https://github.com/google/metallb）可能对您来说很有趣。 希望能有所帮助。