All Products
Search

This Product

    Container Service for Kubernetes:FAQ NGINX Ingress

    Document Center

    Container Service for Kubernetes:FAQ NGINX Ingress

    Last Updated:Jun 18, 2026

    Atasi masalah umum NGINX Ingress Controller terkait TLS, konfigurasi, kinerja, dan peningkatan.

    Apa saja masalah yang diketahui pada versi lama NGINX Ingress Controller?

    Versi lama memiliki masalah yang diketahui berikut ini. Tingkatkan ke versi terbaru untuk stabilitas.

    Versi TLS apa saja yang didukung?

    Ingress-nginx mendukung TLS 1.2 dan TLS 1.3. Klien yang menggunakan versi TLS lebih lama dari 1.2 mungkin mengalami error handshake.

    Untuk mendukung versi TLS tambahan, tambahkan konfigurasi berikut ke ConfigMap nginx-configuration di namespace kube-system. Lihat TLS/HTTPS.

    Catatan

    Untuk mengaktifkan TLS 1.0 atau 1.1 pada NGINX Ingress Controller 1.7.0 dan lebih baru, tentukan @SECLEVEL=0 pada parameter ssl-ciphers.

    image.png

    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:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA"
ssl-protocols: "TLSv1 TLSv1.1 TLSv1.2 TLSv1.3"

    Apakah header permintaan diteruskan ke server backend?

    Secara default, ingress-nginx meneruskan header permintaan Lapisan 7 ke server backend, tetapi memfilter header HTTP non-standar (seperti Mobile Version). Untuk mempertahankan header tersebut, jalankan kubectl edit cm -n kube-system nginx-configuration untuk memperbarui ConfigMap. Lihat ConfigMap.

    enable-underscores-in-headers: true

    Bagaimana cara meneruskan permintaan ke server backend HTTPS?

    Untuk meneruskan permintaan ke server backend HTTPS melalui ingress-nginx, tambahkan anotasi berikut ke Ingress:

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: xxxx
  annotations:
    # Anda harus menentukan HTTPS sebagai protokol yang digunakan oleh server backend. 
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

    Bagaimana cara meneruskan alamat IP klien pada Lapisan 7?

    Secara default, ingress-nginx menambahkan header X-Forwarded-For dan X-Real-IP untuk meneruskan alamat IP klien. Namun, jika klien sudah menyertakan header tersebut, server backend tidak dapat memperoleh IP klien asli.

    Jalankan kubectl edit cm -n kube-system nginx-configuration untuk memodifikasi ConfigMap nginx-configuration dan aktifkan ingress-nginx agar meneruskan alamat IP klien pada Lapisan 7:

    compute-full-forwarded-for: "true"
