Kubernetes padomi un triki: pielāgotas kļūdu lapas pakalpojumā NGINX Ingress

Šajā rakstā es vēlos runāt par divām NGINX Ingress funkcijām, kas saistītas ar personalizētu kļūdu lapu parādīšanu, kā arī par tajās esošajiem ierobežojumiem un veidiem, kā tos apiet.

1. Noklusējuma aizmugursistēmas maiņa

Pēc noklusējuma NGINX Ingress izmanto noklusējuma aizmugursistēmu, kas veic atbilstošo funkciju. Tas nozīmē, ka, pieprasot Ingress, norādot resursdatoru, kas nav Ingress resursos, mēs saņemam šādu lapu ar 404 atbildes kodu:

Tomēr arvien biežāk mūsu klienti nāk ar lūgumu parādīt savu lapu ar korporatīvo logotipu un citām ērtībām standarta 404 vietā. Lai to izdarītu, NGINX Ingress ir iebūvēta iespēja pārdefinēt default-backend-service. Mēs nododam formāta ierakstu kā argumentu tāda paša nosaukuma opcijai namespace/servicename. Pakalpojuma portam jābūt 80.

Lai to izdarītu, jums ir jāizveido savs pods (izvietošana) un pakalpojums ar savu lietojumprogrammu (ieviešanas piemērs YAML no ingress-nginx repozitorija), kas tiks dota noklusējuma aizmugursistēmas vietā.

Šeit ir neliela ilustrācija:

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

Tātad visi domēni, kas nav tieši izveidoti, izmantojot YAML, ar kind: Ingress, ietilpst noklusējuma aizmugursistēmā. Iepriekš minētajā sarakstā šis domēns kļuva sadsdasdas.

2. HTTP kļūdu apstrāde lietojumprogrammā, izmantojot noklusējuma aizmugursistēmu

Cita situācija ir pieprasījumi, kas beidzas ar HTTP kļūdām (404, 500, 502...) lietojumprogrammai, kas šādas situācijas neapstrādā (atbilstošās skaistās lapas netiek ģenerētas). Tas var būt saistīts arī ar izstrādātāju vēlmi apkalpot vienas un tās pašas kļūdu lapas vairākās lietojumprogrammās.

Lai ieviestu šo gadījumu servera pusē, mums ir nepieciešams:

1. Izpildiet iepriekš sniegtos norādījumus rindkopā par noklusējuma aizmugursistēmu;
2. Pievienojiet atslēgu nginx-ingress konfigurācijai ConfigMap custom-http-errors, piemēram, ar vērtību 404,503 (acīmredzami atbilst kļūdu kodiem, uz kuriem attiecas jaunais noteikums).

Paredzētais rezultāts ir sasniegts: kad klienta lietojumprogramma darbojas un saņem kļūdu ar atbildes kodu 404 vai 503, pieprasījums tiks automātiski novirzīts uz jauno noklusējuma aizmugursistēmu...

Tomēr, izstrādājot lietojumprogrammu noklusējuma aizmugursistēmai un pielāgotajām http kļūdām, jums ir jāņem vērā svarīga funkcija:

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

Fakts ir tāds, ka, pāradresējot pieprasījumu, galvenēs būs noderīga informācija ar iepriekšējo atbildes kodu un papildu informācija (ir pieejams pilns to saraksts šeit).

Tas nozīmē, ka jums pašam tas ir jādara rūpējieties par pareizu atbildes kodu. Šeit ir piemērs no dokumentācijas, kā tas darbojas.

Dažādām lietojumprogrammām ir dažādas noklusējuma aizmugursistēmas

Lai nodrošinātu, ka risinājums nav globāls visam klasterim, bet attiecas tikai uz noteiktām lietojumprogrammām, vispirms ir jāpārbauda Ingress versija. Ja sakrīt 0.23 vai vairāk, izmantojiet vietējās Ingress anotācijas:

1. Mēs varam ignorēt default-backend par no katra Ingress's izmantojot anotācijas;
2. Mēs varam ignorēt custom-http-errors par no katra Ingress's izmantojot anotācijas.

Rezultātā Ingress resurss izskatīsies apmēram šādi:

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

Šajā gadījumā kļūdas 404 un 502 tiks novirzītas uz kļūdu lapu pakalpojumu ar visām nepieciešamajām galvenēm.

В iepriekšējās Ingress versijās šīs funkcijas nebija (liktenīgā apņemšanās pie 0.23). Un, ja jūsu klasterī darbojas 2 pilnīgi atšķirīgas lietojumprogrammas un katrai no tām vēlaties norādīt citu noklusējuma aizmugursistēmas pakalpojumu un dažādu kļūdu kodu apstrādi, jums būs jāizmanto risinājumi, no kuriem mums ir divi.

Ieeja < 0.23: tuvojas vienam

Šī opcija ir vienkāršāka. Kā lietojumprogramma, kas apkalpo savas lapas, mums ir parastais HTML, kas nezina, kā apskatīt galvenes un atgriezt pareizos atbildes kodus. Šāda lietojumprogramma tiek izlaista ar Ingress no url /error-pages, un katalogā ws būs atgrieztais HTML.

Ilustrācija YAML valodā:

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

Šīs izvietošanas pakalpojumam ir jābūt ClusterIP tipam.

Tajā pašā laikā lietojumprogrammā, kurā mēs apstrādāsim kļūdu, programmā Ingress pievienojam servera fragmentu vai konfigurācijas fragmentu ar šādu saturu:

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

Iekļūšana < 0.23: otrā pieeja

Opcija lietojumprogrammai, kas var apstrādāt galvenes... Un vispār šis ir pareizāks veids, aizgūts no custom-http-kļūdām. Manuāla lietošana (kopēšana) ļaus nemainīt globālos iestatījumus.

Darbības ir šādas. Mēs radām tāda pati izvietošana ar aplikāciju, kas spēj noklausīties nepieciešamos virsrakstus un pareizi atbildēt. Pievienojiet lietojumprogrammai Ingress servera fragmentu ar šādu saturu:

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

Kā redzat, katrai kļūdai, kuru vēlamies apstrādāt, mums ir jāizveido sava atrašanās vieta, kurā tiks ievietotas visas nepieciešamās galvenes, tāpat kā “vietējā”. pielāgotas kļūdu lapas. Tādā veidā mēs varam izveidot dažādas personalizētas kļūdu lapas pat atsevišķām atrašanās vietām un serveriem.

PS

Citi no K8s padomu un triku sērijas:

• «Klasterī darbojošos resursu pārsūtīšana, ko kontrolē Helm 2";
• «Par mezglu piešķiršanu un slodzēm tīmekļa lietojumprogrammā";
• «Piekļuve izstrādes vietnēm";
• «Sāknēšanas paātrināšana lielām datu bāzēm'.

Lasi arī mūsu emuārā:

• «Atgriezties uz mikropakalpojumiem ar Istio. 1. daļa";
• «[Ilustrēts] Rokasgrāmata tīkla izveidei pakalpojumā Kubernetes. 3. daļa'.

Avots: www.habr.com