Container Service for Kubernetes:Troubleshoot masalah NGINX Ingress

Daftar isi

Informasi latar belakang

Komunitas Kubernetes memelihara Ingress NGINX Controller resmi. NGINX Ingress Controller di ACK menggunakan versi komunitas dan mendukung semua annotations komunitas.

Deploy NGINX Ingress Controller di kluster untuk mengurai aturan pengalihan Ingress. Controller menerima permintaan, mencocokkannya dengan aturan, dan meneruskannya ke pod Service backend. Hubungan antara Service, NGINX Ingress, dan NGINX Ingress Controller:

• Service mengabstraksi satu atau lebih layanan backend identik.

• NGINX Ingress mendefinisikan aturan reverse proxy yang mengarahkan permintaan HTTP/HTTPS ke pod Service berdasarkan host dan path URL.

• NGINX Ingress Controller mengurai aturan NGINX Ingress. Ketika Ingress berubah, controller memperbarui aturan pengalihannya dan mengarahkan permintaan masuk ke pod Service yang sesuai.

NGINX Ingress Controller mengambil perubahan Ingress dari API Server, menghasilkan file konfigurasi load balancer (seperti nginx.conf), dan memuat ulang load balancer (misalnya, nginx -s reload) untuk menerapkan aturan routing baru.

Alur troubleshooting

1. Ikuti langkah-langkah berikut untuk mengisolasi masalah ke Ingress dan memverifikasi konfigurasi ingress controller Anda.

   1. Di Pod controller, pastikan akses berfungsi sebagaimana mestinya. Untuk informasi selengkapnya, lihat Akses secara manual Ingress dan Pod backend di Pod controller.

   2. Verifikasi bahwa Anda menggunakan NGINX Ingress Controller dengan benar. Untuk informasi selengkapnya, lihat dokumentasi komunitas NGINX Ingress Controller.

2. Gunakan fitur diagnostik Ingress untuk memeriksa konfigurasi Ingress dan komponennya, lalu terapkan perubahan yang direkomendasikan. Untuk petunjuk detail, lihat Gunakan fitur diagnostik Ingress.

3. Ikuti panduan troubleshooting untuk mendiagnosis dan menyelesaikan masalah.

4. Jika langkah-langkah sebelumnya tidak menyelesaikan masalah, lakukan pemeriksaan berikut:

   • Untuk masalah sertifikat TLS:

     1. Periksa apakah integrasi WAF atau WAF transparan diaktifkan untuk nama domain tersebut.

        • Jika ya, pastikan tidak ada sertifikat TLS yang dikonfigurasi untuk WAF atau integrasi WAF transparan.

        • Jika tidak, lanjutkan ke langkah berikutnya.

     2. Periksa apakah SLB menggunakan listener layer-7.

        • Jika iya, pastikan tidak ada sertifikat TLS yang dikonfigurasi untuk listener layer-7 tersebut.

        • Jika tidak, lanjutkan ke langkah berikutnya.

   • Untuk masalah yang tidak terkait sertifikat TLS, periksa log error di Pod controller. Untuk informasi selengkapnya, lihat Periksa log error di Pod controller.

5. Jika masalah tetap berlanjut, lakukan pengambilan paket pada Pod controller dan Pod aplikasi yang sesuai untuk mengidentifikasi akar penyebabnya. Untuk informasi selengkapnya, lihat Pengambilan paket.

Troubleshooting

Metode troubleshooting 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.**.**[]

Pengambilan paket

Jika Anda tidak dapat menentukan penyebab masalah, lakukan pengambilan paket.

1. Berdasarkan temuan awal Anda, tentukan apakah masalah jaringan berada di pod Ingress atau pod aplikasi. Jika informasi Anda tidak cukup, Anda dapat mengambil paket di kedua pod.

2. Masuk ke node yang menjalankan pod aplikasi atau pod Ingress yang terpengaruh.

3. Di instance ECS (bukan di dalam kontainer), jalankan perintah berikut untuk mengambil traffic yang terkait dengan pod tertentu dan simpan ke file:

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

