🥇Kubernetes tipy a triky: personalizované chybové stránky v NGINX Ingress

V tomto článku chci hovořit o dvou funkcích NGINX Ingress, které se týkají zobrazení personalizovaných chybových stránek, jakož i o existujících omezeních a způsobech, jak je obejít.

1. Změna výchozího backendu

Ve výchozím nastavení používá NGINX Ingress výchozí backend, který plní funkci odpovídající tomuto účelu. To znamená, že při žádosti o Ingress s hostitelem, který není uveden v Ingress-ressource, obdržíme takovou stránku s kódem odpovědi 404:

Čím dál častěji se naši klienti obracejí s žádostí, aby místo standardního 404 zobrazili svou vlastní stránku s logem firmy a dalšími vymoženostmi. Pro toto má NGINX Ingress vestavěnou možnost přepsat výchozí-backend-služba. Jako argument předáváme stejnou možnost ve formátu namespace/servicename. Port služby musí být 80.

K tomu je třeba vytvořit svůj pod (deployment) a službu se svou aplikací (příklad implementace v YAML z repozitáře ingress-nginx), která se bude podávat místo výchozího backendu.

Zde je malá ilustrace:

~$ curl -i -XGET http://sadsdasdas.kube-cloud.my/
HTTP/1.1 404 Nenalezeno
Datum: Po, 11 Bře 2019 05:38:15 GMT
Typ obsahu: */*
Přenosová jednotka: chunked
Spojení: keep-alive

<span>stránka, kterou hledáte, nebyla nalezena.</span>

Tímto způsobem všechny domény, které nebyly explicitně vytvořeny pomocí YAML s kind: Ingress, spadají do výchozího backendu. V předchozím seznamu se takovou doménou stala sadsdasdas.

2. Zpracování HTTP-chyb v aplikaci pomocí výchozího backendu

Další situace — končící HTTP-chybami (404, 500, 502…) požadavky na aplikaci, ve které takové situace nejsou zpracovávány (nejsou generovány odpovídající krásné stránky). To může být také způsobeno přáním vývojářů vracet stejné chybové stránky v mnoha aplikacích.

Pro realizaci tohoto případu na serverové straně je třeba:

Provést pokyny uvedené výše v části o výchozím backendu;
Do konfiguračního ConfigMap nginx-ingress přidat klíč custom-http-errors, například s hodnotou 404,503 (pochopitelně odpovídající chybovým kódům, na které se nové pravidlo vztahuje).

Očekávaného výsledku bylo dosaženo: při práci klientské aplikace a získání chyby s kódem odpovědi 404 nebo 503 bude požadavek automaticky přesměrován na nový výchozí backend…

Při vývoji aplikace pro výchozí backend a custom-http-errors je však nutné vzít v úvahu důležitou vlastnost:

!!! Důležité Očekává se, že vlastní backend vrátí správný HTTP status code místo 200. NGINX nemění odpověď z vlastního výchozího backendu.

Jde o to, že při přesměrování požadavku v hlavičkách budou užitečné informace s předchozím kódem odpovědi a dodatečnými informacemi (úplný seznam je k dispozici zde).

To znamená, že musíte postarat se o správný kód odpovědi. Tady je příklad z dokumentace, jak to funguje.

Různým aplikacím — různý default backend

Aby řešení nebylo globální pro celý klastr, ale týkalo se pouze konkrétních aplikací, je nejprve nutné zkontrolovat verzi Ingress. Pokud odpovídá 0.23 nebo vyšší, použijte "nativní" anotace Ingress:

Můžeme předefinovat default-backend pro každou Ingressu pomocí anotace V důsledku toho bude zdroj Ingress vypadat přibližně takto:;
Můžeme předefinovat custom-http-errors pro každou Ingressu pomocí anotace V důsledku toho bude zdroj Ingress vypadat přibližně takto:.

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

V takovém případě budou chyby 404 a 502 přesměrovány na službu error-pages se všemi potřebnými hlavičkami.

v předchozích verzích Ingress tato možnost nebyla

V osudový commit v 0.23 (). A pokud v klastru běží 2 zcela různé aplikace a chcete pro každou z nich nastavit různé default-backend-service a zpracování různých kódů chyb — pak budete muset využít workaroundy, kterých máme dva.Ingress < 0.23: první přístup

Tato varianta je jednodušší. Jako aplikaci, která vrací své stránky, máme obyčejné HTML, které neumí nahlížet do hlaviček a vracet správné kódy odpovědi. Taková aplikace je nasazena s Ingress s URL

, a v katalogu /error-pagesws bude ležet vracené HTML. Ilustrace v 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

Služba pro toto nasazení by měla mít typ ClusterIP.

Přitom v aplikaci, kde budeme zpracovávat chybu, přidáme v Ingressu server-snippet nebo configuration-snippet s následujícím obsahem:

V aplikaci, kde budeme zpracovávat chybu, přidáme do Ingressu server-snippet nebo configuration-snippet s následujícím obsahem:

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: druhý přístup

Varianta pro aplikaci, která umí zpracovávat hlavičky… A vůbec, to je korektnější cesta převzatá z custom-http-errors. Jeho ruční použití (kopírování) umožní nepozměnit globální nastavení.

Další kroky. Vytváříme stejný deployment s aplikací, která umí poslouchat potřebné hlavičky a odpovídat správně. Přidáváme do Ingress aplikace server-snippet s následujícím obsahem:

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

Jak je vidět, pro každou chybu, kterou chceme zpracovávat, je potřeba vytvořit vlastní umístění, kde budou vloženy všechny potřebné hlavičky, jako v «rodném» custom-error-pages. Tak můžeme vytvářet různé personalizované chybové stránky i pro jednotlivé umístění a servery.

P.S.

Další z cyklu K8s tipy a triky:

Přečtěte si také náš blog:

Zdroj: habr.com