Kubernetes टिपा आणि युक्त्या: NGINX प्रवेश मधील सानुकूल त्रुटी पृष्ठे

या लेखात, मला वैयक्तिकृत त्रुटी पृष्ठे प्रदर्शित करण्याशी संबंधित एनजीआयएनएक्स इंग्रेसच्या दोन वैशिष्ट्यांबद्दल, तसेच त्यांच्यामध्ये अस्तित्वात असलेल्या मर्यादा आणि त्याभोवती कार्य करण्याच्या पद्धतींबद्दल बोलायचे आहे.

1. डीफॉल्ट बॅकएंड बदलणे

डीफॉल्टनुसार, NGINX Ingress डीफॉल्ट बॅकएंड वापरते, जे संबंधित कार्य करते. याचा अर्थ असा की जेव्हा इंग्रेस संसाधनांमध्ये नसलेले होस्ट निर्दिष्ट करणार्‍या इंग्रेसची विनंती करताना, आम्हाला 404 प्रतिसाद कोडसह खालील पृष्ठ प्राप्त होते:

तथापि, अधिकाधिक वेळा आमचे क्लायंट त्यांचे पृष्ठ कॉर्पोरेट लोगोसह आणि मानक 404 ऐवजी इतर सुविधांसह दाखवण्याची विनंती घेऊन येतात. हे करण्यासाठी, NGINX Ingress आहे अंगभूत क्षमता पुन्हा परिभाषित करा default-backend-service. आम्ही त्याच नावाच्या पर्यायासाठी आर्ग्युमेंट म्हणून फॉरमॅट एंट्री पास करतो namespace/servicename. सेवेचे पोर्ट 80 असावे.

हे करण्यासाठी, तुम्हाला तुमचा स्वतःचा पॉड (उपयोजन) आणि तुमच्या अनुप्रयोगासह सेवा तयार करणे आवश्यक आहे (YAML मध्ये उदाहरण अंमलबजावणी ingress-nginx repository मधून), जे डीफॉल्ट बॅकएंड ऐवजी दिले जाईल.

येथे एक लहान उदाहरण आहे:

~$ 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 सह त्रुटी प्राप्त होईल, तेव्हा विनंती स्वयंचलितपणे नवीन डीफॉल्ट बॅकएंडवर पुनर्निर्देशित केली जाईल...

तथापि, डीफॉल्ट बॅकएंड आणि सानुकूल-एचटीटीपी-एरर्ससाठी अनुप्रयोग विकसित करताना, आपल्याला एक महत्त्वाचे वैशिष्ट्य लक्षात घेणे आवश्यक आहे:

!!! 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

या तैनातीसाठी सेवा क्लस्टरआयपी प्रकारची असणे आवश्यक आहे.

त्याच वेळी, ज्या ऍप्लिकेशनमध्ये आम्ही त्रुटीवर प्रक्रिया करू, त्यामध्ये आम्ही खालील सामग्रीसह सर्व्हर-स्निपेट किंवा कॉन्फिगरेशन-स्निपेट जोडतो:

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 सह microservices वर परत. भाग 1";
• «[सचित्र] Kubernetes मध्ये नेटवर्किंगसाठी मार्गदर्शक. भाग 3».

स्त्रोत: www.habr.com