4. Pantau log. Saat error yang diharapkan terjadi, hentikan pengambilan paket.

5. Korelasikan informasi paket yang diambil dengan log error aplikasi untuk mengidentifikasi masalah.

   Catatan

   • Dalam kondisi normal, pengambilan paket tidak memengaruhi layanan Anda. Ini hanya menambahkan beban CPU dan I/O disk yang kecil.

   • Perintah di atas melakukan rotasi file tangkapan. Ini dapat menghasilkan maksimal 200 file .pcap, masing-masing berukuran 20 MB.

Akses intra-kluster ke alamat load balancer eksternal gagal

Gejala

Di kluster, pod di beberapa node tidak dapat mengakses pod backend melalui alamat eksternal NGINX Ingress Controller (alamat IP instance load balancer), sedangkan pod di node lain dapat.

Penyebab

Masalah ini disebabkan oleh pengaturan externalTrafficPolicy dari service controller, yang menentukan cara traffic eksternal ditangani. Saat diatur ke Local, hanya pod backend di node yang sama dengan pod controller yang dapat menerima permintaan. Saat diatur ke Cluster, semua pod backend dapat diakses secara normal. Saat resource di dalam kluster menggunakan alamat eksternal service load balancer, permintaan tersebut juga dianggap sebagai traffic eksternal.

Solusi

• (Direkomendasikan) Akses layanan dari dalam kluster Kubernetes menggunakan ClusterIP atau nama layanannya. Nama layanan untuk ingress adalah nginx-ingress-lb.kube-system.

• Jalankan perintah kubectl edit svc nginx-ingress-lb -n kube-system untuk mengedit service ingress. Ubah externalTrafficPolicy dari service load balancer menjadi Cluster. Jika plugin jaringan kluster Anda adalah Flannel, IP sumber klien akan hilang. Jika Anda menggunakan Terway, IP sumber klien dipertahankan.

• Contoh:

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

  Untuk informasi selengkapnya tentang anotasi service, lihat Konfigurasikan Classic Load Balancer (CLB) menggunakan anotasi.

Tidak dapat mengakses ingress controller

Gejala

Di kluster Flannel, saat Anda mengakses Ingress dari pod Ingress melalui nama domainnya, IP SLB, atau ClusterIP, beberapa atau semua permintaan gagal.

Penyebab

Konfigurasi Flannel default menonaktifkan hairpinning.

Solusi

• (Direkomendasikan) Buat ulang kluster dengan plugin jaringan Terway dan migrasikan workload Anda ke kluster baru.

• Jika Anda tidak dapat membuat ulang kluster, ubah konfigurasi Flannel untuk mengaktifkan hairpinMode. Setelah mengubah konfigurasi, buat ulang pod Flannel untuk menerapkan perubahan.

  1. Jalankan perintah berikut untuk mengedit konfigurasi Flannel:

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

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

     Contoh:

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

  3. Jalankan perintah berikut untuk menghapus pod Flannel. Sistem secara otomatis membuat ulang pod tersebut dengan konfigurasi baru.

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

Sertifikat TLS default atau lama tetap digunakan

Gejala

Setelah Anda menambahkan atau memodifikasi Secret di kluster dan menentukan secretName di Ingress, permintaan tetap dilayani dengan sertifikat default (Kubernetes Ingress Controller Fake Certificate) atau sertifikat lama.

Penyebab

• Sertifikat tidak dikembalikan oleh ingress controller di kluster.

• Controller tidak memuat sertifikat dengan benar karena sertifikat tersebut tidak valid.

• Controller ingress menggunakan Server Name Indication (SNI) untuk menyajikan sertifikat yang benar, tetapi proses jabat tangan TLS mungkin tidak menyertakan ekstensi SNI.

Solusi

• Verifikasi bahwa proses jabat tangan TLS menyertakan ekstensi SNI dengan menggunakan salah satu metode berikut:

  • Gunakan browser modern yang mendukung SNI.

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

  • Saat menggunakan curl, petakan nama domain dengan parameter --resolve atau dengan mengedit file hosts Anda, daripada mengirim permintaan ke alamat IP dengan header Host.

