：Pemecahan Masalah Nginx Ingress

Daftar Isi

Informasi latar belakang

Container Service for Kubernetes (ACK) menyediakan controller NGINX Ingress yang dioptimalkan berdasarkan versi open-source, dengan kompatibilitas penuh dan dukungan untuk semua anotasi komunitas.

Ingress hanya dapat berfungsi normal jika Anda men-deploy controller NGINX Ingress di kluster untuk mengurai aturan routing Ingress. Setelah controller NGINX Ingress menerima permintaan yang cocok dengan aturan routing, controller tersebut mengarahkan permintaan ke layanan backend yang sesuai. Layanan backend kemudian meneruskan permintaan ke pod. Di kluster Kubernetes, layanan, Ingress, dan controller NGINX Ingress bekerja dalam proses berikut:

• Layanan adalah abstraksi dari aplikasi backend yang berjalan pada sekumpulan pod replikasi.

• Ingress berisi aturan reverse proxy dan mengontrol ke pod layanan mana permintaan HTTP atau HTTPS diarahkan. Misalnya, permintaan diarahkan ke pod layanan yang berbeda berdasarkan host dan path URL dalam permintaan.

• Controller NGINX Ingress adalah program reverse proxy yang mengurai aturan Ingress. Jika terjadi perubahan pada aturan Ingress, controller NGINX Ingress memperbarui aturan tersebut secara sesuai. Setelah menerima permintaan, controller tersebut mengarahkan permintaan ke pod layanan berdasarkan aturan Ingress.

Controller NGINX Ingress memperoleh perubahan aturan Ingress dari server API dan secara dinamis menghasilkan berkas konfigurasi, seperti nginx.conf, yang diperlukan oleh load balancer seperti NGINX. Kemudian, controller NGINX Ingress memuat ulang load balancer tersebut, misalnya dengan menjalankan perintah nginx -s reload untuk memuat ulang NGINX dan menerapkan aturan Ingress baru.

Proses diagnostik

1. Ikuti langkah-langkah berikut untuk memeriksa apakah masalah disebabkan oleh Ingress dan memastikan bahwa Controller Ingress dikonfigurasi dengan benar.

   1. Di pod Controller, verifikasi bahwa akses berfungsi sebagaimana mestinya. Untuk informasi lebih lanjut, lihat Akses secara manual Ingress dan pod backend dari pod Controller.

   2. Konfirmasi bahwa Nginx Ingress Controller digunakan dengan benar. Untuk informasi lebih lanjut, lihat dokumentasi komunitas Nginx Ingress.

2. Gunakan fitur diagnostik Ingress untuk memeriksa konfigurasi Ingress dan komponen, serta terapkan perubahan yang direkomendasikan. Untuk informasi lebih lanjut tentang fitur diagnostik Ingress, lihat Gunakan fitur diagnostik Ingress.

3. Ikuti Ide pemecahan masalah untuk mengidentifikasi dan menyelesaikan masalah terkait.

4. Jika masalah masih berlanjut, lakukan pemeriksaan berikut:

   • Untuk masalah sertifikat HTTPS:

     1. Periksa apakah WAF dalam mode proxy transparan diaktifkan untuk nama domain tersebut.

        • Jika diaktifkan, konfirmasi bahwa tidak ada sertifikat TLS yang ditetapkan untuk WAF atau WAF dalam mode proxy transparan.

        • Jika tidak diaktifkan, lanjutkan ke langkah berikutnya.

     2. Periksa apakah instance SLB menggunakan pendengar Lapisan 7.

        • Jika ya, konfirmasi bahwa tidak ada sertifikat TLS yang ditetapkan untuk pendengar Lapisan 7 instance SLB.

        • Jika tidak, lanjutkan ke langkah berikutnya.

   • Untuk masalah non-sertifikat HTTPS, periksa log kesalahan di pod Controller. Untuk informasi lebih lanjut, lihat Periksa log kesalahan di pod Controller.

5. Jika masalah masih berlanjut, tangkap paket di pod Controller dan pod aplikasi backend yang sesuai untuk mengidentifikasi masalah tersebut. Untuk informasi lebih lanjut, lihat Tangkap paket.

Ide pemecahan masalah

Metode inspeksi umum

$remote_addr - [$remote_addr] - $remote_user [$time_local]
    "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_length
    $request_time [$proxy_upstream_name] $upstream_addr $upstream_response_length
    $upstream_response_time $upstream_status $req_id $host [$proxy_alternative_upstream_name]

kubectl logs <controller pod name> -n <namespace> | less

