Petua & kiat Kubernetes: halaman ralat tersuai dalam NGINX Ingress

Dalam artikel ini, saya ingin bercakap tentang dua ciri NGINX Ingress yang berkaitan dengan memaparkan halaman ralat yang diperibadikan, serta batasan yang wujud di dalamnya dan cara untuk mengatasinya.

1. Menukar hujung belakang lalai

Secara lalai, NGINX Ingress menggunakan hujung belakang lalai, yang melaksanakan fungsi yang sepadan. Ini bermakna apabila meminta Ingress yang menyatakan hos yang tiada dalam sumber Ingress, kami menerima halaman berikut dengan kod respons 404:

Walau bagaimanapun, semakin kerap pelanggan kami datang dengan permintaan untuk menunjukkan halaman mereka dengan logo syarikat dan kemudahan lain dan bukannya standard 404. Untuk melakukan ini, NGINX Ingress mempunyai keupayaan terbina dalam takrif semula default-backend-service. Kami lulus masukan format sebagai hujah kepada pilihan nama yang sama namespace/servicename. Port perkhidmatan hendaklah 80.

Untuk melakukan ini, anda perlu mencipta pod (pengerahan) dan perkhidmatan anda sendiri dengan aplikasi anda (contoh pelaksanaan dalam YAML daripada repositori ingress-nginx), yang akan diberikan bukannya hujung belakang lalai.

Berikut adalah 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>

Jadi semua domain yang tidak dibuat secara eksplisit melalui YAML dengan kind: Ingress, jatuh ke dalam default-backend. Dalam penyenaraian di atas, domain ini menjadi sadsdasdas.

2. Mengendalikan ralat HTTP dalam aplikasi menggunakan hujung belakang lalai

Situasi lain ialah permintaan yang berakhir dengan ralat HTTP (404, 500, 502...) kepada aplikasi yang tidak memproses situasi sedemikian (halaman cantik yang sepadan tidak dihasilkan). Ini juga mungkin disebabkan oleh keinginan pembangun untuk menyampaikan halaman ralat yang sama dalam berbilang aplikasi.

Untuk melaksanakan kes ini di sisi pelayan, kami memerlukan:

1. Ikut arahan di atas daripada perenggan tentang hujung belakang lalai;
2. Tambahkan kunci pada konfigurasi nginx-ingress ConfigMap custom-http-errors, sebagai contoh, dengan nilai 404,503 (jelas sepadan dengan kod ralat yang diliputi oleh peraturan baharu).

Hasil yang dijangkakan telah dicapai: apabila aplikasi klien sedang berjalan dan menerima ralat dengan kod respons 404 atau 503, permintaan akan diubah hala secara automatik ke bahagian belakang lalai baharu...

Walau bagaimanapun, apabila membangunkan aplikasi untuk bahagian belakang lalai dan ralat http tersuai, anda perlu mengambil kira ciri 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.

Hakikatnya ialah apabila permintaan diubah hala, pengepala akan mengandungi maklumat berguna dengan kod respons sebelumnya dan maklumat tambahan (senarai lengkapnya tersedia di sini).

Ini bermakna anda sendiri mesti jaga kod respons yang betul. Berikut adalah contoh daripada dokumentasi cara ia berfungsi.

Aplikasi yang berbeza mempunyai hujung belakang lalai yang berbeza

Untuk memastikan bahawa penyelesaian itu bukan global untuk keseluruhan kluster, tetapi hanya digunakan untuk aplikasi tertentu, anda perlu menyemak versi Ingress terlebih dahulu. Jika ia sepadan 0.23 atau lebih tinggi, gunakan anotasi Ingress asli:

1. Kita boleh mengatasi default-backend untuk masing-masing Ingress's menggunakan anotasi;
2. Kita boleh mengatasi custom-http-errors untuk masing-masing Ingress's menggunakan anotasi.

Akibatnya, sumber Ingress akan kelihatan 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 kes ini, ralat 404 dan 502 akan diubah hala ke perkhidmatan halaman ralat dengan semua pengepala yang diperlukan.

В versi sebelumnya Ingress tidak mempunyai ciri ini (komit fateful pada 0.23). Dan jika anda mempunyai 2 aplikasi yang sama sekali berbeza berjalan dalam kluster anda dan anda ingin menentukan perkhidmatan lalai-belakang-belakang yang berbeza dan pemprosesan kod ralat yang berbeza untuk setiap satu daripada mereka, untuk ini anda perlu menggunakan penyelesaian, yang mana kami mempunyai dua.

Ingress < 0.23: mendekati satu

Pilihan ini lebih mudah. Sebagai aplikasi yang menyediakan halamannya, kami mempunyai HTML biasa, yang tidak tahu cara melihat pengepala dan mengembalikan kod respons yang betul. Aplikasi sedemikian dilancarkan dengan Ingress daripada url /error-pages, dan dalam katalog ws akan menjadi HTML yang dikembalikan.

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

Perkhidmatan untuk penggunaan ini mestilah daripada jenis ClusterIP.

Pada masa yang sama, dalam aplikasi di mana kami akan memproses ralat, dalam Ingress kami menambah coretan pelayan atau coretan konfigurasi dengan kandungan 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 kedua

Pilihan untuk aplikasi yang boleh memproses pengepala... Dan secara umum ini adalah cara yang lebih betul, dipinjam daripada custom-http-errors. Menggunakannya secara manual (menyalin) akan membolehkan anda untuk tidak menukar tetapan global.

Langkah-langkahnya adalah seperti berikut. Kami cipta penempatan yang sama dengan aplikasi yang boleh mendengar tajuk yang diperlukan dan bertindak balas dengan betul. Tambahkan coretan pelayan pada aplikasi Ingress dengan kandungan 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 anda lihat, untuk setiap ralat yang ingin kami proses, kami perlu membuat lokasi kami sendiri, di mana semua pengepala yang diperlukan akan dimasukkan, seperti dalam "asli". halaman-ralat tersuai. Dengan cara ini kita boleh mencipta halaman ralat diperibadikan yang berbeza walaupun untuk lokasi dan pelayan individu.

PS

Lain daripada siri petua & helah K8s:

• «Memindahkan sumber yang berjalan dalam kelompok kepada pengurusan Helm 2»;
• «Mengenai peruntukan dan beban nod pada aplikasi web»;
• «Akses kepada tapak pembangun»;
• «Mempercepatkan bootstrap untuk pangkalan data yang besar'.

Baca juga di blog kami:

• «Kembali ke perkhidmatan mikro dengan Istio. Bahagian 1»;
• «[Illustrated] Panduan untuk rangkaian dalam Kubernetes. Bahagian 3'.

Sumber: www.habr.com