Kubernetes നുറുങ്ങുകളും തന്ത്രങ്ങളും: NGINX പ്രവേശനത്തിലെ ഇഷ്‌ടാനുസൃത പിശക് പേജുകൾ

ഈ ലേഖനത്തിൽ, വ്യക്തിഗതമാക്കിയ പിശക് പേജുകൾ പ്രദർശിപ്പിക്കുന്നതുമായി ബന്ധപ്പെട്ട NGINX പ്രവേശനത്തിന്റെ രണ്ട് സവിശേഷതകളെക്കുറിച്ചും അവയിൽ നിലനിൽക്കുന്ന പരിമിതികളെക്കുറിച്ചും അവയ്‌ക്ക് ചുറ്റും പ്രവർത്തിക്കാനുള്ള വഴികളെക്കുറിച്ചും സംസാരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

1. ഡിഫോൾട്ട് ബാക്കെൻഡ് മാറ്റുന്നു

ഡിഫോൾട്ടായി, എൻജിഎൻഎക്സ് ഇൻഗ്രെസ്സ് ഡിഫോൾട്ട് ബാക്കെൻഡ് ഉപയോഗിക്കുന്നു, അത് അനുബന്ധ പ്രവർത്തനം നിർവ്വഹിക്കുന്നു. ഇതിനർത്ഥം, ഇൻഗ്രെസ്സ് ഉറവിടങ്ങളിൽ ഇല്ലാത്ത ഒരു ഹോസ്റ്റ് വ്യക്തമാക്കുന്ന ഒരു ഇൻഗ്രെസ്സ് അഭ്യർത്ഥിക്കുമ്പോൾ, 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 കോൺഫിഗറേഷൻ കോൺഫിഗറേഷനിലേക്ക് ഒരു കീ ചേർക്കുക 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.

ഒരു അഭ്യർത്ഥന റീഡയറക്‌ട് ചെയ്യുമ്പോൾ, തലക്കെട്ടുകളിൽ മുമ്പത്തെ പ്രതികരണ കോഡും അധിക വിവരങ്ങളും അടങ്ങിയ ഉപയോഗപ്രദമായ വിവരങ്ങൾ അടങ്ങിയിരിക്കും (അവയുടെ പൂർണ്ണമായ ലിസ്റ്റ് ലഭ്യമാണ് ഇവിടെ).

ഇതിനർത്ഥം നിങ്ങൾ തന്നെ വേണം എന്നാണ് ശരിയായ പ്രതികരണ കോഡ് ശ്രദ്ധിക്കുക. ഇതാ ഒരു ഉദാഹരണം ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന ഡോക്യുമെന്റേഷനിൽ നിന്ന്.

വ്യത്യസ്ത ആപ്ലിക്കേഷനുകൾക്ക് വ്യത്യസ്ത ഡിഫോൾട്ട് ബാക്കെൻഡുകളുണ്ട്

സൊല്യൂഷൻ മുഴുവൻ ക്ലസ്റ്ററിനും ആഗോളമല്ലെന്നും പ്രത്യേക ആപ്ലിക്കേഷനുകൾക്ക് മാത്രം ബാധകമാണെന്നും ഉറപ്പാക്കാൻ, നിങ്ങൾ ആദ്യം ഇൻഗ്രെസ്സ് പതിപ്പ് പരിശോധിക്കേണ്ടതുണ്ട്. പൊരുത്തപ്പെടുന്നെങ്കിൽ 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 എന്നിവ ആവശ്യമായ എല്ലാ തലക്കെട്ടുകളുമുള്ള പിശക് പേജുകളുടെ സേവനത്തിലേക്ക് റീഡയറക്‌ടുചെയ്യും.

В Ingress-ന്റെ മുൻ പതിപ്പുകൾക്ക് ഈ സവിശേഷത ഇല്ലായിരുന്നു (0.23 ന് നിർഭാഗ്യകരമായ പ്രതിബദ്ധത). നിങ്ങളുടെ ക്ലസ്റ്ററിൽ പ്രവർത്തിക്കുന്ന 2 തികച്ചും വ്യത്യസ്തമായ ആപ്ലിക്കേഷനുകൾ ഉണ്ടെങ്കിൽ, അവയിൽ ഓരോന്നിനും വ്യത്യസ്തമായ ഡിഫോൾട്ട്-ബാക്കെൻഡ്-സർവീസും പ്രോസസ്സിംഗും വ്യക്തമാക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഇതിനായി നിങ്ങൾ പരിഹാരങ്ങൾ ഉപയോഗിക്കേണ്ടതുണ്ട്, അതിൽ ഞങ്ങൾക്ക് രണ്ടെണ്ണം ഉണ്ട്.

