Kubernetes-ի խորհուրդներ և հնարքներ. հատուկ սխալի էջեր NGINX Ingress-ում

Այս հոդվածում ես ուզում եմ խոսել NGINX Ingress-ի երկու առանձնահատկությունների մասին՝ կապված անհատականացված սխալների էջերի ցուցադրման հետ, ինչպես նաև դրանցում առկա սահմանափակումների և դրանց շուրջ աշխատելու ուղիների մասին:

1. Փոխելով լռելյայն հետնամասը

Լռելյայնորեն, NGINX Ingress-ն օգտագործում է լռելյայն backend-ը, որն իրականացնում է համապատասխան գործառույթը։ Սա նշանակում է, որ երբ խնդրում ենք 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, ընկնում է default-backend-ի մեջ: Վերոնշյալ ցուցակում այս տիրույթը դարձավ sadsdasdas.

2. Հավելվածում HTTP սխալների կառավարում` օգտագործելով լռելյայն հետնամասը

Մեկ այլ իրավիճակ HTTP սխալներով (404, 500, 502...) ավարտվող հարցումներն են այնպիսի հավելվածին, որը չի մշակում նման իրավիճակները (համապատասխան գեղեցիկ էջերը չեն ստեղծվում): Սա կարող է պայմանավորված լինել նաև ծրագրավորողների ցանկությամբ՝ սպասարկել նույն սխալի էջերը բազմաթիվ հավելվածներում:

Այս դեպքը սերվերի կողմից իրականացնելու համար մեզ անհրաժեշտ է.

1. Հետևեք վերը նշված հրահանգներին լռելյայն հետին պլանի մասին պարբերությունից.
2. Ավելացնել բանալի nginx-ingress կոնֆիգուրացիայի ConfigMap-ում custom-http-errors, օրինակ՝ արժեքով 404,503 (ակնհայտորեն համապատասխանում է սխալի կոդերին, որոնք ծածկված են նոր կանոնով):

Սպասվող արդյունքը ձեռք է բերվել. երբ հաճախորդի հավելվածը գործարկվում է և ստանում է 404 կամ 503 պատասխանի կոդով սխալ, հարցումն ավտոմատ կերպով կվերահղվի նոր լռելյայն հետին պլան...

Այնուամենայնիվ, լռելյայն backend-ի և custom-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 սխալները կվերահղվեն error-pages ծառայությանը՝ բոլոր անհրաժեշտ վերնագրերով:

В Ingress-ի նախորդ տարբերակները չունեին այս հատկությունը (ճակատագրական կատարում 0.23-ին) Եվ եթե դուք ունեք 2 բոլորովին տարբեր հավելվածներ, որոնք աշխատում են ձեր կլաստերում և ցանկանում եք նշել այլ լռելյայն-backend-ծառայություն և դրանցից յուրաքանչյուրի համար տարբեր սխալի կոդերի մշակում, դրա համար դուք պետք է օգտագործեք լուծումներ, որոնցից մենք ունենք երկուսը:

Ներխուժում < 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;
      }

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

Ինչպես տեսնում եք, յուրաքանչյուր սխալի համար, որը մենք ցանկանում ենք մշակել, մենք պետք է ստեղծենք մեր սեփական գտնվելու վայրը, որտեղ կտեղադրվեն բոլոր անհրաժեշտ վերնագրերը, ինչպես «հայրենիում»: custom-error-էջեր. Այս կերպ մենք կարող ենք ստեղծել տարբեր անհատականացված սխալի էջեր նույնիսկ առանձին վայրերի և սերվերների համար:

PS

Այլ K8s խորհուրդներ և հնարքներ շարքից.

• «Կլաստերով աշխատող ռեսուրսների փոխանցում Helm 2 կառավարմանը";
• «Վեբ հավելվածում հանգույցների տեղաբաշխման և բեռների մասին";
• «Մուտք դեպի մշակող կայքեր";
• «Խոշոր տվյալների բազաների համար bootstrap-ի արագացում.

Կարդացեք նաև մեր բլոգում.

• «Վերադարձ դեպի միկրոսերվիսներ Istio-ով։ Մաս 1";
• «[Պատկերազարդ] Կուբերնետեսում ցանցային կապի ուղեցույց: Մաս 3.

Source: www.habr.com