Kiat & trik Kubernetes: halaman kesalahan yang dipersonalisasi di NGINX Ingress

Dalam artikel ini saya ingin berbicara tentang dua fitur NGINX Ingress yang terkait dengan menampilkan halaman kesalahan yang dipersonalisasi, serta keterbatasan yang ada di dalamnya dan cara untuk mengatasinya.

1. Mengubah backend default

Secara default, NGINX Ingress menggunakan backend default, yang menjalankan fungsi yang sesuai. Ini berarti bahwa ketika kami meminta Ingress dengan host yang tidak ada dalam sumber daya Ingress, kami mendapatkan halaman dengan kode respons 404:



Namun, semakin sering pelanggan kami datang dengan permintaan alih-alih standar 404 untuk menampilkan halaman mereka dengan logo perusahaan dan fasilitas lainnya. Untuk melakukan ini, NGINX Ingress memiliki kemampuan default-backend-service untuk mengesampingkan default-backend-service . Pilihan nama yang sama, sebagai argumen, namespace/servicename catatan format namespace/servicename . Port layanan harus 80.

Untuk melakukan ini, buat pod Anda sendiri (penyebaran) dan layanan dengan aplikasi Anda ( contoh implementasi dalam YAML dari repositori ingress-nginx), yang akan diberikan sebagai ganti dari backend default.

Ini ilustrasi kecil:

 ~$ curl -i -XGET http://sadsdasdas.kube-cloud.my/ HTTP/1.1 404 Not Found Date: Mon, 11 Mar 2019 05:38:15 GMT Content-Type: */* Transfer-Encoding: chunked Connection: keep-alive <span>The page you're looking for could not be found.</span> 

Dengan demikian, semua domain yang tidak dibuat secara eksplisit melalui YAML dengan kind: Ingress jatuh ke dalam default-backend. Dalam daftar di atas, sadsdasdas menjadi domain itu.

2. Memproses kesalahan HTTP dalam aplikasi menggunakan backend default

Situasi lain adalah permintaan ke aplikasi di mana situasi HTTP (404, 500, 502 ...) yang gagal memproses situasi seperti itu (halaman cantik yang sesuai tidak dihasilkan) berakhir dengan kesalahan HTTP. Ini juga bisa disebabkan oleh keinginan pengembang untuk memberikan halaman kesalahan yang sama di banyak aplikasi.

Untuk mengimplementasikan kasus ini di sisi server, kita perlu:

1. Ikuti instruksi di atas dari item tentang backend default;
2. Tambahkan kunci custom-http-errors ke konfigurasi ConfigMap nginx-ingress, misalnya, dengan nilai 404,503 (jelas, itu sesuai dengan kode kesalahan yang dicakup oleh aturan baru).

Hasil yang diharapkan tercapai: ketika aplikasi klien berjalan dan menerima kesalahan dengan kode respons 404 atau 503, permintaan akan secara otomatis dialihkan ke backend default baru ...

Namun, ketika mengembangkan aplikasi untuk backend default dan custom-http-error, Anda perlu mempertimbangkan fitur penting:

 !!! Important The custom backend is expected to return the correct HTTP status code instead of 200. NGINX does not change the response from the custom default backend. 

Faktanya adalah bahwa ketika mengarahkan permintaan, header akan berisi informasi yang berguna dengan kode respons sebelumnya dan informasi tambahan (daftar lengkapnya tersedia di sini ).

Ini berarti bahwa Anda sendiri harus menjaga kode respons yang benar . Berikut adalah contoh dari dokumentasi tentang cara kerjanya.

Ke aplikasi yang berbeda - backend default yang berbeda

Agar solusinya tidak global untuk seluruh klaster, tetapi hanya berlaku untuk aplikasi tertentu, pertama Anda perlu memeriksa versi Ingress. Jika cocok dengan 0,23 atau lebih tinggi , gunakan anotasi asli Ingress:

1. Kami dapat mendefinisikan kembali default-backend untuk setiap Ingress melalui anotasi ;
2. Kami dapat mengganti custom-http-errors untuk setiap Ingress menggunakan anotasi .

Akibatnya, sumber daya Ingress akan terlihat seperti ini:

 apiVersion: extensions/v1beta1 kind: Ingress metadata: name: {{ .Chart.Name }}-app2 annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/custom-http-errors: "404,502" nginx.ingress.kubernetes.io/default-backend: error-pages spec: tls: - hosts: - app2.example.com secretName: wildcard-tls rules: - host: app2.example.com http: paths: - path: / backend: serviceName: {{ .Chart.Name }}-app2 servicePort: 80 

Dalam hal ini, kesalahan 404 dan 502 akan dialihkan ke layanan halaman kesalahan dengan semua header yang diperlukan.