forwarded-for-header: "X-Forwarded-For"
use-forwarded-headers: "true"

    Jika trafik melewati beberapa server proxy upstream sebelum mencapai NGINX Ingress, Anda harus menambahkan field proxy-real-ip-cidr ke ConfigMap nginx-configuration dan atur proxy-real-ip-cidr ke blok CIDR server proxy upstream (dipisahkan koma). Lihat Gunakan WAF.

    proxy-real-ip-cidr:  "0.0.0.0/0,::/0"

    Pada skenario IPv6 di mana NGINX Ingress menerima header X-Forwarded-For kosong di belakang instance Classic Load Balancer (CLB), aktifkan protokol Proxy pada CLB untuk mengambil IP klien. Lihat Memperoleh alamat IP klien melalui listener Lapisan 4 CLB.

    Bagaimana cara mengonfigurasi HSTS?

    HTTP Strict Transport Security (HSTS) diaktifkan secara default. Saat browser pertama kali mengakses layanan melalui HTTP biasa, server memicu respons HSTS. Di developer tools, Anda akan melihat header respons Non-Authoritative-Reason: HSTS. Browser yang kompatibel dengan HSTS secara otomatis beralih ke HTTPS untuk permintaan berikutnya, menghasilkan kode status 307 Internal Redirect.1

    Untuk mencegah browser secara otomatis meningkatkan permintaan berikutnya ke HTTPS, nonaktifkan HSTS untuk nginx-ingress-controller. Lihat HSTS.

    Catatan

    Browser menyimpan cache konfigurasi HSTS. Bersihkan cache browser secara manual setelah menonaktifkan HSTS untuk nginx-ingress-controller.

    Aturan penulisan ulang apa saja yang didukung?

    Ingress-nginx hanya mendukung rewrite sederhana. Untuk aturan rewrite kompleks, gunakan:

    Snippet lainnya menambahkan konfigurasi global. Lihat main-snippet.2

    Sumber daya apa saja yang diperbarui selama peningkatan NGINX Ingress Controller?

    Jika versi NGINX Ingress Controller lebih lama dari 0.44, sumber daya berikut disertakan:

    • serviceaccount/ingress-nginx

    • configmap/nginx-configuration

    • configmap/tcp-services

    • configmap/udp-services

    • clusterrole.rbac.authorization.k8s.io/ingress-nginx

    • clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx

    • role.rbac.authorization.k8s.io/ingress-nginx

    • rolebinding.rbac.authorization.k8s.io/ingress-nginx

    • service/nginx-ingress-lb

    • deployment.apps/nginx-ingress-controller

    Jika versinya 0.44 atau lebih baru, selain sumber daya di atas, sumber daya berikut juga disertakan:

    • validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission

    • service/ingress-nginx-controller-admission

    • serviceaccount/ingress-nginx-admission

    • clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission

    • clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission

    • role.rbac.authorization.k8s.io/ingress-nginx-admission

    • rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission

    • job.batch/ingress-nginx-admission-create

    • job.batch/ingress-nginx-admission-patch

    Saat Anda meningkatkan NGINX Ingress Controller melalui halaman Add-ons di konsol ACK, sumber daya berikut tetap tidak berubah:

    • configmap/nginx-configuration

    • configmap/tcp-services

    • configmap/udp-services

    • service/nginx-ingress-lb

    Konfigurasi semua sumber daya lainnya akan dikembalikan ke nilai default. Misalnya, nilai default replicas pada sumber daya deployment.apps/nginx-ingress-controller adalah 2. Jika Anda mengatur replicas ke 5 sebelum meningkatkan NGINX Ingress Controller, nilainya akan kembali ke nilai default 2 setelah peningkatan.

    Bagaimana cara beralih dari listener Lapisan 4 ke Lapisan 7?

    Secara default, LoadBalancer ingress-nginx mendengarkan port TCP 80 dan 443. Beralih ke listener Lapisan 7 dengan mengubah protokol menjadi HTTP atau HTTPS.

    Catatan

    Terjadi gangguan layanan selama perubahan listener. Lakukan ini pada jam sepi.

    1. Buat sertifikat dan catat ID sertifikat (cert-id). Lihat Gunakan sertifikat dari Certificate Management Service.

    2. Ubah listener LoadBalancer yang digunakan oleh Ingress dari Lapisan 4 ke Lapisan 7 melalui anotasi.

      1. Masuk ke Konsol ACK. Di panel navigasi kiri, klik Clusters.

      2. Di halaman Clusters, klik nama kluster Anda. Di panel navigasi kiri, klik Network > Services.

      3. Di bagian atas halaman Services, atur Namespace ke kube-system. Temukan Service ingress-nginx-lb dan klik Edit YAML di kolom Actions.

      4. Di panel Edit YAML, perbarui targetPort menjadi 80 untuk port bernama https (port 443).

          - name: https
    port: 443
    protocol: TCP
    targetPort: 80 # Atur targetPort ke 80 untuk port 443.

        Tambahkan konfigurasi berikut ke field annotations, lalu klik OK.

        service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "http:80,https:443"
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cert-id: "${YOUR_CERT_ID}"

    3. Verifikasi hasilnya.

      1. Di halaman Services, temukan Service ingress-nginx-lb dan klik ikon image di kolom Type.

      2. Klik tab Listener. Jika HTTP:80 dan HTTPS:443 ditampilkan di kolom Frontend Protocol/Port, listener LoadBalancer telah berubah dari Lapisan 4 ke Lapisan 7.

    Bagaimana cara menggunakan instance SLB yang ada dengan ack-ingress-nginx?

    1. Masuk ke Konsol ACK. Di panel navigasi kiri, klik Marketplace > Marketplace.

    2. Di tab App Catalog, pilih ack-ingress-nginx atau ack-ingress-nginx-v1 berdasarkan versi kluster Anda:

      • Jika kluster Anda menjalankan Kubernetes 1.20 atau lebih lama, pilih ack-ingress-nginx.

      • Jika kluster Anda menjalankan versi Kubernetes lebih baru dari 1.20, pilih ack-ingress-nginx-v1.

    3. Terapkan controller Ingress. Lihat Terapkan beberapa controller Ingress untuk isolasi trafik.

      Di halaman wizard Parameters:

      1. Hapus semua anotasi di bagian controller.service.annotations.

        image..png

      2. Tambahkan anotasi baru.

        # Tentukan instance SLB yang ingin Anda gunakan.
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "${YOUR_LOADBALANCER_ID}"
# Timpa listener.
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true"

        image..png

    4. Klik OK untuk menerapkan controller Ingress.

    5. Setelah controller Ingress diterapkan, konfigurasikan kelas Ingress. Lihat Terapkan beberapa controller Ingress untuk isolasi trafik.

    Bagaimana cara mengumpulkan log akses dari beberapa controller Ingress?

    Prasyarat

    Prosedur:

    1. Masuk ke Konsol ACK. Di panel navigasi kiri, klik Clusters.

    2. Di halaman Clusters, klik nama kluster target, lalu klik Cluster Information di panel navigasi kiri.

    3. Di halaman Cluster Information, klik tab Basic Information, lalu klik tautan di sebelah kanan Log Service Project di bagian Cluster Resources.

    4. Di halaman Logstores, buat Logstore (lihat Kelola Logstores). Buat Logstore terpisah untuk setiap controller Ingress agar tidak terjadi pengumpulan ganda.

      • Beri nama Logstore sesuai dengan controller Ingress yang menggunakannya.

      • Pada pesan yang muncul, klik Data Collection Wizard.

    5. Di kotak dialog Quick Data Import, pilih K8S - Stdout and Stderr - Old Version > Integrate Now. Di pesan Note, klik Continue. Di halaman Kubernetes Stdout and Stderr, lakukan langkah berikut:

      1. Di langkah Create Machine Group, klik Use Existing Machine Groups.

      2. Di langkah Machine Group Configurations, pilih kelompok mesin k8s-group-<YOUR_CLUSTER_ID>, lalu klik > untuk memindahkan kelompok mesin ke bagian Applied Server Groups. Kemudian, klik Next.

      3. Di langkah Logtail Configuration:

        1. Klik Import Other Configuration. Pilih proyek yang digunakan oleh kluster dan konfigurasi k8s-nginx-ingress. Lalu, klik OK.

        2. Di bagian Global Configurations, ubah nama konfigurasi. Aktifkan opsi Container Filtering, tambahkan label kontainer controller Ingress sebagai pasangan kunci-nilai.

        3. Di bagian Processor Configurations, klik Extract Field (Regex Mode) di kolom Processor Name untuk melihat field pemrosesan log.

          Catatan

          Jika controller NGINX Ingress yang berbeda menggunakan format log berbeda, konfigurasikan kunci field log dan ekspresi reguler yang sesuai.

      4. Di langkah Query and Analysis Configurations, klik Next.

      5. Di langkah End, klik Query Log untuk melihat log yang dikumpulkan.

    Bagaimana cara mengaktifkan listener TCP untuk nginx-ingress-controller?

    Secara default, Ingress hanya meneruskan permintaan HTTP dan HTTPS. Konfigurasikan ingress-nginx untuk meneruskan permintaan TCP eksternal pada port yang ditentukan dalam ConfigMap terkait.

    1. Gunakan templat tcp-echo untuk menerapkan Service dan Deployment.

    2. Gunakan templat berikut untuk membuat ConfigMap.

      1. Modifikasi file tcp-services-cm.yaml, simpan perubahan, lalu keluar.

        apiVersion: v1