• Pastikan tidak ada sertifikat TLS yang dikonfigurasi di WAF, akses transparan WAF, atau listener layer-7 SLB. Sertifikat TLS harus dikembalikan oleh ingress controller di kluster.

• Jalankan diagnostik Ingress di konsol Intelligent Operations untuk memeriksa masalah konfigurasi dan log error. Untuk informasi selengkapnya, lihat Gunakan diagnostik Ingress.

• Jalankan perintah berikut untuk memeriksa secara manual log error Pod Ingress dan lakukan perubahan berdasarkan saran di log.

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

Tidak dapat terhubung ke gRPC melalui Ingress

Gejala

Anda tidak dapat mengakses layanan gRPC melalui Ingress.

Penyebab

• Resource Ingress tidak memiliki Annotation untuk protokol backend.

• Layanan gRPC memerlukan koneksi TLS saat diekspos melalui Ingress.

Solusi

• Tambahkan Annotation berikut ke resource Ingress: nginx.ingress.kubernetes.io/backend-protocol: "GRPC".

• Pastikan klien mengirim lalu lintas terenkripsi melalui port TLS.

Tidak dapat terhubung ke layanan HTTPS backend

Gejala

• Tidak dapat mengakses layanan HTTPS di belakang Ingress.

• Permintaan mungkin mengembalikan kode status 400 dengan pesan The plain HTTP request was sent to HTTPS port.

Penyebab

Controller Ingress mengirim permintaan HTTP ke Pod backend secara default.

Solusi

Atur anotasi berikut di resource Ingress Anda: nginx.ingress.kubernetes.io/backend-protocol:"HTTPS".

Tidak dapat mempertahankan IP sumber di pod Ingress

Gejala

Alamat IP sumber klien tidak dipertahankan di Pod Ingress. Sebagai gantinya, aplikasi menerima alamat IP internal, seperti IP node atau alamat dari rentang 100.XX.XX.XX.

Penyebab

• externalTrafficPolicy dari Service yang mengekspos Ingress diatur ke Cluster.

• Instance Server Load Balancer (SLB) dikonfigurasi sebagai proxy layer-7.

• Web Application Firewall (WAF) atau layanan WAF transparan digunakan.

Solusi

• Jika Service Anda memiliki externalTrafficPolicy diatur ke Cluster dan diekspos oleh instance SLB layer-4:

  Ubah externalTrafficPolicy menjadi Local. Perubahan ini mungkin mencegah pod di dalam kluster mengakses Ingress melalui alamat IP SLB. Untuk solusinya, lihat Tidak dapat mengakses alamat eksternal LoadBalancer kluster dari dalam kluster.

• Jika Anda menggunakan proxy layer-7, seperti instance SLB layer-7, WAF, atau WAF transparan, ikuti langkah-langkah berikut:

  1. Pastikan proxy layer-7 Anda dikonfigurasi untuk menambahkan header permintaan X-Forwarded-For.

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

  3. Periksa log untuk memverifikasi bahwa IP sumber dipertahankan.

• Jika jalur traffic Anda melibatkan beberapa langkah penerusan, seperti layanan reverse proxy tambahan di depan Ingress Controller, aktifkan enable-real-ip dan periksa nilai bidang remote_addr di log. Ini membantu Anda menentukan apakah kontainer Ingress menerima alamat IP sumber klien di header permintaan X-Forwarded-For. Jika tidak, pastikan alamat IP sumber ditambahkan ke permintaan, misalnya di header X-Forwarded-For, sebelum permintaan mencapai Ingress Controller.

Aturan canary gagal berlaku

Gejala

Anda telah mengonfigurasi rilis canary di kluster Anda, tetapi aturan canary tidak berlaku.

Penyebab

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

• Untuk versi NGINX Ingress Controller sebelum 0.47.0, bidang Host di aturan Ingress Anda harus berisi nama domain layanan Anda dan tidak boleh kosong.

Solusi

• Atur anotasi nginx.ingress.kubernetes.io/canary: "true", atau atur bidang Host di aturan Ingress Anda ke nama domain layanan Anda. Untuk informasi selengkapnya, lihat Aturan routing.

