全部产品
Search
文档中心

Container Service for Kubernetes:Konfigurasikan pengontrol NGINX Ingress dalam skenario beban tinggi

更新时间:Jul 02, 2025

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.

Penting

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.

Ubah Spesifikasi Instance CLB

  1. Jalankan perintah berikut untuk mengubah Service yang terkait dengan pengontrol NGINX Ingress:

    kubectl edit service -n kube-system nginx-ingress-lb
  2. Tambahkan anotasi service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec ke Service.

    apiVersion: v1
    kind: Service
    metadata:
      annotations:
        ...
        service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec: "slb.s3.large" # Tentukan spesifikasi CLB
      name: nginx-ingress-lb
      namespace: kube-system
      ...
    spec:
      ...
    
    Penting

    Untuk informasi tentang performa dan penagihan spesifikasi CLB, lihat Spesifikasi. Instance dengan spesifikasi lebih tinggi mengakibatkan biaya lebih tinggi.

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.

Contoh Mengonfigurasi Pod Pengontrol untuk Menggunakan Node Sepenuhnya

  1. Buat pool node baru di kluster dan konfigurasikan parameter berikut. Untuk informasi lebih lanjut, lihat Buat dan Kelola Pool Node.

    • Atur Expected Nodes menjadi 3.

    • Atur Operating System menjadi Alibaba Cloud Linux 3.

    • Konfigurasikan Node Labels dan Taints.

      • Dalam Taints, tambahkan ingress-pod, atur Value menjadi yes, dan atur Effect menjadi NoExecute.

      • Dalam Node Labels, tambahkan ingress-node dan atur Value menjadi yes.

    • Atur CPU Policy menjadi Static.

  2. Jalankan perintah berikut untuk mengubah Deployment pengontrol:

    kubectl edit deploy nginx-ingress-controller -n kube-system
  3. Buat perubahan berikut pada Deployment:

    1. Atur replicas menjadi 3, yang sama dengan jumlah node dalam pool node.

      spec:
        replicas: 3
    2. Ubah nginx-ingress-controller requests dan limits dari kontainer. Atur CPU menjadi 32 vCPU dan memori menjadi 64 GB.

      containers:
        - args:
          ...
          resources:
            limits:
              cpu: "32"
              memory: 64Gi
            requests:
              cpu: "32"
              memory: 64Gi
    3. Atur afinitas node dan tolerations untuk memastikan bahwa pod hanya dijadwalkan ke node dengan label ingress-node:yes dan dapat mentoleransi taint ingress-pod:yes.

      nodeSelector:
        kubernetes.io/os: linux
        ingress-node: "yes"
      tolerations:
      - effect: NoExecute
        key: ingress-pod
        operator: Equal
        value: "yes"
    4. Pastikan Deployment memiliki konfigurasi anti-afinitas berikut, yang memastikan bahwa setiap node memiliki paling banyak satu pod pengontrol NGINX Ingress.

      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app
            operator: In
            values:
            - ingress-nginx
         topologyKey: kubernetes.io/hostname

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.

Nonaktifkan Pengumpulan Metrik

  1. Jalankan perintah berikut untuk memodifikasi Deployment pengontrol:

    kubectl edit deploy nginx-ingress-controller -n kube-system
  2. Tambahkan --enable-metrics=false ke bagian konfigurasi kontainer untuk menonaktifkan semua pengumpulan metrik. --exclude-socket-metrics dapat menghentikan pengumpulan metrik terkait soket.

    containers:
    - args:
      - ...
      - --enable-metrics=false
      - --exclude-socket-metrics # Berlaku saat --enable-metrics=true

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.

Penting

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.

Menyesuaikan Kebijakan Timeout

  1. Jalankan perintah berikut untuk memodifikasi Deployment pengontrol:

    kubectl edit deploy nginx-ingress-controller -n kube-system
  2. Tambahkan sysctl -w net.ipv4.tcp_fin_timeout dan sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait ke initContainers.

    initContainers:
          - command:  
            - /bin/sh
            - -c
            - |
              if [ "$POD_IP" != "$HOST_IP" ]; then
              mount -o remount rw /proc/sys
              sysctl -w net.core.somaxconn=65535
              sysctl -w net.ipv4.ip_local_port_range="1024 65535"
              sysctl -w kernel.core_uses_pid=0
              sysctl -w net.ipv4.tcp_fin_timeout=15 # Tetapkan batas atas status FIN_WAIT2 menjadi 15 detik
              sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30 # Tetapkan batas atas status TIME_WAIT menjadi 30 detik
              fi

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-configuration

Deskripsi parameter

Tabel berikut menjelaskan parameter utama dalam ConfigMap.

Item konfigurasi

Parameter konfigurasi

Deskripsi

keepalive hilir

keep-alive: "60"

Menentukan periode timeout koneksi keepalive hilir. Unit: detik.

keep-alive-requests: "10000"

Menentukan jumlah maksimum permintaan keepalive hilir.

keepalive hulu

upstream-keepalive-connections: "1000"

Jumlah maksimum koneksi keepalive hulu.

upstream-keepalive-requests: "2147483647"

Jumlah maksimum permintaan keepalive hulu yang diizinkan.

upstream-keepalive-time: 1h

Waktu keep-alive maksimum koneksi keepalive hulu.

upstream-keepalive-timeout: "150"

Menentukan periode timeout idle koneksi keepalive hulu. Unit: detik.

Batas koneksi setiap proses kerja

max-worker-connections: "65536"

Jumlah maksimum koneksi simultan yang dapat dibuka oleh proses kerja.

Pengaturan timeout

Catatan

Anda dapat memodifikasi nilai parameter berdasarkan kebutuhan bisnis Anda.

proxy-connect-timeout: "3"

Periode timeout untuk membangun koneksi. Unit: detik.

proxy-read-timeout: "5"

Periode timeout untuk membaca data. Unit: detik.

proxy-send-timeout: "5"

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.

proxy-next-upstream-tries: "3"

Jumlah percobaan ulang setelah permintaan gagal dikirim. Nilai default: 3. Nilai default mencakup permintaan asli dan dua percobaan ulang.

proxy-next-upstream: "off"

Kondisi di mana percobaan ulang dipicu. Untuk menonaktifkan percobaan ulang, atur nilainya menjadi off.

proxy-next-upstream-timeout

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.

  1. 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.

  2. Tambahkan file nginx-log-rotate.sh ke 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)"
    done	
    

    Node 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)"
    done	
    	
  3. Jalankan perintah berikut untuk menambahkan izin eksekusi ke file nginx-log-rotate.sh:

    chmod 755 /root/nginx-log-rotate.sh
  4. Tambahkan konten berikut ke akhir file /etc/crontab:

    */15 * * * *  root /root/nginx-log-rotate.sh
    Catatan

    Contoh 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: true dan false.

  • 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.conf di 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.