કુબરનેટ્સ ટીપ્સ અને યુક્તિઓ: NGINX પ્રવેશમાં કસ્ટમ ભૂલ પૃષ્ઠો

આ લેખમાં, હું NGINX પ્રવેશની બે વિશેષતાઓ વિશે વાત કરવા માંગુ છું જે વ્યક્તિગત કરેલ ભૂલ પૃષ્ઠોને પ્રદર્શિત કરવા સંબંધિત છે, તેમજ તેમાં રહેલી મર્યાદાઓ અને તેની આસપાસ કામ કરવાની રીતો વિશે.

1. ડિફૉલ્ટ બેકએન્ડ બદલવું

મૂળભૂત રીતે, NGINX Ingress ડિફોલ્ટ બેકએન્ડનો ઉપયોગ કરે છે, જે અનુરૂપ કાર્ય કરે છે. આનો અર્થ એ છે કે જ્યારે ઇન્ગ્રેસ સંસાધનોમાં ન હોય તેવા હોસ્ટનો ઉલ્લેખ કરીને ઇન્ગ્રેસની વિનંતી કરવામાં આવે, ત્યારે અમને 404 પ્રતિભાવ કોડ સાથે નીચેનું પૃષ્ઠ પ્રાપ્ત થાય છે:

જો કે, વધુને વધુ વખત અમારા ક્લાયન્ટ્સ પ્રમાણભૂત 404 ને બદલે તેમનું પૃષ્ઠ કોર્પોરેટ લોગો અને અન્ય સુવિધાઓ સાથે બતાવવાની વિનંતી સાથે આવે છે. આ કરવા માટે, NGINX ઇન્ગ્રેસ પાસે છે બિલ્ટ-ઇન ક્ષમતા ફરીથી વ્યાખ્યાયિત કરો 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 રૂપરેખાંકન ConfigMap માટે કી ઉમેરો 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 માંથી 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 પ્રકારની હોવી જોઈએ.

તે જ સમયે, એપ્લિકેશનમાં જ્યાં અમે ભૂલ પર પ્રક્રિયા કરીશું, પ્રવેશમાં અમે નીચેની સામગ્રી સાથે સર્વર-સ્નિપેટ અથવા ગોઠવણી-સ્નિપેટ ઉમેરીએ છીએ:

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

જેમ તમે જોઈ શકો છો, દરેક ભૂલ કે જેની અમે પ્રક્રિયા કરવા માંગીએ છીએ, તેના માટે અમારે પોતાનું સ્થાન બનાવવાની જરૂર છે, જ્યાં "મૂળ" એકની જેમ બધા જરૂરી હેડરો દાખલ કરવામાં આવશે. કસ્ટમ-ત્રુટી-પૃષ્ઠો. આ રીતે આપણે વ્યક્તિગત સ્થાનો અને સર્વર માટે પણ અલગ અલગ વ્યક્તિગત ભૂલ પૃષ્ઠો બનાવી શકીએ છીએ.

PS

K8s ટીપ્સ અને યુક્તિઓ શ્રેણીમાંથી અન્ય:

• «હેલ્મ 2 મેનેજમેન્ટમાં ક્લસ્ટરમાં ચાલતા સંસાધનોને સ્થાનાંતરિત કરવું»;
• «વેબ એપ્લિકેશન પર નોડ ફાળવણી અને લોડ વિશે»;
• «ડેવ સાઇટ્સની ઍક્સેસ»;
• «મોટા ડેટાબેસેસ માટે બુટસ્ટ્રેપને ઝડપી બનાવવું».

અમારા બ્લોગ પર પણ વાંચો:

• «Istio સાથે માઇક્રોસર્વિસિસ પર પાછા જાઓ. ભાગ 1»;
• «[સચિત્ર] કુબરનેટ્સમાં નેટવર્કિંગ માટેની માર્ગદર્શિકા. ભાગ 3».

સોર્સ: www.habr.com