• Jika skenario ini tidak berlaku, lihat Traffic tidak didistribusikan sesuai aturan rilis canary atau traffic diarahkan ke layanan canary.

Traffic yang tidak diharapkan diarahkan ke layanan canary

Gejala

Anda telah mengonfigurasi aturan canary, tetapi traffic tidak didistribusikan sesuai spesifikasi. Anda juga mungkin menemukan bahwa traffic dari ingress standar lainnya diarahkan ke layanan canary.

Penyebab

NGINX Ingress Controller menerapkan aturan canary tidak hanya ke satu ingress, tetapi ke semua ingress yang berbagi layanan yang sama.

Untuk informasi selengkapnya tentang perilaku ini, lihat Ingress dengan aturan canary memengaruhi semua ingress yang berbagi layanan yang sama.

Solusi

Untuk mengaktifkan rilis canary untuk ingress (termasuk yang menggunakan service-match dan anotasi terkait canary-*), buat layanan khusus (satu layanan stabil dan satu layanan canary) yang mengarah ke pod yang ada. Kemudian, aktifkan aturan canary pada ingress tersebut. Untuk informasi selengkapnya, lihat Implementasikan rilis canary dan penyebaran biru-hijau menggunakan NGINX Ingress.

Error saat membuat Ingress: "failed calling webhook"

Gejala

Saat Anda membuat resource Ingress, Anda menerima error "Internal error occurred: failed calling webhook...".

Kode error lengkapnya adalah APISERVER_500. Pesan detailnya adalah Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": Post https://ingress-nginx-controller-admission.kube-system.svc:443/networking/v1beta1/ingresses?timeout=10s: context deadline exceeded. Frasa 'context deadline exceeded' menunjukkan akar penyebabnya: timeout panggilan webhook.

Penyebab

Saat Anda membuat resource Ingress, Service—secara default, ingress-nginx-controller-admission—harus memvalidasi konfigurasinya. Jika komponen dalam rantai panggilan tidak tersedia (misalnya, jika Service atau Ingress Controller dihapus), validasi gagal dan server API menolak resource Ingress.

Solusi

• Periksa rantai panggilan webhook untuk memastikan semua resource yang diperlukan berjalan dengan benar. Rantainya adalah: ValidatingWebhookConfiguration → Service → Pod.

• Verifikasi bahwa Pod Ingress Controller memiliki fitur admission yang diaktifkan dan dapat diakses dari luar.

• Jika Ingress Controller dihapus atau Anda tidak memerlukan fungsionalitas webhook, hapus resource ValidatingWebhookConfiguration.

Error SSL_ERROR_RX_RECORD_TOO_LONG saat akses HTTPS

Gejala

Anda menerima error saat mengakses HTTPS: SSL_ERROR_RX_RECORD_TOO_LONG atau routines:CONNECT_CR_SRVR_HELLO:wrong version number.

Penyebab

Permintaan HTTPS dikirim ke port non-HTTPS, seperti port HTTP.

Solusi

Modifikasi pengaturan SLB atau Service untuk mengarahkan traffic HTTPS ke port yang benar.

Kode error HTTP umum

Gejala

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

Penyebab dan solusi

Periksa log akses untuk menentukan apakah error dikembalikan oleh Ingress Controller. Untuk informasi selengkapnya, lihat Gunakan Log Service untuk melihat log akses controller NGINX Ingress. Jika demikian, lihat solusi berikut:

• Error 413

  • Penyebab: NGINX Ingress Controller berfungsi dengan benar, tetapi ukuran data permintaan melebihi batas yang diizinkan.

  • 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 (default: 20m).

• Error 499

  • Penyebab: Klien memutus koneksi lebih awal. Hal ini tidak selalu menunjukkan masalah pada komponen atau layanan backend.

  • Solusi:

    • Sejumlah kecil error 499 bisa dianggap normal dan diabaikan, tergantung aplikasi Anda.

    • Jika banyak error 499 terjadi, periksa apakah waktu pemrosesan layanan backend dan timeout permintaan sisi klien dikonfigurasi sesuai harapan.

