Kubernetese näpunäited ja nipid: kohandatud vealehed NGINX Ingressis

Kubernetese näpunäited ja nipid: kohandatud vealehed NGINX Ingressis

Selles artiklis tahan rääkida kahest NGINX Ingressi funktsioonist, mis on seotud isikupärastatud vealehtede kuvamisega, samuti nendes esinevatest piirangutest ja nende ümbertöötamise viisidest.

1. Vaikimisi taustaprogrammi muutmine

Vaikimisi kasutab NGINX Ingress vaikimisi taustaprogrammi, mis täidab vastavat funktsiooni. See tähendab, et kui taotlete sissepääsu, mis määrab hosti, mida sisestusressurssides pole, saame järgmise lehe vastusekoodiga 404:

Kubernetese näpunäited ja nipid: kohandatud vealehed NGINX Ingressis

Üha sagedamini tulevad meie kliendid aga sooviga näidata oma lehte tavapärase 404 asemel ettevõtte logo ja muude mugavustega. Selleks on NGINX Ingressil sisseehitatud võimalus uuesti määratleda default-backend-service. Edastame vormingukirje argumendina samanimelisele valikule namespace/servicename. Teenuse port peaks olema 80.

Selleks peate oma rakendusega looma oma tasku (juurutuse) ja teenuse (rakendamise näide YAML-is ingress-nginx hoidlast), mis antakse vaikimisi taustaprogrammi 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>The page you're looking for could not be found.</span>

Nii et kõik domeenid, mis pole otseselt YAML-i kaudu loodud, koos kind: Ingress, kuuluvad vaike-taustaprogrammi. Ülaltoodud loendis sai see domeen sadsdasdas.

2. HTTP-tõrgete käsitlemine rakenduses vaikimisi taustaprogrammi abil

Teine olukord on HTTP vigadega lõppevad päringud (404, 500, 502...) rakendusele, mis selliseid olukordi ei töötle (vastavaid ilusaid lehti ei genereerita). Selle põhjuseks võib olla ka arendajate soov esitada samu vealehti mitmes rakenduses.

Selle juhtumi juurutamiseks serveri poolel vajame:

  1. Järgige ülaltoodud juhiseid vaiketaustaprogrammi käsitlevas lõigus;
  2. Lisage võti nginxi sissepääsu konfiguratsiooni ConfigMap custom-http-errors, näiteks väärtusega 404,503 (vastab ilmselgelt veakoodidele, mida uus reegel hõlmab).

Oodatud tulemus on saavutatud: kui klientrakendus töötab ja saab tõrketeate vastusekoodiga 404 või 503, suunatakse päring automaatselt ümber uude vaiketaustaprogrammi...

Vaikimisi taustaprogrammi ja kohandatud http-vigade jaoks mõeldud rakenduse arendamisel peate siiski arvestama ühe olulise funktsiooniga:

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

Fakt on see, et päringu ümbersuunamisel sisaldavad päised kasulikku teavet eelmise vastuse koodiga ja lisateavet (nende täielik nimekiri on saadaval siin).

See tähendab, et peate ise hoolitsege õige vastusekoodi eest. Siin on näide. dokumentatsioonist, kuidas see töötab.

Erinevatel rakendustel on erinevad vaiketaustaprogrammid

Tagamaks, et lahendus ei oleks kogu klastri jaoks globaalne, vaid kehtiks ainult konkreetsete rakenduste puhul, tuleb esmalt kontrollida Ingressi versiooni. Kui sobib 0.23 või kõrgem, kasutage natiivseid Ingressi märkusi:

  1. Saame alistada default-backend eest iga Ingressi oma annotatsioonide kasutamine;
  2. Saame alistada custom-http-errors eest iga Ingressi oma annotatsioonide kasutamine.

Selle tulemusel näeb Ingressi ressurss välja umbes selline:

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 koos kõigi vajalike päistega vealehtede teenusesse.

В Ingressi varasemates versioonides seda funktsiooni ei olnud (saatuslik toime 0.23 juures). Ja kui teie klastris töötab 2 täiesti erinevat rakendust ja soovite igaühe jaoks määrata erineva vaike-taustateenuse ja erinevate veakoodide töötlemise, peate selleks kasutama lahendusi, millest meil on kaks.

Sissepääs < 0.23: lähenemine ühele

See valik on lihtsam. Oma lehti teenindava rakendusena on meil tavaline HTML, mis ei tea, kuidas päiseid vaadata ja õigeid vastusekoode tagastada. Selline rakendus avaldatakse URL-ist koos Ingressiga /error-pagesja kataloogis ws on tagastatud 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 juurutuse teenus peab olema ClusterIP tüüpi.

Samal ajal lisame rakenduses, kus viga töötleme, Ingressis järgmise sisuga serverijupi või konfiguratsioonijupi:

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

Sissepääs < 0.23: teine ​​lähenemine

Valik rakendusele, mis suudab päiseid töödelda... Ja üldiselt on see korrektsem viis, laenatud custom-http-vigadest. Selle käsitsi kasutamine (kopeerimine) võimaldab teil mitte muuta globaalseid sätteid.

Toimingud on järgmised. Meie loome sama kasutuselevõtt rakendusega, mis suudab vajalikke pealkirju kuulata ja õigesti vastata. Lisage rakendusele Ingress järgmise sisuga serverijupp:

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äete, peame iga töödeldava vea jaoks määrama oma asukoha, kuhu sisestatakse kõik vajalikud päised, nagu ka "natiivses" päises. kohandatud vealehed. Nii saame luua erinevaid isikupärastatud vealehti isegi üksikute asukohtade ja serverite jaoks.

PS

Muud K8s näpunäidete ja nippide seeriast:

Loe ka meie blogist:

Allikas: www.habr.com

Lisa kommentaar