Съвети и трикове на Kubernetes: персонализирани страници за грешки в NGINX Ingress

В тази статия искам да говоря за две функции на NGINX Ingress, свързани с показването на персонализирани страници за грешки, както и за техните ограничения и начини за заобикалянето им.

1. Променете бекенда по подразбиране

По подразбиране NGINX Ingress използва бекенда по подразбиране, който изпълнява съответната функция. Това означава, че когато поискаме Ingress с хост, който не е в ресурсите на Ingress, получаваме тази страница с код за отговор 404:

Въпреки това все по-често клиентите ни идват с молба да им покажем страницата си с фирмено лого и други удобства вместо стандартния 404. За това NGINX Ingress има вградена способност предефинирам default-backend-service. Предаваме записа на формата като аргумент на опцията със същото име namespace/servicename. Сервизният порт трябва да е 80.

За да направите това, трябва да създадете свой собствен pod (разгръщане) и услуга с вашето приложение (примерна реализация в YAML от хранилището на ingress-nginx), който ще бъде даден вместо бекенда по подразбиране.

Ето малка илюстрация:

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

Така че всички домейни, които не са изрично създадени чрез YAML с kind: Ingress, попадат в бекенда по подразбиране. В списъка по-горе този домейн стана sadsdasdas.

2. Обработка на HTTP грешки в приложението от бекенда по подразбиране

Друга ситуация са заявки, завършващи с HTTP грешки (404, 500, 502…) към приложение, което не обработва такива ситуации (не се генерират съответните красиви страници). Може също да е причинено от желанието на разработчиците да връщат едни и същи страници с грешки в множество приложения.

За да приложим този случай от страна на сървъра, имаме нужда от:

1. Следвайте инструкциите по-горе от параграфа за бекенда по подразбиране;
2. Добавете ключа към конфигурацията ConfigMap nginx-ingress custom-http-errors, например със стойността 404,503 (очевидно съвпада с кодовете за грешки, обхванати от новото правило).

Очакваният резултат е постигнат: когато клиентското приложение работи и получава грешка с код за отговор 404 или 503, заявката ще бъде автоматично пренасочена към новия бекенд по подразбиране ...

Въпреки това, когато разработвате приложение за бекенд по подразбиране и персонализирани http-грешки, трябва да се вземе предвид една важна характеристика:

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

Факт е, че когато заявката бъде пренасочена, заглавките ще съдържат полезна информация с предишния код на отговор и допълнителна информация (пълният им списък е наличен тук).

Това означава, че трябва погрижете се за правилния код за отговор. Ето един пример от документацията как работи.

Различни приложения - различен бекенд по подразбиране

Така че решението не е глобално за целия клъстер, а се отнася само за конкретни приложения, първо трябва да проверите версията на Ingress. Ако съвпада 0.23 или по-висока, използвайте собствените анотации на Ingress:

1. Можем да предефинираме default-backend за всеки Влизане с анотация;
2. Можем да предефинираме custom-http-errors за всеки Влизане с анотация.

В резултат на това ресурсът на Ingress ще изглежда по следния начин:

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

В този случай грешките 404 и 502 ще бъдат пренасочени към услугата за страници с грешки с всички необходими заглавки.

В предишните версии на Ingress нямаха тази функция. (съдбоносен ангажимент в 0.23). И ако имате 2 напълно различни приложения, работещи във вашия клъстер и искате да посочите различни услуги по подразбиране и обработка на различни кодове за грешка за всяко от тях, ще трябва да използвате заобиколни решения за това, от които имаме две.

Ingress < 0.23: подход едно

Тази опция е по-проста. Като приложение, което изобразява своите страници, имаме обикновен HTML, който не знае как да разглежда заглавките и да връща правилни кодове за отговор. Такова приложение се пуска с Ingress с url /error-pages, и в указателя ws ще бъде даден HTML.

Илюстрация в 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

Услугата за това внедряване трябва да е от тип ClusterIP.

В същото време в приложението, където ще обработваме грешката, в Ingress добавяме сървърен фрагмент или конфигурационен фрагмент със следното съдържание:

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

Влизане < 0.23: втори подход

Вариант за приложение, което може да обработва хедъри ... И като цяло това е по-правилен начин, заимстван от custom-http-errors. Използването му ръчно (копиране) ще ви позволи да не променяте глобалните настройки.

Стъпките са както следва. Ние създаваме същото разгръщане с приложение, което може да слуша правилните заглавки и да отговаря правилно. Добавяме сървърни приложения към Ingress със следното съдържание:

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

Както можете да видите, за всяка грешка, която искаме да обработим, трябва да направим наше собствено местоположение, където ще бъдат заменени всички необходими заглавки, както в "native" custom-error-страници. По този начин можем да създадем различни персонализирани страници за грешки дори за отделни местоположения и сървъри.

PS

Други от серията съвети и трикове на K8s:

• «Прехвърляне на ресурси, работещи в клъстера под контрола на Helm 2»;
• «Относно разпределението на възлите и натоварванията на уеб приложението»;
• «Достъп до сайтове за разработчици»;
• «Ускоряване на bootstrap за големи бази данни".

Прочетете също в нашия блог:

• «Обратно към микроуслугите с Istio. Част 1»;
• «[Илюстрирано] Ръководство за работа в мрежа на Kubernetes. Част 3".

Източник: www.habr.com