42.11.**.** - [42.11.**.**]--[25/Nov/2021:11:40:30 +0800]"GET / HTTP/1.1" 200 615 "_" "curl/7.64.1" 76 0.001 [default-nginx-svc-80] 172.16.254.208:80 615 0.000 200 46b79dkahflhakjhdhfkah**** 47.11.**.**[]
42.11.**.** - [42.11.**.**]--[25/Nov/2021:11:40:31 +0800]"GET / HTTP/1.1" 200 615 "_" "curl/7.64.1" 76 0.001 [default-nginx-svc-80] 172.16.254.208:80 615 0.000 200 fadgrerthflhakjhdhfkah**** 47.11.**.**[]

Tangkap paket

Saat Anda tidak dapat menemukan lokasi masalah, Anda perlu menangkap paket untuk diagnosis lebih lanjut.

1. Berdasarkan lokasi masalah awal, tentukan apakah masalah jaringan berada di pod Ingress atau pod aplikasi. Jika informasi tidak mencukupi, Anda dapat menangkap paket dari keduanya.

2. Masuk ke node tempat pod aplikasi bermasalah atau pod Ingress berada.

3. Di instance ECS (bukan di dalam kontainer), jalankan perintah berikut untuk menangkap informasi trafik Ingress ke berkas.

   tcpdump -i any host <application pod IP or Ingress pod IP> -C 20 -W 200 -w /tmp/ingress.pcap

4. Amati log. Saat kesalahan yang diharapkan terjadi, hentikan penangkapan paket.

5. Gunakan pesan kesalahan di log aplikasi untuk menemukan pesan yang sesuai pada waktu persis terjadinya kesalahan.

   Catatan

   • Dalam kondisi normal, penangkapan paket tidak memengaruhi aplikasi. Ini hanya sedikit meningkatkan beban CPU dan penulisan disk.

   • Perintah di atas melakukan rotasi paket yang ditangkap. Perintah tersebut dapat menulis hingga 200 berkas .pcap, masing-masing berukuran 20 MB.

Tidak dapat mengakses alamat eksternal LoadBalancer kluster dari dalam kluster

Gejala

Di kluster, beberapa pod di node tertentu tidak dapat mengakses pod backend melalui alamat eksternal (alamat IP instance SLB) Controller Nginx Ingress, sedangkan yang lain dapat.

Penyebab

Masalah ini disebabkan oleh konfigurasi externalTrafficPolicy dari layanan Controller. Konfigurasi ini menentukan cara trafik eksternal ditangani. Saat diatur ke local, hanya pod backend di node yang sama dengan pod Controller yang dapat menerima permintaan. Saat diatur ke cluster, akses berhasil. Permintaan dari sumber daya di kluster yang menggunakan alamat LoadBalancer eksternal untuk mengakses layanan juga dianggap sebagai trafik eksternal.

Solusi

• (Direkomendasikan) Akses layanan di dalam kluster Kubernetes menggunakan ClusterIP-nya atau nama layanan Ingress. Nama layanan Ingress adalah nginx-ingress-lb.kube-system.

• Jalankan perintah kubectl edit svc nginx-ingress-lb -n kube-system untuk memodifikasi layanan Ingress. Atur externalTrafficPolicy ke Cluster di layanan LoadBalancer. Jika plugin jaringan kontainer kluster adalah Flannel, alamat IP sumber klien akan hilang. Jika Anda menggunakan Terway, alamat IP sumber dapat dipertahankan.

• Contoh:

  apiVersion: v1
  kind: Service
  metadata:
    annotations:
      service.beta.kubernetes.io/backend-type: eni   # Akses ENI langsung.
    labels:
      app: nginx-ingress-lb
    name: nginx-ingress-lb
    namespace: kube-system
  spec:
    externalTrafficPolicy: Cluster

  Untuk informasi lebih lanjut tentang anotasi layanan, lihat Konfigurasi instance Classic Load Balancer (CLB) menggunakan anotasi.

Tidak dapat mengakses Controller Ingress itu sendiri

Gejala

Untuk kluster Flannel, saat Anda mengakses Ingress dari dalam pod-nya sendiri menggunakan nama domain, alamat IP SLB, atau ClusterIP, beberapa atau semua permintaan gagal.

Penyebab

Konfigurasi default Flannel tidak mengizinkan akses loopback.

Solusi

• (Direkomendasikan) Jika memungkinkan, buat ulang kluster dan gunakan plugin jaringan Terway. Migrasikan aplikasi kluster yang ada ke kluster mode Terway.

• Jika Anda tidak dapat membuat ulang kluster, Anda dapat menyelesaikan masalah ini dengan memodifikasi konfigurasi Flannel untuk mengaktifkan hairpinMode. Setelah memodifikasi konfigurasi, buat ulang pod Flannel agar perubahan berlaku.

  1. Jalankan perintah berikut untuk mengedit Flannel.

     kubectl edit cm kube-flannel-cfg -n kube-system

  2. Di cni-conf.json yang dikembalikan, tambahkan "hairpinMode": true ke bagian delegate.

     Contoh:

     cni-conf.json: |
         {
           "name": "cb0",
           "cniVersion":"0.3.1",
           "type": "flannel",
           "delegate": {
             "isDefaultGateway": true,
             "hairpinMode": true
           }
         }

  3. Jalankan perintah berikut untuk menghapus dan membuat ulang Flannel.

     kubectl delete pod -n kube-system -l app=flannel   

Sertifikat TLS ditambahkan atau dimodifikasi di kluster, tetapi sertifikat default atau lama masih digunakan untuk akses

Gejala

Setelah Anda menambahkan atau memodifikasi Secret di kluster dan menentukan secretName di Ingress, mengakses Ingress masih menggunakan sertifikat default (Kubernetes Ingress Controller Fake Certificate) atau sertifikat lama.

Penyebab

• Sertifikat tidak dikembalikan oleh Controller Ingress di dalam kluster.

• Sertifikat tidak valid dan tidak dimuat dengan benar oleh Controller.

• Controller Ingress mengembalikan sertifikat yang sesuai berdasarkan Server Name Indication (SNI), tetapi SNI mungkin tidak disertakan selama proses jabat tangan TLS.

Solution

• Gunakan salah satu metode berikut untuk mengonfirmasi apakah field SNI disertakan saat membangun koneksi TLS:

  • Gunakan versi browser yang lebih baru yang mendukung SNI.

  • Saat menggunakan perintah openssl s_client untuk menguji sertifikat, sertakan parameter -servername.

  • Saat menggunakan perintah curl, tambahkan entri hosts atau gunakan parameter --resolve untuk memetakan nama domain, alih-alih menggunakan metode alamat IP dan header permintaan Host.

• Konfirmasi bahwa tidak ada sertifikat TLS yang ditetapkan untuk WAF, WAF dalam mode proxy transparan, atau pendengar Lapisan 7 SLB. Sertifikat TLS harus dikembalikan oleh Controller Ingress di dalam kluster.

• Lakukan diagnosis Ingress di konsol ACK untuk memeriksa kesalahan konfigurasi dan log kesalahan. Untuk informasi lebih lanjut, lihat Gunakan fitur diagnostik Ingress.

• Jalankan perintah berikut untuk melihat secara manual log kesalahan pod Ingress dan terapkan perbaikan berdasarkan log tersebut.

  kubectl logs <ingress pod name> -n <pod namespace> | grep -E ^[EW]

Tidak dapat terhubung ke layanan gRPC yang diekspos oleh Ingress

Symptom

Tidak dapat mengakses layanan gRPC di belakang Ingress.

Cause

• Anotasi yang menentukan jenis protokol backend tidak ditetapkan di sumber daya Ingress.

• Layanan gRPC hanya dapat diakses melalui port TLS.

Solution

• Tetapkan anotasi di sumber daya Ingress yang sesuai: nginx.ingress.kubernetes.io/backend-protocol:"GRPC".

• Konfirmasi bahwa klien menggunakan port TLS dan mengenkripsi trafik saat mengirim permintaan.

Tidak dapat terhubung ke layanan backend HTTPS

Symptom

• Tidak dapat mengakses layanan backend HTTPS melalui Ingress.

• Tanggapan mungkin berupa kesalahan 400 dengan pesan The plain HTTP request was sent to HTTPS port.

Cause

Permintaan dari Controller Ingress ke pod backend menggunakan protokol HTTP default.

Solution

Tetapkan anotasi di sumber daya Ingress: nginx.ingress.kubernetes.io/backend-protocol:"HTTPS".

Tidak dapat mempertahankan alamat IP asal di pod Ingress

Symptom

Alamat IP asli klien tidak dapat dipertahankan di pod Ingress. Alamat tersebut muncul sebagai alamat IP node, alamat dalam rentang 100.XX.XX.XX, atau alamat lainnya.

Cause

• externalTrafficPolicy di layanan yang digunakan oleh Ingress diatur ke Cluster.

• Proxy Lapisan 7 digunakan di instance SLB.

• WAF dalam mode proxy transparan digunakan.

Solution

• Untuk kasus di mana externalTrafficPolicy diatur ke Cluster dan instance SLB Lapisan 4 digunakan di frontend.

  Anda dapat mengubah externalTrafficPolicy menjadi Local. Namun, hal ini dapat menyebabkan upaya mengakses Ingress menggunakan alamat IP SLB dari dalam kluster gagal. Untuk solusinya, lihat Tidak dapat mengakses alamat eksternal LoadBalancer kluster dari dalam kluster.

