：Nginx Ingress FAQ

• Apa saja masalah yang diketahui di versi sebelumnya dari NGINX Ingress controller?

• Versi protokol SSL atau TLS mana yang didukung oleh Ingresses?

• Apakah Ingresses meneruskan header permintaan Lapisan 7 ke server backend secara default?

• Dapatkah ingress-nginx meneruskan permintaan ke server backend HTTPS?

• Apakah Ingresses meneruskan alamat IP klien pada Lapisan 7?

• Apakah NGINX Ingress controller mendukung HSTS?

• Aturan penulisan ulang apa yang didukung oleh ingress-nginx?

• Konfigurasikan NGINX Ingress controller yang menghadap Internet atau internal

• Apa yang diperbarui dalam sistem setelah saya memperbarui NGINX Ingress controller di halaman Add-ons dari konsol ACK?

• Bagaimana cara mengubah listener Lapisan 4 menjadi listener Lapisan 7 HTTP atau HTTPS untuk ingress-nginx?

• Bagaimana cara menentukan instance SLB yang ada untuk ack-ingress-nginx yang diterapkan dari halaman Marketplace konsol ACK?

• Bagaimana cara mengumpulkan log akses dari beberapa controller Ingress?

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

• Apa logika pencocokan sertifikat yang dikonfigurasi untuk NGINX Ingresses?

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

• Apa yang harus saya lakukan jika pod NGINX gagal dalam pemeriksaan kesehatan dalam skenario beban berat?

• Apa yang harus saya lakukan jika sertifikat gagal diterbitkan karena kesalahan cert-manager?

• Bagaimana cara menangani lonjakan penggunaan memori NGINX selama jam sibuk?

• Apa yang harus saya lakukan jika NGINX Ingress controller tetap berada dalam status Upgrading?

• Apa yang harus saya lakukan jika transfer chunked tidak berfungsi normal (Transfer-Encoding: chunked) saat saya menggunakan NGINX Ingress controller 1.10 atau lebih baru?

• Bagaimana cara mengonfigurasi daftar hitam dan daftar putih IP untuk mengontrol akses ke NGINX Ingresses?

• Apa saja masalah yang diketahui di NGINX Ingress controller V1.2.1?

• Apa yang harus saya lakukan jika terjadi kesalahan reset koneksi saat saya menggunakan curl untuk mengakses layanan eksternal melalui Internet?

• Apa logika prioritas pencocokan path?

• Mengapa permintaan non-idempoten tidak dicoba ulang?

• Bagaimana cara mengaktifkan NGINX Ingresses untuk mendukung header permintaan klien besar atau cookie?

• Setelah saya mengatur pathType ke Exact atau Prefix untuk path tertentu dalam konfigurasi Ingress, mengapa ekspresi reguler digunakan sebagai gantinya?

• Mengapa webhook validasi merespons lambat ketika saya menambahkan Ingress baru ke kluster yang sudah memiliki banyak Ingress?

• Mengapa masalah snippet terjadi?

• Mengapa sertifikat yang disimpan di Secrets tidak berlaku?

• Mengapa saya masih menerima notifikasi peringatan untuk kedaluwarsa sertifikat setelah saya memperpanjang sertifikat yang kedaluwarsa?

• Bagaimana cara melihat konfigurasi default dari versi berbeda dari NGINX Ingress controller?

Apa saja masalah yang diketahui di versi sebelumnya dari NGINX Ingress controller?

Daftar berikut memberikan referensi untuk masalah-masalah di versi sebelumnya dari NGINX Ingress controller. Untuk mencegah masalah saat Anda menggunakan NGINX Ingress controller, kami sarankan Anda memperbaruinya ke versi terbaru. Untuk informasi lebih lanjut, lihat Perbarui NGINX Ingress controller.

• Nginx ingress(v1.1.0) crash

• Worker Segmentation Fault (v0.44.0)

• Nilai parameter defaultBackend dari sebuah Ingress menimpa konfigurasi global dari NGINX Ingress controller

  Versi yang terpengaruh: 1.2.1-aliyun.1 dan sebelumnya.

  Solusi: Perbarui NGINX Ingress controller ke versi 1.5.1-aliyun.1 atau lebih baru.

