Kubernetes tips og triks: tilpassede feilsider i NGINX Ingress

I denne artikkelen vil jeg snakke om to funksjoner ved NGINX Ingress relatert til visning av personlige feilsider, samt begrensningene som finnes i dem og måter å omgå dem på.

1. Endre standard backend

Som standard bruker NGINX Ingress standard backend, som utfører den tilsvarende funksjonen. Dette betyr at når vi ber om en Ingress som spesifiserer en vert som ikke er i Ingress-ressursene, mottar vi følgende side med en 404-svarkode:

Imidlertid kommer oftere og oftere våre kunder med en forespørsel om å vise siden deres med en bedriftslogo og andre fasiliteter i stedet for standard 404. For å gjøre dette har NGINX Ingress innebygd kapasitet redefinere default-backend-service. Vi sender formatoppføringen som et argument til alternativet med samme navn namespace/servicename. Tjenestens port skal være 80.

For å gjøre dette må du lage din egen pod (distribusjon) og tjeneste med applikasjonen din (eksempelimplementering i YAML fra ingress-nginx-depotet), som vil bli gitt i stedet for standard backend.

Her er en liten illustrasjon:

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

Så alle domener som ikke er eksplisitt opprettet via YAML med kind: Ingress, faller inn i standard-backend. I oppføringen ovenfor ble dette domenet sadsdasdas.

2. Håndtering av HTTP-feil i applikasjonen ved å bruke standard backend

En annen situasjon er forespørsler som ender med HTTP-feil (404, 500, 502...) til en applikasjon som ikke behandler slike situasjoner (de tilsvarende vakre sidene genereres ikke). Dette kan også skyldes at utviklere ønsker å betjene de samme feilsidene i flere applikasjoner.

For å implementere denne saken på serversiden trenger vi:

1. Følg instruksjonene ovenfor fra avsnittet om standard backend;
2. Legg til en nøkkel til nginx-ingress-konfigurasjonen ConfigMap custom-http-errors, for eksempel med verdien 404,503 (tilsvarer åpenbart feilkodene som omfattes av den nye regelen).

Det forventede resultatet er oppnådd: når klientapplikasjonen kjører og mottar en feil med svarkode 404 eller 503, vil forespørselen automatisk bli omdirigert til den nye standard backend...

Men når du utvikler en applikasjon for standard backend og tilpassede http-feil, må du ta hensyn til en viktig funksjon:

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

Faktum er at når en forespørsel omdirigeres, vil overskriftene inneholde nyttig informasjon med den forrige svarkoden og tilleggsinformasjon (deres komplette liste er tilgjengelig her).

Det betyr at du selv må ta vare på riktig svarkode. Her er et eksempel fra dokumentasjonen hvordan det fungerer.

Ulike applikasjoner har forskjellige standard backends

For å sikre at løsningen ikke er global for hele klyngen, men kun gjelder spesifikke applikasjoner, må du først sjekke Ingress-versjonen. Hvis det stemmer 0.23 eller høyere, bruk de opprinnelige Ingress-kommentarene:

1. Vi kan overstyre default-backend for av hver Ingress sin ved hjelp av merknader;
2. Vi kan overstyre custom-http-errors for av hver Ingress sin ved hjelp av merknader.

Som et resultat vil Ingress-ressursen se omtrent slik ut:

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

I dette tilfellet vil feil 404 og 502 bli omdirigert til feilsidetjenesten med alle nødvendige overskrifter.

В tidligere versjoner av Ingress hadde ikke denne funksjonen (skjebnesvangre forpliktelse på 0.23). Og hvis du har 2 helt forskjellige applikasjoner som kjører i klyngen din og du vil spesifisere en annen standard-backend-tjeneste og behandling av forskjellige feilkoder for hver av dem, må du bruke løsninger, hvorav vi har to.

Inngang < 0.23: nærmer seg én

Dette alternativet er enklere. Som en applikasjon som betjener sidene sine, har vi vanlig HTML, som ikke vet hvordan man ser på overskriftene og returnerer de riktige svarkodene. En slik applikasjon rulles ut med Ingress fra url /error-pages, og i katalogen ws vil være den returnerte HTML-en.

Illustrasjon i 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

Tjenesten for denne distribusjonen må være av typen ClusterIP.

Samtidig, i applikasjonen der vi skal behandle feilen, legger vi i Ingress til en server-snippet eller configuration-snippet med følgende innhold:

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

Inngang < 0.23: andre tilnærming

Et alternativ for en applikasjon som kan behandle overskrifter... Og generelt er dette en mer korrekt måte, lånt fra tilpassede-http-feil. Ved å bruke den manuelt (kopiering) kan du ikke endre globale innstillinger.

Fremgangsmåten er som følger. Vi skaper samme utplassering med en applikasjon som kan lytte til de nødvendige overskriftene og svare riktig. Legg til en server-snippet til Ingress-applikasjonen med følgende innhold:

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

Som du kan se, for hver feil vi ønsker å behandle, må vi lage vår egen plassering, der alle nødvendige overskrifter vil bli satt inn, som i den "innfødte". tilpassede feilsider. På denne måten kan vi lage forskjellige personlige feilsider selv for individuelle lokasjoner og servere.

PS

Annet fra K8s tips og triks-serien:

• «Overføring av ressurser som kjører i en klynge til Helm 2-administrasjon";
• «Om nodeallokering og belastninger på en nettapplikasjon";
• «Tilgang til utviklingssider";
• «Fremskynder oppstartstrap for store databaser'.

Les også på bloggen vår:

• «Tilbake til mikrotjenester med Istio. Del 1";
• «[Illustrert] Veiledning til nettverksbygging i Kubernetes. Del 3'.

Kilde: www.habr.com