Container Service for Kubernetes：FAQ Ingress NGINX

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

Versi lama memiliki masalah yang diketahui berikut. Kami merekomendasikan melakukan peningkatan ke versi terbaru untuk memastikan stabilitas.

• Ingress NGINX (v1.1.0) kadang-kadang crash

• Segmentation fault worker (v0.44.0)

• Nilai parameter defaultBackend suatu Ingress menimpa konfigurasi global Controller Ingress NGINX

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

  Solusi: Tingkatkan Controller Ingress NGINX ke versi 1.5.1-aliyun.1 atau yang lebih baru.

• File konfigurasi sementara nginx-cfg-xx tidak dibersihkan, yang dapat menyebabkan disk penuh

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

  Solusi: Tingkatkan Controller Ingress NGINX ke versi 1.10.4-aliyun.1 atau yang lebih baru.

• Kegagalan unggah file berukuran lebih dari 2 GB

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

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

Versi TLS apa saja yang didukung?

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

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?

enable-underscores-in-headers: true

Bagaimana cara 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"

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.

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"  

Bagaimana cara mengonfigurasi HSTS?

Aturan penulisan ulang apa saja yang didukung?

Resource apa saja yang diperbarui saat melakukan peningkatan Controller Ingress NGINX?

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

Bagaimana cara beralih dari listener Lapisan 4 ke Lapisan 7?

1. Buat sertifikat dan catat ID sertifikatnya (cert-id). Untuk informasi selengkapnya, 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. Pada halaman Clusters, temukan kluster yang diinginkan dan klik namanya. Di panel navigasi kiri, pilih 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 # Setel 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 di kolom Type.

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

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

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 berdasarkan versi kluster Anda:

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

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

3. Terapkan controller Ingress. Untuk instruksi, lihat Terapkan beberapa controller Ingress untuk isolasi trafik.

   Di halaman wizard Parameters:

   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.
      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 untuknya. Untuk instruksi, lihat Terapkan beberapa controller Ingress untuk isolasi trafik.

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

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

Bagaimana cara Controller Ingress NGINX mencocokkan sertifikat TLS dengan permintaan?

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

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

Alur Permintaan

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

2. Controller Ingress NGINX 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 yang ditandatangani sendiri 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), sebuah fitur yang meningkatkan kinerja validasi status sertifikat. Dengan fitur ini diaktifkan, klien tidak perlu lagi menghubungi Certificate Authority (CA) secara langsung untuk memeriksa status pencabutan sertifikat. Hal ini mengurangi waktu validasi sertifikat dan meningkatkan kecepatan koneksi awal secara keseluruhan. Untuk informasi selengkapnya, lihat Konfigurasikan OCSP stapling.

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

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 oleh klien. Lakukan operasi berikut untuk troubleshooting masalah ini:

• Verifikasi bahwa sertifikat dan kunci privat cocok

  Jalankan perintah berikut untuk mengekstrak sertifikat dan kunci privat dari Secret Kubernetes dan membandingkan 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 di atas mengekstrak dan mendekode sertifikat serta kunci, menyimpannya ke /tmp/tls.crt dan /tmp/tls.key masing-masing. Perintah openssl kemudian menghitung hash MD5 dari modulus publik untuk kedua file tersebut.

  Jika dua nilai hash yang dihasilkan tidak identik, artinya sertifikat dan kunci privat tidak cocok. Untuk memperbaikinya, Anda harus memperbarui Secret dengan pasangan kunci yang valid dan cocok.

• Verifikasi bahwa sertifikat cocok dengan nama domain

  Jalankan perintah berikut untuk memeriksa isi sertifikat dan memeriksa 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 dari perintah dan periksa:

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

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

  Jika hostname yang Anda gunakan untuk mengakses layanan tidak tercantum di field CN atau entri SAN, artinya sertifikat tersebut tidak valid untuk domain tersebut. Untuk mengatasinya, Anda harus memperoleh dan mengonfigurasi 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 untuk Controller Ingress NGINX bekerja dengan mengakses path /healthz, yang diekspos oleh proses NGINX pada port 10246. Pemeriksaan ini memverifikasi bahwa proses NGINX sehat dan layanan berjalan dengan benar.

Gejala

Saat pemeriksaan kesehatan gagal, Anda akan melihat entri log seperti berikut, yang menunjukkan bahwa endpoint 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 menjadi kelebihan beban, menyebabkan penggunaan CPU sangat tinggi (kadang-kadang mendekati 100%). Saat sistem berada di bawah tekanan sebesar ini, sistem mungkin tidak memiliki cukup sumber daya untuk merespons probe pemeriksaan kesehatan secara tepat waktu, sehingga menyebabkan kegagalan.

Solusi

Solusi yang direkomendasikan adalah meningkatkan jumlah replika pod untuk Controller Ingress NGINX. Hal ini akan mendistribusikan beban trafik ke beberapa pod, mengurangi tekanan CPU pada setiap instance dan memungkinkan pemeriksaan kesehatan berhasil.

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

Masalah ini dapat terjadi saat Web Application Firewall (WAF) diaktifkan. WAF dapat mencegat atau memblokir permintaan HTTP01 yang digunakan cert-manager untuk memverifikasi kepemilikan domain, yang mencegah proses penerbitan sertifikat selesai dengan sukses.

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

