🥇Kubernetes tippek és trükkök: Egyéni hibaoldalak az NGINX Ingressben

Ebben a cikkben az NGINX Ingress két olyan funkciójáról szeretnék beszélni, amelyek a személyre szabott hibaoldalak megjelenítésével kapcsolatosak, valamint a bennük rejlő korlátokról és azok megkerülésének módjairól.

1. Az alapértelmezett háttérrendszer módosítása

Alapértelmezés szerint az NGINX Ingress az alapértelmezett háttérprogramot használja, amely végrehajtja a megfelelő funkciót. Ez azt jelenti, hogy amikor olyan bemenetet kérünk, amely olyan gazdagépet ad meg, amely nem szerepel az Ingress erőforrásokban, a következő oldalt kapjuk 404-es válaszkóddal:

Ügyfeleink azonban egyre gyakrabban érkeznek azzal a kéréssel, hogy a szokásos 404 helyett céges logóval és egyéb szolgáltatásokkal mutassák meg oldalukat. Ehhez az NGINX Ingress rendelkezik beépített képesség újradefiniál default-backend-service. A formátum bejegyzést argumentumként adjuk át az azonos nevű opciónak namespace/servicename. A szolgáltatás portjának 80-asnak kell lennie.

Ehhez létre kell hoznia saját pod (telepítést) és szolgáltatást az alkalmazással (példa megvalósítás YAML-ben az ingress-nginx tárolóból), amely az alapértelmezett háttérprogram helyett lesz megadva.

Íme egy kis illusztráció:

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

Tehát minden olyan tartomány, amelyet nem kifejezetten a YAML-en keresztül hoztak létre kind: Ingress, az alapértelmezett háttérprogramba esik. A fenti listában ez a domain lett sadsdasdas.

2. HTTP-hibák kezelése az alkalmazásban az alapértelmezett háttérprogram használatával

Egy másik helyzet a HTTP hibákra (404, 500, 502...) végződő kérések egy olyan alkalmazáshoz, amely nem dolgozza fel az ilyen helyzeteket (a megfelelő szép oldalak nem jönnek létre). Ennek oka lehet az is, hogy a fejlesztők szeretnék ugyanazokat a hibaoldalakat több alkalmazásban is megjeleníteni.

Ennek az esetnek a szerveroldali megvalósításához szükségünk van:

Kövesse a fenti utasításokat az alapértelmezett háttérprogramról;
Adjon hozzá egy kulcsot a ConfigMap nginx-ingress konfigurációjához custom-http-errors, például az értékkel 404,503 (nyilvánvalóan megfelel az új szabály által lefedett hibakódoknak).

A várt eredmény megtörtént: amikor az ügyfélalkalmazás fut, és 404-es vagy 503-as válaszkódú hibaüzenetet kap, a kérést automatikusan átirányítja az új alapértelmezett háttérrendszerre...

Az alapértelmezett háttér- és egyéni http-hibákra vonatkozó alkalmazás fejlesztésekor azonban figyelembe kell vennie egy fontos funkciót:

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

A helyzet az, hogy egy kérés átirányításakor a fejlécek hasznos információkat tartalmaznak az előző válaszkóddal és további információkkal (a teljes listája elérhető itt).

Ez azt jelenti, hogy magának kell ügyeljen a helyes válaszkódra. Íme egy példa a dokumentációból, hogyan működik.

A különböző alkalmazásoknak eltérő alapértelmezett háttérprogramjuk van

Annak érdekében, hogy a megoldás ne globális legyen a teljes fürtre, hanem csak bizonyos alkalmazásokra vonatkozzon, először ellenőriznie kell az Ingress verziót. Ha egyezik 0.23 vagy újabb, használja a natív Ingress megjegyzéseket:

Felülírhatjuk default-backend a mindegyikből Ingressé megjegyzések segítségével;
Felülírhatjuk custom-http-errors a mindegyikből Ingressé megjegyzések segítségével.

Ennek eredményeként az Ingress erőforrás valahogy így fog kinézni:

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

Ebben az esetben a 404-es és 502-es hiba az összes szükséges fejléccel együtt át lesz irányítva a hibaoldalak szolgáltatásra.

В az Ingress korábbi verziói nem rendelkeztek ezzel a funkcióval (végzetes elkövetés 0.23-nál). Ha pedig 2 teljesen különböző alkalmazás fut a fürtben, és mindegyikhez más alapértelmezett-háttérszolgáltatást és más hibakódok feldolgozását szeretnénk megadni, akkor ehhez megkerülő megoldásokat kell alkalmazni, amelyek közül kettőnk van.

Belépés < 0.23: közelíts egyet

Ez a lehetőség egyszerűbb. Az oldalait kiszolgáló alkalmazásként normál HTML-kóddal rendelkezünk, amely nem tudja, hogyan kell megnézni a fejléceket és visszaadni a helyes válaszkódokat. Egy ilyen alkalmazás az Ingress segítségével kerül kihelyezésre az URL-ből /error-pages, és a katalógusban ws lesz a visszaadott HTML.

Illusztráció YAML-ben:

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

Az ehhez a telepítéshez tartozó szolgáltatásnak ClusterIP típusúnak kell lennie.

Ugyanakkor abban az alkalmazásban, ahol a hibát feldolgozzuk, az Ingressben hozzáadunk egy szerver-kódrészletet vagy konfigurációs kódrészletet a következő tartalommal:

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: második megközelítés

Opció egy olyan alkalmazáshoz, amely képes feldolgozni a fejléceket... És általában ez egy korrektebb módszer, az egyedi http-hibákból kölcsönözve. Kézi használata (másolás) lehetővé teszi, hogy ne módosítsa a globális beállításokat.

A lépések a következők. Mi alkotunk ugyanaz a bevetés olyan alkalmazással, amely képes meghallgatni a szükséges főcímeket és helyesen válaszolni. Adjon hozzá egy szerver-kódrészletet az Ingress alkalmazáshoz a következő tartalommal:

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

Amint látja, minden feldolgozni kívánt hibához saját helyet kell létrehoznunk, ahová az összes szükséges fejléc be lesz illesztve, mint a „natív” fejlécben. egyéni hibaoldalak. Így akár egyedi helyszínekre, szerverekre is különböző személyre szabott hibaoldalakat tudunk készíteni.