kind: ConfigMap
metadata:
  name: tcp-services
  namespace: kube-system 
data:
  9000: "default/tcp-echo:9000" # Konfigurasi ini menunjukkan bahwa permintaan TCP eksternal yang diterima pada port 9000 diteruskan ke Service tcp-echo di namespace default. 
  9001: "default/tcp-echo:9001"

      2. Buat ConfigMap.

        kubectl apply -f tcp-services-cm.yaml

    3. Tambahkan port TCP untuk Service yang digunakan oleh nginx-ingress-controller, lalu simpan perubahan dan keluar.

      kubectl edit svc nginx-ingress-lb -n kube-system 
      apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-ingress-lb
  name: nginx-ingress-lb
  namespace: kube-system
spec:
  allocateLoadBalancerNodePorts: true
  clusterIP: 192.168.xx.xx
  ipFamilies:
  - IPv4
  ports:
  - name: http
    nodePort: 30xxx
    port: 80
    protocol: TCP
    targetPort: 80
  - name: https
    nodePort: 30xxx
    port: 443
    protocol: TCP
    targetPort: 443
  - name: tcp-echo-9000       # Nama port.
    port: 9000                # Nomor port.
    protocol: TCP             # Protokol.
    targetPort: 9000          # Port tujuan.
  - name: tcp-echo-9001       # Nama port.
    port: 9001                # Nomor port.
    protocol: TCP             # Protokol.
    targetPort: 9001
  selector:
    app: ingress-nginx
  sessionAffinity: None
  type: LoadBalancer

    4. Verifikasi konfigurasi:

      1. Kueri Ingress untuk memperoleh alamat IP instance SLB:

         kubectl get svc -n kube-system| grep nginx-ingress-lb

        Output yang diharapkan:

        nginx-ingress-lb      LoadBalancer   192.168.xx.xx  172.16.xx.xx   80:31246/TCP,443:30298/TCP,9000:32545/TCP,9001:31069/TCP

      2. Kirim helloworld ke alamat IP pada port 9000 menggunakan nc. Jika tidak ada respons yang dikembalikan, konfigurasi telah berlaku.

        echo "helloworld" |  nc <172.16.xx.xx> 9000

