Kubernetes wenke en truuks: persoonlike foutbladsye in NGINX Ingress

In hierdie artikel wil ek praat oor twee kenmerke van NGINX Ingress wat verband hou met die vertoon van gepersonaliseerde foutbladsye, sowel as hul beperkings en maniere om dit te omseil.

1. Verander die verstek agterkant

By verstek gebruik NGINX Ingress die verstek agterkant, wat die ooreenstemmende funksie verrig. Dit beteken dat wanneer ons 'n Ingress versoek met 'n gasheer wat nie in die Ingress-bronne is nie, ons hierdie bladsy kry met 'n 404-antwoordkode:

Ons kliënte kom egter meer en meer gereeld met 'n versoek om hul bladsy met 'n maatskappylogo en ander geriewe te wys in plaas van die standaard 404. Hiervoor het NGINX Ingress ingeboude vermoë herdefinieer default-backend-service. Ons gee die formaatrekord as 'n argument aan die opsie met dieselfde naam namespace/servicename. Die dienspoort moet 80 wees.

Om dit te doen, moet jy jou eie pod (ontplooiing) en 'n diens met jou toepassing skep (voorbeeld implementering in YAML vanaf die ingress-nginx-bewaarplek), wat gegee sal word in plaas van die verstek agterkant.

Hier is 'n klein illustrasie:

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

So alle domeine wat nie eksplisiet geskep is via YAML met kind: Ingress, val in die verstek-agterkant. In die lys hierbo het hierdie domein geword sadsdasdas.

2. Hantering van HTTP-foute in die toepassing deur die verstek-backend

Nog 'n situasie is versoeke wat eindig met HTTP-foute (404, 500, 502 ...) na 'n toepassing wat nie sulke situasies hanteer nie (ooreenstemmende pragtige bladsye word nie gegenereer nie). Dit kan ook veroorsaak word deur die begeerte van ontwikkelaars om dieselfde foutbladsye in verskeie toepassings terug te gee.

Om hierdie geval aan die bedienerkant te implementeer, benodig ons:

1. Volg die instruksies hierbo uit die paragraaf oor die verstek agterkant;
2. Voeg die sleutel by die konfigurasie ConfigMap nginx-ingress custom-http-errors, byvoorbeeld, met die waarde 404,503 (kom natuurlik ooreen met die foutkodes wat deur die nuwe reël gedek word).

Die verwagte resultaat word behaal: wanneer die kliënttoepassing loop en 'n fout met 'n 404- of 503-antwoordkode ontvang, sal die versoek outomaties herlei word na die nuwe verstek-agtergrond ...

Wanneer 'n toepassing vir die verstek-agtergrond en persoonlike http-foute ontwikkel word, moet 'n belangrike kenmerk egter in ag geneem word:

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

Die feit is dat wanneer die versoek herlei word, die opskrifte nuttige inligting sal bevat met die vorige antwoordkode en bykomende inligting (hul volledige lys is beskikbaar hier).

Dit beteken dat jy moet sorg vir die korrekte antwoordkode. Hier is 'n voorbeeld. uit die dokumentasie hoe dit werk.

Verskillende toepassings - verskillende standaard backend

Sodat die oplossing nie wêreldwyd vir die hele groepering is nie, maar slegs op spesifieke toepassings van toepassing is, moet u eers die weergawe van Ingress nagaan. As dit ooreenstem 0.23 of hoër, gebruik die oorspronklike Ingress-aantekeninge:

1. Ons kan herdefinieer default-backend vir elkeen Intrede met annotasie;
2. Ons kan herdefinieer custom-http-errors vir elkeen Intrede met annotasie.

As gevolg hiervan sal die Ingress-hulpbron iets soos volg lyk:

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

In hierdie geval sal 404- en 502-foute na die foutbladsye-diens herlei word met al die nodige opskrifte.

В vorige weergawes van Ingress het nie hierdie kenmerk gehad nie. (noodlottige pleeg in 0.23). En as jy 2 heeltemal verskillende toepassings in jou groepering het en jy wil verskillende verstek-backend-dienste spesifiseer en verskillende foutkodes vir elkeen van hulle hanteer, sal jy oplossings hiervoor moet gebruik, waarvan ons twee het.

Ingang < 0.23: nader een

Hierdie opsie is eenvoudiger. As 'n toepassing wat sy bladsye weergee, het ons gewone HTML, wat nie weet hoe om na kopskrifte te kyk en korrekte antwoordkodes terug te gee nie. So 'n toepassing ontplooi met Ingress met url /error-pages, en in die gids ws sal HTML gegee word.

Illustrasie in 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

Die diens vir hierdie ontplooiing moet van die tipe ClusterIP wees.

Terselfdertyd, in die toepassing waar ons die fout sal hanteer, voeg ons in Ingress bediener-brokkie of konfigurasie-brokkie by met die volgende inhoud:

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

Ingang < 0.23: tweede benadering

'n Variant vir 'n toepassing wat opskrifte kan verwerk ... En in die algemeen is dit 'n meer korrekte manier, geleen van persoonlike-http-foute. Deur dit met die hand te gebruik (kopieer) sal jy nie die globale instellings verander nie.

Die stappe is soos volg. Ons skep dieselfde ontplooiing met 'n toepassing wat na die regte kopskrifte kan luister en korrek kan reageer. Ons voeg bediener-brokkie-toepassings by die Ingress met die volgende inhoud:

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

Soos u kan sien, moet ons vir elke fout wat ons wil verwerk, ons eie ligging maak, waar al die nodige opskrifte vervang sal word, soos in "native" pasgemaakte foutbladsye. Op hierdie manier kan ons verskillende gepersonaliseerde foutbladsye skep, selfs vir individuele liggings en bedieners.

PS

Ander uit die K8s wenke en truuks-reeks:

• «Oordrag van hulpbronne wat in die groepering onder beheer van Helm 2 loop»;
• «Oor die toekenning van nodusse en die vragte op die webtoepassing»;
• «Toegang tot ontwikkelingswebwerwe»;
• «Bespoediging van selflaai vir groot databasisse".

Lees ook op ons blog:

• «Terug na mikrodienste met Istio. Deel 1»;
• «[Geïllustreerd] Kubernetes-netwerkgids. Deel 3".

Bron: will.com