• Untuk kasus di mana proxy Lapisan 7 (SLB Lapisan 7, WAF, atau WAF dalam mode proxy transparan) digunakan, ikuti langkah-langkah berikut:

  1. Pastikan proxy Lapisan 7 digunakan dan header permintaan X-Forwarded-For diaktifkan.

  2. Di ConfigMap Controller Ingress (default adalah nginx-configuration di namespace kube-system), tambahkan enable-real-ip: "true".

  3. Amati log untuk memverifikasi apakah alamat IP sumber dapat diperoleh.

• Untuk jalur koneksi panjang dengan beberapa penerusan (misalnya, layanan reverse proxy tambahan dikonfigurasi di depan Controller Ingress), Anda dapat mengamati nilai remote_addr di log setelah mengaktifkan enable-real-ip untuk menentukan apakah alamat IP asli diteruskan ke kontainer Ingress melalui header permintaan X-Forwarded-For. Jika tidak, pastikan alamat IP asli klien dibawa menggunakan metode seperti X-Forwarded-For sebelum permintaan mencapai Controller Ingress.

Aturan rilis bertahap tidak berlaku

Symptom

Rilis bertahap diatur di kluster, tetapi aturan rilis bertahap tidak berlaku.

Cause

Ada dua kemungkinan alasan:

• Saat menggunakan anotasi terkait canary-*, nginx.ingress.kubernetes.io/canary: "true" tidak ditetapkan.

• Saat menggunakan anotasi terkait canary-* dengan versi Nginx Ingress Controller sebelum 0.47.0, Anda harus menentukan nama domain aplikasi Anda di field Host aturan Ingress. Field tersebut tidak boleh kosong.

Solution

• Berdasarkan penyebabnya, modifikasi nginx.ingress.kubernetes.io/canary: "true" atau field Host di aturan Ingress. Untuk informasi lebih lanjut, lihat Aturan routing.

• Jika situasi di atas tidak berlaku, lihat Trafik tidak didistribusikan berdasarkan aturan rilis bertahap atau trafik lainnya diarahkan ke layanan rilis bertahap.

Trafik tidak didistribusikan berdasarkan aturan rilis bertahap atau trafik lainnya diarahkan ke layanan rilis bertahap

Symptom

Aturan rilis bertahap ditetapkan, tetapi trafik tidak didistribusikan sesuai aturan, atau trafik dari Ingress normal lainnya diarahkan ke layanan rilis bertahap.

Cause

Di Controller Nginx Ingress, aturan rilis bertahap tidak diterapkan pada satu Ingress saja. Sebaliknya, aturan tersebut diterapkan pada semua Ingress yang menggunakan layanan yang sama.

Untuk informasi lebih lanjut tentang masalah ini, lihat Ingress with canary annotation will affect all ingresses with same service.

Solution

Untuk Ingress yang memerlukan rilis bertahap (termasuk yang menggunakan service-match dan anotasi terkait canary-*), buat layanan terpisah (baik layanan produksi maupun layanan rilis bertahap) yang mengarah ke pod asli. Kemudian, aktifkan rilis bertahap untuk Ingress tersebut. Untuk informasi lebih lanjut, lihat Implementasikan rilis bertahap dan penyebaran biru-hijau menggunakan Nginx Ingress.

Kesalahan "failed calling webhook" dilaporkan saat Anda membuat sumber daya Ingress

Symptom

Saat menambahkan sumber daya Ingress, pesan "Internal error occurred: failed calling webhook..." ditampilkan, seperti yang ditunjukkan pada gambar berikut.

Cause

Saat sumber daya Ingress ditambahkan, validitasnya harus diverifikasi oleh layanan (secara default, ingress-nginx-controller-admission). Jika terjadi masalah pada tautan (misalnya, layanan dihapus atau controller Ingress dihapus), verifikasi gagal, dan sumber daya Ingress tidak dapat ditambahkan.

Solution

• Periksa tautan webhook untuk memastikan semua sumber daya ada dan berfungsi dengan benar. Tautannya adalah ValidatingWebhookConfiguration -> Layanan -> Pod.

• Konfirmasi bahwa fitur admission pada pod Controller Ingress diaktifkan dan pod tersebut dapat diakses dari luar.

• Jika Controller Ingress telah dihapus atau fitur webhook tidak diperlukan, Anda dapat langsung menghapus sumber daya ValidatingWebhookConfiguration.

Kesalahan SSL_ERROR_RX_RECORD_TOO_LONG dilaporkan untuk akses HTTPS

Symptom

Saat mengakses melalui HTTPS, terjadi kesalahan SSL_ERROR_RX_RECORD_TOO_LONG atau routines:CONNECT_CR_SRVR_HELLO:wrong version number.

Cause

Permintaan HTTPS mengakses port non-HTTPS, seperti port HTTP.

Solution

