Konsiloj kaj lertaĵoj de Kubernetes: kutimaj eraraj paĝoj en NGINX Ingress

En ĉi tiu artikolo, mi volas paroli pri du trajtoj de NGINX Ingress rilataj al montrado de personigitaj eraraj paĝoj, same kiel la limigoj, kiuj ekzistas en ili, kaj manieroj labori ĉirkaŭ ili.

1. Ŝanĝi la defaŭltan backend

Defaŭlte, NGINX Ingress uzas la defaŭltan backend, kiu plenumas la respondan funkcion. Ĉi tio signifas, ke kiam oni petas Eniron specifantan gastiganton kiu ne estas en la Ingress-resursoj, ni ricevas la sekvan paĝon kun respondkodo 404:

Tamen, pli kaj pli ofte niaj klientoj venas kun peto montri sian paĝon kun kompania emblemo kaj aliaj agrablaĵoj anstataŭ la norma 404. Por fari tion, NGINX Ingress havas enkonstruita kapableco redifini default-backend-service. Ni pasas la formatan eniron kiel argumenton al la samnoma opcio namespace/servicename. La haveno de la servo devus esti 80.

Por fari tion, vi devas krei vian propran pod (deplojo) kaj servon kun via aplikaĵo (ekzempla efektivigo en YAML de la deponejo ingress-nginx), kiu estos donita anstataŭ la defaŭlta backend.

Jen malgranda ilustraĵo:

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

Do ĉiuj domajnoj kiuj ne estas eksplicite kreitaj per YAML kun kind: Ingress, falu en defaŭltan backend. En la supra listo, ĉi tiu domajno fariĝis sadsdasdas.

2. Pritrakti HTTP-erarojn en la aplikaĵo uzante la defaŭltan backend

Alia situacio estas petoj finiĝantaj per HTTP-eraroj (404, 500, 502...) al aplikaĵo, kiu ne prilaboras tiajn situaciojn (la respondaj belaj paĝoj ne estas generitaj). Ĉi tio ankaŭ povas esti pro la deziro de programistoj servi la samajn erarpaĝojn en pluraj aplikoj.

Por efektivigi ĉi tiun kazon ĉe la servilo ni bezonas:

1. Sekvu la suprajn instrukciojn de la alineo pri defaŭlta backend;
2. Aldonu ŝlosilon al la nginx-ingress-agordo ConfigMap custom-http-errors, ekzemple, kun la valoro 404,503 (evidente respondas al la erarkodoj kiuj estas kovritaj de la nova regulo).

La atendata rezulto estis atingita: kiam la klienta aplikaĵo funkcias kaj ricevas eraron kun respondkodo de 404 aŭ 503, la peto estos aŭtomate redirektita al la nova defaŭlta backend...

Tamen, dum disvolvado de aplikaĵo por defaŭlta backend kaj kutimaj http-eraroj, vi devas konsideri gravan funkcion:

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

Fakte, kiam peto estas alidirektita, la kaplinioj enhavos utilajn informojn kun la antaŭa respondkodo kaj pliajn informojn (ilia kompleta listo disponeblas tie).

Ĉi tio signifas, ke vi mem devas prizorgu la ĝustan respondkodon. Jen ekzemplo de la dokumentaro kiel ĝi funkcias.

Malsamaj aplikoj havas malsamajn defaŭltajn backends

Por certigi, ke la solvo ne estas tutmonda por la tuta areto, sed validas nur por specifaj aplikoj, vi unue devas kontroli la Ingress-version. Se ĝi kongruas 0.23 aŭ pli alta, uzu la denaskajn Ingress-kotadojn:

1. Ni povas superregi default-backend por ĉiu Eniro de uzante komentariojn;
2. Ni povas superregi custom-http-errors por ĉiu Eniro de uzante komentariojn.

Kiel rezulto, la rimedo Ingress aspektos kiel ĉi tio:

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

En ĉi tiu kazo, eraroj 404 kaj 502 estos redirektitaj al la servo de erarpaĝoj kun ĉiuj necesaj kaplinioj.

В antaŭaj versioj de Ingress ne havis ĉi tiun funkcion (fatala kompromiso ĉe 0.23). Kaj se vi havas 2 tute malsamajn aplikojn kurantajn en via areto kaj vi volas specifi malsaman defaŭltan-backend-servon kaj prilaboradon de malsamaj erarkodoj por ĉiu el ili, por tio vi devos uzi solvojn, el kiuj ni havas du.

Eniro < 0.23: alproksimiĝu al unu

Ĉi tiu opcio estas pli simpla. Kiel aplikaĵo, kiu servas ĝiajn paĝojn, ni havas regulan HTML, kiu ne scias kiel rigardi la kapliniojn kaj resendi la ĝustajn respondkodojn. Tia aplikaĵo estas lanĉita kun Ingress de la url /error-pages, kaj en la katalogo ws estos la resendita HTML.

Ilustraĵo en 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

La servo por ĉi tiu deplojo devas esti de la tipo ClusterIP.

Samtempe, en la aplikaĵo, kie ni prilaboros la eraron, en Ingress ni aldonas servilon-fragmenton aŭ agordo-fragmenton kun la sekva enhavo:

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

Eniro < 0.23: dua alproksimiĝo

Opcio por aplikaĵo, kiu povas prilabori titolojn... Kaj ĝenerale ĉi tio estas pli ĝusta maniero, pruntita de custom-http-eraroj. Uzi ĝin permane (kopiante) permesos al vi ne ŝanĝi tutmondajn agordojn.

La paŝoj estas kiel sekvas. Ni kreas sama deplojo kun aplikaĵo, kiu povas aŭskulti la necesajn titolojn kaj respondi ĝuste. Aldonu servilan fragmenton al la aplikaĵo Ingress kun la sekva enhavo:

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

Kiel vi povas vidi, por ĉiu eraro, kiun ni volas prilabori, ni devas fari nian propran lokon, kie ĉiuj necesaj kaplinioj estos enmetitaj, kiel en la "denaska". kutimo-eraraj-paĝoj. Tiel ni povas krei malsamajn personigitajn erarpaĝojn eĉ por individuaj lokoj kaj serviloj.

PS

Aliaj el la serio de konsiletoj kaj lertaĵoj K8s:

• «Transdonante rimedojn kurantajn en areto al administrado de Helm 2»;
• «Pri noda atribuo kaj ŝarĝoj sur TTT-apliko»;
• «Aliro al dev-ejoj»;
• «Akcelo de ekfunkciigo por grandaj datumbazoj".

Legu ankaŭ en nia blogo:

• «Reen al mikroservoj kun Istio. Parto 1»;
• «[Ilustrita] Gvidilo pri retigado en Kubernetes. Parto 3".

fonto: www.habr.com