Kubernetes-vinkkejä ja temppuja: mukautetut virhesivut NGINX Ingressissä

Tässä artikkelissa haluan puhua kahdesta NGINX Ingressin ominaisuudesta, jotka liittyvät henkilökohtaisten virhesivujen näyttämiseen, sekä niillä olevista rajoituksista ja tavoista kiertää ne.

1. Oletuksena olevan taustaohjelman muuttaminen

Oletusarvoisesti NGINX Ingress käyttää oletustaustaa, joka suorittaa vastaavan toiminnon. Tämä tarkoittaa, että kun pyydämme Ingressiä, jossa määritellään isäntä, joka ei ole Ingress-resursseissa, saamme seuraavan sivun 404-vastauskoodilla:

Asiakkaamme tulevat kuitenkin yhä useammin pyyntöön näyttää sivunsa yrityslogolla ja muilla mukavuuksilla tavallisen 404:n sijaan. Tätä varten NGINX Ingressillä on sisäänrakennettu ominaisuus uudelleenmääritellä default-backend-service. Välitämme muotomerkinnän argumenttina samannimiselle vaihtoehdolle namespace/servicename. Palvelun portin tulee olla 80.

Tätä varten sinun on luotava oma pod (käyttöönotto) ja palvelu sovelluksesi kanssa (esimerkkitoteutus YAML:ssa ingress-nginx-arkistosta), joka annetaan oletustaustan sijasta.

Tässä pieni esimerkki:

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

Joten kaikki verkkotunnukset, joita ei ole erikseen luotu YAML:n kautta kind: Ingress, kuuluvat oletustaustajärjestelmään. Yllä olevassa luettelossa tästä verkkotunnuksesta tuli sadsdasdas.

2. HTTP-virheiden käsittely sovelluksessa käyttämällä oletustaustaa

Toinen tilanne on HTTP-virheisiin (404, 500, 502...) päättyvät pyynnöt sovellukselle, joka ei käsittele tällaisia ​​tilanteita (vastaavia kauniita sivuja ei synny). Tämä voi johtua myös siitä, että kehittäjät haluavat tarjota samoja virhesivuja useissa sovelluksissa.

Tämän tapauksen toteuttamiseksi palvelinpuolella tarvitsemme:

1. Noudata yllä olevia ohjeita oletustaustasta;
2. Lisää avain nginx-ingress-kokoonpanoon ConfigMap custom-http-errorsesimerkiksi arvolla 404,503 (vastaa ilmeisesti uuden säännön kattamia virhekoodeja).

Odotettu tulos on saavutettu: kun asiakassovellus on käynnissä ja vastaanottaa virheen, jonka vastauskoodi on 404 tai 503, pyyntö ohjataan automaattisesti uuteen oletustaustajärjestelmään...

Kuitenkin, kun kehität sovellusta oletustaustalle ja mukautettuja http-virheitä varten, sinun on otettava huomioon tärkeä ominaisuus:

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

Tosiasia on, että kun pyyntö uudelleenohjataan, otsikot sisältävät hyödyllistä tietoa edellisen vastauskoodin kanssa ja lisätietoja (niiden täydellinen luettelo on saatavilla täällä).

Tämä tarkoittaa, että sinun täytyy itse huolehdi oikeasta vastauskoodista. Tässä on esimerkki. dokumentaatiosta miten se toimii.

Eri sovelluksilla on erilaiset oletustaustaohjelmat

Varmistaaksesi, että ratkaisu ei ole globaali koko klusterin osalta, vaan koskee vain tiettyjä sovelluksia, sinun on ensin tarkistettava Ingress-versio. Jos vastaa 0.23 tai enemmän, käytä alkuperäisiä Ingress-merkintöjä:

1. Voimme ohittaa default-backend varten kukin Ingressin käyttämällä huomautuksia;
2. Voimme ohittaa custom-http-errors varten kukin Ingressin käyttämällä huomautuksia.

Tämän seurauksena Ingress-resurssi näyttää suunnilleen tältä:

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

Tässä tapauksessa virheet 404 ja 502 ohjataan virhesivupalveluun kaikilla tarvittavilla otsikoilla.

В Ingressin aikaisemmissa versioissa tätä ominaisuutta ei ollut (kohtalokas sitoumus 0.23). Ja jos klusterissasi on käynnissä 2 täysin erilaista sovellusta ja haluat määrittää kullekin niistä erilaisen oletustaustapalvelun ja erilaisten virhekoodien käsittelyn, sinun on käytettävä tätä varten kiertotapoja, joita meillä on kaksi.

Sisääntulo < 0.23: lähestyy yhtä

Tämä vaihtoehto on yksinkertaisempi. Sivujaan palvelevana sovelluksena meillä on tavallinen HTML, joka ei osaa katsoa otsikoita ja palauttaa oikeita vastauskoodeja. Tällainen sovellus otetaan käyttöön Ingressin avulla URL-osoitteesta /error-pages, ja luettelossa ws on palautettu HTML.

Kuva YAML:ssa:

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

Tämän käyttöönoton palvelun on oltava ClusterIP-tyyppinen.

Samanaikaisesti sovellukseen, jossa käsittelemme virheen, lisäämme Ingressiin palvelinkoodinpätkän tai konfiguraatiokoodinpätkän, jossa on seuraava sisältö:

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

Sisääntulo < 0.23: toinen lähestymistapa

Vaihtoehto sovellukselle, joka pystyy käsittelemään otsikoita... Ja yleensä tämä on oikeampi tapa, lainattu custom-http-virheistä. Käyttämällä sitä manuaalisesti (kopioimalla), et voi muuttaa yleisiä asetuksia.

Vaiheet ovat seuraavat. Me luomme sama käyttöönotto sovelluksella, joka voi kuunnella tarvittavat otsikot ja vastata oikein. Lisää Ingress-sovellukseen palvelinkoodinpätkä, jossa on seuraava sisältö:

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

Kuten näet, jokaiselle käsiteltävälle virheelle meidän on tehtävä oma sijainti, johon kaikki tarvittavat otsikot lisätään, kuten "alkuperäisessä" otsikossa. mukautetut virhesivut. Näin voimme luoda erilaisia ​​yksilöllisiä virhesivuja jopa yksittäisille sijainneille ja palvelimille.

PS.

Muita K8s-vinkkejä ja temppuja -sarjasta:

• «Klusterissa käynnissä olevien resurssien siirtäminen Helm 2 -hallintaan";
• «Tietoja solmujen allokoinnista ja latauksista verkkosovelluksessa";
• «Pääsy kehityssivustoille";
• «Bootstrapin nopeuttaminen suurille tietokannoille'.

Lue myös blogistamme:

• «Takaisin mikropalveluihin Istion kanssa. Osa 1";
• «[Kuvitettu] Opas verkottumiseen Kubernetesissa. Osa 3'.

Lähde: will.com