👏 🚣🏾 🦌 कुबेरनेट्स टिप्स एंड ट्रिक्स: एनजीआईएनएक्स इनग्रेड में व्यक्तिगत त्रुटि पृष्ठ 🈳 ⬇️ ↙️

इस लेख में मैं दो एनजीआईएनएक्स इनग्रेड फ़ीचर के बारे में बात करना चाहता हूं, जो व्यक्तिगत त्रुटि पृष्ठों को प्रदर्शित करने से संबंधित हैं, साथ ही साथ जो सीमाएं उनमें मौजूद हैं और उनके आसपास आने के तरीके।

1. डिफ़ॉल्ट बैकएंड को बदलना

डिफ़ॉल्ट रूप से, NGINX इनग्रेड डिफ़ॉल्ट बैकएंड का उपयोग करता है, जो संबंधित फ़ंक्शन करता है। इसका मतलब यह है कि जब हम एक होस्ट के साथ Ingress को क्वेरी करते हैं जो Ingress संसाधनों में नहीं है, तो हमें 404 उत्तर कोड वाला एक पेज मिलता है:

हालांकि, अधिक से अधिक बार हमारे ग्राहक कंपनी के लोगो और अन्य सुविधाओं के साथ अपना पेज दिखाने के लिए मानक 404 के बजाय एक अनुरोध के साथ आते हैं। ऐसा करने के लिए, NGINX Ingress में default-backend-service को ओवरराइड करने की अंतर्निहित क्षमता है । एक तर्क के रूप में एक ही नाम का विकल्प, namespace/servicename प्रारूप रिकॉर्ड namespace/servicename जाता है। सर्विस पोर्ट 80 होना चाहिए।

ऐसा करने के लिए, अपने आवेदन के साथ अपनी खुद की फली (तैनाती) और सेवा बनाएं ( इनग्रेस -नेग्नेक्स रिपॉजिटरी से यमल में एक उदाहरण कार्यान्वयन ), जो डिफ़ॉल्ट बैकएंड के बजाय दिया जाएगा।

यहाँ एक छोटा चित्रण है:

 ~$ 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 से नहीं बनाए गए हैं kind: Ingress डिफ़ॉल्ट-बैकएंड में आते हैं। ऊपर की सूची में, sadsdasdas वह डोमेन बन गया है।

2. डिफ़ॉल्ट बैकएंड का उपयोग करके एप्लिकेशन में HTTP त्रुटियों को संसाधित करना

एक और स्थिति HTTP त्रुटि (404, 500, 502 ...) के साथ समाप्त होने वाले एप्लिकेशन के लिए अनुरोध है, जिसमें ऐसी परिस्थितियां संसाधित नहीं होती हैं (तदनुसार सुंदर पृष्ठ उत्पन्न नहीं होते हैं)। यह कई अनुप्रयोगों में एक ही त्रुटि पृष्ठ देने के लिए डेवलपर्स की इच्छा के कारण भी हो सकता है।

सर्वर साइड पर इस मामले को लागू करने के लिए, हमें इसकी आवश्यकता है:

डिफ़ॉल्ट बैकएंड के बारे में आइटम से ऊपर दिए गए निर्देशों का पालन करें;
विन्यास-विन्यास के लिए कस्टम-http-एरर कीज को जोड़ें। कॉन्फिगरेशन नेग्नेक्स-इंग्रेस, उदाहरण के लिए, 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 या अधिक से मेल खाता है, तो इनग्रेड देशी एनोटेशन का उपयोग करें:

हम एनोटेशन के माध्यम से प्रत्येक इनग्रेड के लिए default-backend को फिर से परिभाषित कर सकते हैं;
हम एनोटेशन का उपयोग करके प्रत्येक इनग्रेड के लिए 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 है, जो हेडर को देखने और सही प्रतिक्रिया कोड देने का तरीका नहीं जानता है। इस तरह के एप्लिकेशन को यूआरएल /error-pages साथ इनग्रेड के साथ रोलआउट किया जाता है, और HTML को ws निर्देशिका में दिया जाएगा।

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-त्रुटियों से उधार लिया गया है। मैन्युअल रूप से इसका उपयोग करना (नकल करना) आपको वैश्विक सेटिंग्स को बदलने की अनुमति नहीं देगा।

चरण इस प्रकार हैं। हम एक एप्लिकेशन के साथ एक ही परिनियोजन बनाते हैं जो आवश्यक हेडर को सुन सकता है और सही ढंग से प्रतिक्रिया कर सकता है। निम्नलिखित सामग्री के साथ 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; }

जैसा कि आप देख सकते हैं, प्रत्येक त्रुटि के लिए जिसे हम संभालना चाहते हैं, आपको अपना स्थान बनाने की आवश्यकता है, जहां सभी आवश्यक हेडर को प्रतिस्थापित किया जाएगा, जैसा कि "मूल" कस्टम-त्रुटि-पृष्ठों में है । इसलिए हम अलग-अलग स्थानों और सर्वरों के लिए भी अलग-अलग व्यक्तिगत पेज बना सकते हैं।

पुनश्च

K8s टिप्स एंड ट्रिक्स चक्र से अन्य:

हमारे ब्लॉग में भी पढ़ें: