🥇Kubernetesi näpunäited ja nipid: isikupärastatud vea lehed NGINX Ingressis

Selles artiklis tahan rääkida kahest võimalusest, mis on seotud NGINX Ingressiga, mis puudutavad personaliseeritud vealehtede kuvamist, samuti nende piirangutest ja viisidest, kuidas neid ületada.

1. Vaikimisi tagaproksi muutmine

Vaikimisi kasutab NGINX Ingress default backend'i, mis täidab vastavat funktsiooni. See tähendab, et kui Ingress'i päringule esitatakse host, mida pole Ingress-resurssides, saame sellise lehe vastuskoodiga 404:

Kuid üha enam tulevad meie kliendid sooviga, et standardse 404 asemel kuvataks nende logo ja muid mugavustega leht. Selleks on NGINX Ingressil sisseehitatud võimalus ülekirjutada default-backend-service. Selle nimetusega valikule edastame argumendina salvestuse formaadis namespace/servicename. Teenuse port peab olema 80.

Selleks on vajalik luua oma pod (deployment) ja teenus oma rakendusega (YAML näidisrakenduse rakendamine ingress-nginx hoidlas), mida antakse välja vaikimisi tagaproksina.

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>Otsitavat lehte ei leitud.</span>

Nii on kõik domeenid, mis ei ole selgelt loodud YAML kaudu koos kind: Ingress, sattuvad default-backendi. Ülaltoodud loendis sai selliseks domeeniks sadsdasdas.

2. HTTP-vigade töötlemine rakenduses vaikimisi tagaproksi kaudu

Teine olukord on HTTP-vigadega (404, 500, 502…) päringud rakendusele, mis selliseid olukordi ei tööta (ei genereerita vastavaid ilusaid lehti). Seda võib samuti põhjustada arendajate soov anda sama vealehte paljudes rakendustes.

Selle juhtumi teostamiseks serveripoolsel tasandil on meil vaja:

Teha ülaltoodud juhiseid vaikimisi tagaproksi kohta;
Lisada nginx-ingressi konfiguratsiooni ConfigMap võtme custom-http-errors, näiteks väärtusega 404,503 (ilmselgelt vastab see vigade koodidele, millele uus reegel laieneb).

Oodatud tulemus saavutati: kliendirakenduse töötamisel ja vastuse koodiga 404 või 503 saamisel suunatakse päring automaatselt uude vaikimisi tagaproksi...

Kuid vaikimisi tagaproksi ja custom-http-errors'i rakendamisel tuleb arvesse võtta olulist nähtust:

!!! Oluline Oodatakse, et kohandatud tagaproksi tagastaks õige HTTP staatuse koodi, mitte 200. NGINX ei muuda kohandatud vaikimisi tagaproksi vastust.

As it turns out, when redirecting a request, there will be useful information in the headers with the previous response code and additional information (a complete list is available siin).

This means you need to take care of the correct response code. Here is an example from the documentation on how this works.

Different applications require different default backends

To ensure the solution isn't global for the entire cluster, but rather applies only to specific applications, you first need to check the Ingress version. If it matches 0.23 or higher, use the 'native' Ingress annotations:

We can override default-backend jaoks of each Ingress with the help of an annotation;
We can override custom-http-errors jaoks of each Ingress with the help of an annotation.

As a result, the Ingress resource will look something like this:

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

In this case, errors 404 and 502 will be redirected to the error-pages service with all the necessary headers.

Uues previous versions of Ingress did not have this capability (the fateful commit in 0.23). And if you have 2 completely different applications running in your cluster and want to specify different default-backend-services and handle different error codes for each — you'll need to use workarounds, of which we have two.

Ingress < 0.23: the first approach

This option is simpler. As an application serving its pages, we have a regular HTML that cannot look at headers and return correct response codes. Such an application is rolled out with Ingress at the url /error-pages, and the directory ws will contain the served HTML.

Illustration in 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

The service for this deployment must be of type ClusterIP.

Meanwhile, in the application where we will handle the error, we add a server-snippet or configuration-snippet in the Ingress with the following content:

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

Ingress < 0.23: teine lähenemine

Rakenduse variant, mis suudab päiseid töödelda... Üldiselt on see korrektsem tee, võetud custom-http-errors'ist. Selle käsitsi (kopeerimise) kasutamine ei muuda globaalseid seadeid.

Järgmised sammud. Loome sama deployment'i rakendusega, mis suudab kuulata vajalikke päiseid ja vastata õigesti. Lisame rakenduse Ingress'i serveri lõigu järgmise sisuga:

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

Kuidas näha, et iga veakoodi, mida tahame töödelda, tuleb luua oma location, kuhu lisatakse kõik vajalikud päised nagu "poleemikas" custom-error-pages. Nii saame luua erinevaid personaliseeritud veateate lehti isegi erinevate location'ite ja serverite jaoks.