• File konfigurasi sementara nginx-cfg-xx tidak dibersihkan, yang dapat menyebabkan disk penuh (Kami merekomendasikan Anda memperbarui NGINX Ingress controller ke 1.10.4 atau lebih baru)

  Versi yang terpengaruh: 1.10.2-aliyun.1 dan sebelumnya.

  Solusi: Perbarui NGINX Ingress controller ke 1.10.4-aliyun.1 atau lebih baru.

• Kegagalan unggah file besar (lebih besar dari 2 GB)

  Penyebab: Nilai dari client-body-buffer-size lebih besar dari batas penyimpanan untuk bilangan bulat 32-bit.

  Solusi: Atur client-body-buffer-size ke nilai yang lebih kecil, seperti 200M.

Versi protokol SSL atau TLS mana yang didukung oleh Ingresses?

Ingress-nginx mendukung Transport Layer Security (TLS) 1.2 dan TLS 1.3. Jika versi protokol TLS yang digunakan oleh browser atau klien seluler lebih awal dari 1.2, kesalahan mungkin terjadi selama handshake antara klien dan ingress-nginx.

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 Ingresses meneruskan header permintaan Lapisan 7 ke server backend secara default?

enable-underscores-in-headers: true

Dapatkah ingress-nginx meneruskan permintaan ke server backend HTTPS?

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"

Apakah Ingresses meneruskan alamat IP klien pada Lapisan 7?

Secara default, ingress-nginx menambahkan bidang header X-Forward-For dan X-Real-IP untuk meneruskan alamat IP klien. Namun, jika bidang header X-Forward-For dan X-Real-IP sudah ditambahkan ke permintaan oleh klien, server backend tidak dapat memperoleh alamat IP klien.

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

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

Apakah NGINX Ingress controller mendukung HSTS?

Aturan penulisan ulang apa yang didukung oleh ingress-nginx?

Apa yang diperbarui dalam sistem setelah saya memperbarui NGINX Ingress controller di halaman Add-ons dari konsol ACK?

Konfigurasi sumber daya lainnya diatur ulang ke nilai default. Sebagai contoh, nilai default parameter replicas dari sumber daya deployment.apps/nginx-ingress-controller adalah 2. Jika Anda mengatur nilai replicas menjadi 5 sebelum memperbarui NGINX Ingress controller, parameter replicas akan menggunakan nilai default 2 setelah Anda memperbarui komponen dari halaman Add-ons konsol ACK.

Bagaimana cara mengubah listener Lapisan 4 menjadi listener Lapisan 7 HTTP atau HTTPS untuk ingress-nginx?

1. Buat sertifikat dan catat ID sertifikat (cert-id). Untuk informasi lebih lanjut, lihat Gunakan sertifikat dari Layanan Manajemen Sertifikat.

2. Ubah listener SLB instance yang digunakan oleh Ingress dari Lapisan 4 menjadi Lapisan 7 dengan menggunakan anotasi.

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

   2. Di halaman Clusters, temukan kluster yang diinginkan dan klik namanya. Di panel kiri, pilih Network > Services.

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

   4. Di panel View in YAML, atur targetPort menjadi 80 untuk port 443 di bagian ports.

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

      Tambahkan konfigurasi berikut ke parameter annotations lalu klik Update.

      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 Layanan ingress-nginx-lb dan klik ikon di kolom Type.

   2. Klik tab Listener. Jika HTTP:80 dan HTTPS:443 ditampilkan di kolom Frontend Protocol/Port, listener SLB instance telah diubah dari Lapisan 4 menjadi Lapisan 7.

Bagaimana cara menentukan instance SLB yang ada untuk ack-ingress-nginx yang diterapkan dari halaman Marketplace konsol ACK?

1. Masuk ke konsol ACK. Di panel navigasi kiri, pilih Marketplace > Marketplace.

2. Di tab App Catalog, pilih ack-ingress-nginx atau ack-ingress-nginx-v1.

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

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

3. Terapkan controller Ingress. Untuk informasi lebih lanjut, lihat Terapkan beberapa controller Ingress dalam sebuah kluster.

   Di halaman wizard Parameter, hapus anotasi asli lalu tambahkan anotasi baru.

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

      

   2. Tambahkan anotasi baru.

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

      

4. Klik OK untuk menerapkan controller Ingress.

5. Setelah controller Ingress diterapkan, konfigurasikan kelas Ingress untuk controller Ingress. Untuk informasi lebih lanjut, lihat Terapkan beberapa controller Ingress dalam sebuah kluster.

