Këshilla dhe truket e Kubernetes: faqet e gabimeve të personalizuara në NGINX Ingress

Në këtë artikull, dua të flas për dy veçori të NGINX Ingress në lidhje me shfaqjen e faqeve të personalizuara të gabimeve, si dhe kufizimet që ekzistojnë në to dhe mënyrat për t'i shmangur ato.

1. Ndryshimi i backend-it të paracaktuar

Si parazgjedhje, NGINX Ingress përdor backend-in e paracaktuar, i cili kryen funksionin përkatës. Kjo do të thotë që kur kërkojmë një Ingress që specifikon një host që nuk është në burimet e Ingress, ne marrim faqen e mëposhtme me një kod përgjigjeje 404:

Sidoqoftë, gjithnjë e më shpesh klientët tanë vijnë me një kërkesë për të shfaqur faqen e tyre me një logo të korporatës dhe pajisje të tjera në vend të standardit 404. Për ta bërë këtë, NGINX Ingress ka aftësi e integruar ripërcaktoje default-backend-service. Ne ia kalojmë hyrjen e formatit si argument opsionit me të njëjtin emër namespace/servicename. Porta e shërbimit duhet të jetë 80.

Për ta bërë këtë, ju duhet të krijoni podin tuaj (vendosjen) dhe shërbimin me aplikacionin tuaj (shembull zbatimi në YAML nga depoja e ingress-nginx), e cila do të jepet në vend të backend-it të paracaktuar.

Ja një ilustrim i vogël:

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

Pra, të gjitha domenet që nuk janë krijuar në mënyrë eksplicite nëpërmjet YAML me kind: Ingress, bien në bazën e paracaktuar. Në listën e mësipërme, ky domen u bë sadsdasdas.

2. Trajtimi i gabimeve HTTP në aplikacion duke përdorur backend-in e paracaktuar

Një situatë tjetër janë kërkesat që përfundojnë me gabime HTTP (404, 500, 502...) për një aplikacion që nuk përpunon situata të tilla (faqet e bukura përkatëse nuk krijohen). Kjo mund të jetë edhe për shkak të dëshirës së zhvilluesve për të shërbyer të njëjtat faqe gabimi në aplikacione të shumta.

Për të zbatuar këtë rast në anën e serverit na duhet:

1. Ndiqni udhëzimet e mësipërme nga paragrafi në lidhje me backend-in e paracaktuar;
2. Shtoni një çelës në konfigurimin e nginx-ingress ConfigMap custom-http-errors, për shembull, me vlerën 404,503 (Natyrisht korrespondon me kodet e gabimit që mbulohen nga rregulli i ri).

Rezultati i pritur është arritur: kur aplikacioni i klientit po ekzekutohet dhe merr një gabim me kodin e përgjigjes 404 ose 503, kërkesa do të ridrejtohet automatikisht në bazën e re të paracaktuar...

Sidoqoftë, kur zhvilloni një aplikacion për gabimet e paracaktuara dhe me porosi-http, duhet të merrni parasysh një veçori të rëndësishme:

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

Fakti është se kur një kërkesë ridrejtohet, titujt do të përmbajnë informacion të dobishëm me kodin e mëparshëm të përgjigjes dhe informacione shtesë (lista e tyre e plotë është e disponueshme këtu).

Kjo do të thotë që ju vetë duhet kujdesuni për kodin e saktë të përgjigjes. Këtu është një shembull. nga dokumentacioni si funksionon.

Aplikacione të ndryshme kanë backend të ndryshëm të paracaktuar

Për t'u siguruar që zgjidhja nuk është globale për të gjithë grupin, por zbatohet vetëm për aplikacione specifike, fillimisht duhet të kontrolloni versionin Ingress. Nëse përputhet 0.23 ose më shumë, përdorni shënimet vendase Ingress:

1. Ne mund të anashkalojmë default-backend për i secilit Të Ingress-it duke përdorur shënime;
2. Ne mund të anashkalojmë custom-http-errors për i secilit Të Ingress-it duke përdorur shënime.

Si rezultat, burimi Ingress do të duket diçka si kjo:

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

Në këtë rast, gabimet 404 dhe 502 do të ridrejtohen në shërbimin e faqeve të gabimeve me të gjitha titujt e nevojshëm.

В Versionet e mëparshme të Ingress nuk e kishin këtë veçori (kryerja fatale në 0.23). Dhe nëse keni 2 aplikacione krejtësisht të ndryshme që funksionojnë në grupin tuaj dhe dëshironi të specifikoni një shërbim tjetër të paracaktuar dhe përpunim të kodeve të ndryshme të gabimit për secilën prej tyre, për këtë do t'ju duhet të përdorni zgjidhje, nga të cilat ne kemi dy.

Hyrja < 0.23: afrojeni një

Ky opsion është më i thjeshtë. Si një aplikacion që shërben faqet e tij, ne kemi HTML të rregullt, i cili nuk di të shikojë titujt dhe të kthejë kodet e sakta të përgjigjes. Një aplikacion i tillë lëshohet me Ingress nga url /error-pages, dhe në katalog ws do të jetë HTML-ja e kthyer.

Ilustrimi në 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

Shërbimi për këtë vendosje duhet të jetë i llojit ClusterIP.

Në të njëjtën kohë, në aplikacionin ku do të përpunojmë gabimin, në Ingress shtojmë një fragment serveri ose konfigurim-snippet me përmbajtjen e mëposhtme:

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

Hyrja < 0.23: qasja e dytë

Një opsion për një aplikacion që mund të përpunojë titujt... Dhe në përgjithësi kjo është një mënyrë më e saktë, e huazuar nga gabimet custom-http-e. Përdorimi i tij me dorë (kopjimi) do t'ju lejojë të mos ndryshoni cilësimet globale.

Hapat janë si më poshtë. Ne krijojmë të njëjtën vendosje me një aplikacion që mund të dëgjojë titujt e nevojshëm dhe të përgjigjet saktë. Shtoni një fragment serveri në aplikacionin Ingress me përmbajtjen e mëposhtme:

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

Siç mund ta shihni, për çdo gabim që duam të përpunojmë, duhet të bëjmë vendndodhjen tonë, ku do të futen të gjithë titujt e nevojshëm, si në atë "vendas". faqet e gabimeve me porosi. Në këtë mënyrë ne mund të krijojmë faqe të ndryshme gabimesh të personalizuara edhe për vendndodhje dhe serverë individualë.

PS

Të tjera nga seria e këshillave dhe trukeve K8s:

• «Transferimi i burimeve që funksionojnë në një grup në menaxhimin e Helm 2"?
• «Rreth shpërndarjes së nyjeve dhe ngarkesave në një aplikacion në internet"?
• «Qasja në faqet e zhvilluesve"?
• «Përshpejtimi i bootstrap-it për bazat e të dhënave të mëdha'.

Lexoni edhe në blogun tonë:

• «Kthehu te mikroshërbimet me Istio. Pjesa 1"?
• «[Ilustruar] Udhëzues për rrjetëzimin në Kubernetes. Pjesa 3'.

Burimi: www.habr.com