🥇Kubernetes'i näpunäited ja trikid: isikupärastatud vealehed NGINX Ingress'is

Selles artiklis tahan rääkida kahest NGINX Ingressi omadusest, mis on seotud isikupärastatud vealehtede kuvamisega, samuti nende piirangutest ja võimalustest, kuidas neid ületada.

1. Vaikimisi backend'i muutmine

NGINX Ingressis kasutatakse vaikimisi backend'ina default backend'i, mis täidab vastavat funktsiooni. See tähendab, et kui teeme Ingress'i päringu hostiga, mis ei ole Ingress ressources, saame sellise vealehe koos vastusekoodiga 404:

Kuid üha sagedamini tulevad meie kliendid palvega näidata tavalise 404 asemel oma lehte koos brändi logoga ja muude mugavustega. Selleks on NGINX Ingressil sisseehitatud võimalus ülekirjutada default-backend-service. Samanimelist valikut argumendina edastades tuleb esitada kirje vormingus namespace/servicename. Teenuse port peab olema 80.

Selleks on vajalik luua oma pod (deployment) ja teenus koos teie rakendusega (YAML'i rakenduse näidis ingress-nginx repostiost), mis antakse välja vaikimisi backend'i asemel.

Siin on väike illustratsioon:

~$ 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>Otsitavat lehte ei leitud.</span>

Nii on kõik domeenid, mis pole selgelt loodud läbi YAML, tüüp: Ingress, jõuavad default-backend'i. Ülaltoodud nimekirjas sai selliseks domeeniks sadsdasdas.

2. HTTP-ettevõtete töötlemine rakenduses default backend'i abil

Teine olukord on see, kui rakendusele esitatakse HTTP-ettevõtted (404, 500, 502…), kus selliseid olukordi ei käsitleta (vastavaid ilusaid lehti ei genereerita). See võib olla tingitud arendajate soovist anda sama vealehti mitmes rakenduses.

Selle juhtumi rakendamiseks serveripoolt on vajalik:

Teha ülaltoodud juhiste kohaselt default backend'i kohta;
Lisada konfigureerimis ConfigMap nginx-ingress'i võtme custom-http-errors, näiteks väärtusega 404,503 (ilmselgelt vastab see uue reegli alla kuuluvate veakoodide jaoks).

Oodatud tulemus saavutatakse: kliendi rakenduse töö käigus, kui kohtate 404 või 503 vastuskoodi, suunatakse päring automaatselt uude default backend'i…

Kuid custom-http-errors'i ja default backend'i rakenduse arendamisel tuleb arvesse võtta olulist aspekti:

!!! Tähtis. Eeldatakse, et kohandatud backend tagastab õige HTTP staatusekoodi, mitte 200. NGINX ei muuda vastust kohandatud default backend'ilt.

Asja on selles, et päringu suunamisel peavad headerites olema kasulikud andmed eelmise vastuse koodi ja täiendava teabe kohta (täielik loend on saadaval siit).

See tähendab, et te peate ise hoolitsema õige vastuse koodi eest. Siin on näide dokumentatsioonist, kuidas see töötab.

Erinevatele rakendustele – erinev default backend

Kuna lahendus ei tohiks olla globaalne kogu klastris, vaid seonduda ainult konkreetsetele rakendustele, tuleb esmalt kontrollida Ingressi versiooni. Kui see vastab 0.23 või uuemale, kasutage "natiivseid" Ingressi annotatsioone:

Me saame üle kirjutada default-backend kuna peamise domeeni kohta loendis. Ingressist annotatsiooni abil;
Me saame üle kirjutada custom-http-errors kuna peamise domeeni kohta loendis. Ingressist annotatsiooni abil.

Seetõttu näeb Ingressi ressurss välja umbes nii:

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

Sel juhul suunatakse vead 404 ja 502 teenusele error-pages koos kõigi vajalike headeritega.

V eelnevates Ingressi versioonides sellist võimalust ei olnud (saatuslik commit versioonis 0.23). Ja kui teil klastris töötab 2 täiesti erinevat rakendust ja soovite igale neist määrata erinevad default-backend-service'id ning erinevate veakoodide töötlemise — selleks peate kasutama workaround'e, millest meil on kaks.

Ingress < 0.23: esimene lähenemine

See variant on lihtsam. Rakenduse jaoks, mis annab oma lehti, on meil tavaline HTML, mis ei oska vaadata pealkirju ja anda õigeid vastusekoode. Selline rakendus käivitatakse koos Ingress'iga URL-iga /error-pages, ja kataloogis ws asub väljaantud HTML.

Illustratsioon YAML-is:

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

Selle tõuke jaoks peab teenus olema tüübiga ClusterIP.

Samuti rakenduses, kus töötleme viga, lisame Ingress'ile serveri-šnipi või konfiguratsiooni-šnipi järgmise sisuga:

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: teine lähenemine

Variant rakendusele, mis oskab pealkirju töödelda… Lisaks on see üldiselt korrektsem tee, mis on laenatud custom-http-errors'ist. Selle käsitsi kasutamine (kopeerimine) võimaldab mitte muuta globaalsete seadete seadeid.

Järgmised sammud. Loome sama tüüpi kasutuselevõtu rakendusega, mis oskab kuulata vajalikke pealkirju ja vastata õigesti. Lisame Ingress'e server-snippeti järgmise sisuga:

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

Nagu näha, tuleb iga vea jaoks, mida soovime töödelda, luua oma asukoht, kus pannakse sisse kõik vajalikud päised nagu „kohalikus” custom-error-pages. Nii saame luua erinevaid isikupärastatud vealehti isegi konkreetsete asukohtade ja serverite jaoks.