echo "helloworld" |  nc <172.16.xx.xx> 9001

    Bagaimana NGINX Ingress Controller mencocokkan sertifikat TLS dengan permintaan?

    Dalam resource Kubernetes Ingress, sertifikat TLS didefinisikan di field spec.tls, tetapi hostname yang berlaku ditentukan di field spec.rules.host.

    NGINX Ingress Controller memproses aturan ini dan menyimpan pemetaan antara setiap hostname dan sertifikatnya yang sesuai dalam tabel Lua internal.

    Alur Permintaan

    1. Saat klien memulai permintaan HTTPS, ia menyertakan hostname yang diminta dalam ekstensi Server Name Indication (SNI) dari proses jabat tangan TLS.

    2. NGINX Ingress Controller menerima permintaan ini dan menggunakan fungsi certificate.call() untuk mencari hostname SNI dalam tabel pemetaan Lua-nya.

    3. Jika ditemukan sertifikat yang cocok, sertifikat tersebut disajikan kepada klien untuk menyelesaikan proses jabat tangan TLS.

    4. Jika tidak ditemukan sertifikat yang cocok untuk hostname yang diminta, controller menyajikan sertifikat default self-signed fake.

    Konfigurasi NGINX terkait yang mengimplementasikan logika ini ditunjukkan di bawah ini:

    
    ## Start server _
    server {
        server_name _ ;
        listen 80 default_server reuseport backlog=65535 ;
        listen [::]:80 default_server reuseport backlog=65535 ;
        listen 443 default_server reuseport backlog=65535 ssl http2 ;
        listen [::]:443 default_server reuseport backlog=65535 ssl http2 ;
        set $proxy_upstream_name "-";
        ssl_reject_handshake off;
        ssl_certificate_by_lua_block {
            certificate.call()
        }
   ...
   }
    
    
    ## Start server www.example.com
    server {
        server_name www.example.com ;
        listen 80  ;
        listen [::]:80  ;
        listen 443  ssl http2 ;
        listen [::]:443  ssl http2 ;
        set $proxy_upstream_name "-";
        ssl_certificate_by_lua_block {
            certificate.call()
        }
    ...
    }

    ingress-nginx mendukung Pengikatan OCSP (Online Certificate Status Protocol), yang menghilangkan kontak langsung ke CA untuk pemeriksaan pencabutan dan mengurangi waktu koneksi awal. Lihat Konfigurasi pengikatan OCSP.

    Apa yang harus saya lakukan jika tidak ada sertifikat yang cocok dengan NGINX Ingress?

    Error akses HTTPS dapat terjadi jika sertifikat TLS dan kunci privatnya tidak cocok, atau jika nama domain dalam sertifikat tidak sesuai dengan hostname yang digunakan klien. Lakukan langkah-langkah berikut untuk memecahkan masalah ini:

    • Verifikasi bahwa sertifikat dan kunci privat cocok

      Ekstrak sertifikat dan kunci privat dari Secret Kubernetes dan bandingkan modulus kriptografinya:

      # Ganti <YOUR-SECRET-NAME> dan <SECRET-NAMESPACE> dengan nilai Anda
kubectl get secret <YOUR-SECRET-NAME>  -n <SECRET-NAMESPACE> -o jsonpath='{.data.tls\.crt}' | base64 -d > /tmp/tls.crt && \ # Ganti <YOUR-SECRET-NAME> dengan Secret yang Anda gunakan.
kubectl get secret <YOUR-SECRET-NAME>  -n <SECRET-NAMESPACE> -o jsonpath='{.data.tls\.key}' | base64 -d > /tmp/tls.key && \

