Kubernetes Tipps & Tricks: Benotzerdefinéiert Feeler Säiten an NGINX Ingress

An dësem Artikel wëll ech iwwer zwee Features vun NGINX Ingress schwätzen am Zesummenhang mat personaliséierte Feeler Säiten ze weisen, souwéi d'Limiten déi an hinnen existéieren a Weeër fir se ëmzegoen.

1. Änneren der Default Backend

Par défaut benotzt NGINX Ingress den Default-Backend, deen déi entspriechend Funktioun ausféiert. Dëst bedeit datt wann Dir en Ingress freet deen en Host spezifizéiert deen net an den Ingress Ressourcen ass, mir déi folgend Säit mat engem 404 Äntwertcode kréien:

Wéi och ëmmer, ëmmer méi dacks kommen eis Cliente mat enger Ufro fir hir Säit mat engem Firmelogo an aner Facilitéite ze weisen amplaz vum Standard 404. Fir dëst ze maachen, huet NGINX Ingress gebaut-an Fäegkeet nei definéieren default-backend-service. Mir passéieren d'Formatentrée als Argument un d'Optioun mam selwechten Numm namespace/servicename. Den Hafen vum Service soll 80 sinn.

Fir dëst ze maachen, musst Dir Ären eegene Pod (Deployment) a Service mat Ärer Applikatioun erstellen (Beispill Implementatioun an YAML vum ingress-nginx Repository), deen amplaz vum Standard Backend gëtt.

Hei eng kleng Illustratioun:

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

Also all Domainen déi net explizit iwwer YAML erstallt ginn mat kind: Ingress, falen an Default-Backend. An der Oplëschtung uewendriwwer gouf dëst Domain sadsdasdas.

2. Handling HTTP-Feeler an der Applikatioun mam Standard-Backend

Eng aner Situatioun ass Ufroen déi mat HTTP-Feeler ophalen (404, 500, 502 ...) un eng Applikatioun déi sou Situatiounen net veraarbecht (déi entspriechend schéin Säiten ginn net generéiert). Dëst kann och wéinst dem Wonsch vun Entwéckler sinn déi selwecht Feeler Säiten an MÉI Uwendungen ze déngen.

Fir dëse Fall op der Server Säit ëmzesetzen brauche mir:

1. Follegt d'Instruktioune uewen aus dem Paragraph iwwer Standard Backend;
2. Füügt e Schlëssel un d'nginx-ingress Konfiguratioun ConfigMap custom-http-errors, zum Beispill, mam Wäert 404,503 (entsprécht selbstverständlech de Feelercodes, déi vun der neier Regel ofgedeckt sinn).

Dat erwaart Resultat ass erreecht ginn: wann d'Clientapplikatioun leeft an e Feeler mat engem Äntwertcode vu 404 oder 503 kritt, gëtt d'Ufro automatesch op den neie Standard-Backend ëmgeleet ...

Wéi och ëmmer, wann Dir eng Applikatioun fir Standard Backend a Custom-http-Feeler entwéckelt, musst Dir eng wichteg Feature berücksichtegen:

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

D'Tatsaach ass datt wann eng Ufro ëmgeleet gëtt, wäerten d'Header nëtzlech Informatioune mat dem fréiere Äntwertcode an zousätzlech Informatioun enthalen (hir komplett Lëscht ass verfügbar hei).

Dat heescht, datt Dir selwer muss këmmere sech ëm de richtegen Äntwertcode. Hei ass e Beispill aus der Dokumentatioun wéi et funktionnéiert.

Verschidde Applikatiounen hu verschidde Standard-Backends

Fir sécherzestellen datt d'Léisung net fir de ganze Stärekoup global ass, awer nëmme fir spezifesch Uwendungen gëlt, musst Dir als éischt d'Ingress Versioun kontrolléieren. Wann et passt 0.23 oder méi héich, benotzt déi gebierteg Ingress Annotatiounen:

1. Mir kënnen iwwerdribblen default-backend fir vun all eenzel Ingress's benotzt Annotatiounen;
2. Mir kënnen iwwerdribblen custom-http-errors fir vun all eenzel Ingress's benotzt Annotatiounen.

Als Resultat wäert d'Ingress Ressource sou ausgesinn:

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

An dësem Fall ginn d'Fehler 404 an 502 op de Fehler-Säiten-Service mat all néideg Header ëmgeleet.

В virdrun Versiounen vun Ingress hunn dës Fonktioun net (Schicksal Engagement op 0.23). A wann Dir 2 komplett verschidden Applikatiounen an Ärem Cluster hutt an Dir wëllt en anere Standard-Backend-Service an d'Veraarbechtung vu verschiddene Feelercodes fir jidderee vun hinnen spezifizéieren, dofir musst Dir Léisunge benotzen, vun deenen mir zwee hunn.

Ingress < 0.23: Approche eent

Dës Optioun ass méi einfach. Als Applikatioun déi seng Säiten déngt, hu mir regelméisseg HTML, déi net weess wéi d'Header kucken an déi richteg Äntwertcodes zréckginn. Esou eng Applikatioun gëtt mat Ingress vun der URL ausgerullt /error-pages, an am Katalog ws wäert de zréckginn HTML sinn.

Illustratioun an 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

De Service fir dës Détachement muss vum ClusterIP Typ sinn.

Zur selwechter Zäit, an der Applikatioun wou mir de Feeler veraarbechten, addéiere mer am Ingress e Server-Snippet oder Configuration-Snippet mat dem folgenden Inhalt:

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: zweet Approche

Eng Optioun fir eng Applikatioun déi d'Header kann veraarbechten ... An am Allgemengen ass dat e méi korrekte Wee, geléint vu Custom-http-Feeler. Wann Dir et manuell benotzt (Kopie) erlaabt Iech net global Astellungen z'änneren.

D'Schrëtt sinn wéi follegt. Mir kreéieren déiselwecht Deployment mat enger Applikatioun déi déi néideg Schlagzeilen nolauschtere kann a richteg äntweren. Füügt e Server-Snippet un d'Ingress Applikatioun mat dem folgenden Inhalt:

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

Wéi Dir gesitt, fir all Feeler, dee mir veraarbecht wëllen, musse mir eis eege Plaz maachen, wou all déi néideg Header agebaut ginn, wéi an der "native". Benotzerdefinéiert Feeler Säiten. Esou kënne mir verschidde personaliséiert Feeler Säiten erstellen och fir eenzel Plazen a Serveren.

PS

Aner aus der K8s Tipps & Tricks Serie:

• «Ressourcen iwwerdroen, déi an engem Cluster lafen, op Helm 2 Gestioun";
• «Iwwer Nodeallokatioun a Luede op enger Webapplikatioun";
• «Zougang zu Dev Siten";
• «Beschleunegt Bootstrap fir grouss Datenbanken".

Liest och op eisem Blog:

• «Zréck op Mikroservicer mat Istio. Deel 1";
• «[Illustréiert] Guide fir Netzwierker zu Kubernetes. Deel 3".

Source: will.com