Mga tip at trick ng Kubernetes: mga custom na pahina ng error sa NGINX Ingress

Sa artikulong ito, gusto kong pag-usapan ang tungkol sa dalawang tampok ng NGINX Ingress na nauugnay sa pagpapakita ng mga personalized na pahina ng error, pati na rin ang mga limitasyon na umiiral sa mga ito at mga paraan upang malutas ang mga ito.

1. Pagbabago ng default na backend

Bilang default, ginagamit ng NGINX Ingress ang default na backend, na gumaganap ng kaukulang function. Nangangahulugan ito na kapag humihiling ng Ingress na tumutukoy sa isang host na wala sa mga mapagkukunan ng Ingress, natatanggap namin ang sumusunod na page na may 404 response code:

Gayunpaman, parami nang parami ang aming mga kliyente na may kasamang kahilingan na ipakita ang kanilang page na may logo ng kumpanya at iba pang amenities sa halip na ang karaniwang 404. Upang gawin ito, mayroon ang NGINX Ingress built-in na kakayahan muling tukuyin default-backend-service. Ipinapasa namin ang format na entry bilang argumento sa opsyon ng parehong pangalan namespace/servicename. Ang port ng serbisyo ay dapat na 80.

Upang gawin ito, kailangan mong lumikha ng iyong sariling pod (deployment) at serbisyo sa iyong aplikasyon (halimbawa ng pagpapatupad sa YAML mula sa ingress-nginx repository), na ibibigay sa halip na ang default na backend.

Narito ang isang maliit na ilustrasyon:

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

Kaya lahat ng domain na hindi tahasang ginawa sa pamamagitan ng YAML na may kind: Ingress, nahulog sa default-backend. Sa listahan sa itaas, naging ang domain na ito sadsdasdas.

2. Pangangasiwa sa mga error sa HTTP sa application gamit ang default na backend

Ang isa pang sitwasyon ay ang mga kahilingan na nagtatapos sa mga error sa HTTP (404, 500, 502...) sa isang application na hindi nagpoproseso ng mga ganoong sitwasyon (ang kaukulang magagandang pahina ay hindi nabuo). Maaaring dahil din ito sa pagnanais ng mga developer na maghatid ng parehong mga pahina ng error sa maraming application.

Upang ipatupad ang kasong ito sa panig ng server kailangan namin:

1. Sundin ang mga tagubilin sa itaas mula sa talata tungkol sa default na backend;
2. Magdagdag ng susi sa configuration ng nginx-ingress na ConfigMap custom-http-errors, halimbawa, na may halaga 404,503 (malinaw na tumutugma sa mga error code na sakop ng bagong panuntunan).

Naabot na ang inaasahang resulta: kapag tumatakbo ang application ng kliyente at nakatanggap ng error na may response code 404 o 503, awtomatikong mare-redirect ang kahilingan sa bagong default na backend...

Gayunpaman, kapag bumubuo ng isang application para sa default na backend at custom-http-errors, kailangan mong isaalang-alang ang isang mahalagang tampok:

!!! 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.

Ang katotohanan ay kapag ang isang kahilingan ay na-redirect, ang mga header ay maglalaman ng kapaki-pakinabang na impormasyon kasama ang nakaraang code ng tugon at karagdagang impormasyon (ang kanilang kumpletong listahan ay magagamit dito).

Nangangahulugan ito na ikaw mismo ay dapat ingatan ang tamang response code. Narito ang isang halimbawa. mula sa dokumentasyon kung paano ito gumagana.

Ang iba't ibang mga application ay may iba't ibang mga default na backend

Upang matiyak na ang solusyon ay hindi pandaigdigan para sa buong cluster, ngunit nalalapat lamang sa mga partikular na application, kailangan mo munang suriin ang bersyon ng Ingress. Kung magkatugma 0.23 o mas mataas, gamitin ang katutubong Ingress annotation:

1. Maaari naming i-override default-backend para sa ng bawat isa kay Ingress gamit ang mga anotasyon;
2. Maaari naming i-override custom-http-errors para sa ng bawat isa kay Ingress gamit ang mga anotasyon.

Bilang resulta, magiging ganito ang hitsura ng mapagkukunan ng Ingress:

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

Sa kasong ito, ang mga error 404 at 502 ay ire-redirect sa serbisyo ng mga pahina ng error kasama ang lahat ng kinakailangang header.

В Ang mga nakaraang bersyon ng Ingress ay walang tampok na ito (nakamamatay na gumawa sa 0.23). At kung mayroon kang 2 ganap na magkakaibang mga application na tumatakbo sa iyong cluster at gusto mong tumukoy ng ibang default-backend-service at pagproseso ng iba't ibang mga error code para sa bawat isa sa kanila, para dito kailangan mong gumamit ng mga workaround, kung saan mayroon kaming dalawa.

Ingress <0.23: lumapit sa isa

Ang pagpipiliang ito ay mas simple. Bilang isang application na nagsisilbi sa mga pahina nito, mayroon kaming regular na HTML, na hindi alam kung paano tingnan ang mga header at ibalik ang mga tamang sagot na code. Ang naturang application ay inilunsad gamit ang Ingress mula sa url /error-pages, at sa catalog ws ay ang ibinalik na HTML.

Ilustrasyon sa 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

Ang serbisyo para sa deployment na ito ay dapat na nasa uri ng ClusterIP.

Kasabay nito, sa application kung saan ipoproseso namin ang error, sa Ingress nagdaragdag kami ng server-snippet o configuration-snippet na may sumusunod na content:

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: pangalawang diskarte

Isang opsyon para sa isang application na maaaring magproseso ng mga header... At sa pangkalahatan ito ay isang mas tamang paraan, na hiniram mula sa custom-http-errors. Ang paggamit nito nang manu-mano (pagkopya) ay magbibigay-daan sa iyo na huwag baguhin ang mga pandaigdigang setting.

Ang mga hakbang ay ang mga sumusunod. Lumilikha kami parehong deployment na may isang application na maaaring makinig sa mga kinakailangang headline at tumugon nang tama. Magdagdag ng server-snippet sa Ingress application na may sumusunod na nilalaman:

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

Tulad ng nakikita mo, para sa bawat error na gusto naming iproseso, kailangan naming gumawa ng sarili naming lokasyon, kung saan ilalagay ang lahat ng kinakailangang header, tulad ng sa "katutubong" isa. custom-error-pages. Sa ganitong paraan makakagawa kami ng iba't ibang personalized na pahina ng error kahit para sa mga indibidwal na lokasyon at server.

PS

Iba pa mula sa serye ng mga tip at trick ng K8:

• «Paglilipat ng mga resource na tumatakbo sa isang cluster sa pamamahala ng Helm 2";
• «Tungkol sa paglalaan at pag-load ng node sa isang web application";
• «Access sa mga dev site";
• «Pagpapabilis ng bootstrap para sa malalaking database'.

Basahin din sa aming blog:

• «Bumalik sa mga microservice kasama si Istio. Bahagi 1";
• «[Illustrated] Gabay sa networking sa Kubernetes. Bahagi 3'.

Pinagmulan: www.habr.com