• Error 502

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

  • Solusi:

    • Jika error selalu terjadi:

      • Konfigurasi yang salah untuk Service atau pod backend dapat menyebabkan error ini. Periksa konfigurasi port Service backend dan kode aplikasi di kontainer.

    • Jika error terjadi secara intermiten:

      • Beban tinggi pada pod NGINX Ingress Controller dapat menyebabkan error ini. Anda dapat menilai beban dengan memeriksa jumlah permintaan dan koneksi pada instance load balancer yang terkait dengan controller. Lihat Konfigurasikan controller NGINX Ingress untuk skenario beban tinggi untuk mengalokasikan lebih banyak resource ke controller.

      • Error ini dapat terjadi jika pod backend secara aktif menutup sesi. NGINX Ingress Controller mengaktifkan koneksi persisten secara default. Pastikan periode timeout idle koneksi persisten backend lebih lama dari periode timeout idle controller (default: 900 detik).

    • Jika Anda tidak dapat mengidentifikasi masalah menggunakan metode di atas, lakukan pengambilan paket untuk analisis.

• Error 503

  • Penyebab: Ingress Controller tidak dapat menemukan pod backend apa pun, atau semua pod backend tidak dapat dijangkau.

  • Solusi:

    • Jika error terjadi secara intermiten:

      • Lihat solusi untuk error 502.

      • Periksa status kesiapan layanan backend dan konfigurasikan pemeriksaan kesehatan yang sesuai.

    • Jika error selalu terjadi:

      Periksa apakah Service backend dikonfigurasi dengan benar dan memiliki endpoint.

Error net::ERR_HTTP2_SERVER_REFUSED_STREAM

Gejala

Beberapa resource gagal dimuat, dan konsol developer browser menampilkan error net::ERR_HTTP2_SERVER_REFUSED_STREAM atau net::ERR_FAILED.

Penyebab

Jumlah permintaan resource konkuren melebihi batas aliran maksimum untuk koneksi HTTP/2.

Solusi

• (Direkomendasikan) Di ConfigMap, tingkatkan http2-max-concurrent-streams (default: 128) ke nilai yang sesuai untuk workload Anda. Untuk detailnya, lihat http2-max-concurrent-streams.

• Sebagai alternatif, nonaktifkan dukungan HTTP/2 di ConfigMap dengan mengatur use-http2 ke false. Untuk detailnya, lihat use-http2.

Error: "The param of ServerGroupName is illegal"

Penyebab

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

Solusi

Modifikasi nama grup server agar sesuai dengan persyaratan penamaan.

Error pembuatan Ingress: "certificate signed by unknown authority"

Saat Anda membuat Ingress, kluster mengembalikan error dengan kode APISERVER_500 dan pesan berikut: Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": Post https://ingress-nginx-controller-admission.kube-system.svc:443/networking/v1beta1/ingresses?timeout=10s: x509: certificate signed by unknown authority.

Penyebab

Error ini terjadi jika beberapa penyebaran Ingress di kluster Anda berbagi resource seperti Secret, layanan, atau konfigurasi Webhook. Tumpang tindih resource ini menyebabkan ketidakcocokan sertifikat SSL saat Webhook admission berkomunikasi dengan layanan backend-nya, sehingga validasi gagal.

Solusi

Sebarkan ulang Ingress Anda dan pastikan setiap penyebaran menggunakan kumpulan resource yang unik. Untuk informasi selengkapnya tentang resource dalam penyebaran Ingress, lihat Pembaruan apa saja yang dilakukan saat Anda meningkatkan NGINX Ingress Controller di manajemen komponen ACK?.

Pod Ingress restart karena pemeriksaan kesehatan gagal

Gejala

Pemeriksaan kesehatan yang gagal menyebabkan pod controller restart.

Penyebab

• Pemeriksaan kesehatan dapat gagal jika Pod Ingress atau nodenya mengalami beban tinggi.

• Pemeriksaan kesehatan dapat gagal jika parameter kernel tcp_tw_reuse atau tcp_timestamps diatur di node kluster.

Solusi

