Kubernetes tips och tricks: anpassade felsidor i NGINX Ingress

I den här artikeln vill jag prata om två funktioner hos NGINX Ingress relaterade till visning av personliga felsidor, såväl som de begränsningar som finns i dem och sätt att kringgå dem.

1. Ändra standardbackend

Som standard använder NGINX Ingress standardbackend, som utför motsvarande funktion. Detta innebär att när vi begär en Ingress som anger en värd som inte finns i Ingress-resurserna, får vi följande sida med en 404-svarskod:

Men allt oftare kommer våra kunder med en begäran om att visa sin sida med en företagslogotyp och andra bekvämligheter istället för standard 404. För att göra detta har NGINX Ingress inbyggd förmåga omdefiniera default-backend-service. Vi skickar formatposten som ett argument till alternativet med samma namn namespace/servicename. Tjänstens port bör vara 80.

För att göra detta måste du skapa din egen pod (distribution) och tjänst med din applikation (exempelimplementering i YAML från ingress-nginx-förvaret), som kommer att ges istället för standardbackend.

Här är en liten 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>

Så alla domäner som inte är explicit skapade via YAML med kind: Ingress, faller in i standard-backend. I listan ovan blev denna domän sadsdasdas.

2. Hantera HTTP-fel i applikationen med standardbackend

En annan situation är förfrågningar som slutar med HTTP-fel (404, 500, 502...) till en applikation som inte behandlar sådana situationer (motsvarande vackra sidor genereras inte). Detta kan också bero på utvecklarnas önskan att visa samma felsidor i flera applikationer.

För att implementera detta fall på serversidan behöver vi:

1. Följ instruktionerna ovan från stycket om standardbackend;
2. Lägg till en nyckel till nginx-ingress-konfigurationen ConfigMap custom-http-errors, till exempel med värdet 404,503 (motsvarar självklart de felkoder som omfattas av den nya regeln).

Det förväntade resultatet har uppnåtts: när klientapplikationen körs och får ett felmeddelande med svarskod 404 eller 503, kommer begäran automatiskt att omdirigeras till den nya standardbackend...

Men när du utvecklar en applikation för standardbackend och anpassade http-fel måste du ta hänsyn till en viktig 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 är att när en förfrågan omdirigeras kommer rubrikerna att innehålla användbar information med den tidigare svarskoden och ytterligare information (deras fullständiga lista är tillgänglig här).

Det betyder att du själv måste ta hand om rätt svarskod. Här är ett exempel. från dokumentationen hur det fungerar.

Olika applikationer har olika standardbackends

För att säkerställa att lösningen inte är global för hela klustret, utan endast gäller specifika applikationer, måste du först kontrollera Ingress-versionen. Om det stämmer 0.23 eller högre, använd de inbyggda Ingress-anteckningarna:

1. Vi kan åsidosätta default-backend för av varje Ingress's använda anteckningar;
2. Vi kan åsidosätta custom-http-errors för av varje Ingress's använda anteckningar.

Som ett resultat kommer Ingress-resursen att se ut ungefär så här:

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 det här fallet kommer fel 404 och 502 att omdirigeras till tjänsten felsidor med alla nödvändiga rubriker.

В tidigare versioner av Ingress hade inte den här funktionen (ödesdigert begå på 0.23). Och om du har 2 helt olika applikationer som körs i ditt kluster och du vill ange en annan standard-backend-tjänst och bearbetning av olika felkoder för var och en av dem, för detta måste du använda lösningar, varav vi har två.

Ingång < 0.23: närmar sig ett

Det här alternativet är enklare. Som en applikation som servar sina sidor har vi vanlig HTML, som inte vet hur man ser på rubrikerna och returnerar rätt svarskoder. En sådan applikation rullas ut med Ingress från webbadressen /error-pages, och i katalogen ws kommer att vara den returnerade HTML-koden.

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

Tjänsten för den här distributionen måste vara av typen ClusterIP.

Samtidigt, i applikationen där vi kommer att behandla felet, lägger vi i Ingress till en server-snippet eller konfigurations-snippet med följande innehåll:

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

Ingång < 0.23: andra tillvägagångssätt

Ett alternativ för en applikation som kan bearbeta rubriker... Och i allmänhet är detta ett mer korrekt sätt, lånat från custom-http-fel. Genom att använda det manuellt (kopiera) kan du inte ändra globala inställningar.

Stegen är som följer. Vi skapar samma utplacering med en applikation som kan lyssna på nödvändiga rubriker och svara rätt. Lägg till ett serverutdrag till Ingress-applikationen med följande innehåll:

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, för varje fel som vi vill bearbeta, måste vi göra vår egen plats, där alla nödvändiga rubriker kommer att infogas, som i den "infödda". anpassade felsidor. På så sätt kan vi skapa olika personliga felsidor även för enskilda platser och servrar.

PS

Annat från K8s tips & tricks-serien:

• «Överföra resurser som körs i ett kluster till Helm 2-hantering";
• «Om nodtilldelning och laddningar på en webbapplikation";
• «Tillgång till utvecklingswebbplatser";
• «Påskyndar bootstrap för stora databaser".

Läs även på vår blogg:

• «Tillbaka till mikrotjänster med Istio. Del 1";
• «[Illustrerad] Guide till nätverk i Kubernetes. Del 3".

Källa: will.com