Modifikasi pengaturan SLB atau pengaturan layanan sesuai kebutuhan untuk memastikan HTTPS dapat mengakses port yang benar.

Kode kesalahan HTTP umum muncul

Symptom

Permintaan mengembalikan kode status non-2xx atau non-3xx, seperti 502, 503, 413, atau 499.

Cause And Solution

Periksa log untuk menentukan apakah kesalahan dikembalikan oleh Controller Ingress. Untuk informasi lebih lanjut, lihat Lihat log akses di pod Controller menggunakan Simple Log Service (SLS). Jika demikian, lihat solusi berikut:

• 413 Error

  • Penyebab: Ukuran data permintaan melebihi batas yang dikonfigurasi.

  • Solusi: Jalankan kubectl edit cm -n kube-system nginx-configuration untuk memodifikasi konfigurasi Controller. Sesuaikan nilai nginx.ingress.kubernetes.io/client-max-body-size dan nginx.ingress.kubernetes.io/proxy-body-size sesuai kebutuhan. Nilai default adalah 20m.

• 499 Error

  • Penyebab: Klien memutus koneksi sebelum server dapat mengirim tanggapan. Hal ini belum tentu merupakan masalah pada komponen atau aplikasi backend.

  • Solusi:

    • Sejumlah kecil kesalahan 499 mungkin normal tergantung pada aplikasi dan dapat diabaikan.

    • Jika banyak kesalahan 499 terjadi, periksa apakah waktu pemrosesan aplikasi backend dan timeout permintaan frontend sesuai harapan.

• kesalahan 502

  • Penyebab: Nginx Ingress berfungsi dengan benar, tetapi pod Nginx Ingress tidak dapat terhubung ke pod backend target.

  • Solusi:

    • Kondisi pemicu:

      • Hal ini mungkin disebabkan oleh konfigurasi yang salah di layanan backend dan pod. Periksa konfigurasi port layanan backend dan kode aplikasi di kontainer.

    • Masalah intermiten

      • Hal ini mungkin disebabkan oleh beban tinggi pada pod Controller Nginx Ingress. Anda dapat menilai beban dengan memeriksa jumlah permintaan dan koneksi di instance SLB Controller dan menambahkan lebih banyak sumber daya ke Controller jika perlu. Untuk informasi lebih lanjut, lihat "Deploy a highly available Nginx Ingress Controller".

      • Hal ini mungkin karena pod backend secara aktif menutup sesi. Controller Nginx Ingress mengaktifkan koneksi persisten secara default. Pastikan bahwa timeout idle untuk koneksi persisten di backend lebih besar daripada timeout idle Controller (default adalah 900 detik).

    • Jika metode-metode ini tidak mengidentifikasi masalah, analisis paket yang ditangkap.

• 503 Error

  • Penyebab: Controller Ingress tidak dapat menemukan pod backend yang tersedia untuk meneruskan permintaan.

  • Solusi:

    • Skenario yang tidak umum

      • Lihat solusi untuk kesalahan 502.

      • Periksa status kesiapan aplikasi backend dan konfigurasikan pemeriksaan kesehatan yang wajar.

    • Jika kesalahan bersifat persisten:

      Periksa apakah layanan backend dikonfigurasi dengan benar dan apakah Endpoint ada.

Terjadi kesalahan net::ERR_HTTP2_SERVER_REFUSED_STREAM

Symptom

Saat mengakses halaman web, beberapa sumber daya gagal dimuat dengan benar, dan konsol menunjukkan kesalahan net::ERR_HTTP2_SERVER_REFUSED_STREAM atau net::ERR_FAILED.

Cause

Jumlah permintaan sumber daya paralel tinggi, mencapai batas aliran konkuren maksimum HTTP/2.

Solution

• (Direkomendasikan) Di ConfigMap, tingkatkan nilai http2-max-concurrent-streams sesuai kebutuhan. Nilai default adalah 128. Untuk informasi lebih lanjut, lihat http2-max-concurrent-streams.

• Di ConfigMap, nonaktifkan dukungan HTTP/2 dengan mengatur use-http2 ke false. Untuk informasi lebih lanjut, lihat use-http2.

Terjadi kesalahan "The param of ServerGroupName is illegal"

Cause

Format untuk menghasilkan ServerGroupName adalah namespace+svcName+port. Nama grup server harus terdiri dari 2 hingga 128 karakter, dimulai dengan huruf atau karakter Tionghoa, serta dapat berisi angka, titik (.), garis bawah (_), dan tanda hubung (-).

Solution

Ubah nama agar sesuai dengan persyaratan penamaan grup server.

Kesalahan "certificate signed by unknown authority" dilaporkan saat Anda membuat Ingress

Cause

