Namigi in triki Kubernetes: strani z napakami po meri v NGINX Ingress

V tem članku želim govoriti o dveh funkcijah NGINX Ingress, povezanih s prikazovanjem prilagojenih strani z napakami, pa tudi o omejitvah, ki obstajajo v njih, in načinih, kako jih zaobiti.

1. Spreminjanje privzetega zaledja

NGINX Ingress privzeto uporablja privzeto zaledje, ki izvaja ustrezno funkcijo. To pomeni, da ko zahtevamo Ingress z navedbo gostitelja, ki ni v virih Ingress, prejmemo naslednjo stran z odzivno kodo 404:

Vendar pa vse pogosteje naše stranke prihajajo s prošnjo, da namesto standardnega 404 prikažejo svojo stran z logotipom podjetja in drugimi ugodnostmi. Za to ima NGINX Ingress vgrajena zmogljivost redefinirati default-backend-service. Vnos formata posredujemo kot argument istoimenski možnosti namespace/servicename. Vrata storitve morajo biti 80.

Če želite to narediti, morate s svojo aplikacijo ustvariti svoj pod (razmestitev) in storitev (primer izvedbe v YAML iz repozitorija ingress-nginx), ki bo podan namesto privzetega zaledja.

Tukaj je majhna ilustracija:

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

Torej vse domene, ki niso izrecno ustvarjene prek YAML z kind: Ingress, spadajo v privzeto zaledje. V zgornjem seznamu je ta domena postala sadsdasdas.

2. Obravnava napak HTTP v aplikaciji z uporabo privzetega zaledja

Druga situacija so zahteve, ki se končajo z napakami HTTP (404, 500, 502 ...) za aplikacijo, ki takih situacij ne obdela (ustrezne lepe strani se ne ustvarijo). To je lahko tudi posledica želje razvijalcev, da strežejo iste strani z napakami v več aplikacijah.

Za izvedbo tega primera na strani strežnika potrebujemo:

1. Sledite zgornjim navodilom iz odstavka o privzetem zaledju;
2. Dodajte ključ v konfiguracijo nginx-ingress ConfigMap custom-http-errors, na primer z vrednostjo 404,503 (očitno ustreza kodam napak, ki jih zajema novo pravilo).

Pričakovani rezultat je bil dosežen: ko se odjemalska aplikacija izvaja in prejme napako z odzivno kodo 404 ali 503, bo zahteva samodejno preusmerjena na novo privzeto zaledje ...

Ko pa razvijate aplikacijo za privzeto zaledje in napake http po meri, morate upoštevati pomembno lastnost:

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

Dejstvo je, da ko je zahteva preusmerjena, bodo glave vsebovale uporabne informacije s prejšnjo odzivno kodo in dodatne informacije (njihov celoten seznam je na voljo tukaj).

To pomeni, da morate sami poskrbite za pravilno odzivno kodo. Tukaj je primer. iz dokumentacije kako deluje.

Različne aplikacije imajo različna privzeta zaledja

Če želite zagotoviti, da rešitev ni globalna za celotno gručo, ampak velja samo za določene aplikacije, morate najprej preveriti različico Ingress. Če se ujema 0.23 ali več, uporabite izvorne opombe Ingress:

1. Lahko preglasimo default-backend za vsakega Ingress's z uporabo opomb;
2. Lahko preglasimo custom-http-errors za vsakega Ingress's z uporabo opomb.

Posledično bo vir Ingress videti nekako takole:

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 tem primeru bosta napaki 404 in 502 preusmerjeni na storitev strani z napakami z vsemi potrebnimi glavami.

В prejšnje različice Ingressa te funkcije niso imele (usodna zaveza pri 0.23). In če se v vaši gruči izvajata 2 popolnoma različni aplikaciji in želite za vsako od njih določiti drugačno privzeto zaledno storitev in obdelavo različnih kod napak, boste za to morali uporabiti rešitve, od katerih imamo dve.

Ingress < 0.23: pristop ena

Ta možnost je preprostejša. Kot aplikacija, ki služi svojim stranem, imamo običajni HTML, ki ne zna pogledati glav in vrniti pravilnih odzivnih kod. Takšna aplikacija se uvede z Ingressom z url-ja /error-pages, in v katalogu ws bo vrnjeni HTML.

Ilustracija 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

Storitev za to razmestitev mora biti tipa ClusterIP.

Hkrati v aplikaciji, kjer bomo obdelali napako, v Ingressu dodamo delček strežnika ali konfiguracijski delček z naslednjo vsebino:

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

Vstop < 0.23: drugi pristop

Možnost za aplikacijo, ki lahko obdeluje glave ... In na splošno je to bolj pravilen način, izposojen iz custom-http-errors. Z ročno uporabo (kopiranje) ne boste mogli spreminjati globalnih nastavitev.

Koraki so naslednji. Mi ustvarjamo enako razporeditev z aplikacijo, ki lahko posluša potrebne naslove in se pravilno odzove. V aplikacijo Ingress dodajte delček strežnika z naslednjo vsebino:

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

Kot lahko vidite, moramo za vsako napako, ki jo želimo obdelati, narediti svojo lokacijo, kamor bodo vstavljene vse potrebne glave, kot v »domači«. strani z napakami po meri. Tako lahko ustvarimo različne prilagojene strani z napakami tudi za posamezne lokacije in strežnike.

PS

Drugo iz serije nasvetov in zvijač K8s:

• «Prenos virov, ki se izvajajo v gruči, v upravljanje Helm 2»;
• «O dodeljevanju vozlišč in obremenitvah spletne aplikacije»;
• «Dostop do spletnih mest za razvijalce»;
• «Pospešitev zagona za velike baze podatkov".

Preberite tudi na našem blogu:

• «Nazaj k mikrostoritvam z Istio. 1. del»;
• «[Ilustrirano] Vodnik za mreženje v Kubernetesu. 3. del".

Vir: www.habr.com