Kubernetes кеңестері мен амалдары: NGINX Ingress қолданбасындағы қате беттері

Бұл мақалада мен жекелендірілген қате беттерін көрсетуге қатысты NGINX Ingress бағдарламасының екі мүмкіндігі, сондай-ақ оларда бар шектеулер және оларды айналып өту жолдары туралы айтқым келеді.

1. Әдепкі серверді өзгерту

Әдепкі бойынша, NGINX 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. 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 немесе одан жоғары, жергілікті кіріс аннотацияларын пайдаланыңыз:

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 мүлдем басқа қолданба болса және олардың әрқайсысы үшін басқа әдепкі-бағдарлама қызметін және әртүрлі қате кодтарын өңдеуді көрсеткіңіз келсе, бұл үшін бізде екеуі бар уақытша шешімдерді қолдануға тура келеді.

Енгізу < 0.23: біріншіге жақындау

Бұл опция қарапайымырақ. Өз беттеріне қызмет көрсететін қолданба ретінде бізде тақырыптарды қалай қарауды және дұрыс жауап кодтарын қайтаруды білмейтін кәдімгі HTML бар. Мұндай қолданба url мекенжайынан Ingress арқылы шығарылады /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: екінші тәсіл

Тақырыптарды өңдей алатын қолданбаға арналған опция... Жалпы бұл реттелетін http-қателерінен алынған дұрысырақ жол. Оны қолмен пайдалану (көшіру) жаһандық параметрлерді өзгертпеуге мүмкіндік береді.

Қадамдар келесідей. Біз жасаймыз бірдей орналастыру қажетті тақырыптарды тыңдап, дұрыс жауап бере алатын қосымшамен. Келесі мазмұнмен 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 басқаруына тасымалдау«;
• «Веб-қосымшадағы түйінді бөлу және жүктеулер туралы«;
• «Әзірлеуші ​​сайттарға кіру«;
• «Үлкен дерекқорлар үшін жүктеуді жылдамдату«.

Біздің блогта да оқыңыз:

• «Istio көмегімен микросервистерге оралу. 1 бөлім«;
• «[Illustrated] Kubernetes жүйесінде желіге қосылуға арналған нұсқаулық. 3-бөлім«.

Ақпарат көзі: www.habr.com