Saat Anda membuat Ingress, terjadi kesalahan seperti yang ditunjukkan pada gambar di atas. Hal ini karena beberapa controller Ingress dideploy, dan mereka menggunakan sumber daya yang sama (yang mungkin mencakup Secrets, layanan, konfigurasi webhook, dll.). Hal ini menyebabkan sertifikat SSL yang digunakan selama eksekusi webhook tidak konsisten dengan layanan backend, sehingga terjadi kesalahan.

Solution

Deploy ulang kedua controller Ingress dan pastikan sumber daya mereka tidak tumpang tindih. Untuk informasi tentang sumber daya yang disertakan dalam Ingress, lihat Apa saja pembaruan yang dilakukan pada sistem saat saya meningkatkan komponen Nginx Ingress Controller di manajemen komponen ACK?.

Pod Ingress restart karena pemeriksaan kesehatannya gagal

Symptom

Pod Controller gagal dalam pemeriksaan kesehatan dan restart.

Cause

• Pod Ingress atau nodenya memiliki beban tinggi, menyebabkan pemeriksaan kesehatan gagal.

• Parameter kernel tcp_tw_reuse atau tcp_timestamps diatur di node kluster, yang dapat menyebabkan pemeriksaan kesehatan gagal.

Solution

• Skalakan pod Ingress dan amati apakah masalah masih berlanjut. Untuk informasi lebih lanjut, lihat Penerapan Nginx Ingress Controller dengan ketersediaan tinggi.

• Nonaktifkan tcp_tw_reuse atau atur ke 2, dan juga nonaktifkan tcp_timestamps. Kemudian, amati apakah masalah masih berlanjut.

Tambahkan layanan TCP dan UDP

1. Di ConfigMap yang sesuai (secara default, tcp-services dan udp-services di namespace kube-system), tambahkan entri yang sesuai.

   Misalnya, untuk memetakan port 8080 example-go di namespace default ke port 9000, lihat contoh berikut.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: tcp-services
     namespace: ingress-nginx
   data:
     9000: "default/example-go:8080"  # Petakan port 8080 ke port 9000.

2. Di deployment Ingress (secara default, nginx-ingress-controller di namespace kube-system), tambahkan port yang dipetakan.

3. Di layanan yang sesuai dengan Ingress, tambahkan port yang dipetakan.

   Klik untuk melihat contoh kode

   apiVersion: v1
   kind: Service
   metadata:
     name: ingress-nginx
     namespace: ingress-nginx
     labels:
       app.kubernetes.io/name: ingress-nginx
       app.kubernetes.io/part-of: ingress-nginx
   spec:
     type: LoadBalancer
     ports:
       - name: http
         port: 80
         targetPort: 80
         protocol: TCP
       - name: https
         port: 443
         targetPort: 443
         protocol: TCP
       - name: proxied-tcp-9000
         port: 9000
         targetPort: 9000
         protocol: TCP
     selector:
       app.kubernetes.io/name: ingress-nginx
       app.kubernetes.io/part-of: ingress-nginx

   Untuk informasi lebih lanjut tentang menambahkan layanan TCP dan UDP, lihat Exposing TCP and UDP services.

Aturan Ingress tidak berlaku

Symptom

Aturan Ingress ditambahkan atau dimodifikasi tetapi tidak berlaku.

Cause

• Kesalahan dalam konfigurasi Ingress mencegah aturan Ingress baru dimuat dengan benar.

• Sumber daya Ingress dikonfigurasi salah dan tidak sesuai dengan konfigurasi yang diharapkan.

• Ada masalah izin pada Controller Ingress, sehingga tidak dapat memantau perubahan sumber daya Ingress dengan benar.

• Ingress lama menggunakan konfigurasi server-alias untuk nama domain yang bertentangan dengan Ingress baru, menyebabkan aturan diabaikan.

Beberapa sumber daya gagal dimuat atau layar kosong muncul setelah menulis ulang ke direktori root

Symptom

Setelah menulis ulang akses menggunakan anotasi Ingress rewrite-target, beberapa sumber daya halaman gagal dimuat, atau layar kosong muncul.

Cause

• rewrite-target mungkin tidak dikonfigurasi dengan ekspresi reguler.

• Path permintaan sumber daya di aplikasi dikodekan secara keras ke direktori root.

Solution

• Periksa apakah rewrite-target digunakan dengan ekspresi reguler dan grup penangkapan. Untuk informasi lebih lanjut, lihat Rewrite.

• Periksa apakah permintaan frontend mengakses path yang benar.

Cara memperbaiki penguraian log yang tidak normal di SLS setelah peningkatan

Symptom