• Tingkatkan jumlah Pod Ingress dan verifikasi bahwa masalah telah terselesaikan. Untuk detailnya, lihat Menyebarkan NGINX Ingress Controller untuk ketersediaan tinggi.

• Nonaktifkan parameter kernel tcp_tw_reuse atau atur ke 2, dan nonaktifkan parameter kernel tcp_timestamps. Kemudian, verifikasi bahwa masalah telah terselesaikan.

Tambahkan layanan TCP dan UDP

1. Tambahkan entri ke ConfigMap tcp-services atau udp-services. Secara default, ConfigMap ini berada di namespace ingress-nginx.

   Misalnya, untuk memetakan port eksternal 9000 ke port 8080 layanan example-go di namespace default:

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

2. Tambahkan port yang dipetakan ke definisi kontainer di Deployment Ingress. Secara default, ini adalah Deployment nginx-ingress-controller di namespace ingress-nginx.

3. Tambahkan port yang dipetakan ke Service yang mengekspos controller Ingress.

   Kode contoh

   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 selengkapnya, lihat Mengekspos layanan TCP dan UDP.

Aturan Ingress tidak berlaku

Gejala

Anda menambahkan atau memodifikasi aturan Ingress, tetapi aturan tersebut tidak berlaku.

Kemungkinan penyebab

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

• Resource Ingress salah konfigurasi.

• Controller Ingress tidak memiliki izin yang diperlukan untuk memantau perubahan resource Ingress.

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

Penulisan ulang path menyebabkan kegagalan pemuatan atau layar putih

Gejala

Setelah Anda menggunakan anotasi Ingress rewrite-target untuk menulis ulang path akses, beberapa resource gagal dimuat atau layar putih muncul.

Penyebab

• Anotasi rewrite-target tidak dikonfigurasi dengan ekspresi reguler.

• Aplikasi menggunakan path absolut yang dikodekan keras untuk meminta resource.

Solusi

• Konfigurasikan anotasi rewrite-target dengan ekspresi reguler dan grup tangkapan. Untuk informasi selengkapnya, lihat Rewrite.

• Verifikasi bahwa permintaan frontend menggunakan path yang benar.

Perbaiki parsing log SLS setelah upgrade

Gejala

Komponen ingress-nginx-controller memiliki dua versi utama: 0.20 dan 0.30. Setelah Anda meningkatkan komponen dari versi 0.20 ke 0.30 menggunakan Add-ons di konsol, Dashboard Ingress salah menampilkan informasi traffic untuk layanan backend saat Anda menggunakan rilis canary atau penyebaran biru-hijau.

Penyebab

Versi 0.20 dan 0.30 menggunakan format log default yang berbeda. Akibatnya, Dashboard Ingress salah mengurai log saat Anda menggunakan rilis canary atau penyebaran biru-hijau.

Solusi

Untuk memperbaiki masalah ini, perbarui nginx-configuration configmap dan konfigurasi k8s-nginx-ingress.

1. Perbarui nginx-configuration configmap.

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

     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 memperbaiki masalah tanpa menimpa konfigurasi Anda:

     kubectl edit configmap nginx-configuration -n kube-system

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

2. Perbarui konfigurasi k8s-nginx-ingress.

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

   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

Error: "cannot list/get/update resource"

Gejala

Saat memeriksa error di Pod controller seperti yang dijelaskan di Periksa log error di Pod controller, Anda mungkin menemukan log error seperti ini:

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

NGINX Ingress Controller tidak memiliki izin yang diperlukan untuk memperbarui resource terkait.

Solusi

• Periksa log untuk menentukan apakah ClusterRole atau Role yang menyebabkan masalah.

  • Jika log berisi at the cluster scope, masalah disebabkan oleh ClusterRole (ingress-nginx).

  • Log berisi in the namespace "kube-system", menunjukkan bahwa masalah disebabkan oleh Role (kube-system/ingress-nginx).