Bagaimana cara mengaktifkan listener TCP untuk nginx ingress controller?

Secara default, Ingress hanya meneruskan permintaan HTTP dan HTTPS eksternal ke Layanan di kluster. Anda dapat mengonfigurasi ingress-nginx untuk mengaktifkan penerusan permintaan TCP eksternal yang diterima pada port TCP tertentu melalui ConfigMap terkait.

Apa logika pencocokan sertifikat yang dikonfigurasi untuk NGINX Ingresses?

Ingress menggunakan parameter spec.tls untuk menentukan konfigurasi TLS dan parameter spec.rules.host untuk menentukan nama domain. Controller NGINX Ingress menggunakan tabel Lua untuk menyimpan pemetaan antara nama domain dan sertifikat.

Ketika klien mengirimkan permintaan HTTPS ke NGINX, permintaan tersebut mencakup bidang Server Name Indication (SNI) yang menentukan host tujuan permintaan. NGINX Ingress menggunakan metode certificate.call() untuk memverifikasi apakah sertifikat terkait dengan nama domain. Jika sertifikat tidak ditemukan, sertifikat fake akan dikembalikan.

Contoh konfigurasi NGINX:

    ## 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 fitur OCSP (Online Certificate Status Protocol) stapling, yang digunakan untuk memeriksa status sertifikat. Dengan mengaktifkan fitur ini, klien tidak perlu memverifikasi status sertifikat langsung dengan otoritas sertifikat (CAs). Hal ini mempercepat proses validasi sertifikat serta meningkatkan kecepatan akses ke NGINX. Untuk informasi lebih lanjut, lihat Konfigurasikan OCSP stapling.

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

Masalah ini terjadi ketika sertifikat dan kunci privat yang Anda gunakan tidak cocok atau nama domain sertifikat yang Anda gunakan berbeda dari nama domain yang diakses. Lakukan operasi berikut untuk memecahkan masalah ini:

• Periksa apakah sertifikat dan kunci privat di Secret yang Anda gunakan cocok satu sama lain:

  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 && \
  openssl x509 -noout -modulus -in /tmp/tls.crt | openssl md5 && \
  openssl rsa -noout -modulus -in /tmp/tls.key | openssl md5

  Jalankan perintah di atas untuk menggunakan kubectl mengekstrak konten sertifikat dari Secret, mendekode sertifikat, dan menyimpan sertifikat ke file /tmp/tls.crt dan kunci privat ke file /tmp/tls.key. Lalu, gunakan fungsi MD5 OpenSSL untuk menghitung nilai hash dari sertifikat dan kunci privat.

  Jika nilai hash dari sertifikat berbeda dengan nilai hash dari kunci privat, sertifikat dan kunci privat tidak cocok. Kami sarankan Anda mengonfigurasi sertifikat dan kunci privat yang cocok satu sama lain.

• Periksa apakah nama domain sertifikat sama dengan nama domain yang diakses:

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

  Setelah Anda menjalankan perintah di atas, sistem akan mengembalikan detail sertifikat dalam output. Anda dapat melihat nama domain sertifikat di bidang CN dalam output, yang menunjukkan Common Name. Contoh: CN = example.com. Jika nilai bidang CN tidak mencakup nama domain yang diakses, nama domain sertifikat berbeda dengan nama domain yang diakses. Ubah nama domain sesuai kebutuhan bisnis Anda dan pastikan bahwa nama domain sertifikat sama dengan nama domain yang diakses.

Apa yang harus saya lakukan jika pod NGINX gagal dalam pemeriksaan kesehatan dalam skenario beban berat?

Pemeriksaan kesehatan dilakukan dengan mengirimkan permintaan ke path /healthz melalui port 10246 dari NGINX.

Pesan berikut dikembalikan ketika NGINX gagal dalam pemeriksaan kesehatan:

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

Dalam skenario beban berat, penggunaan CPU proses NGINX melonjak dan bahkan bisa mendekati 100%. Dalam kasus ini, NGINX gagal dalam pemeriksaan kesehatan. Untuk menyelesaikan masalah ini, kami sarankan Anda menambah jumlah pod NGINX untuk menyebarkan pod ke node yang berbeda.

Apa yang harus saya lakukan jika sertifikat gagal diterbitkan karena kesalahan cert-manager?

