我正在使用EKS部署服务，而入口则在alb-ingress-controller上运行。
总共我有一个Pod的大约10个副本，并具有类型NodePort的单个服务，该服务将流量转发给它们。这些副本在由eksctl建立的10个节点上运行，并分布在3个可用区中。
我看到的问题非常奇怪-在集群内部，所有日志都显示请求的处理时间不到1秒，大部分时间约为20-50毫秒。我知道这一点是因为我使用linkerd来显示请求延迟的百分位数以及应用程序日志本身。但是，ALB日志/监视的情况截然不同。我发现请求等待时间相对较高（通常接近20秒或更长时间），而且ELB通常还会返回504个错误（有时每5分钟2-3个错误）。
当尝试读取ALB的访问日志时，我注意到504行如下所示：
https 2019-12-10T14:56:54.514487Z app/1d061b91-XXXXX-3e15/19297d73543adb87 52.207.101.56:41266 192.168.32.189:30246 0.000 -1 -1 504 - 747 308 "GET XXXXXXXX" "-" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:eu-west-1:750977848747:targetgroup/1d061b91-358e2837024de757a3d/e59bbbdb58407de3 "Root=1-5defb1fa-cbcdd248dd043b5bf1221ad8" "XXXX" "XXXX" 1 2019-12-10T14:55:54.514000Z "forward" "-" "-" "192.168.32.189:30246" "-"
请求处理时间为0，目标处理时间为-1，表示请求从未到达后端，并立即返回响应。
我尝试使用后端HTTP keepalive超时（当前为75s）和ALB空闲时间（当前为60s），但是这种行为似乎并没有太大改变。
如果有人可以指出我该如何进行调查，或者是什么原因，我将非常感谢。
答案 0 :(得分：0)
我们面临着与EKS和ALB组合类似的问题。如果目标响应代码表示为-1，则可能有请求等待队列在目标侧已满。因此，ALB将立即删除该请求。
通过跳过ALB并直接将请求发送到服务或专用IP地址，尝试进行ab基准测试。这样做将帮助您确定问题出在哪里。
对于我们来说，如果我们通过ALB发送流量，则十分之一的请求失败。如果我们直接将请求发送到服务，则不会看到失败。
AWS建议在NLB上使用NLB。 NLB具有更多优势，适用于Kubernetes。有一个博客对此https://aws.amazon.com/blogs/opensource/network-load-balancer-nginx-ingress-controller-eks/
进行了说明我们更改为NLB，现在没有出现5XX错误。