• Verifikasi bahwa izin dan binding yang diperlukan ada.

  • Untuk ClusterRole:

    • Pastikan ClusterRole ingress-nginx dan ClusterRoleBinding ingress-nginx ada. Jika tidak ada, buat, pulihkan dari cadangan, atau uninstall dan instal ulang komponen tersebut.

    • Pastikan ClusterRole ingress-nginx berisi izin yang ditunjukkan di log (dalam contoh di bawah, izin untuk list resource ingresses di grup API networking.k8s.io). Jika izin tersebut hilang, tambahkan secara manual ke ClusterRole.

      E0629 17:26:22.916137       8 reflector.go:138] k8s.io/client-go@v0.23.6/tools/cache/reflector.go:167: Failed to watch *v1.Ingress: failed to list *v1.Ingress: ingresses.networking.k8s.io is forbidden: User "system:serviceaccount:kube-system:ingress-nginx" cannot list resource "ingresses" in API group "networking.k8s.io" at the cluster scope

  • Untuk Role:

    • Pastikan Role kube-system/ingress-nginx dan RoleBinding kube-system/ingress-nginx ada. Jika tidak ada, buat, pulihkan dari cadangan, atau uninstall dan instal ulang komponen tersebut.

    • Pastikan Role ingress-nginx berisi izin yang ditunjukkan di log (dalam contoh di bawah, izin update untuk ConfigMap ingress-controller-leader-nginx). Jika izin tersebut hilang, tambahkan secara manual ke Role.

      E0629 17:07:09.111640       9 leaderelection.go:367] Failed to update lock: configmaps "ingress-controller-leader-nginx" is forbidden: User "system:serviceaccount:kube-system:ingress-nginx" cannot update resource "configmaps" in API group "" in the namespace "kube-system"

Uji file konfigurasi gagal

Gejala

Saat Anda memeriksa log controller di pod seperti yang dijelaskan di Periksa log error di pod controller, Anda mungkin menemukan log error seperti berikut:

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

Penyebab

Kesalahan konfigurasi mencegah NGINX memuat ulang konfigurasinya. Penyebabnya biasanya kesalahan sintaksis dalam aturan ingress atau cuplikan yang disisipkan ke ConfigMap.

Solusi

• Periksa pesan error di log untuk mengidentifikasi masalah. Anda dapat mengabaikan pesan dengan level warn. Jika pesan error tidak jelas, gunakan file dan nomor baris dari log untuk memeriksa file di pod. Misalnya, log berikut menunjukkan error di file /tmp/nginx/nginx-cfg2825306115 pada baris 449.

  E0629 19:54:09.340338       8 queue.go:130] "requeuing" err=<
  -----------------------------------------------------------------------
        Error: exit status 1
        2022/06/29 19:54:09 [warn] 179#179: the "http2_max_field_size" directive is obsolete, use the "large_client_header_buffers" directive instead in /tmp/nginx/nginx-cfg2825306115:146
          nginx: [warn] the "http2_max_field_size" directive is obsolete, use the "large_client_header_buffers" directive instead in /tmp/nginx/nginx-cfg2825306115:146
        2022/06/29 19:54:09 [warn] 179#179: the "http2_max_header_size" directive is obsolete, use the "large_client_header_buffers" directive instead in /tmp/nginx/nginx-cfg2825306115:147
          nginx: [warn] the "http2_max_header_size" directive is obsolete, use the "large_client_header_buffers" directive instead in /tmp/nginx/nginx-cfg2825306115:147
        2022/06/29 19:54:09 [warn] 179#179: the "http2_max_requests" directive is obsolete, use the "keepalive_requests" directive instead in /tmp/nginx/nginx-cfg2825306115:148
          nginx: [warn] the "http2_max_requests" directive is obsolete, use the "keepalive_requests" directive instead in /tmp/nginx/nginx-cfg2825306115:148
        2022/06/29 19:54:09 [emerg] 179#179: unexpected "}" in /tmp/nginx/nginx-cfg2825306115:449
          nginx: [emerg] unexpected "}" in /tmp/nginx/nginx-cfg2825306115:449
        nginx: configuration file /tmp/nginx/nginx-cfg2825306115 test failed

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

  # Masuk ke pod.
  kubectl exec -n <namespace> <controller pod name> -it -- bash
  # Lihat file dengan nomor baris untuk memeriksa konfigurasi di sekitar error.
  cat -n /tmp/nginx/nginx-cfg2825306115

