Кубернетес савети и трикови: прилагођене странице грешака у НГИНКС Ингресс-у

У овом чланку желим да говорим о две карактеристике НГИНКС Ингресс-а које се односе на приказивање персонализованих страница са грешкама, као ио ограничењима која постоје у њима и начинима да их се заобиђе.

1. Промена подразумеване позадине

Подразумевано, НГИНКС Ингресс користи подразумевану позадину, која обавља одговарајућу функцију. То значи да када захтевамо Ингресс који наводи хост који није у Ингресс ресурсима, добијамо следећу страницу са кодом одговора 404:

Међутим, све чешће наши клијенти долазе са захтевом да своју страницу покажу са корпоративним логотипом и другим садржајима уместо стандардног 404. Да би то урадио, НГИНКС Ингресс има уграђена способност редефинисати default-backend-service. Проследимо унос формата као аргумент опцији истог имена namespace/servicename. Порт услуге треба да буде 80.

Да бисте то урадили, потребно је да креирате сопствену под (примену) и услугу са својом апликацијом (пример имплементације у ИАМЛ из ингресс-нгинк спремишта), који ће бити дат уместо подразумеваног позадинског дела.

Ево мале илустрације:

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

Дакле, сви домени који нису експлицитно креирани преко ИАМЛ-а са kind: Ingress, спадају у подразумевани бацкенд. У листи изнад, овај домен је постао sadsdasdas.

2. Руковање ХТТП грешкама у апликацији користећи подразумевану позадину

Друга ситуација су захтеви који се завршавају ХТТП грешкама (404, 500, 502...) апликацији која не обрађује такве ситуације (не генеришу се одговарајуће лепе странице). Ово такође може бити због жеље програмера да послужују исте странице са грешкама у више апликација.

За имплементацију овог случаја на страни сервера потребно нам је:

1. Следите упутства изнад из параграфа о подразумеваној позадини;
2. Додајте кључ у нгинк-ингресс конфигурацију ЦонфигМап custom-http-errors, на пример, са вредношћу 404,503 (очигледно одговара кодовима грешака који су обухваћени новим правилом).

Очекивани резултат је постигнут: када се клијентска апликација покрене и добије грешку са кодом одговора 404 или 503, захтев ће аутоматски бити преусмерен на нову подразумевану позадину...

Међутим, када развијате апликацију за подразумеване позадинске и прилагођене хттп-грешке, морате да узмете у обзир важну карактеристику:

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

Чињеница је да када се захтев преусмери, заглавља ће садржати корисне информације са претходним кодом одговора и додатне информације (њихова комплетна листа је доступна овде).

То значи да и сами морате водите рачуна о исправном коду одговора. Ево примера. из документације како то функционише.

Различите апликације имају различите подразумеване позадине

Да бисте били сигурни да решење није глобално за цео кластер, већ да се односи само на одређене апликације, прво морате да проверите верзију Ингресс. Ако се поклапа 0.23 или више, користите изворне Ингресс напомене:

1. Можемо надјачати default-backend за сваки Ингресс'с користећи напомене;
2. Можемо надјачати custom-http-errors за сваки Ингресс'с користећи напомене.

Као резултат тога, Ингресс ресурс ће изгледати отприлике овако:

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 ће бити преусмерене на услугу еррор-пагес са свим потребним заглављима.

В претходне верзије Ингресс-а нису имале ову функцију (судбоносно извршење на 0.23). А ако имате 2 потпуно различите апликације које раде у вашем кластеру и желите да наведете различиту подразумевану позадинску услугу и обраду различитих кодова грешака за сваку од њих, за ово ћете морати да користите заобилазна решења, од којих имамо два.

Улазак < 0.23: приступ један

Ова опција је једноставнија. Као апликација која опслужује своје странице, имамо обичан ХТМЛ, који не уме да погледа заглавља и врати исправне кодове одговора. Таква апликација се покреће са Ингресс-ом са урл-а /error-pages, и у каталогу ws ће бити враћени ХТМЛ.

Илустрација у ИАМЛ-у:

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

Услуга за ову примену мора бити типа ЦлустерИП.

Истовремено, у апликацију у којој ћемо обрадити грешку, у Ингресс додајемо сервер-сниппет или конфигурациони исечак са следећим садржајем:

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: други приступ

Опција за апликацију која може да обрађује заглавља... И генерално, ово је исправнији начин, позајмљен од цустом-хттп-грешака. Ручно коришћење (копирање) омогућиће вам да не мењате глобална подешавања.

Кораци су следећи. Ми стварамо исто распоређивање са апликацијом која може да слуша потребне наслове и да правилно одговори. Додајте фрагмент сервера у апликацију Ингресс са следећим садржајем:

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

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

ПС

Остало из К8с серије савета и трикова:

• «Пренос ресурса који раде у кластеру на управљање Хелм 2";
• «О алокацији чворова и учитавањима на веб апликацији";
• «Приступ сајтовима за програмере";
• «Убрзавање покретања за велике базе података'.

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

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

Извор: ввв.хабр.цом