Masalah ini mungkin terjadi ketika Web Application Firewall (WAF) diaktifkan. WAF dapat mengganggu permintaan HTTP01, yang mengganggu penerbitan sertifikat. Untuk menyelesaikan masalah ini, kami sarankan Anda menonaktifkan WAF. Sebelum menonaktifkan WAF, evaluasi dampak setelah WAF dinonaktifkan.

Bagaimana cara menangani lonjakan penggunaan memori NGINX selama jam sibuk?

Jika NGINX mengalami lonjakan penggunaan memori dan kesalahan out of memory (OOM) selama jam sibuk, masuk ke pod NGINX dan identifikasi proses yang menggunakan memori berlebihan. Dalam banyak kasus, proses pengumpulan metrik menyebabkan kebocoran memori. Ini adalah masalah yang diketahui di NGINX Ingress controller V1.6.4. Untuk menyelesaikan masalah ini, kami sarankan Anda memperbarui NGINX Ingress controller ke versi terbaru dan merujuk ke Instal NGINX Ingress controller dalam skenario beban tinggi untuk menonaktifkan pengumpulan metrik yang secara signifikan meningkatkan penggunaan memori, seperti nginx_ingress_controller_ingress_upstream_latency_seconds. Untuk informasi lebih lanjut, lihat Uji stres controller Ingress, Kebocoran memori kolektor metrik Prometheus, dan PR Metrik.

Apa yang harus saya lakukan jika NGINX Ingress controller tetap berada dalam status Upgrading?

Saat Anda menerapkan rilis canary untuk memperbarui NGINX Ingress controller, tugas pembaruan macet di langkah verifikasi dan sistem memberi prompt Operasi dilarang untuk tugas dalam status gagal. Dalam banyak kasus, masalah ini terjadi karena durasi tugas pembaruan melebihi periode timeout, yaitu empat hari secara default. Ketika tugas pembaruan timeout, sistem secara otomatis menghentikan tugas tersebut. Untuk menyelesaikan masalah ini, Anda harus secara manual mengubah status rilis canary.

Jika tugas pembaruan berada pada langkah Release, Anda tidak perlu melakukan pembaruan. Ketika durasi tugas pembaruan melebihi empat hari, sistem secara otomatis menghentikan tugas tersebut.

Prosedur

Setelah Anda menyelesaikan modifikasi, sistem melanjutkan rilis canary untuk memperbarui NGINX Ingress controller. Namun, NGINX Ingress controller mungkin tetap berada dalam status Upgrading di halaman Add-ons di konsol ACK selama sekitar dua minggu.

1. Jalankan perintah berikut untuk memodifikasi Deployment nginx-ingress-controller:

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

2. Konfigurasikan parameter berikut:

   • spec.minReadySeconds: 0

   • spec.progressDeadlineSeconds: 600

   • spec.strategy.rollingUpdate.maxSurge: 25%

   • spec.strategy.rollingUpdate.maxUnavailable: 25%

   

3. Simpan perubahan dan keluar.

Apa yang harus saya lakukan jika transfer chunked tidak berfungsi normal (Transfer-Encoding: chunked) saat saya menggunakan NGINX Ingress controller 1.10 atau lebih baru?

Jika Anda menentukan header HTTP Transfer-Encoding: chunked dalam kode dan header Transfer-Encoding: chunked yang duplikat ada di log kontroler, masalah ini mungkin disebabkan oleh pembaruan NGINX. Untuk informasi lebih lanjut, lihat log pembaruan NGINX. NGINX 1.10 atau yang lebih baru memperkuat verifikasi terhadap respons HTTP. Akibatnya, jika beberapa header Transfer-Encoding: chunked dikembalikan dari aplikasi backend, respons tersebut dianggap tidak valid. Untuk menyelesaikan masalah ini, Anda harus mengonfigurasi aplikasi backend untuk mengembalikan hanya satu header Transfer-Encoding: chunked. Untuk informasi lebih lanjut, lihat GitHub Issue #11162.

Bagaimana cara mengonfigurasi daftar hitam dan daftar putih IP untuk mengontrol akses ke NGINX Ingresses?

Apa saja masalah yang diketahui di NGINX Ingress controller 1.2.1?

Saat Anda mengonfigurasi parameter defaultBackend dari sebuah Ingress, nilai parameter defaultBackend dari server default mungkin ditimpa. Untuk informasi lebih lanjut, lihat GitHub Issue #8823. Untuk menyelesaikan masalah ini, kami sarankan Anda memperbarui NGINX Ingress controller ke V1.3 atau lebih baru. Untuk informasi lebih lanjut tentang cara memperbarui NGINX Ingress controller, lihat Perbarui NGINX Ingress controller.

