Kubernetes ráð og brellur: sérsniðnar villusíður í NGINX Ingress

Í þessari grein vil ég tala um tvo eiginleika NGINX Ingress sem tengjast því að sýna persónulegar villusíður, svo og takmarkanir sem eru á þeim og leiðir til að vinna í kringum þær.

1. Breyting á sjálfgefna bakenda

Sjálfgefið er að NGINX Ingress notar sjálfgefna bakenda, sem framkvæmir samsvarandi aðgerð. Þetta þýðir að þegar við biðjum um Ingress sem tilgreinir hýsil sem er ekki í Ingress tilföngunum, fáum við eftirfarandi síðu með 404 svarkóða:

Hins vegar koma sífellt oftar viðskiptavinir okkar með beiðni um að sýna síðuna sína með fyrirtækismerki og öðrum þægindum í stað venjulegs 404. Til að gera þetta hefur NGINX Ingress innbyggður hæfileiki endurskilgreina default-backend-service. Við sendum sniðfærsluna sem rök fyrir valkostinn með sama nafni namespace/servicename. Höfn þjónustunnar ætti að vera 80.

Til að gera þetta þarftu að búa til þinn eigin pod (dreifing) og þjónustu með forritinu þínu (dæmi um innleiðingu í YAML frá ingress-nginx geymslunni), sem verður gefið í stað sjálfgefna bakendans.

Hér er lítil mynd:

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

Svo öll lén sem eru ekki beinlínis búin til í gegnum YAML með kind: Ingress, falla í sjálfgefið bakenda. Í skráningunni hér að ofan varð þetta lén sadsdasdas.

2. Meðhöndlun HTTP villur í forritinu með því að nota sjálfgefna bakendann

Önnur staða er beiðnir sem enda á HTTP villum (404, 500, 502...) í forrit sem vinnur ekki úr slíkum aðstæðum (viðsvarandi fallegar síður eru ekki búnar til). Þetta getur líka stafað af löngun þróunaraðila til að þjóna sömu villusíðum í mörgum forritum.

Til að útfæra þetta mál á netþjónahliðinni þurfum við:

1. Fylgdu leiðbeiningunum hér að ofan úr málsgreininni um sjálfgefna bakenda;
2. Bættu lykli við nginx-ingress stillingar ConfigMap custom-http-errors, til dæmis með gildinu 404,503 (svarar augljóslega til villukóðanna sem falla undir nýju regluna).

Áætluð niðurstaða hefur náðst: þegar biðlaraforritið er í gangi og fær villu með svarkóða 404 eða 503, verður beiðninni sjálfkrafa vísað á nýja sjálfgefna bakenda...

Hins vegar, þegar þú þróar forrit fyrir sjálfgefna bakenda og sérsniðnar http-villur, þarftu að taka tillit til mikilvægs eiginleika:

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

Staðreyndin er sú að þegar beiðni er vísað áfram munu hausarnir innihalda gagnlegar upplýsingar með fyrri svarkóða og viðbótarupplýsingum (heill listi þeirra er tiltækur hér).

Þetta þýðir að þú verður sjálfur sjá um réttan svarkóða. Hér er dæmi úr skjölunum hvernig það virkar.

Mismunandi forrit eru með mismunandi sjálfgefna bakenda

Til að tryggja að lausnin sé ekki alþjóðleg fyrir allan klasann, heldur eigi hún aðeins við tiltekin forrit, þarftu fyrst að athuga Ingress útgáfuna. Ef það passar 0.23 eða hærri, notaðu innfæddu Ingress athugasemdirnar:

1. Við getum hnekkt default-backend í af hverju hjá Ingress með því að nota athugasemdir;
2. Við getum hnekkt custom-http-errors í af hverju hjá Ingress með því að nota athugasemdir.

Fyrir vikið mun Ingress tilföngin líta einhvern veginn svona út:

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

Í þessu tilviki verður villum 404 og 502 vísað á villusíðuþjónustuna með öllum nauðsynlegum hausum.

В fyrri útgáfur af Ingress voru ekki með þennan eiginleika (örlagavaldur á 0.23). Og ef þú ert með 2 gjörólík forrit í gangi í þyrpingunni þinni og þú vilt tilgreina aðra sjálfgefna bakendaþjónustu og vinnslu mismunandi villukóða fyrir hvert þeirra, til þess verður þú að nota lausnir, þar af höfum við tvær.

Inngangur < 0.23: nálgast eitt

Þessi valkostur er einfaldari. Sem forrit sem þjónar síðum sínum höfum við venjulegan HTML, sem veit ekki hvernig á að líta á hausana og skila réttum svarkóðum. Slíkt forrit er sett út með Ingress frá slóðinni /error-pages, og í vörulistanum ws verður skilað HTML.

Myndskreyting í 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

Þjónustan fyrir þessa dreifingu verður að vera af ClusterIP gerðinni.

Á sama tíma, í forritinu þar sem við munum vinna úr villunni, í Ingress bætum við netþjónsbúti eða stillingarbúti með eftirfarandi innihaldi:

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

Inngangur < 0.23: önnur nálgun

Valkostur fyrir forrit sem getur unnið úr hausum... Og almennt er þetta réttari leið, fengin að láni frá sérsniðnum-http-villum. Með því að nota það handvirkt (afrita) geturðu ekki breytt alþjóðlegum stillingum.

Skrefin eru sem hér segir. Við sköpum sama dreifing með forriti sem getur hlustað á nauðsynlegar fyrirsagnir og svarað rétt. Bættu netþjónsbúti við Ingress forritið með eftirfarandi efni:

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

Eins og þú sérð, fyrir hverja villu sem við viljum vinna úr, þurfum við að búa til okkar eigin staðsetningu, þar sem allir nauðsynlegir hausar verða settir inn, eins og í „innfæddum“. sérsniðnar villusíður. Þannig getum við búið til mismunandi sérsniðnar villusíður, jafnvel fyrir einstaka staði og netþjóna.

PS

Annað úr K8s tips & tricks röðinni:

• «Flytja tilföng sem keyra í klasa yfir í stjórn Helm 2»;
• «Um úthlutun hnúta og álag á vefforrit»;
• «Aðgangur að þróunarsíðum»;
• «Hraða upp bootstrap fyrir stóra gagnagrunna'.

Lestu líka á blogginu okkar:

• «Aftur í örþjónustur með Istio. 1. hluti»;
• «[Myndskreytt] Leiðbeiningar um netkerfi í Kubernetes. 3. hluti'.

Heimild: www.habr.com