• Gunakan pesan error dan file konfigurasi untuk mengidentifikasi dan memperbaiki kesalahan konfigurasi.

Error: "Unexpected error validating SSL certificate"

Gejala

Saat Anda memeriksa log Pod Controller seperti yang dijelaskan di Periksa log error di pod controller, Anda mungkin menemukan log error controller seperti berikut:

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

W0629 20:39:10.993206    7 controller.go:1364] Unexpected error validating SSL certificate "default/tls-secret" for server "test.example.com": x509: certificate is not valid for any names, but wanted to match test.example.com
W0629 20:39:10.993238    7 controller.go:1365] Validating certificate against DNS names. This will be deprecated in a future version
W0629 20:39:10.993252    7 controller.go:1370] SSL certificate "default/tls-secret" does not contain a Common Name or Subject Alternative Name for server "test.example.com": x509: certificate is not valid for any names, but wanted to match test.example.com

Penyebab

Error ini disebabkan oleh kesalahan konfigurasi certificate. Penyebab umum adalah ketidaksesuaian antara nama domain yang dikonfigurasi di resource ingress dan nama domain yang termasuk dalam certificate. Beberapa log level peringatan, seperti subject alternative name yang hilang, mungkin tidak memengaruhi fungsionalitas certificate. Tentukan apakah ini merupakan masalah aktual untuk kasus penggunaan Anda.

Solusi

Gunakan pesan error untuk memeriksa masalah berikut dengan certificate di cluster Anda.

• Verifikasi bahwa format dan konten file certificate (.crt) dan file kunci privat (.key) benar.

• Pastikan nama domain di certificate, seperti common name atau subject alternative name, sesuai dengan nama domain yang dikonfigurasi di resource ingress.

• Periksa apakah certificate telah kedaluwarsa.

File konfigurasi yang tertinggal di controller

1.6M	nginx-cfg1093913015
1.6M	nginx-cfg1093943092
1.6M	nginx-cfg1093985057
1.6M	nginx-cfg1093989258
1.6M	nginx-cfg1094101515
1.6M	nginx-cfg1094200269
1.6M	nginx-cfg1094291268
1.6M	nginx-cfg1094298834
1.6M	nginx-cfg1094398542
0	nginx-cfg1094455202
1.6M	nginx-cfg1094500903
1.6M	nginx-cfg1094513787
1.6M	nginx-cfg1094539327
1.6M	nginx-cfg1094651267
0	nginx-cfg1094749495
0	nginx-cfg1094766605
1.6M	nginx-cfg1094774347
1.6M	nginx-cfg1094799028
1.6M	nginx-cfg109483858
1.6M	nginx-cfg1094903817
1.6M	...

Pod macet di status Pending setelah upgrade controller

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

kubectl -n kube-system get events

Kerancuan aliran TCP dengan beberapa CLB untuk Nginx Ingress

Filter: tcp.stream eq 7517
Frame 197967: 2582 bytes on wire (20656 bits), 2582 bytes captured (20656 bits)
Ethernet II, Src: 66:4b:c1:20:9a:0a (66:4b:c1:20:9a:0a), Dst: d6:79:26:1b:14:4d (d6:79:26:1b:14:4d)
Internet Protocol Version 4, Src: 172.30.3.183, Dst: xxx
Transmission Control Protocol, Src Port: 80, Dst Port: 1458, Seq: 1284522488, Ack: 173965101, Len: 2516
Selected packet (Frame 197967):
Src: 172.30.3.183 -> Dst: xxx
TCP Seq: 2516
Sequence number: 1284522488
Acknowledgement: 173965101
Timestamp value: 1789595929
Hex dump (partial):
0000  d6 79 26 1b 14 4d 66 4b  c1 20 9a 0a 08 45 b0
0010  ...
Info column shows multiple entries including:
[ACK] Seq=xxx Ack=xxx
[TCP Window Full]
[TCP Retransmission]
[RST]