Tip & trik Kubernetes: kaca kesalahan khusus ing NGINX Ingress

Ing artikel iki, aku pengin ngomong babagan rong fitur NGINX Ingress sing ana gandhengane karo nampilake kaca kesalahan sing dipersonalisasi, uga watesan sing ana lan cara kanggo ngatasi.

1. Ngganti backend gawan

Kanthi gawan, NGINX Ingress nggunakake backend standar, sing nindakake fungsi sing cocog. Iki tegese nalika njaluk Ingress sing nemtokake host sing ora ana ing sumber daya Ingress, kita nampa kaca ing ngisor iki kanthi kode respon 404:

Nanging, luwih akeh klien kita njaluk panjaluk kanggo nuduhake kaca kanthi logo perusahaan lan fasilitas liyane tinimbang standar 404. Kanggo nindakake iki, NGINX Ingress duwe kemampuan dibangun ing nemtokake maneh default-backend-service. We pass entri format minangka bantahan kanggo pilihan saka jeneng sing padha namespace/servicename. Port layanan kudu 80.

Kanggo nindakake iki, sampeyan kudu nggawe pod (penyebaran) lan layanan karo aplikasi sampeyan (conto implementasine ing YAML saka repositori ingress-nginx), sing bakal diwenehake tinimbang backend standar.

Mangkene ilustrasi cilik:

~$ 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>

Dadi kabeh domain sing ora digawe sacara eksplisit liwat YAML karo kind: Ingress, tiba ing default-backend. Ing dhaptar ing ndhuwur, domain iki dadi sadsdasdas.

2. Nangani kesalahan HTTP ing aplikasi nggunakake backend gawan

Kahanan liyane yaiku panjaluk sing diakhiri karo kesalahan HTTP (404, 500, 502...) menyang aplikasi sing ora ngolah kahanan kasebut (kaca-kaca ayu sing cocog ora digawe). Iki bisa uga amarga kepinginan para pangembang kanggo ngladeni kaca kesalahan sing padha ing pirang-pirang aplikasi.

Kanggo ngleksanakake kasus iki ing sisih server kita kudu:

1. Tindakake pandhuan ing ndhuwur saka paragraf babagan backend standar;
2. Tambah tombol menyang konfigurasi nginx-ingress ConfigMap custom-http-errors, contone, karo nilai 404,503 (temenan cocog karo kode kesalahan sing dijamin dening aturan anyar).

Asil sing dikarepake wis digayuh: nalika aplikasi klien mlaku lan nampa kesalahan kanthi kode respon 404 utawa 503, panjalukan kasebut bakal dialihake kanthi otomatis menyang backend standar anyar...

Nanging, nalika ngembangake aplikasi kanggo backend default lan custom-http-errors, sampeyan kudu nggatekake 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.

Kasunyatane yaiku nalika panyuwunan dialihake, header bakal ngemot informasi sing migunani karo kode respon sadurunge lan informasi tambahan (dhaptar lengkap kasedhiya kene).

Iki tegese sampeyan dhewe kudu ngurus kode respon sing bener. Mangkene conto saka dokumentasi cara kerjane.

Aplikasi sing beda duwe backend standar sing beda

Kanggo mesthekake yen solusi ora global kanggo kabeh kluster, nanging mung ditrapake kanggo aplikasi tartamtu, sampeyan kudu mriksa versi Ingress. Yen cocog 0.23 utawa luwih, gunakake anotasi Ingress asli:

1. Kita bisa ngatasi default-backend kanggo saben Ingress nggunakake anotasi;
2. Kita bisa ngatasi custom-http-errors kanggo saben Ingress nggunakake anotasi.

Akibaté, sumber daya Ingress bakal katon kaya iki:

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

Ing kasus iki, kesalahan 404 lan 502 bakal dialihake menyang layanan kaca kesalahan kanthi kabeh header sing dibutuhake.

В Ingress versi sadurungé ora duwe fitur iki (fateful commit ing 0.23). Lan yen sampeyan duwe 2 aplikasi temen beda mlaku ing kluster lan sampeyan pengin nemtokake standar-backend-layanan beda lan pangolahan kode kesalahan beda kanggo saben wong, kanggo iki sampeyan kudu nggunakake workarounds, kang kita duwe loro.

Ingress <0.23: nyedhaki siji

Pilihan iki luwih prasaja. Minangka aplikasi sing nglayani kaca, kita duwe HTML biasa, sing ora ngerti carane ndeleng header lan ngasilake kode respon sing bener. Aplikasi kasebut diluncurake karo Ingress saka url /error-pages, lan ing katalog ws bakal dadi HTML bali.

Ilustrasi ing 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 kanggo panyebaran iki kudu saka jinis ClusterIP.

Ing wektu sing padha, ing aplikasi sing bakal ngolah kesalahan, ing Ingress kita nambah potongan server utawa potongan konfigurasi kanthi konten ing ngisor iki:

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 kapindho

Pilihan kanggo aplikasi sing bisa ngolah header ... Lan ing umum iki cara sing luwih bener, dipinjam saka custom-http-errors. Nggunakake kanthi manual (nyalin) bakal ngidini sampeyan ora ngganti setelan global.

Langkah-langkahe kaya ing ngisor iki. Kita nggawe panyebaran padha kanthi aplikasi sing bisa ngrungokake judhul sing dibutuhake lan nanggapi kanthi bener. Tambah potongan-server menyang aplikasi Ingress kanthi isi ing ngisor iki:

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;
      }

Kaya sing sampeyan ngerteni, kanggo saben kesalahan sing arep diproses, kita kudu nggawe lokasi dhewe, ing ngendi kabeh header sing dibutuhake bakal dilebokake, kaya ing "native". kaca-kesalahan-custom. Kanthi cara iki, kita bisa nggawe kaca kesalahan pribadi sing beda sanajan kanggo lokasi lan server individu.

PS

Liyane saka seri tips & trik K8s:

• «Nransfer sumber daya sing mlaku ing kluster menyang manajemen Helm 2";
• «Babagan alokasi simpul lan beban ing aplikasi web";
• «Akses menyang situs dev";
• «Nyepetake bootstrap kanggo database gedhe".

Waca uga ing blog kita:

• «Bali menyang microservices karo Istio. Bagean 1";
• «[Ilustrasi] Pandhuan kanggo jaringan ing Kubernetes. Bagean 3".

Source: www.habr.com