Dalam versi Ingress sebelumnya, ini tidak mungkin ( komit yang menentukan di 0,23 ). Dan jika Anda memiliki 2 aplikasi yang sama sekali berbeda yang berjalan di cluster Anda dan Anda ingin menentukan layanan backend-default yang berbeda dan menangani kode kesalahan yang berbeda untuk masing-masing dari mereka - Anda harus menggunakan workarounds untuk ini, yang mana kami memiliki dua.

Ingress <0.23: pendekatan satu

Opsi ini lebih sederhana. Sebagai aplikasi yang memberikan halamannya, kami memiliki HTML biasa, yang tidak tahu cara melihat header dan memberikan kode respons yang benar. Aplikasi semacam itu diluncurkan dengan Ingress dengan url /error-pages , dan HTML akan diberikan di direktori ws .

Ilustrasi dalam YAML:

 apiVersion: extensions/v1beta1 kind: Ingress metadata: name: {{ .Chart.Name }}-app2 annotations: kubernetes.io/ingress.class: "nginx" ingress.kubernetes.io/server-snippet: | proxy_intercept_errors on; error_page 500 501 502 503 504 @error_pages; location @error_pages { rewrite ^ /error-pages/other/index.html break; proxy_pass http://error-pages.prod.svc.cluster.local; } spec: tls: - hosts: - app2.example.com secretName: wildcard-tls rules: - host: app2.example.com http: paths: - path: / backend: serviceName: {{ .Chart.Name }}-app2 servicePort: 80 

Layanan untuk penyebaran ini harus bertipe ClusterIP.

Pada saat yang sama, dalam aplikasi tempat kami akan menangani kesalahan, dalam Ingress kami menambahkan server-snippet atau konfigurasi-snippet dengan konten berikut:

 nginx.ingress.kubernetes.io /server-snippet: | proxy_intercept_errors on; error_page 500 501 502 503 504 @error_pages; location @error_pages { rewrite ^ /error-pages/ws/index.html break; proxy_pass http://error-pages.prod.svc.cluster.local; } 

Ingress <0,23: pendekatan dua

Opsi untuk aplikasi yang dapat menangani tajuk ... Bagaimanapun, ini adalah jalur yang lebih benar, dipinjam dari custom-http-error. Menggunakannya secara manual (menyalin) akan memungkinkan Anda untuk tidak mengubah pengaturan global.

Langkah-langkahnya adalah sebagai berikut. Kami membuat penyebaran yang sama dengan aplikasi yang dapat mendengarkan tajuk yang diperlukan dan merespons dengan benar. Tambahkan aplikasi server-snippet ke Ingress dengan konten berikut:

 nginx.ingress.kubernetes.io /server-snippet: | proxy_intercept_errors off; error_page 404 = @custom_404; error_page 503 = @custom_503; location @custom_404 { internal; proxy_intercept_errors off; proxy_set_header X-Code 404; proxy_set_header X-Format $http_accept; proxy_set_header X-Original-URI $request_uri; proxy_set_header X-Namespace $namespace; proxy_set_header X-Ingress-Name $ingress_name; proxy_set_header X-Service-Name $service_name; proxy_set_header X-Service-Port $service_port; proxy_set_header Host $best_http_host; rewrite ^ /error-pages/ws/index.html break; proxy_pass http://error-pages.prod.svc.cluster.local; } location @custom_503 { internal; proxy_intercept_errors off; proxy_set_header X-Code 503; proxy_set_header X-Format $http_accept; proxy_set_header X-Original-URI $request_uri; proxy_set_header X-Namespace $namespace; proxy_set_header X-Ingress-Name $ingress_name; proxy_set_header X-Service-Name $service_name; proxy_set_header X-Service-Port $service_port; proxy_set_header Host $best_http_host; rewrite ^ /error-pages/ws/index.html break; proxy_pass http://error-pages.prod.svc.cluster.local; } 

Seperti yang dapat Anda lihat, untuk setiap kesalahan yang ingin kami tangani, Anda harus membuat lokasi Anda, tempat semua header yang diperlukan akan diganti, seperti pada halaman " custom " error-custom . Jadi kami dapat membuat halaman khusus yang berbeda dengan kesalahan bahkan untuk lokasi dan server individual.

PS

Lainnya dari siklus tips & trik K8:

• " Transfer sumber daya yang bekerja di sebuah cluster ke manajemen Helm 2 ";
• " Tentang alokasi node dan beban pada aplikasi web ";
• " Akses ke situs dev ";
• " Mempercepat bootstrap dari database besar. "

Baca juga di blog kami:

• “ Kembali ke layanan microser dengan Istio. Bagian 1 ";
• “ [Illustrated] Guide to networking in Kubernetes. Bagian 3 ".