Apa yang harus saya lakukan jika kesalahan reset koneksi terjadi saat saya menggunakan curl untuk mengakses layanan publik melalui Internet?

Saat Anda menggunakan curl untuk mengakses layanan publik di luar China melalui HTTP, kesalahan curl: (56) Recv failure: Connection reset by peer mungkin dikembalikan. Dalam banyak kasus, masalah ini terjadi karena permintaan teks biasa HTTP mencakup kata-kata sensitif, yang menyebabkan permintaan diblokir atau respons direset. Anda dapat mengonfigurasi sertifikat TLS untuk aturan Ingress untuk mengenkripsi komunikasi.

Apa logika prioritas pencocokan path?

Di NGINX, ekspresi reguler mengikuti kebijakan pertama cocok. Untuk memungkinkan pencocokan path yang lebih akurat, ingress-nginx pertama-tama mengurutkan path dalam urutan panjang menurun sebelum menulis path ke konfigurasi NGINX. Untuk informasi lebih lanjut, lihat https://kubernetes.github.io/ingress-nginx/user-guide/ingress-path-matching/.

Mengapa permintaan non-idempoten tidak dicoba ulang?

Di NGINX 1.9.13 dan lebih baru, NGINX tidak mencoba ulang permintaan non-idempoten, seperti POST, LOCK, PATCH, saat kesalahan terjadi. Untuk mengembalikan perilaku sebelumnya, tentukan retry-non-idempotent=true di ConfigMap nginx-configuration.

Bagaimana cara mengaktifkan NGINX Ingresses untuk mendukung header permintaan klien besar atau cookie?

Jika NGINX Ingress menerima header permintaan klien atau cookie yang terlalu besar, kesalahan "400 Request Header Or Cookie Too Large /Bad request" mungkin dikembalikan. Untuk menyelesaikan masalah ini, Anda harus memodifikasi parameter berikut untuk meningkatkan ukuran buffer untuk membaca header permintaan klien:

• client-header-buffer-size: ukuran buffer untuk membaca header permintaan klien. Nilai default: 1k.

• large-client-header-buffers: jumlah maksimum dan ukuran buffer yang digunakan untuk membaca header permintaan klien besar. Nilai default: 4 8k.

Anda dapat menjalankan perintah kubectl edit cm -n kube-system nginx-configuration untuk memodifikasi ConfigMap nginx-configuration sesuai dengan kebutuhan bisnis Anda. Contoh:

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

Setelah Anda menyelesaikan modifikasi, pastikan konfigurasi baru berlaku pada data plane NGINX. Anda dapat menjalankan perintah kubectl exec <nginx-ingress-pod> -n kube-system -- cat /etc/nginx/nginx.conf | vim - untuk menanyakan konfigurasi dalam file nginx.conf untuk memeriksa apakah konfigurasi disinkronkan dari ConfigMap nginx-configuration.

Setelah saya mengatur pathType menjadi Exact atau Prefix untuk path tertentu dalam konfigurasi Ingress, mengapa ekspresi reguler digunakan sebagai gantinya?

Jika anotasi use-regex atau rewrite-target ditambahkan ke salah satu Ingress untuk host tertentu, ekspresi reguler case-insensitive diberlakukan pada semua path untuk host tersebut. Ini adalah logika implementasi dari NGINX Ingress controller. Untuk informasi lebih lanjut, lihat Dokumentasi Komunitas.

Mengapa webhook validasi merespons lambat ketika saya menambahkan Ingress baru ke kluster yang sudah memiliki banyak Ingress?

Ini adalah masalah kinerja yang diketahui di NGINX Ingress controller V1.12 dan sebelumnya. Untuk informasi lebih lanjut, lihat #11115.

Solusi:

1. Anggaplah kluster Anda toleran terhadap respons lambat dan tidak menerima verifikasi. Jika respons webhook saat ini telah timeout, Anda dapat meningkatkan periode timeout untuk validatingwebhookconfigurations dari ingress-nginx-admission. Periode timeout default adalah 10 detik. Periode timeout maksimum adalah 30 detik. Perhatikan bahwa nilai parameter timeout akan ditimpa saat NGINX Ingress controller diperbarui.

