如何缩放Nginx-inress/loadbalancer? [英] How to scale a nginx-ingress/loadbalancer?

查看:36
本文介绍了如何缩放Nginx-inress/loadbalancer?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

所以我正在使用 kubernetes NGINX入口控制器并通过

So I am using the kubernetes NGINX Ingress Controller and installed it via the helm chart.

我没有找到图表的任何真实文档,但引用了 values.yaml ,我将controller.kind值更改为DaemonSet.

I didn't find any real documentation for the chart but referencing the values.yaml, I changed the controller.kind value to DaemonSet.

因此,这个问题的第一部分是一种好的做法.我找不到任何有关此的信息,但是一个控制器可能不足以处理所有传入的流量,我们还遇到了一些问题,其中运行入口控制器的节点已关闭.我希望使控制器以DaemonSet的身份运行就足够了,无论是在可用性方面还是在性能方面?

So the first part of this question, is this a good practice. I couldn't find any information about this, but one controller might not be enough to handle all incomming traffic, also we ran into some issues, where the node running ingress controller was down. I hope having the controller run as DaemonSet is sufficient, both regarding the availability and also regarding performance?

问题的第二个也是更重要的部分是,如何在这样的设置中拥有多个负载均衡器?由于一个负载均衡器可能无法处理所有流量,因此我们想添加多个负载均衡器,但据我所知,将创建一个负载均衡器类型的服务.我如何拥有多个负载均衡器?

The second and more important part of the question is, how could I have multiple loadbalancers in such a setup? Since one loadbalancer might not be able to handle all traffic, we want to add multiple Loadbalancers, but as far as I understand, there will be one Service of type Loadbalancer created. How can I have multiple Loadbalancers?

还可以通过舵图配置来做到这一点吗?

Also is it possible to do this through a helm chart configuration?

推荐答案

Nginx Ingress Controller不是负载均衡器,因此当您说一个负载均衡器不足时,我想您的意思是一个Ingress Controller pod不够用.在那种情况下,创建多个负载均衡器并没有真正的帮助,因为您将获得更多的云提供商负载均衡器指向同一个Ingress Controller.

Nginx Ingress Controller is not a load balancer, so when you say one load balancer would not be enough, I guess you mean one Ingress Controller pod would not be enough. In that case, creating several load balancers would not really help, as you would get more cloud provider load balancers pointing to the same Ingress Controller.

现在,为IC设置一个 DaemonSet 似乎是一个好主意,但事实并非如此.尤其是当您有数十或数百个节点时,在这种情况下,您可能会真正不需要数十或数百个IC盒.对于40个节点,您可能需要5个.

Now, Having a DaemonSet for IC might seem a good idea, but it is not. Especially when you have tens or hundreds of nodes, in which case you might have tens or hundreds of IC pods that you don't really need. You might need 5, for 40 nodes.

正确的方法是将对象改回 Deployment ,为该 Deployment 创建一个 Horizo​​ntalPodAutoscaler 对象,以根据您将设置的阈值.为此,您可能需要安装指标服务器.例如,如果遇到节点自动缩放器的问题,这可能随时使节点崩溃,则应设置 PodDisruptionBudget 对象,以防止出现这种情况.PDB将防止节点耗尽,并且节点自动缩放器将关闭另一个节点.您还可以为其自身设置一个 Anti-affinity (反亲和力),以防止将两个IC Pod部署在同一节点上,以增加距离.

The proper way would be to change the object back to Deployment, create a HorizontalPodAutoscaler object for that Deployment, to scale based on a threshold that you will set. You might need to install metrics server for that. If you have the issue of having a node autoscaler, for example, that might take a node down at any moment, you should set a PodDisruptionBudget object, to prevent these cases. PDBs will prevent a node from being drained, and the node autoscaler would take down another node. You could also set an Anti-affinity against itself to prevent two IC pods to be deployed on the same node, to do the extra mile.

这篇关于如何缩放Nginx-inress/loadbalancer?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