Kubernetes кеңештери жана амалдары: NGINX Ingress ичиндеги ыңгайлаштырылган ката барактары

Бул макалада мен жекелештирилген ката барактарын көрсөтүүгө байланыштуу NGINX Ingressтин эки өзгөчөлүгү, ошондой эле алардагы чектөөлөр жана аларды айланып өтүү жолдору жөнүндө айткым келет.

1. Демейки серверди өзгөртүү

Демейки боюнча, NGINX 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, default-backend'ге кирет. Жогорудагы тизмеде бул домен болуп калды sadsdasdas.

2. Демейки серверди колдонуу менен колдонмодогу HTTP каталарын иштетүү

Дагы бир жагдай - HTTP каталары (404, 500, 502...) менен аяктаган өтүнмөлөр, мындай жагдайларды иштетпейт (тиешелүү кооз баракчалар түзүлбөйт). Бул ошондой эле иштеп чыгуучулардын бир нече тиркемелерде бир эле ката барактарын тейлөө каалоосуна байланыштуу болушу мүмкүн.

Бул ишти сервер тарабында ишке ашыруу үчүн бизге керек:

1. Демейки backend жөнүндө абзацтан жогорудагы көрсөтмөлөрдү аткарыңыз;
2. Nginx-ingress конфигурациясынын ConfigMap ачкычын кошуңуз custom-http-errors, мисалы, мааниси менен 404,503 (албетте жаңы эрежеде камтылган ката коддоруна туура келет).

Күтүлгөн натыйжага жетишилди: кардар тиркемеси иштеп жатканда жана 404 же 503 жооп коду менен катаны алганда, сурам автоматтык түрдө жаңы демейки серверге багытталат...

Бирок, демейки backend жана салт-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's аннотацияларды колдонуу;
2. Биз жокко чыгара алабыз custom-http-errors үчүн ар биринин Ingress's аннотацияларды колдонуу.

Натыйжада, 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 такыр башка тиркеме иштеп жатса жана алардын ар бири үчүн ар кандай демейки-backend-кызматын жана ар кандай ката коддорун иштетүүнү белгилегиңиз келсе, анда бул үчүн бизде экөөнү чечүү жолдорун колдонушуңуз керек болот.

Кирүү < 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;
      }

Көрүнүп тургандай, биз иштеп чыгууну каалаган ар бир ката үчүн, биз өзүбүздүн жайгашкан жерибизди жасашыбыз керек, анда бардык керектүү аталыштар киргизилет, мисалы, "түпкүлүктүү". custom-error-беттер. Ушундай жол менен биз ар кандай жекелештирилген ката беттерин түзө алабыз, атүгүл айрым жерлер жана серверлер үчүн.

PS

K8s кеңештер жана ыкмалар сериясынан башка:

• «Кластерде иштеген ресурстарды Helm 2 башкаруусуна өткөрүп берүү";
• «Веб тиркемесинде түйүндөрдү бөлүштүрүү жана жүктөөлөр жөнүндө";
• «Иштеп чыгуучу сайттарга кирүү";
• «Чоң маалымат базалары үчүн жүктөөнү тездетүү«.

Биздин блогдон дагы окуңуз:

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

Source: www.habr.com