2. Tambahkan pengaturan --disable-full-test=true ke parameter startup Deployment yang dibuat untuk NGINX Ingress controller. Setelah Anda menambahkan pengaturan, sistem hanya melakukan verifikasi inkremental pada Ingress. Ini mempercepat kecepatan verifikasi. Namun, konflik antara aturan Ingress tidak dapat dideteksi.

Mengapa masalah snippet terjadi?

Jika Anda mengonfigurasi beberapa snippet di Ingress yang berbeda, kesalahan tipe mungkin terjadi. Akibatnya, konfigurasi mungkin tidak sesuai harapan.

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")

Mengapa sertifikat yang disimpan di Secrets tidak berlaku?

Jalankan perintah kubectl -n kube-system logs <nginx-ingress-controller-pod-name> | grep "Error getting SSL certificate" untuk melihat log pod dari NGINX Ingress controller. Jika pesan kesalahan berikut ditampilkan di log, Anda dapat melakukan langkah-langkah berikut untuk memecahkan masalah ini. xxxx mengacu pada nama Layanan.

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

Pesan kesalahan ini mungkin terjadi karena alasan berikut:

1. Layanan xxxx tidak ada.

2. Kunci publik (tls.crt) tidak cocok dengan kunci privat (tls.key). Saat Anda menjalankan perintah kubectl create secret tls untuk membuat Secret TLS di mana kunci publik (tls.crt) tidak cocok dengan kunci privat (tls.key), pesan kesalahan akan dikembalikan. Contoh:

   root@Aliyun ~/ssl # kubectl create secret tls tls-test-ingress --key example.com.key --cert httpbin.example.com.crt
   error: tls: private key does not match public key

   Untuk Secret yang sudah ada, Anda dapat menjalankan perintah berikut untuk memeriksa apakah masalah ini ada di Secret:

   export SECRET_NAME=<Nama Secret Anda>
   export NAME_SPACE=<Namespace Secret Anda>
   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 "Sertifikat dan Kunci cocok" || echo "Sertifikat dan Kunci tidak cocok"

   Jika output berikut dikembalikan, masalah ini ada di Secret:

   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 "Sertifikat dan Kunci cocok" || echo "Sertifikat dan Kunci tidak cocok"
   1c1
   < (stdin)= 66a309089e87e32d1b6fe361ebf8cd88
   ---
   > (stdin)= 12e15c5fe35585b6fd9920abc8e8706d
   Sertifikat dan Kunci tidak cocok

3. Nama domain yang sama digunakan oleh beberapa sertifikat TLS yang dikonfigurasi untuk Ingress yang berbeda. Namun, satu sertifikat TLS dikonfigurasi secara salah. Temukan sertifikat TLS dengan konfigurasi salah dan perbaiki konfigurasi tersebut.

Mengapa saya masih menerima notifikasi peringatan untuk kedaluwarsa sertifikat setelah saya memperpanjang sertifikat yang kedaluwarsa?

Bug spesifik mungkin ada di versi sebelumnya dari NGINX Ingress controller. Setelah Anda memperpanjang sertifikat, metrik metrics nginx_ingress_controller_ssl_expire_time_seconds mungkin masih ada. Untuk menyelesaikan masalah ini, Anda harus melakukan pembaruan bergulir untuk NGINX Ingress controller. Masalah ini telah diperbaiki di NGINX Ingress controller V1.11.4 dan lebih baru. Untuk informasi lebih lanjut tentang cara memperbarui NGINX Ingress controller, lihat Perbarui NGINX Ingress controller.

Bagaimana cara melihat konfigurasi default dari versi berbeda dari NGINX Ingress controller?

Banyak versi NGINX Ingress controller telah dirilis secara iteratif. Pengaturan default dari parameter mungkin bervariasi berdasarkan versi. Sebagai contoh, parameter use-gzip diaktifkan secara default di NGINX Ingress controller V0.35.0 dan sebelumnya, tetapi dinonaktifkan secara default di NGINX Ingress controller V1.11.4.

Untuk mendapatkan informasi tentang pengaturan default dari parameter dalam versi tertentu, periksa file configmap.md di cabang versi tersebut di repositori Git NGINX Ingress controller. Gambar berikut menunjukkan file configmap.d di cabang versi controller-v1.8.0. Anda dapat beralih versi di sisi kiri halaman.