jakie są limity czasu kubernetes / elb dla żądań HTTP?

Mam Java API (akceptujący żądania HTTPS_ spakowane w obraz dokera, a następnie wdrażany za pomocą klastra k8s na EC2. Główny EC2 ma ELB z przodu.

Mogę wysyłać curl żądania POST do ELB, aby uzyskać dostęp do interfejsu API Java.

Czasami moje żądanie curl siedzi na zawsze i czeka na odpowiedź, nawet jeśli widzę dzienniki kube, przetwarzanie zakończyło się powodzeniem.

Dzieje się tak w przypadku większych żądań około 40 minut, żądania 25 minut otrzymują odpowiedź w porządku.

Jak myślisz, gdzie może być limit czasu? jakieś konkretne parametry konfiguracji, na które powinienem spojrzeć?

klient (curl) -> ELB -> k8s -> pod działający obraz Java API

myślałem, że to będzie istotne (nie ustawiam IdleTimeout) dla ELB, ale docs mówią, że domyślnie jest to 60s, chociaż mogę uzyskać odpowiedź na 20-minutowe żądania „ConnectionSettings”: {„IdleTimeout”}

Tak jak Pampy wspomniał w swojej odpowiedzi, limit czasu ELB liczy tylko czas bezczynności. Może to wynosić od 1 do 4000 sekund i jest domyślnie ustawione na 60 sekund. Możesz zmienić limit czasu za pomocą CLI lub konsoli.

Oto przykład użycia interfejsu CLI do zmiany go na 5 minut:

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

Źródło: docs

Ponieważ przesyłanie dużych plików zajmuje 20–40 minut, nadal polecam inne sugestie dotyczące korzystania z brokera wiadomości, takiego jak RabbitM lub Kafka, do asynchronicznego przesyłania i przetwarzania.

Limit czasu ELB liczy się tylko dla czasu „bezczynności” . Oznacza to, że dopóki przesyłanie jest nadal uruchomione, nie jest bezczynne. Gdy plik dotrze na twój serwer, musisz zmierzyć czas do momentu, gdy serwer zareaguje.

Po prawidłowym uzyskaniu odpowiedzi serwer przetworzy żądanie i zwróci odpowiedź do klienta. Domyślny limit czasu wynosi 60 sekund, a serwer ma te 60 sekund na przetworzenie przesłanego pliku i zwrócenie odpowiedzi.

Może Twój serwer potrzebuje mniej niż 60 sekund na przetworzenie 25-minutowego przesyłania, ale więcej na przetworzenie 40-minutowego przesyłania?

Dlaczego nie przesyłasz pliku i nie wysyłasz zdarzenia do brokera wiadomości, takiego jak rabbitMQ. Wykonaj ETL na plikach za pomocą obiektu kubernetes Job / CronJob asynchronicznie i odpowiednio powiadom klienta.

W ten sposób nie musisz blokować przychodzącego żądania przez dłuższy czas. wysyłaj post po opublikowaniu wydarzenia, wyślij wiadomość do klienta, że ​​żądanie jest przetwarzane.

25 minut to dość długo na żądanie HTTP. Całkowicie zgadzam się z P. Ekambaram.

Myślę, że lepiej byłoby ustawić punkt końcowy jako asynchroniczny i odpowiedzieć, gdy tylko plik zostanie przesłany (powinno być szybsze), jednocześnie używaj wiadomości oprogramowania pośredniego (RabbitMQ, Kafka lub NATS) lub Websocket, które wypychają zdarzenie po plik został pomyślnie zaimportowany i przetworzony.

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

użyj tego w cLI, aby zmienić limit czasu na 5 min