Tipy a triky Kubernetes: vlastné chybové stránky v NGINX Ingress

V tomto článku chcem hovoriť o dvoch funkciách NGINX Ingress súvisiacich so zobrazovaním prispôsobených chybových stránok, ako aj o obmedzeniach, ktoré v nich existujú, a spôsoboch, ako ich obísť.

1. Zmena predvoleného backendu

NGINX Ingress štandardne používa predvolený backend, ktorý vykonáva zodpovedajúcu funkciu. To znamená, že keď požiadate o Ingress s uvedením hostiteľa, ktorý nie je v zdrojoch Ingress, dostaneme nasledujúcu stránku s kódom odpovede 404:

Čoraz častejšie však naši klienti prichádzajú s požiadavkou zobraziť svoju stránku s firemným logom a ďalšími vymoženosťami namiesto štandardnej 404. Na to má NGINX Ingress vstavaná schopnosť predefinovať default-backend-service. Záznam formátu odovzdáme ako argument rovnomennej možnosti namespace/servicename. Port služby by mal byť 80.

Ak to chcete urobiť, musíte si vytvoriť svoj vlastný modul (nasadenie) a službu s vašou aplikáciou (príklad implementácie v YAML z úložiska ingress-nginx), ktorý bude poskytnutý namiesto predvoleného backendu.

Tu je malá ilustrácia:

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

Takže všetky domény, ktoré nie sú explicitne vytvorené cez YAML s kind: Ingress, spadajú do predvoleného backendu. Vo vyššie uvedenom zozname sa táto doména stala sadsdasdas.

2. Spracovanie chýb HTTP v aplikácii pomocou predvoleného backendu

Ďalšou situáciou sú požiadavky končiace sa chybami HTTP (404, 500, 502...) do aplikácie, ktorá takéto situácie nespracováva (negenerujú sa zodpovedajúce krásne stránky). Môže to byť spôsobené aj túžbou vývojárov zobrazovať rovnaké chybové stránky vo viacerých aplikáciách.

Na implementáciu tohto prípadu na strane servera potrebujeme:

1. Postupujte podľa pokynov uvedených vyššie v odseku o predvolenom backende;
2. Pridajte kľúč do konfigurácie nginx-ingress ConfigMap custom-http-errors, napríklad s hodnotou 404,503 (samozrejme zodpovedá chybovým kódom, na ktoré sa vzťahuje nové pravidlo).

Očakávaný výsledok bol dosiahnutý: keď je klientska aplikácia spustená a dostane chybu s kódom odpovede 404 alebo 503, požiadavka bude automaticky presmerovaná na nový predvolený backend...

Pri vývoji aplikácie pre predvolený backend a vlastné http-chyby však musíte vziať do úvahy dôležitú vlastnosť:

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

Faktom je, že keď je požiadavka presmerovaná, hlavičky budú obsahovať užitočné informácie s predchádzajúcim kódom odpovede a ďalšie informácie (ich úplný zoznam je k dispozícii tu).

To znamená, že vy sami musíte dbajte na správny kód odpovede. Tu je príklad. z dokumentácie, ako to funguje.

Rôzne aplikácie majú rôzne predvolené backendy

Aby ste sa uistili, že riešenie nie je globálne pre celý klaster, ale vzťahuje sa len na konkrétne aplikácie, musíte najprv skontrolovať verziu Ingress. Ak sa zhoduje 0.23 alebo vyššie, použite natívne anotácie Ingress:

1. Môžeme prepísať default-backend pre z každého Ingress pomocou anotácií;
2. Môžeme prepísať custom-http-errors pre z každého Ingress pomocou anotácií.

V dôsledku toho bude zdroj Ingress vyzerať asi 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 tomto prípade budú chyby 404 a 502 presmerované na službu error-pages so všetkými potrebnými hlavičkami.

В predchádzajúce verzie Ingress túto funkciu nemali (osudný záväzok o 0.23). A ak máte vo svojom klastri spustené 2 úplne odlišné aplikácie a chcete pre každú z nich určiť inú predvolenú backendovú službu a spracovanie rôznych chybových kódov, budete musieť použiť riešenia, z ktorých máme dve.

Vstup < 0.23: priblížiť sa k jednej

Táto možnosť je jednoduchšia. Ako aplikáciu, ktorá obsluhuje svoje stránky, máme bežné HTML, ktoré sa nevie pozrieť na hlavičky a vrátiť správne kódy odpovedí. Takáto aplikácia je spustená pomocou Ingress z adresy URL /error-pagesa v katalógu ws bude vrátený kód HTML.

Ilustrácia 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 pre toto nasadenie musí byť typu ClusterIP.

Zároveň do aplikácie, v ktorej budeme chybu spracovávať, v Ingress pridáme serverový úryvok alebo konfiguračný úryvok s nasledujúcim obsahom:

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

Vstup < 0.23: druhý prístup

Možnosť pre aplikáciu, ktorá dokáže spracovať hlavičky... A vo všeobecnosti je to správnejšia cesta, požičaná z vlastných http-chyb. Ručné použitie (kopírovanie) vám umožní nemeniť globálne nastavenia.

Kroky sú nasledovné. Tvoríme rovnaké nasadenie s aplikáciou, ktorá dokáže počúvať potrebné titulky a správne reagovať. Pridajte útržok servera do aplikácie Ingress s nasledujúcim obsahom:

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

Ako vidíte, pre každú chybu, ktorú chceme spracovať, si musíme vytvoriť vlastné umiestnenie, kam sa vložia všetky potrebné hlavičky, ako v „natívnom“. vlastné chybové stránky. Takto môžeme vytvárať rôzne personalizované chybové stránky aj pre jednotlivé lokality a servery.

PS

Ďalšie zo série tipov a trikov K8s:

• «Prenos prostriedkov spustených v klastri do správy Helm 2»;
• «O prideľovaní uzlov a zaťaženiach webovej aplikácie»;
• «Prístup na stránky pre vývojárov»;
• «Zrýchlenie bootstrapu pre veľké databázy".

Prečítajte si aj na našom blogu:

• «Späť k mikroslužbám s Istio. Časť 1»;
• «[Ilustrovaný] Sprievodca sieťovaním v Kubernetes. Časť 3".

Zdroj: hab.com