# Hitung dan bandingkan hash MD5 modulus untuk sertifikat dan kunci
openssl x509 -noout -modulus -in /tmp/tls.crt | openssl md5 && \
openssl rsa -noout -modulus -in /tmp/tls.key | openssl md5

      Perintah ini mengekstrak sertifikat dan kunci ke /tmp/tls.crt dan /tmp/tls.key secara berturut-turut. Perintah openssl menghitung hash MD5 dari modulus publik untuk keduanya.

      Jika nilai hash tidak identik, sertifikat dan kunci privat tidak cocok. Perbarui Secret dengan pasangan kunci yang valid dan cocok.

    • Verifikasi bahwa sertifikat cocok dengan nama domain

      Periksa sertifikat dan periksa nama domain yang dicakupnya:

      kubectl get secret  <YOUR-SECRET-NAME>  -n <SECRET-NAMESPACE>  -o jsonpath={.data."tls\.crt"} | base64 -d  | openssl x509  -text -noout

      Tinjau output:

      • Subject: Cari field Common Name (CN), yang akan berformat seperti CN = example.com.

      • Subject Alternative Name (SAN): Cari entri DNS:.

      Jika hostname Anda tidak tercantum di CN atau entri SAN, sertifikat tidak valid untuk domain tersebut. Dapatkan sertifikat baru yang mencakup hostname yang benar.

    Apa yang harus saya lakukan jika pod NGINX gagal pemeriksaan kesehatan di bawah trafik tinggi?

    Latar Belakang

    Pemeriksaan kesehatan NGINX Ingress Controller mengakses path /healthz pada port 10246, memverifikasi bahwa proses NGINX dalam kondisi sehat.

    Gejala

    Saat pemeriksaan kesehatan gagal, log menunjukkan titik akhir healthz tidak dapat dijangkau:

    I0412 11:01:52.581960       7 healthz.go:261] nginx-ingress-controller check failed: healthz