Komponen ingress-nginx-controller saat ini memiliki dua versi utama: 0.20 dan 0.30. Setelah meningkatkan dari versi 0.20 ke 0.30 melalui halaman Components di konsol, Dasbor Ingress mungkin tidak menampilkan status akses layanan backend yang sebenarnya dengan benar saat menggunakan fitur rilis bertahap atau penyebaran biru-hijau Ingress.

Cause

Karena format output default versi 0.20 dan 0.30 berbeda, Dasbor Ingress mungkin tidak menampilkan status akses layanan backend yang sebenarnya dengan benar saat menggunakan fitur rilis bertahap atau penyebaran biru-hijau Ingress.

Solution

Lakukan langkah-langkah berikut untuk memperbaiki masalah dengan memperbarui konfigurasi nginx-configuration configmap dan k8s-nginx-ingress.

1. Perbarui nginx-configuration configmap.

   • Jika Anda belum memodifikasi nginx-configuration configmap, simpan konten berikut sebagai nginx-configuration.yaml lalu jalankan perintah kubectl apply -f nginx-configuration.yaml untuk menerapkannya.

     apiVersion: v1
     kind: ConfigMap
     data:
       allow-backend-server-header: "true"
       enable-underscores-in-headers: "true"
       generate-request-id: "true"
       ignore-invalid-headers: "true"
       log-format-upstream: $remote_addr - [$remote_addr] - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_length $request_time [$proxy_upstream_name] $upstream_addr $upstream_response_length $upstream_response_time $upstream_status $req_id $host [$proxy_alternative_upstream_name]
       max-worker-connections: "65536"
       proxy-body-size: 20m
       proxy-connect-timeout: "10"
       reuse-port: "true"
       server-tokens: "false"
       ssl-redirect: "false"
       upstream-keepalive-timeout: "900"
       worker-cpu-affinity: auto
     metadata:
       labels:
         app: ingress-nginx
       name: nginx-configuration
       namespace: kube-system

   • Jika Anda telah memodifikasi nginx-configuration configmap, jalankan perintah berikut untuk memperbaikinya agar tidak menimpa konfigurasi Anda:

     kubectl edit configmap nginx-configuration -n kube-system

   Di akhir field log-format-upstream, tambahkan [$proxy_alternative_upstream_name], lalu simpan dan keluar.

2. Perbarui konfigurasi k8s-nginx-ingress.

   Simpan konten berikut sebagai berkas k8s-nginx-ingress.yaml, lalu jalankan perintah kubectl apply -f k8s-nginx-ingress.yaml untuk menerapkannya.

   Klik untuk melihat konten YAML

   apiVersion: log.alibabacloud.com/v1alpha1
   kind: AliyunLogConfig
   metadata:
     namespace: kube-system
     # your config name, must be unique in you k8s cluster
     name: k8s-nginx-ingress
   spec:
     # logstore name to upload log
     logstore: nginx-ingress
     # product code, only for k8s nginx ingress
     productCode: k8s-nginx-ingress
     # logtail config detail
     logtailConfig:
       inputType: plugin
       # logtail config name, should be same with [metadata.name]
       configName: k8s-nginx-ingress
       inputDetail:
         plugin:
           inputs:
           - type: service_docker_stdout
             detail:
               IncludeLabel:
                 io.kubernetes.container.name: nginx-ingress-controller
               Stderr: false
               Stdout: true
           processors:
           - type: processor_regex
             detail:
               KeepSource: false
               Keys:
               - client_ip
               - x_forward_for
               - remote_user
               - time
               - method
               - url
               - version
               - status
               - body_bytes_sent
               - http_referer
               - http_user_agent
               - request_length
               - request_time
               - proxy_upstream_name
               - upstream_addr
               - upstream_response_length
               - upstream_response_time
               - upstream_status
               - req_id
               - host
               - proxy_alternative_upstream_name
               NoKeyError: true
               NoMatchError: true
               Regex: ^(\S+)\s-\s\[([^]]+)]\s-\s(\S+)\s\[(\S+)\s\S+\s"(\w+)\s(\S+)\s([^"]+)"\s(\d+)\s(\d+)\s"([^"]*)"\s"([^"]*)"\s(\S+)\s(\S+)+\s\[([^]]*)]\s(\S+)\s(\S+)\s(\S+)\s(\S+)\s(\S+)\s*(\S*)\s*\[*([^]]*)\]*.*
               SourceKey: content

Terjadi kesalahan "cannot list/get/update resource"

Gejala

Anda dapat menemukan log kesalahan Controller di pod menggunakan metode yang dijelaskan di Periksa log kesalahan di pod Controller. Log tersebut mirip dengan berikut:

User "system:serviceaccount:kube-system:ingress-nginx" cannot list/get/update resource "xxx" in API group "xxx" at the cluster scope/ in the namespace "kube-system"

Penyebab

