Jika pengontrol NGINX Ingress Anda sering mengalami beban tinggi, Anda dapat meningkatkan kinerjanya dengan menyesuaikan plug-in jaringan kluster, spesifikasi node, dan konfigurasi pengontrol. Topik ini menjelaskan cara mengonfigurasi pengontrol NGINX Ingress berperforma tinggi.
Metode konfigurasi yang dijelaskan dalam topik ini hanya untuk referensi. Anda perlu memilih konfigurasi dan nilai parameter tertentu berdasarkan beban aktual dari pengontrol Anda.
Plug-in jaringan kontainer
Plug-in Container Network Interface (CNI) dari kluster Anda memengaruhi kinerja komunikasi jaringan dalam kluster, yang pada gilirannya memengaruhi kinerja pengontrol NGINX Ingress. Kami merekomendasikan Anda menggunakan Terway sebagai plug-in jaringan kontainer. Jika Anda memiliki persyaratan lebih tinggi untuk kinerja jaringan, Anda dapat mempertimbangkan menggunakan Terway dalam mode eksklusif elastic network interface (ENI). Namun, mode ini mengurangi jumlah maksimum pod yang dapat diterapkan pada sebuah node. Untuk informasi lebih lanjut tentang Terway, lihat Bekerja dengan Terway.
Pemilihan spesifikasi node
Kinerja jaringan pod pengontrol NGINX Ingress dibatasi oleh spesifikasi node. Sebagai contoh, jika paket per detik (PPS) dari sebuah node adalah 300.000, PPS maksimum dari pod pengontrol juga 300.000. Kami merekomendasikan Anda memilih jenis instance Elastic Compute Service (ECS) berperforma tinggi berikut:
Instance dioptimalkan komputasi: ecs.c6e.8xlarge (32 vCPU, 64 GB, 6.000.000 PPS)
Instance dioptimalkan jaringan: ecs.g6e.8xlarge (32 vCPU, 128 GB, 6.000.000 PPS)
Untuk informasi lebih lanjut tentang jenis instance ECS, lihat Ikhtisar Keluarga Instance.
Konfigurasi pengontrol NGINX Ingress
Spesifikasi instance CLB
Pengontrol NGINX Ingress menggunakan instance Classic Load Balancer (CLB) untuk menerima permintaan eksternal. Spesifikasi instance CLB memengaruhi kinerja pengontrol. Anda dapat menentukan spesifikasi CLB dengan menggunakan anotasi dalam Service yang terkait dengan pengontrol NGINX Ingress.
Node yang sepenuhnya digunakan oleh pod
Karena overhead dasar NGINX, satu pod dengan spesifikasi tinggi (seperti pod 32-vCPU) berkinerja lebih baik daripada beberapa pod dengan spesifikasi rendah (seperti dua pod 16-vCPU) dengan total sumber daya yang sama. Oleh karena itu, sambil memastikan ketersediaan tinggi, Anda dapat menggunakan sejumlah kecil pod berperforma tinggi alih-alih beberapa pod berperforma lebih rendah.
Sebagai contoh, Anda dapat membuat pool node dengan spesifikasi tinggi tetapi hanya sejumlah kecil node, dan mengonfigurasi taints dan tolerations untuk membuat setiap node sepenuhnya digunakan oleh pod pengontrol NGINX Ingress. Ini memungkinkan pengontrol NGINX Ingress memaksimalkan pemanfaatan sumber daya dan tidak terpengaruh oleh aplikasi lain dalam kluster.
Nonaktifkan pengumpulan metrik
Pengontrol NGINX Ingress secara default mengumpulkan metrik untuk digunakan oleh komponen lain. Namun, pengumpulan metrik mengonsumsi sumber daya CPU. Jika Anda tidak perlu mendapatkan metrik, kami sarankan Anda menonaktifkan pengumpulan metrik. Anda dapat menonaktifkan semua pengumpulan metrik dengan menambahkan --enable-metrics=false ke parameter startup NGINX.
Versi pengontrol NGINX Ingress setelah v1.9.3 mencakup parameter tambahan untuk pengumpulan metrik kustom. Sebagai contoh, setelah Anda menambahkan --exclude-socket-metrics, pengumpulan metrik terkait soket akan dihentikan. Untuk informasi lebih lanjut tentang parameter startup, lihat cli-arguments.
Menyesuaikan kebijakan timeout
Anda dapat mengurangi periode timeout untuk status FIN_WAIT2 dan TIME_WAIT untuk memungkinkan pengontrol NGINX Ingress menutup koneksi yang telah menyelesaikan transmisi data lebih cepat, yang mengurangi penggunaan sumber daya.
Dalam pengontrol NGINX Ingress, konfigurasi terkait adalah:
net.ipv4.tcp_fin_timeout: Periode timeout untuk status FIN_WAIT2. Nilai default adalah 60 detik.net.netfilter.nf_conntrack_tcp_timeout_time_wait: Waktu koneksi tetap hidup dalam status TIME_WAIT. Nilai default adalah 60 detik.
FIN_WAIT2 dan TIME_WAIT adalah konfigurasi kernel kontainer. Memodifikasi konfigurasi ini memengaruhi kinerja pengontrol NGINX Ingress. Jika Anda perlu memodifikasi konfigurasi ini, pastikan Anda memahami prinsip-prinsip koneksi TCP. Setelah Anda memodifikasi konfigurasi, pantau terus status koneksi dan penggunaan sumber daya untuk memastikan bahwa penyesuaian tersebut aman dan efektif.
Konfigurasi ConfigMap
Konfigurasi global pengontrol NGINX Ingress disimpan dalam ConfigMap. Anda dapat menjalankan perintah berikut untuk memodifikasi ConfigMap:
kubectl edit cm -n kube-system nginx-configurationDeskripsi parameter
Tabel berikut menjelaskan parameter utama dalam ConfigMap.
Item konfigurasi | Parameter konfigurasi | Deskripsi |
|
| Menentukan periode timeout koneksi |
| Menentukan jumlah maksimum permintaan | |
|
| Jumlah maksimum koneksi |
| Jumlah maksimum permintaan | |
| Waktu keep-alive maksimum koneksi | |
| Menentukan periode timeout idle koneksi | |
Batas koneksi setiap proses kerja |
| Jumlah maksimum koneksi simultan yang dapat dibuka oleh proses kerja. |
Pengaturan timeout Catatan Anda dapat memodifikasi nilai parameter berdasarkan kebutuhan bisnis Anda. |
| Periode timeout untuk membangun koneksi. Unit: detik. |
| Periode timeout untuk membaca data. Unit: detik. | |
| Periode timeout untuk mengirim data. Unit: detik. | |
Pengaturan ulang percobaan Catatan Saat terjadi kesalahan pada layanan backend, beberapa percobaan ulang dapat menyebabkan permintaan berlebihan. Ini dapat meningkatkan beban pada layanan backend atau bahkan menyebabkan avalan layanan. Untuk informasi lebih lanjut, lihat Dokumentasi resmi ingress-nginx. |
| Jumlah percobaan ulang setelah permintaan gagal dikirim. Nilai default: 3. Nilai default mencakup permintaan asli dan dua percobaan ulang. |
| Kondisi di mana percobaan ulang dipicu. Untuk menonaktifkan percobaan ulang, atur nilainya menjadi off. | |
| Periode timeout permintaan ulang. Unit: detik. Anda dapat memodifikasi nilainya berdasarkan kebutuhan bisnis Anda. |
Konfigurasikan rotasi log otomatis
Secara default, pod pengontrol NGINX Ingress mencatat log ke /dev/stdout. Saat file log bertambah besar, lebih banyak sumber daya dikonsumsi untuk mencatat log baru. Anda dapat mengurangi konsumsi sumber daya pencatatan log dengan memutar log secara berkala. Metode ini menyimpan log dari periode waktu tertentu ke file terpisah dan membersihkan catatan log asli.
Masuk ke node ECS tempat pod pengontrol NGINX Ingress diterapkan menggunakan SSH. Untuk informasi lebih lanjut, lihat Hubungkan ke Instance Linux Menggunakan Pasangan Kunci SSH.
Tambahkan file
nginx-log-rotate.shke direktori/root.Node containerd
#!/bin/bash # Tentukan jumlah maksimum file log yang disimpan. Anda dapat mengubah angka berdasarkan kebutuhan Anda. keep_log_num=5 #Dapatkan ID semua kontainer ingress-nginx yang sedang berjalan ingress_nginx_container_ids=$(crictl ps | grep nginx-ingress-controller | grep -v pause | awk '{print $1}') if [[ -z "$ingress_nginx_container_ids" ]]; then echo "error: failed to get ingress nginx container ids" exit 1 fi # Buat pod pengontrol NGINX Ingress tidur selama periode waktu acak antara 5 dan 10 detik. sleep $(( RANDOM % (10 - 5 + 1 ) + 5 )) for id in $ingress_nginx_container_ids; do crictl exec $id bash -c "cd /var/log/nginx; if [[ \$(ls access.log-* | wc -l) -gt $keep_log_num ]]; then rm -f \$(ls -t access.log-* | tail -1); fi ; mv access.log access.log-\$(date +%F:%T) ; kill -USR1 \$(cat /tmp/nginx/nginx.pid)" doneNode Docker
#!/bin/bash # Tentukan jumlah maksimum file log yang disimpan. Anda dapat mengubah angka berdasarkan kebutuhan Anda. keep_log_num=5 #Dapatkan ID semua kontainer ingress-nginx yang sedang berjalan ingress_nginx_container_ids=$(docker ps | grep nginx-ingress-controller | grep -v pause | awk '{print $1}') if [[ -z "$ingress_nginx_container_ids" ]]; then echo "error: failed to get ingress nginx container ids" exit 1 fi # Buat pod pengontrol NGINX Ingress tidur selama periode waktu acak antara 5 dan 10 detik. sleep $(( RANDOM % (10 - 5 + 1 ) + 5 )) for id in $ingress_nginx_container_ids; do docker exec $id bash -c "cd /var/log/nginx; if [[ \$(ls access.log-* | wc -l) -gt $keep_log_num ]]; then rm -f \$(ls -t access.log-* | tail -1); fi ; mv access.log access.log-\$(date +%F:%T) ; kill -USR1 \$(cat /tmp/nginx/nginx.pid)" doneJalankan perintah berikut untuk menambahkan izin eksekusi ke file
nginx-log-rotate.sh:chmod 755 /root/nginx-log-rotate.shTambahkan konten berikut ke akhir file
/etc/crontab:*/15 * * * * root /root/nginx-log-rotate.shCatatanContoh ini menggunakan ekspresi cron untuk memutar log setiap 15 menit. Anda dapat menyesuaikan frekuensinya berdasarkan kebutuhan Anda.
Aktifkan kompresi brotli
Meskipun kompresi data mengonsumsi waktu CPU tambahan, paket data terkompresi mengurangi penggunaan bandwidth, yang meningkatkan throughput jaringan. Brotli adalah algoritma kompresi open source yang dikembangkan oleh Google. Dibandingkan dengan algoritma kompresi gzip yang umum digunakan (yang digunakan secara default oleh pengontrol NGINX Ingress), Brotli biasanya mencapai rasio kompresi 15% hingga 30% lebih tinggi untuk data teks seperti sumber daya web. Namun, peningkatan spesifik tergantung pada detail skenario. Untuk mengaktifkan kompresi Brotli dalam pengontrol NGINX Ingress, Anda perlu mengonfigurasi parameter berikut:
enable-brotli: Menentukan apakah akan mengaktifkan algoritma kompresi Brotli. Nilai valid:truedanfalse.brotli-level: Tingkat kompresi. Nilai valid: 1 hingga 11. Nilai default: 4. Tingkat kompresi yang lebih tinggi memerlukan lebih banyak sumber daya CPU.brotli-types: Jenis Multipurpose Internet Mail Extensions (MIME) yang menggunakan kompresi Brotli secara real-time.
Anda dapat mengaktifkan kompresi Brotli dengan menambahkan konfigurasi berikut ke ConfigMap:
data:
enable-brotli: "true"
brotli-level: "6"
brotli-types: "text/xml image/svg+xml application/x-font-ttf image/vnd.microsoft.icon application/x-font-opentype application/json font/eot application/vnd.ms-fontobject application/javascript font/otf application/xml application/xhtml+xml text/javascript application/x-javascript text/plain application/x-font-truetype application/xml+rss image/x-icon font/opentype text/css image/x-win-bitmap"Optimasi kinerja HTTPS
Untuk meningkatkan kinerja HTTPS pengontrol NGINX Ingress, Anda dapat mengonfigurasi parameter berikut: caching sesi SSL, OCSP stapling, data awal TLS 1.3, dan prioritas cipher suite.
Caching Sesi SSL dan Timeout
Anda dapat mengurangi overhead handshake SSL dengan menyetel ukuran caching sesi SSL bersama dan periode waktu untuk menggunakan kembali sesi yang disimpan dalam cache.
Konfigurasi ConfigMap:
data: ssl-session-cache-size: "10m" ssl-session-timeout: "10m"Konfigurasi
nginx.confdi sisi NGINX. Anda dapat menyesuaikan konfigurasi berdasarkan kebutuhan bisnis Anda.ssl_session_cache shared:SSL:120m; # 1m dapat menyimpan 4.000 sesi. ssl_session_timeout 1h; # Periode timeout sesi adalah 1 jam.
Aktifkan OCSP Stapling
OCSP stapling mengurangi waktu yang diperlukan untuk verifikasi sertifikat klien.
data: enable-ocsp: "true"Dukungan untuk Data Awal TLS 1.3 (0-RTT)
Fitur data awal TLS 1.3, juga dikenal sebagai zero round trip-time (0-RTT), memungkinkan klien mengirim data sebelum handshake selesai. Ini mengurangi waktu respons.
data: ssl-early-data: "true" ssl-protocols: "TLSv1.3"Ubah Prioritas Cipher Suite (Non-Manual)
Anda dapat mengubah prioritas cipher suite untuk mengurangi latensi jaringan. ACK telah mengoptimalkan prioritas cipher suite untuk konfigurasi pengontrol NGINX Ingress.
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384'; ssl_prefer_server_ciphers on; # Prioritaskan konfigurasi cipher di sisi server.