[-]nginx-ingress-controller failed: the ingress controller is shutting down
2024/04/12 11:01:55 Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
W0412 11:01:55.895683       7 nginx_status.go:171] unexpected error obtaining nginx status info: Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
I0412 11:02:02.582247       7 healthz.go:261] nginx-ingress-controller check failed: healthz
[-]nginx-ingress-controller failed: the ingress controller is shutting down
2024/04/12 11:02:05 Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
W0412 11:02:05.896126       7 nginx_status.go:171] unexpected error obtaining nginx status info: Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
I0412 11:02:12.582687       7 healthz.go:261] nginx-ingress-controller check failed: healthz
[-]nginx-ingress-controller failed: the ingress controller is shutting down
2024/04/12 11:02:15 Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
W0412 11:02:15.895719       7 nginx_status.go:171] unexpected error obtaining nginx status info: Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
I0412 11:02:22.582516       7 healthz.go:261] nginx-ingress-controller check failed: healthz
[-]nginx-ingress-controller failed: the ingress controller is shutting down
2024/04/12 11:02:25 Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
W0412 11:02:25.896955       7 nginx_status.go:171] unexpected error obtaining nginx status info: Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
I0412 11:02:28.983016       7 nginx.go:408] "NGINX process has stopped"
I0412 11:02:28.983033       7 sigterm.go:44] Handled quit, delaying controller exit for 10 seconds
I0412 11:02:32.582587       7 healthz.go:261] nginx-ingress-controller check failed: healthz
[-]nginx-ingress-controller failed: the ingress controller is shutting down
2024/04/12 11:02:35 Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
W0412 11:02:35.895853       7 nginx_status.go:171] unexpected error obtaining nginx status info: Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
I0412 11:02:38.986048       7 sigterm.go:47] "Exiting" code=0

    Penyebab

    Di bawah trafik tinggi, proses worker NGINX dapat mencapai pemanfaatan CPU hampir 100%, sehingga tidak cukup sumber daya untuk merespons probe pemeriksaan kesehatan tepat waktu.

    Solusi

    Tingkatkan jumlah replika pod untuk NGINX Ingress Controller untuk mendistribusikan trafik dan mengurangi tekanan CPU per pod.

    Apa yang harus saya lakukan jika cert-manager gagal menerbitkan sertifikat?

    Hal ini terjadi ketika Web Application Firewall (WAF) diaktifkan. WAF dapat mencegat permintaan HTTP01 yang cert-manager gunakan untuk verifikasi kepemilikan domain, sehingga mencegah penerbitan sertifikat.

    Untuk mengatasinya, sementara nonaktifkan WAF agar tantangan HTTP-01 berhasil.

    Penting

    Sebelum menonaktifkan WAF Anda, Anda harus sepenuhnya menilai implikasi keamanan potensial untuk menghindari mengekspos aplikasi Anda terhadap risiko yang tidak perlu.

    Mengapa NGINX menggunakan banyak memori di bawah trafik tinggi?

    Gejala

    Di bawah trafik tinggi, penggunaan memori NGINX Ingress Controller meningkat secara signifikan, akhirnya menyebabkan event Out-of-Memory (OOM).

    Penyebab

    Jika proses controller mengonsumsi memori berlebihan, kemungkinan besar terjadi kebocoran memori dalam pengumpulan metrik Prometheus.

    Ini adalah masalah yang diketahui pada NGINX Ingress Controller versi 1.6.4, sering dikaitkan dengan metrik cardinalitas tinggi seperti nginx_ingress_controller_ingress_upstream_latency_seconds.

    Solusi

    Tingkatkan NGINX Ingress Controller ke versi terbaru, yang memperbaiki masalah ini. Saat mengonfigurasi NGINX Ingress untuk lingkungan trafik tinggi, pantau metrik yang berdampak signifikan pada penggunaan memori.

    Sumber daya komunitas:

    Apa yang harus saya lakukan jika NGINX Ingress Controller berada dalam status peningkatan macet?

    Gejala

    Selama peluncuran bertahap (peningkatan canary) NGINX Ingress Controller, proses terjebak di fase validasi. Anda mungkin melihat: Operation is forbidden for task in a failed state.

    Penyebab

    Hal ini terjadi ketika tugas peningkatan add-on dibersihkan oleh sistem setelah melebihi periode kedaluwarsa 4 hari. Setel ulang status deployment add-on secara manual untuk mengatasi hal ini.

    Catatan: Jika add-on telah mencapai fase akhir Released dari peningkatan, tidak diperlukan tindakan. Cukup tunggu hingga tugas saat ini habis waktu dan dihentikan secara otomatis.

    Prosedur

    Setel ulang Deployment dan izinkan peningkatan dilanjutkan.

    1. Buka manifes Deployment untuk diedit:

      kubectl edit deploy -n kube-system  nginx-ingress-controller

    2. Di editor, cari field berikut di bagian spec dan kembalikan ke nilai default seperti di bawah ini:

      • spec.minReadySeconds: 0

      • spec.progressDeadlineSeconds: 600

      • spec.strategy.rollingUpdate.maxSurge: 25%

      • spec.strategy.rollingUpdate.maxUnavailable: 25%

      image

    3. Simpan perubahan dan keluar dari editor.

    Hasil yang diharapkan

    Setelah disimpan, peningkatan add-on secara otomatis dilanjutkan dan pod lama diganti untuk menyelesaikan peluncuran bertahap.

    Penting

    Peningkatan selesai di latar belakang, tetapi status add-on di halaman Add-ons konsol ACK mungkin menunjukkan Upgrading hingga dua minggu sebelum diselesaikan secara otomatis.

    Mengapa encoding transfer chunked (Transfer-Encoding: chunked) berhenti berfungsi sejak versi controller 1.10?

    Gejala

    Aplikasi Anda menyetel Transfer-Encoding: chunked, dan log controller menunjukkan error terkait header duplikat.

    Penyebab

    Mulai v1.10, versi NGINX yang mendasari (lihat log pembaruan NGINX) memberlakukan validasi respons HTTP yang lebih ketat. Jika backend mengembalikan beberapa header Transfer-Encoding: chunked, NGINX kini menganggap respons tersebut tidak valid.

    Solusi

    Pastikan backend Anda hanya mengembalikan satu header Transfer-Encoding: chunked. Lihat GitHub Issue #11162.

    Bagaimana cara mengonfigurasi daftar izin/daftar larang IP untuk kontrol akses?

    NGINX Ingress mendukung kontrol akses berbasis IP menggunakan anotasi pada resource Ingress atau pasangan kunci-nilai dalam ConfigMap global.

    • ConfigMap: Berlaku global untuk semua Ingress.

    • Anotasi Ingress: Hanya berlaku untuk resource Ingress tertentu.

    Catatan

    Anotasi pada resource Ingress selalu mengambil prioritas dibandingkan pengaturan ConfigMap global.

    Gunakan anotasi berikut dalam manifes Ingress Anda:

    Anotasi

    Deskripsi

    nginx.ingress.kubernetes.io/denylist-source-range

    Daftar larang alamat IP klien atau blok CIDR. Beberapa nilai dapat diberikan, dipisahkan koma (,).

    nginx.ingress.kubernetes.io/whitelist-source-range

    Daftar izin berisi alamat IP klien atau blok CIDR. Beberapa nilai dapat diberikan, dipisahkan dengan koma (,).

    Lihat dokumentasi resmi untuk Denylist Source Range dan Whitelist Source Range.

    Masalah yang diketahui pada NGINX Ingress v1.2.1 dengan defaultBackend

    Gejala

    Mengonfigurasi defaultBackend dalam resource Ingress dapat salah menimpa pengaturan defaultBackend server default.

    Solusi

    Ini adalah masalah yang diketahui (lihat GitHub Issue #8823). Tingkatkan NGINX Ingress Controller ke versi 1.3 atau lebih baru. Lihat Tingkatkan NGINX Ingress Controller.

    Mengapa saya mendapatkan error Connection reset by peer saat menggunakan curl?

    Gejala

    Saat menggunakan curl untuk mengakses layanan publik eksternal melalui HTTP, Anda menerima error: curl: (56) Recv failure: Connection reset by peer.

    Penyebab

    Hal ini biasanya terjadi ketika permintaan HTTP teks biasa berisi kata kunci yang ditandai sensitif oleh perantara jaringan, menyebabkan koneksi diblokir atau direset.

    Solusi

    Konfigurasikan sertifikat TLS untuk rute Ingress Anda dan gunakan HTTPS untuk semua komunikasi guna memastikan trafik dienkripsi.

    Bagaimana prioritas pencocokan path bekerja?

    Path ekspresi reguler NGINX dievaluasi sesuai urutan definisinya, dan kecocokan pertama yang digunakan. Untuk mengaktifkan pencocokan path yang lebih tepat, ingress-nginx terlebih dahulu mengurutkan semua path secara menurun berdasarkan panjangnya, lalu menuliskannya sebagai blok location dalam file nginx.conf.

    Lihat Pencocokan Path Ingress.

    Mengapa permintaan non-idempoten tidak dicoba ulang?

    Mulai versi 1.9.13, NGINX tidak akan mencoba ulang permintaan non-idempoten (POST, LOCK, dan PATCH) saat terjadi error.

    Untuk mengembalikan perilaku sebelumnya, atur retry-non-idempotent: "true" dalam ConfigMap nginx-configuration.

    Bagaimana cara mendukung permintaan dengan header atau cookie klien besar?

    Gejala

    Saat mengakses layanan Anda melalui NGINX Ingress, Anda menerima error 400 Bad Request dengan pesan Request Header Or Cookie Too Large.

    Penyebab

    Error ini terjadi saat ukuran header atau cookie permintaan klien melebihi ukuran buffer default yang dikonfigurasi di Nginx.

    Solusi

    Tingkatkan ukuran buffer terkait. Dua parameter utama adalah:

    Modifikasi parameter ini dengan mengedit ConfigMap nginx-configuration:
    kubectl edit cm -n kube-system nginx-configuration

    Contoh:

    client-header-buffer-size: "16k"
large-client-header-buffers: "4 32k"

    Setelah menerapkan perubahan, verifikasi bahwa perubahan telah berlaku dalam konfigurasi NGINX. Anda dapat memeriksa file nginx.conf di dalam salah satu pod controller Ingress:
    kubectl exec <nginx-ingress-pod> -n kube-system -- cat /etc/nginx/nginx.conf

    Mengapa path Exact atau Prefix saya tetap diperlakukan sebagai ekspresi reguler?

    Jika ada aturan Ingress untuk host tertentu yang menggunakan anotasi use-regex atau rewrite-target, semua path di bawah host yang sama akan dipaksa menggunakan pencocokan ekspresi reguler case-insensitive. Ini adalah logika implementasi saat ini dari NGINX Ingress Controller. Lihat Dokumentasi komunitas.

    image.png

    Mengapa webhook validasi lambat merespons saat menambahkan Ingress di kluster dengan banyak Ingress ?

    Ini adalah masalah kinerja yang diketahui pada NGINX Ingress Controller V1.12 dan lebih lama. Webhook validasi melakukan pemeriksaan penuh terhadap semua Ingress yang ada, yang bisa lambat di lingkungan besar. Lihat #11115.

    Solusi:

    • Opsi 1: Tingkatkan timeout webhook
      Jika Anda dapat mentolerir waktu respons lebih lama dan tidak ingin menggunakan validasi inkremental, tingkatkan timeout untuk webhook validasi. Default-nya adalah 10s.

      • Tindakan: Edit objek validatingwebhookconfigurations bernama ingress-nginx-admission dan tingkatkan nilai timeoutSeconds (maksimum 30s).

      • Peringatan: Nilai ini akan ditimpa selama peningkatan add-on.

    • Opsi 2: Aktifkan validasi inkremental
      Modifikasi Deployment NGINX Ingress Controller untuk menambahkan argumen startup --disable-full-test=true.

      • Efek: Dengan flag ini, webhook hanya akan melakukan validasi inkremental pada aturan Ingress baru. Hal ini secara signifikan meningkatkan kecepatan validasi tetapi tidak akan mendeteksi konflik antara resource Ingress yang berbeda.

    Catatan tentang penggunaan snippet

    Masalah

    Jika Anda mengonfigurasi anotasi server-snippet untuk domain yang sama di beberapa resource Ingress, Anda mungkin menemui peringatan di log, dan hanya snippet pertama yang diterapkan. Hal ini dapat menyebabkan perilaku tak terduga.

    Contoh peringatan log:

    W0619 14:58:49.323721       7 controller.go:1314] Server snippet already configured for server "test.example.com", skipping (Ingress "default/test.example.com")
