apa batas waktu kubernetes / elb untuk permintaan http?


9

Saya memiliki java API (menerima HTTPS request_ yang dikemas menjadi gambar buruh pelabuhan, dan kemudian digunakan menggunakan kluster k8s di atas EC2s. Master EC2 memiliki ELB di depan.

Saya bisa membuat permintaan POST curl ke ELB untuk memukul java API itu.

Terkadang permintaan ikal saya duduk menunggu respons selamanya meskipun ketika saya melihat log kubus prosesnya berhasil.

Ini terjadi untuk permintaan yang lebih besar sekitar 40 menit, permintaan 25 menit mendapatkan respons ok.

Menurut Anda di mana batas waktu itu bisa terjadi? params konfigurasi khusus yang harus saya lihat?

client (curl) -> ELB -> k8s -> pod yang menjalankan gambar java api

saya pikir ini akan relevan (saya tidak mengatur IdleTimeout) untuk ELB tetapi dokumen mengatakan default adalah 60-an, meskipun saya bisa mendapatkan respons untuk permintaan 20 menit "ConnectionSettings": {"IdleTimeout"}


"permintaan lebih besar sekitar 40 menit" apa maksudmu dengan itu?
Arghya Sadhu

yaitu mengunggah file besar, api membutuhkan waktu 40 menit untuk 'menelannya' dengan proses ETL kemudian dimaksudkan untuk mengirim respons kembali
tooptoop4

Saya bertanya-tanya mengapa Anda memiliki LB di depan master (maksud Anda api-server?), Dan bagaimana Anda bisa mencapai API Anda mengenai LB itu.
suren

Jawaban:


1

Seperti yang disebutkan Pampy dalam jawabannya, batas waktu ELB hanya menghitung waktu Idle. Ini dapat berkisar antara 1 dan 4000 detik dan diatur ke 60 detik secara default. Anda dapat mengubah batas waktu menggunakan CLI atau konsol.

Berikut ini adalah contoh penggunaan CLI untuk mengubahnya menjadi 5 menit:

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

Sumber: docs

Saat Anda mengunggah file besar dengan waktu 20-40 menit, saya masih akan merekomendasikan saran lain tentang menggunakan broker pesan seperti RabbitM atau Kafka untuk menangani unggahan dan pemrosesan secara tidak sinkron.


0

Batas waktu ELB hanya dihitung untuk waktu "idle" . Itu berarti selama unggahan Anda masih berjalan, itu tidak menganggur. Ketika file tiba di server Anda, Anda perlu mengukur waktu sampai server Anda merespons.

Ketika mendapatkannya dengan benar, server akan memproses permintaan dan mengembalikan respons kepada klien sesudahnya. Dengan batas waktu default 60 detik, server Anda memiliki 60 detik ini untuk memproses file yang diunggah dan mengembalikan jawaban.

Mungkin server Anda membutuhkan kurang dari 60 detik untuk memproses unggahan 25 menit, tetapi lebih untuk memproses unggahan 40 menit?


dari mana datangnya 60 detik? saya tidak menggunakan IdleTimeout default di ELB
tooptoop4

60 detik adalah batas waktu idle default dari ELB. Anda tidak dapat "tidak menggunakannya". Anda dapat memodifikasinya antara 1 detik dan 60 menit, tetapi tidak ada cara untuk memberitahu ELB untuk tidak memutuskan koneksi sama sekali.
Pampy

0

Mengapa Anda tidak mengunggah file dan mendorong suatu acara ke broker pesan seperti rabbitMQ. Lakukan ETL pada file menggunakan kubernetes Job / CronJob objek asynchronous dan sesuai pemberitahuan klien.

Dengan cara ini, Anda tidak perlu memblokir permintaan masuk untuk waktu yang lebih lama. posting unggah setelah acara diterbitkan kirim pesan ke klien bahwa permintaan sedang diproses.


saya masih ingin menemukan di mana batas waktu
tooptoop4

0

25 menit cukup lama untuk permintaan HTTP. Saya cukup setuju dengan P Ekambaram.

Saya pikir akan lebih baik untuk membuat titik akhir asinkron dan membalas segera setelah file diunggah (harus lebih cepat), pada saat yang sama, menggunakan pesan middleware (RabbitMQ, Kafka atau NATS) atau Websocket, yang mendorong suatu peristiwa setelah file berhasil diimpor dan diproses.


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

gunakan ini di cLI untuk mengubah batas waktu menjadi 5 menit

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.