Kubernetes-en aholkuak eta trikimailuak: errore-orri pertsonalizatuak NGINX Ingress-en

Artikulu honetan, errore-orri pertsonalizatuak bistaratzearekin lotutako NGINX Ingress-en bi ezaugarriei buruz hitz egin nahi dut, baita horietan dauden mugei eta horien inguruan lan egiteko moduei buruz ere.

1. Backend lehenetsia aldatzea

Lehenespenez, NGINX Ingress-ek backend lehenetsia erabiltzen du, dagokion funtzioa betetzen duena. Horrek esan nahi du Ingress baliabideetan ez dagoen ostalari bat zehazten duen Ingress bat eskatzean, hurrengo orrialdea jasotzen dugula 404 erantzun-kode batekin:

Hala ere, gero eta maizago etortzen dira gure bezeroak 404 estandarraren ordez logo korporatiboa eta beste erosotasun batzuk dituen orria erakusteko eskaerarekin. Horretarako, NGINX Ingress-ek barne-gaitasuna birdefinitu default-backend-service. Formatu sarrera argumentu gisa pasatzen diogu izen bereko aukerari namespace/servicename. Zerbitzuaren portuak 80 izan behar du.

Horretarako, zure pod (hedapena) eta zerbitzu propioa sortu behar duzu zure aplikazioarekin (adibidea YAML-n inplementatzea ingress-nginx biltegitik), backend lehenetsiaren ordez emango dena.

Hona hemen ilustrazio txiki bat:

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

Beraz, YAML bidez esplizituki sortzen ez diren domeinu guztiak kind: Ingress, default-backend-ean erori. Goiko zerrendan, domeinu hau bihurtu zen sadsdasdas.

2. Aplikazioan HTTP erroreak kudeatzea backend lehenetsia erabiliz

Beste egoera bat HTTP erroreetan amaitzen diren eskaerak dira (404, 500, 502...) horrelako egoerak prozesatzen ez dituen aplikazio bati (dagozkion orrialde ederrak ez dira sortzen). Garatzaileek hainbat aplikaziotan errore-orri berberak hornitzeko nahia izateagatik ere gerta daiteke.

Kasu hau zerbitzariaren aldean ezartzeko:

1. Jarraitu backend lehenetsiari buruzko paragrafoko goiko argibideak;
2. Gehitu gako bat nginx-ingress ConfigMap konfigurazioari custom-http-errors, adibidez, balioarekin 404,503 (Arau berriak jasotzen dituen errore-kodeei dagokie, jakina).

Espero den emaitza lortu da: bezeroaren aplikazioa exekutatzen ari denean eta 404 edo 503 erantzun-kode batekin errore bat jasotzen duenean, eskaera automatikoki birbideratuko da backend lehenetsi berrira...

Hala ere, backend lehenetsietarako eta pertsonalizatutako http-erroreetarako aplikazio bat garatzean, ezaugarri garrantzitsu bat hartu behar duzu kontuan:

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

Izan ere, eskaera bat birbideratzen denean, goiburuek informazio erabilgarria izango dute aurreko erantzun-kodearekin eta informazio osagarriarekin (beren zerrenda osoa eskuragarri dago Hemen).

Horrek esan nahi du zuk zeuk behar duzula zaindu erantzun-kode zuzena. Hona hemen adibide bat dokumentaziotik nola funtzionatzen duen.

Aplikazio ezberdinek backend lehenetsi desberdinak dituzte

Irtenbidea kluster osorako globala ez dela ziurtatzeko, baina aplikazio zehatzei soilik aplikatzen zaiela, lehenik Ingress bertsioa egiaztatu behar duzu. Etortzen bada 0.23 edo handiagoa, erabili jatorrizko Ingress oharrak:

1. Gainditu dezakegu default-backend egiteko bakoitzeko Sarrerarena oharrak erabiliz;
2. Gainditu dezakegu custom-http-errors egiteko bakoitzeko Sarrerarena oharrak erabiliz.

Ondorioz, Ingress baliabideak itxura hau izango du:

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

Kasu honetan, 404 eta 502 erroreak errore-orrien zerbitzura birbideratuko dira beharrezko goiburu guztiekin.

В Ingress-en aurreko bertsioek ez zuten ezaugarri hori (zorigaiztoko konpromisoa 0.23an). Eta zure klusterrean 2 aplikazio guztiz desberdinak exekutatzen badituzu eta haietako bakoitzarentzako errore-kode desberdinen eta errore-kode desberdinen prozesamendu lehenetsi bat zehaztu nahi baduzu, horretarako konponbideak erabili beharko dituzu, horietako bi ditugu.

Sarrera < 0.23: hurbildu bat

Aukera hau sinpleagoa da. Bere orrialdeak zerbitzatzen dituen aplikazio gisa, HTML arrunta dugu, goiburuak begiratu eta erantzun-kode zuzenak itzultzen ez dakiena. Aplikazio hori Ingress-ekin zabaltzen da url-etik /error-pages, eta katalogoan ws itzuliko HTMLa izango da.

Ilustrazioa YAML-n:

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

Inplementazio honen zerbitzuak ClusterIP motakoa izan behar du.

Aldi berean, errorea prozesatuko dugun aplikazioan, Ingress-en zerbitzari-snippet edo konfigurazio-snippet bat gehitzen dugu honako edukiarekin:

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

Sarrera < 0.23: bigarren hurbilketa

Goiburuak prozesatu ditzakeen aplikazio baterako aukera bat... Eta orokorrean hau modu zuzenagoa da, custom-http-errors-etatik mailegatua. Eskuz erabiltzeak (kopiatzeak) ezarpen orokorrak ez aldatzeko aukera emango du.

Urratsak hauek dira. Guk sortzen dugu hedapen bera beharrezko tituluak entzun eta zuzen erantzuteko gai den aplikazio batekin. Gehitu zerbitzari-zati bat Ingress aplikaziora eduki hau duena:

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

Ikusten duzunez, prozesatu nahi dugun errore bakoitzeko, geure kokapena egin behar dugu, non beharrezko goiburu guztiak txertatuko diren, “natiboan” bezala. Ohiko-error-orriak. Horrela, errore-orri pertsonalizatu desberdinak sor ditzakegu kokapen eta zerbitzari indibidualetarako ere.

PS

K8s aholku eta trikimailu serieko beste batzuk:

• «Kluster batean exekutatzen diren baliabideak Helm 2 kudeaketara transferitzea»;
• «Web aplikazio bateko nodoen esleipenari eta kargari buruz»;
• «Garatzaile guneetarako sarbidea»;
• «Datu-base handietarako bootstrap bizkortzea'.

Irakurri ere gure blogean:

• «Itzuli mikrozerbitzuetara Istio-rekin. 1. zatia»;
• «[Ilustrazioa] Kubernetes-en sareko gida. 3. zatia'.

Iturria: www.habr.com