W0619 14:58:49.323727       7 controller.go:1314] Server snippet already configured for server "test.example.com", skipping (Ingress "default/test.example.com")
W0619 14:58:49.323734       7 controller.go:1314] Server snippet already configured for server "test.example.com", skipping (Ingress "default/test.example.com")

    Peringatan ini menunjukkan bahwa snippet untuk test.example.com telah didefinisikan, dan definisi berikutnya dari resource Ingress lainnya diabaikan.

    Mengapa sertifikat TLS yang saya konfigurasi dalam Secret tidak berfungsi?

    Periksa log controller

    Periksa log pod NGINX Ingress Controller Anda untuk error terkait sertifikat.

    kubectl -n kube-system logs <nginx-ingress-controller-pod-name> | grep "Error getting SSL certificate"

    Jika Anda melihat error serupa di bawah ini, itu menunjukkan masalah memuat Secret sertifikat Anda (di mana xxxx adalah nama Secret Anda).

    Error getting SSL certificate "xxxx": local SSL certificate xxxx tls was not found. Using default certificate

    Error ini dapat memiliki tiga penyebab utama:

    Penyebab 1: Secret tidak ada

    Verifikasi bahwa Secret yang disebutkan dalam pesan log benar-benar ada di namespace yang benar.

    Penyebab 2: Sertifikat dan kunci privat tidak cocok

    tls.crt (kunci publik) dan tls.key (kunci privat) yang disimpan dalam Secret harus merupakan pasangan yang cocok.

    • Jika Anda mencoba membuat Secret tls dengan pasangan tidak cocok menggunakan kubectl create secret tls, perintah akan gagal dengan error:
      error: tls: private key does not match public key

    • Untuk memeriksa Secret yang sudah ada terhadap ketidakcocokan, jalankan skrip berikut:

      export SECRET_NAME=<Your Secret Name>