പ്രവേശനം <0.23: ഒന്നിനെ സമീപിക്കുക

ഈ ഓപ്ഷൻ കൂടുതൽ ലളിതമാണ്. അതിന്റെ പേജുകൾ സേവിക്കുന്ന ഒരു ആപ്ലിക്കേഷൻ എന്ന നിലയിൽ, ഞങ്ങൾക്ക് പതിവ് HTML ഉണ്ട്, അത് തലക്കെട്ടുകൾ നോക്കാനും ശരിയായ പ്രതികരണ കോഡുകൾ നൽകാനും അറിയില്ല. 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 തരത്തിലായിരിക്കണം.

അതേ സമയം, ഞങ്ങൾ പിശക് പ്രോസസ്സ് ചെയ്യുന്ന ആപ്ലിക്കേഷനിൽ, ഇൻഗ്രെസിൽ ഞങ്ങൾ ഇനിപ്പറയുന്ന ഉള്ളടക്കമുള്ള ഒരു സെർവർ-സ്നിപ്പറ്റ് അല്ലെങ്കിൽ കോൺഫിഗറേഷൻ-സ്നിപ്പറ്റ് ചേർക്കുന്നു:

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-പിശക്കളിൽ നിന്ന് കടമെടുത്തതാണ്. ഇത് സ്വമേധയാ ഉപയോഗിക്കുന്നത് (പകർത്തൽ) ആഗോള ക്രമീകരണങ്ങൾ മാറ്റാതിരിക്കാൻ നിങ്ങളെ അനുവദിക്കും.

ഘട്ടങ്ങൾ ഇപ്രകാരമാണ്. ഞങ്ങൾ സൃഷ്ടിക്കുന്നു ഒരേ വിന്യാസം ആവശ്യമായ തലക്കെട്ടുകൾ കേൾക്കാനും ശരിയായി പ്രതികരിക്കാനും കഴിയുന്ന ഒരു ആപ്ലിക്കേഷൻ ഉപയോഗിച്ച്. ഇനിപ്പറയുന്ന ഉള്ളടക്കമുള്ള ഇൻഗ്രെസ് ആപ്ലിക്കേഷനിലേക്ക് ഒരു സെർവർ-സ്നിപ്പറ്റ് ചേർക്കുക:

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

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഞങ്ങൾ പ്രോസസ്സ് ചെയ്യാൻ ആഗ്രഹിക്കുന്ന ഓരോ പിശകിനും, "നേറ്റീവ്" എന്നതിലെന്നപോലെ ആവശ്യമായ എല്ലാ തലക്കെട്ടുകളും ചേർക്കുന്ന ഞങ്ങളുടെ സ്വന്തം ലൊക്കേഷൻ നിർമ്മിക്കേണ്ടതുണ്ട്. കസ്റ്റം-എറർ-പേജുകൾ. ഇതുവഴി വ്യക്തിഗത ലൊക്കേഷനുകൾക്കും സെർവറുകൾക്കുമായി പോലും നമുക്ക് വ്യത്യസ്ത വ്യക്തിഗത പിശക് പേജുകൾ സൃഷ്ടിക്കാൻ കഴിയും.

പി.എസ്

K8s നുറുങ്ങുകളും തന്ത്രങ്ങളും പരമ്പരയിൽ നിന്നുള്ള മറ്റുള്ളവ:

• «ഒരു ക്ലസ്റ്ററിൽ പ്രവർത്തിക്കുന്ന ഉറവിടങ്ങൾ ഹെൽം 2 മാനേജ്മെന്റിന് കൈമാറുന്നു";
• «ഒരു വെബ് ആപ്ലിക്കേഷനിലെ നോഡ് അലോക്കേഷനെയും ലോഡുകളെയും കുറിച്ച്";
• «ഡെവലപ്പ് സൈറ്റുകളിലേക്കുള്ള ആക്സസ്";
• «വലിയ ഡാറ്റാബേസുകൾക്കായി ബൂട്ട്സ്ട്രാപ്പ് വേഗത്തിലാക്കുന്നു".

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «ഇസ്തിയോയ്‌ക്കൊപ്പം മൈക്രോസർവീസുകളിലേക്ക് മടങ്ങുക. ഭാഗം 1";
• «[ഇല്ലസ്ട്രേറ്റഡ്] കുബർനെറ്റസിലെ നെറ്റ്‌വർക്കിംഗിലേക്കുള്ള വഴികാട്ടി. ഭാഗം 3".

അവലംബം: www.habr.com