Mengapa NGINX menggunakan banyak memori di bawah trafik tinggi?

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

Gejala

Saat melakukan peluncuran bertahap (peningkatan canary) Controller Ingress NGINX, prosesnya macet di fase validasi dan Anda tidak dapat melanjutkan. Anda mungkin melihat pesan error seperti: Operation is forbidden for task in a failed state.

Penyebab

Masalah ini biasanya terjadi ketika tugas peningkatan add-on secara otomatis dibersihkan oleh sistem karena telah melebihi periode kedaluwarsa 4 hari yang telah ditentukan. Saat hal ini terjadi, Anda harus mengatur ulang status deployment add-on secara manual untuk menyelesaikan masalah.

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

Prosedur

Ikuti langkah-langkah berikut untuk mengatur ulang Deployment dan memungkinkan peningkatan dilanjutkan.

1. Jalankan perintah berikut untuk membuka manifes Deployment untuk diedit:

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

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

   • spec.minReadySeconds: 0

   • spec.progressDeadlineSeconds: 600

   • spec.strategy.rollingUpdate.maxSurge: 25%

   • spec.strategy.rollingUpdate.maxUnavailable: 25%

   

3. Simpan perubahan dan keluar dari editor.

Hasil yang diharapkan

Setelah Anda menyimpan perubahan, peningkatan add-on akan dilanjutkan secara otomatis, dan pod lama akan diganti untuk menyelesaikan peluncuran bertahap.

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

Gejala

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

Penyebab

Hal ini terkait dengan pembaruan versi NGINX yang mendasari yang digunakan oleh controller mulai dari v1.10 (lihat log pembaruan NGINX). Versi NGINX yang lebih baru menerapkan validasi yang lebih ketat terhadap respons HTTP. Jika layanan backend mengembalikan beberapa header Transfer-Encoding: chunked, NGINX sekarang menganggap respons tersebut tidak valid.

Solusi

Pastikan layanan backend Anda hanya mengembalikan satu header Transfer-Encoding: chunked. Untuk detail selengkapnya, lihat GitHub Issue #11162.

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

Masalah yang diketahui pada Ingress NGINX v1.2.1 dengan defaultBackend

Gejala

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

Solusi

Ini adalah masalah yang diketahui (lihat GitHub Issue #8823). Untuk mengatasinya, kami merekomendasikan menaikkan versi Controller Ingress NGINX ke versi 1.3 atau yang lebih baru. Untuk instruksi, lihat Tingkatkan Controller Ingress NGINX.

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 sebagai 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 cara kerja prioritas pencocokan path?

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

Untuk penjelasan mendetail, lihat dokumentasi resmi Ingress Path Matching.

Mengapa permintaan non-idempoten tidak dicoba ulang?

Mulai dari 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" di ConfigMap nginx-configuration.

Bagaimana cara mendukung permintaan dengan header atau cookie klien yang besar?

Gejala

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

Penyebab

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

Solusi

Tingkatkan ukuran buffer terkait. Dua parameter utama adalah:

• client-header-buffer-size: Ukuran buffer untuk header permintaan klien. Default-nya adalah 1k.

• large-client-header-buffers: Jumlah maksimum dan ukuran buffer untuk membaca header permintaan klien yang besar. Default-nya adalah 4 8k.

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

Contoh:

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

Setelah menerapkan perubahan, verifikasi bahwa perubahan tersebut telah berlaku di 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 masih diperlakukan sebagai ekspresi reguler?

Jika salah satu aturan Ingress untuk host tertentu 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 Controller Ingress NGINX. Untuk informasi selengkapnya, lihat Dokumentasi komunitas.

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

Ini adalah masalah kinerja yang diketahui pada Controller Ingress NGINX V1.12 dan sebelumnya. 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 yang 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
  Ubah Deployment Controller Ingress NGINX 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 yang tidak 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 konfigurasikan di Secret tidak berfungsi?

Periksa log controller

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

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

Jika Anda melihat error seperti di bawah, hal ini 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 di Secret harus merupakan pasangan yang cocok.

• Jika Anda mencoba membuat Secret tls dengan pasangan yang tidak cocok menggunakan kubectl create secret tls, perintah tersebut 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 yang berbeda dan pesan Certificate and Key do not match. Anda harus memperbarui 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 yang salah dikonfigurasi 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 konfigurasi yang salah.

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

Penyebab

Versi lama Controller Ingress NGINX memiliki bug yang diketahui di mana metrik nginx_ingress_controller_ssl_expire_time_seconds tidak diperbarui atau dibersihkan dengan benar setelah sertifikat diperbarui. Hal ini dapat menyebabkan sistem pemantauan terus memicu peringatan certificate expired berdasarkan data lama.

Solusi

Untuk membersihkan metrik lama, Anda harus melakukan restart bergulir pod Controller Ingress NGINX.

Kami sangat merekomendasikan meningkatkan Controller Ingress NGINX ke versi 1.11.4 atau yang lebih baru, karena masalah ini telah diselesaikan di versi yang lebih baru.

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

Nilai default untuk parameter konfigurasi berubah antar versi Controller Ingress NGINX. Misalnya, use-gzip diaktifkan secara default di versi 0.35.0 dan sebelumnya, 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.