Controller Nginx Ingress tidak memiliki izin yang diperlukan untuk memperbarui sumber daya terkait.

Solusi

• Berdasarkan log, tentukan apakah masalah disebabkan oleh ClusterRole atau Role.

  • Jika log berisi at the cluster scope, masalahnya ada pada ClusterRole (ingress-nginx).

  • Jika log berisi in the namespace "kube-system", masalahnya ada pada Role (kube-system/ingress-nginx).

• Konfirmasi bahwa izin dan pengikatan izin yang sesuai lengkap.

  • Untuk ClusterRole:

    • Pastikan ClusterRole ingress-nginx dan ClusterRoleBinding ingress-nginx ada. Jika tidak ada, Anda dapat membuatnya, memulihkannya, atau menguninstall dan menginstal ulang komponen tersebut.

    • Pastikan ClusterRole ingress-nginx mencakup izin yang sesuai dengan log (dalam contoh, izin List untuk networking.k8s.io/ingresses). Jika izin tersebut tidak ada, Anda dapat menambahkannya secara manual ke ClusterRole.

  • Untuk Role:

    • Konfirmasi bahwa Role kube-system/ingress-nginx dan RoleBinding kube-system/ingress-nginx ada. Jika tidak ada, Anda dapat membuatnya, memulihkannya, atau menguninstall dan menginstal ulang komponen tersebut.

    • Konfirmasi bahwa Role ingress-nginx mencakup izin yang sesuai dengan log (dalam contoh, izin Update untuk ConfigMap ingress-controller-leader-nginx). Jika izin tersebut tidak ada, Anda dapat menambahkannya secara manual ke Role.

Terjadi kesalahan "berkas konfigurasi gagal"

Gejala

Anda dapat menemukan log kesalahan Controller di pod menggunakan metode yang dijelaskan di Periksa log kesalahan di pod Controller. Log tersebut mirip dengan berikut:

requeuing……nginx: configuration file xxx test failed (multiple lines)

Penyebab

Kesalahan konfigurasi menyebabkan pemuatan ulang konfigurasi Nginx gagal. Hal ini biasanya disebabkan oleh kesalahan sintaksis dalam cuplikan yang dimasukkan ke aturan Ingress atau ConfigMap.

Solusi

• Periksa pesan kesalahan di log (pesan level peringatan dapat diabaikan) untuk menentukan lokasi masalah secara kasar. Jika pesan kesalahan tidak jelas, Anda dapat menggunakan nomor baris berkas dari pesan kesalahan untuk melihat berkas yang sesuai di pod. Dalam contoh berikut, berkasnya adalah /tmp/nginx/nginx-cfg2825306115 dan barisnya adalah 449.

  Jalankan perintah berikut untuk memeriksa kesalahan di konfigurasi di sekitar baris yang sesuai.

  # Jalankan perintah di pod.
  kubectl exec -n <namespace> <controller pod name> -it -- bash
  # Lihat berkas kesalahan dengan nomor baris dan periksa kesalahan di konfigurasi di sekitar baris yang sesuai.
  cat -n /tmp/nginx/nginx-cfg2825306115

• Berdasarkan pesan kesalahan dan berkas konfigurasi, tentukan penyebab kesalahan dan perbaiki sesuai konfigurasi aktual Anda.

Terjadi kesalahan "Unexpected error validating SSL certificate"

Gejala

Anda dapat menemukan log kesalahan Controller di pod menggunakan metode yang dijelaskan di Periksa log kesalahan di pod Controller. Log tersebut mirip dengan berikut:

Unexpected error validating SSL certificate "xxx" for server "xxx"

Penyebab

Sertifikat dikonfigurasi salah. Alasan umum adalah nama domain yang disertakan dalam sertifikat tidak cocok dengan nama domain yang dikonfigurasi di Ingress. Beberapa log level Peringatan, seperti sertifikat yang tidak memiliki ekstensi SAN, tidak memengaruhi penggunaan sertifikat secara normal. Tentukan apakah ada masalah berdasarkan situasi aktual.

Solusi

Periksa masalah sertifikat di kluster berdasarkan pesan kesalahan.

• Apakah format dan isi sertifikat cert dan key benar?

• Apakah nama domain yang disertakan dalam sertifikat cocok dengan nama domain yang dikonfigurasi di Ingress?

• Apakah sertifikat telah kedaluwarsa?

Banyak berkas konfigurasi tidak dibersihkan dari Controller

Pemecahan masalah ketika pod tetap dalam status Pending setelah peningkatan Controller

kubectl -n kube-system describe pod <pending-pod-name>

kubectl -n kube-system get events

Terjadi kebingungan aliran TCP ketika beberapa instance CLB digunakan untuk Nginx Ingress di kluster Flannel CNI dan IPVS dengan konkurensi tinggi