为什么1荚复制速度比其他5只慢？

Question

我有一个多节点kubernetes集群，它有6个荚(副本、8Gi、4个CPU核)，运行在位于自动缩放组中的不同节点上。这些吊舱包含一个为REST服务的应用程序，并连接到Redis。

对于所有通过入口配置的ALB请求，有些请求比其他请求慢得令人痛苦。

当我在Pod-IP级别发送请求时，我发现一个pod比其他5个要慢得多(几乎是其他5个的5倍)，大大降低了总的响应时间。

我试着把吊舱弄死，这样的话，部署就产生了一种新的，效果很好。问题是，其他一些吊舱因为这个而变慢了。快:慢的比例保持在5:1。

吊舱的CPU利用率低于30%，有充足的可用资源.

我找不出原因。请帮帮忙。

Answer 1

我不是一个质疑者，但奇怪的是，我遇到了一个类似的问题，不能归咎于任何显而易见的问题本身。

经过大量的调试和循环，我们最终禁用了Prometheus操作符，通过删除所需的注释来抓取我们的豆荚。"1脚表演问题“神奇地消失了。

我们转发了一个豆荚并检查了我们的度量端点:它生成了6MB (!)这是相当多的公制数据，在没有负载的情况下需要大约700到1000毫秒才能生成。事实证明，我们的自定义度量有一个回归，并为一个特定的度量创建了许多标记变体，这归因于生成的度量中的将近3MB。下一个问题是Kafka流，它生成了许多非常详细的度量标准(即使是在每个Kafka流节点操作的基础上，也可以对连接的Kafka集群中的每个节点进行标记)。对于我们来说，没有简单的方法可以禁用这些度量的集合，但是我们只是将它们排除在prometheus端点之外。

这给我们留下了仅有的32 of的度量。重新激活普罗米修斯操作符刮擦没有重新引入观察到的问题。

但为什么只有一个吊舱？我们基本上有两个Prometheus操作符实例，每30秒刮一次所有已注册的端点，这导致平均抓取间隔约15秒。我们检查了我们的http指标，然后它击中了我们:一个荚是刮8-10倍，比任何其他荚！考虑到高负载情况，prometheus端点响应超过1.5秒并不是不可能的，这意味着另一个抓取过程将启动，而之前的刮取尚未完成。所有这些都增加了越来越多的CPU使用量，导致吊舱的节流越来越多，因为它达到了CPU限制，这反过来又增加了度量端点响应时间，从而导致更多并发擦伤，生成6MB的数据。

至于为什么经常有一个吊舱被刮掉:我们目前还没有明确的答案，因为我们的系统团队还在调查。可悲的是，在我们缩小了度量端点的响应大小之后，8-10倍的抓取量就消失了。

我们基本上得到了DDOSd的度量刮，这是经常发生在一个荚(原因未知)。这肯定是我调试过的最复杂的事情了。我们基本上删除了应用程序的每个部分(DB层、跟踪、prometheus、自定义度量)，直到找到了罪魁祸首。我们甚至考虑了特定的Kubernetes节点，其中的罪魁祸首，甚至检查是否有像熵一样的东西是出于任何原因而耗尽的。

祝你好运，我希望这能帮助一些可怜的灵魂，不要浪费超过一个星期的时间在大海捞针！

Answer 2

ALB入侵控制器支持两种流量模式：instance mode和ip mode。用户可以通过声明alb.ingress.kubernetes.io/target-type注释和服务定义来显式地指定这些流量模式。

instance模式:入口流量从ALB开始，到达为您的服务打开的NodePort。然后将通信量路由到集群中的吊舱。(默认)

ip模式:入口流量从ALB开始，直接到达集群中的豆荚。要使用这种模式，Kubernetes集群的网络插件必须在ENI上使用二级IP地址，称为pod，也称为Kubernetes的AWS CNI插件。

默认是instance模式。