http 請求的 kubernetes/elb 超時是多少？

Question

我有一個java API（接受HTTPS請求_打包成docker鏡像，然后使用k8s集群部署在EC2s之上。主EC2前面有一個ELB。

我可以向 ELB 發出 curl POST 請求以訪問該 Java API。

有時，即使我看到 kube 日志處理成功，我的 curl 請求也會永遠等待響應。

對於大約 40 分鍾的較大請求，會發生這種情況，25 分鍾的請求會得到響應。

你認為超時可能在哪里？ 我應該查看任何特定的配置參數？

客戶端 (curl) --> ELB --> k8s --> 運行 java api 鏡像的 pod

我認為這與 ELB 相關（我沒有設置 IdleTimeout），但文檔說默認值為 60 秒，盡管我可以獲得 20 分鍾請求的響應“ConnectionSettings”：{“IdleTimeout”}

Answer 1

正如Pampy在他的回答中提到的，ELB 超時只計算空閑時間。 這可以介於 1 到 4000 秒之間，默認設置為 60 秒。 您可以使用 CLI 或控制台更改超時。

以下是使用 CLI 將其更改為 5 分鍾的示例：

aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"ConnectionSettings\":{\"IdleTimeout\":300}}"

來源： 文檔

當你上傳大文件需要 20-40 分鍾時，我仍然會推薦其他關於使用像 RabbitM 或 Kafka 這樣的消息代理來異步處理上傳和處理的建議。

Answer 2

ELB 超時僅計入“空閑”時間。 這意味着只要您的上傳仍在運行，它就不會空閑。 當文件到達您的服務器時，您需要測量服務器響應之前的時間。

當正確獲取時，服務器將處理請求並隨后向客戶端返回響應。 默認超時時間為 60 秒，您的服務器有這 60 秒的時間來處理上傳的文件並返回答案。

也許您的服務器需要不到 60 秒來處理您的 25 分鍾上傳，但需要更多時間來處理 40 分鍾上傳？

Answer 3

為什么不上傳文件並將事件推送到像rabbitMQ這樣的消息代理。 使用 kubernetes Job/CronJob 對象異步對文件執行 ETL，並相應地通知客戶端。

這樣，您不必長時間阻止傳入請求。 發布事件后上傳后向客戶端發送一條消息，表示正在處理請求。

Answer 4

25 分鍾對於 HTTP 請求來說相當長。 我非常同意 P Ekambaram。

我認為最好使端點異步並在文件上傳后立即回復（應該更快），同時使用中間件消息傳遞（RabbitMQ、Kafka 或 NATS）或 Websocket，一旦文件已成功導入和處理。

Answer 5

 aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"ConnectionSettings\":{\"IdleTimeout\":300}}"

在 cLI 中使用它可以將超時更改為 5 分鍾