Kubernetes tips og tricks: tilpassede fejlsider i NGINX Ingress

I denne artikel vil jeg tale om to funktioner i NGINX Ingress relateret til visning af personlige fejlsider, samt de begrænsninger, der findes i dem, og måder at omgå dem på.

1. Ændring af standard backend

Som standard bruger NGINX Ingress standard backend, som udfører den tilsvarende funktion. Dette betyder, at når vi anmoder om en Ingress, der angiver en vært, der ikke er i Ingress-ressourcerne, modtager vi følgende side med en 404-svarkode:

Men oftere og oftere kommer vores kunder med en anmodning om at vise deres side med et firmalogo og andre faciliteter i stedet for standard 404. For at gøre dette har NGINX Ingress indbygget kapacitet omdefinere default-backend-service. Vi videregiver formatindgangen som et argument til indstillingen af ​​samme navn namespace/servicename. Tjenestens port skal være 80.

For at gøre dette skal du oprette din egen pod (implementering) og service med din applikation (eksempel implementering i YAML fra ingress-nginx repository), som vil blive givet i stedet for standard backend.

Her er en lille illustration:

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

Altså alle domæner der ikke er eksplicit oprettet via YAML med kind: Ingress, falder ind i standard-backend. I listen ovenfor blev dette domæne sadsdasdas.

2. Håndtering af HTTP-fejl i applikationen ved hjælp af standard backend

En anden situation er anmodninger, der ender med HTTP-fejl (404, 500, 502...) til en applikation, der ikke behandler sådanne situationer (de tilsvarende smukke sider genereres ikke). Dette kan også skyldes udviklernes ønske om at betjene de samme fejlsider i flere applikationer.

For at implementere denne sag på serversiden har vi brug for:

1. Følg instruktionerne ovenfor fra afsnittet om standard backend;
2. Tilføj en nøgle til nginx-ingress-konfigurationen ConfigMap custom-http-errors, for eksempel med værdien 404,503 (svarer naturligvis til de fejlkoder, der er omfattet af den nye regel).

Det forventede resultat er opnået: når klientapplikationen kører og modtager en fejl med en svarkode på 404 eller 503, vil anmodningen automatisk blive omdirigeret til den nye standard backend...

Men når du udvikler en applikation til standard backend og brugerdefinerede http-fejl, skal du tage højde for en vigtig funktion:

!!! 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 anmodning omdirigeres, vil overskrifterne indeholde nyttig information med den tidligere svarkode og yderligere information (deres komplette liste er tilgængelig her).

Det betyder, at du selv skal sørge for den korrekte svarkode. Her er et eksempel ud fra dokumentationen, hvordan det fungerer.

Forskellige applikationer har forskellige standard backends

For at sikre, at løsningen ikke er global for hele klyngen, men kun gælder for specifikke applikationer, skal du først tjekke Ingress-versionen. Hvis det passer 0.23 eller højere, brug de indbyggede Ingress-annoteringer:

1. Vi kan tilsidesætte default-backend for hver Ingress's ved hjælp af anmærkninger;
2. Vi kan tilsidesætte custom-http-errors for hver Ingress's ved hjælp af anmærkninger.

Som et resultat vil Ingress-ressourcen se sådan ud:

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 tilfælde vil fejl 404 og 502 blive omdirigeret til fejlsider-tjenesten med alle de nødvendige overskrifter.

В tidligere versioner af Ingress havde ikke denne funktion (skæbnesvanger begå på 0.23). Og hvis du har 2 helt forskellige applikationer kørende i din klynge, og du vil angive en anden standard-backend-service og behandling af forskellige fejlkoder for hver af dem, skal du bruge løsninger, hvoraf vi har to.

Indgang < 0.23: nærmer sig én

Denne mulighed er enklere. Som en applikation, der betjener sine sider, har vi almindelig HTML, som ikke ved, hvordan man ser på overskrifterne og returnerer de korrekte svarkoder. En sådan applikation rulles ud med Ingress fra url'en /error-pagesog i kataloget ws vil være den returnerede HTML.

Illustration 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 til denne installation skal være af typen ClusterIP.

Samtidig, i applikationen, hvor vi vil behandle fejlen, tilføjer vi i Ingress et server-snippet eller konfigurations-snippet med følgende indhold:

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

Indgang < 0.23: anden tilgang

En mulighed for en applikation, der kan behandle headers... Og generelt er dette en mere korrekt måde, lånt fra custom-http-fejl. Ved at bruge det manuelt (kopiering) kan du ikke ændre globale indstillinger.

Trinene er som følger. Vi skaber samme indsættelse med en applikation, der kan lytte til de nødvendige overskrifter og svare korrekt. Tilføj et server-snippet til Ingress-applikationen med følgende indhold:

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, skal vi for hver fejl, som vi vil behandle, lave vores egen placering, hvor alle de nødvendige overskrifter vil blive indsat, som i den "native". brugerdefinerede fejlsider. På denne måde kan vi oprette forskellige personlige fejlsider selv for individuelle lokationer og servere.

PS

Andet fra K8s tips & tricks-serien:

• «Overførsel af ressourcer, der kører i en klynge, til Helm 2-administration";
• «Om nodeallokering og belastninger på en webapplikation";
• «Adgang til udviklersider";
• «Fremskynder bootstrap til store databaser'.

Læs også på vores blog:

• «Tilbage til mikrotjenester med Istio. Del 1";
• «[Illustreret] Guide til netværk i Kubernetes. Del 3'.

Kilde: www.habr.com