quali sono i timeout di kubernetes / elb per le richieste http?

Ho un'API Java (che accetta richieste HTTPS_ impacchettate in un'immagine docker, quindi viene distribuita usando il cluster k8 sopra EC2. L'EC2 master ha un ELB davanti.

Posso fare richieste POST arricciate all'ELB per colpire quell'API java.

A volte la mia richiesta di arricciatura rimane in attesa di una risposta per sempre anche se quando vedo i registri del kube l'elaborazione è riuscita.

Questo accade per richieste più grandi di circa 40 minuti, le richieste di 25 minuti stanno ottenendo una risposta ok.

Dove pensi possa essere il timeout? eventuali parametri di configurazione specifici che dovrei guardare?

client (curl) -> ELB -> k8s -> pod che esegue un'immagine API Java

ho pensato che questo sarebbe pertinente (non sto impostando IdleTimeout) per ELB ma i documenti dicono che l'impostazione predefinita è 60s, anche se posso ottenere una risposta per le richieste di 20 minuti "ConnectionSettings": {"IdleTimeout"}

Proprio come Pampy ha menzionato nella sua risposta, il timeout ELB conta solo il tempo di inattività. Può variare da 1 a 4000 secondi ed è impostato su 60 secondi per impostazione predefinita. È possibile modificare il timeout utilizzando l'interfaccia della riga di comando o la console.

Di seguito è riportato un esempio dell'utilizzo della CLI per modificarlo in 5 minuti:

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

Fonte: docs

Dato che stai caricando file di grandi dimensioni in 20-40 minuti, consiglierei comunque gli altri suggerimenti sull'utilizzo di un broker di messaggi come RabbitM o Kafka per gestire il caricamento e l'elaborazione in modo asincrono.

Il timeout ELB conta solo per il tempo "inattivo" . Ciò significa che finché il tuo caricamento è ancora in esecuzione, non è inattivo. Quando il file è arrivato sul tuo server, devi misurare il tempo fino a quando il tuo server non risponde.

Se ottenuto correttamente, il server elaborerà la richiesta e restituirà una risposta al client in seguito. Con un timeout predefinito di 60 secondi, il server dispone di questi 60 secondi per elaborare il file caricato e restituire una risposta.

Forse il tuo server ha bisogno di meno di 60 secondi per elaborare il tuo caricamento di 25 minuti, ma più per elaborare il caricamento di 40 minuti?

Perché non caricare il file e inviare un evento al broker di messaggi come rabbitMQ. Eseguire ETL sui file utilizzando l'oggetto Job / CronJob di kubernetes in modo asincrono e, di conseguenza, avvisare il client.

In questo modo, non è necessario bloccare la richiesta in arrivo per un periodo più lungo. dopo il caricamento dopo che l'evento è stato pubblicato invia un messaggio al cliente che la richiesta è in elaborazione.

25 minuti sono abbastanza lunghi per una richiesta HTTP. Sono abbastanza d'accordo con P Ekambaram.

Penso che potrebbe essere meglio rendere l'endpoint asincrono e rispondere non appena il file viene caricato (dovrebbe essere più veloce), allo stesso tempo, utilizzare la messaggistica di middleware (RabbitMQ, Kafka o NATS) o Websocket, che inviano un evento una volta che il file viene importato ed elaborato correttamente.

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

usare questo in cLI per cambiare il timeout a 5 min