export NAME_SPACE=<Your Secret Namespace>
diff <(kubectl get secret $SECRET_NAME -n $NAME_SPACE -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -modulus | openssl md5) <(kubectl get secret $SECRET_NAME -n $NAME_SPACE -o jsonpath='{.data.tls\.key}' | base64 -d | openssl rsa -noout -modulus | openssl md5) && echo "Certificate and Key match" || echo "Certificate and Key do not match"

      Perintah ini membandingkan modulus sertifikat dan kunci. Jika kunci dan sertifikat tidak cocok, output akan menunjukkan dua nilai hash berbeda dan pesan Certificate and Key do not match. Perbarui Secret dengan pasangan kunci yang valid.

      root@Aliyun ~/ssl # export SECRET_NAME=test
root@Aliyun ~/ssl # export NAME_SPACE=default
root@Aliyun ~/ssl # diff <(kubectl get secret $SECRET_NAME -n $NAME_SPACE -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -modulus | openssl md5) <(kubectl get secret $SECRET_NAME -n $NAME_SPACE -o jsonpath='{.data.tls\.key}' | base64 -d | openssl rsa -noout -modulus | openssl md5) && echo "Certificate and Key match" || echo "Certificate and Key do not match"
1c1
< (stdin)= 66a309089e87e32d1b6fe361ebf8cd88
---
> (stdin)= 12e15c5fe35585b6fd9920abc8e8706d
Certificate and Key do not match

    Penyebab 3: Entri TLS salah konfigurasi di Ingress lain untuk domain yang sama

    Jika Anda telah mendefinisikan bagian tls untuk domain yang sama di beberapa resource Ingress, error pada salah satu konfigurasi tersebut dapat mencegah sertifikat dimuat dengan benar. Tinjau semua resource Ingress yang mereferensikan domain tersebut dan perbaiki kesalahan konfigurasi.

    Mengapa saya masih menerima peringatan kedaluwarsa sertifikat setelah memperbarui sertifikat saya?

    Penyebab

    Versi lama memiliki bug yang diketahui di mana metrik nginx_ingress_controller_ssl_expire_time_seconds tidak diperbarui setelah perpanjangan sertifikat, menyebabkan peringatan sertifikat kedaluwarsa usang.

    Solusi

    Bersihkan metrik usang dengan melakukan restart bergulir pod NGINX Ingress Controller.

    Tingkatkan NGINX Ingress Controller ke versi 1.11.4 atau lebih baru, karena masalah ini telah diperbaiki di versi baru.

    Bagaimana saya menemukan konfigurasi default untuk versi NGINX Ingress Controller tertentu?

    Nilai default untuk parameter konfigurasi berubah antar versi NGINX Ingress Controller. Misalnya, use-gzip diaktifkan secara default di versi 0.35.0 dan lebih lama, tetapi dinonaktifkan secara default di versi 1.11.4.

    Untuk menemukan perilaku default untuk parameter tertentu di versi tertentu, konsultasikan file configmap.md di cabang versi yang sesuai dari dokumentasi resmi.

    Contoh: Untuk controller-v1.8.0, gunakan pemilih versi di sisi kiri halaman untuk beralih ke versi lain.