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

Во оваа статија, сакам да зборувам за две карактеристики на NGINX Ingress поврзани со прикажување на персонализирани страници за грешки, како и за ограничувањата што постојат во нив и начините за нивно работење.

1. Промена на стандардниот заднина

Стандардно, NGINX Ingress го користи стандардниот заден дел, кој ја извршува соодветната функција. Ова значи дека кога бараме Ingress со одредување на домаќин што не е во ресурсите на Ingress, ја добиваме следната страница со код за одговор 404:

Сепак, сè почесто нашите клиенти доаѓаат со барање да ја покажат својата страница со корпоративно лого и други погодности наместо стандардниот 404. За да го направите ова, NGINX Ingress има вградена способност редефинира default-backend-service. Записот за формат го пренесуваме како аргумент на опцијата со исто име namespace/servicename. Пристаништето на услугата треба да биде 80.

За да го направите ова, треба да креирате сопствена подлога (распоредување) и услуга со вашата апликација (пример имплементација во 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. Додадете клуч на конфигурацијата nginx-ingress ConfigMap 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 за од секоја На Ingress користејќи прибелешки;
2. Можеме да прескокнеме custom-http-errors за од секоја На Ingress користејќи прибелешки.

Како резултат на тоа, ресурсот 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 сосема различни апликации што работат во вашиот кластер и сакате да наведете различна стандардна услуга за задната страна и обработка на различни шифри за грешка за секоја од нив, за ова ќе треба да користите решенија, од кои имаме две.

Влез < 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 додаваме сервер-snippet или конфигурација-snippet со следната содржина:

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

Како што можете да видите, за секоја грешка што сакаме да ја обработиме, треба да направиме своја локација, каде што ќе бидат вметнати сите потребни заглавија, како во „мајчинот“. сопствени-страници за грешки. На овој начин можеме да креираме различни персонализирани страници за грешки дури и за поединечни локации и сервери.

PS

Друго од серијата совети и трикови K8s:

• «Пренесување на ресурси кои работат во кластер до управувањето на Helm 2";
• «За распределбата на јазлите и вчитувањата на веб-апликацијата";
• «Пристап до веб-локации за развој";
• «Забрзување на bootstrap за големи бази на податоци".

Прочитајте и на нашиот блог:

• «Назад на микросервисите со Istio. Дел 1";
• «[Илустрирано] Водич за вмрежување во Кубернетес. Дел 3".

Извор: www.habr.com