Kubernetes सुझाव र चालहरू: NGINX प्रवेशमा अनुकूलन त्रुटि पृष्ठहरू

यस लेखमा, म व्यक्तिगत त्रुटि पृष्ठहरू प्रदर्शन गर्न सम्बन्धित NGINX Ingress को दुई विशेषताहरू, साथै तिनीहरूमा अवस्थित सीमितताहरू र तिनीहरूको वरिपरि काम गर्ने तरिकाहरू बारे कुरा गर्न चाहन्छु।

1. पूर्वनिर्धारित ब्याकइन्ड परिवर्तन गर्दै

पूर्वनिर्धारित रूपमा, NGINX Ingress ले पूर्वनिर्धारित ब्याकइन्ड प्रयोग गर्दछ, जसले सम्बन्धित कार्य गर्दछ। यसको मतलब यो हो कि जब इन्ग्रेस स्रोतहरूमा नभएको होस्ट निर्दिष्ट गर्ने इन्ग्रेस अनुरोध गर्दा, हामीले 404 प्रतिक्रिया कोडको साथ निम्न पृष्ठ प्राप्त गर्छौं:

यद्यपि, अधिक र अधिक बार हाम्रा ग्राहकहरू मानक 404 को सट्टा कर्पोरेट लोगो र अन्य सुविधाहरूको साथ आफ्नो पृष्ठ देखाउन अनुरोधको साथ आउँछन्। यो गर्नको लागि, NGINX Ingress छ निर्मित क्षमता पुन: परिभाषित गर्नुहोस् default-backend-service। हामी समान नामको विकल्पमा तर्कको रूपमा ढाँचा प्रविष्टि पास गर्छौं namespace/servicename। सेवाको पोर्ट ८० हुनुपर्छ।

यो गर्नको लागि, तपाईंले आफ्नो आवेदन (डिप्लोयमेन्ट) र सेवा सिर्जना गर्न आवश्यक छ।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 पूर्णतया फरक अनुप्रयोगहरू चलिरहेको छ र तपाइँ फरक पूर्वनिर्धारित-ब्याकएन्ड-सेवा निर्दिष्ट गर्न चाहानुहुन्छ र ती प्रत्येकको लागि फरक त्रुटि कोडहरूको प्रशोधन गर्न चाहनुहुन्छ भने, यसको लागि तपाइँले workarounds प्रयोग गर्नुपर्नेछ, जसमध्ये हामीसँग दुई छ।

प्रवेश <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

यो परिनियोजनको लागि सेवा क्लस्टरआईपी प्रकारको हुनुपर्छ।

एकै समयमा, अनुप्रयोगमा जहाँ हामी त्रुटि प्रक्रिया गर्नेछौं, 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;
      }

प्रवेश <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 सुझाव र चाल श्रृंखलाबाट अन्य:

• «हेल्म २ व्यवस्थापनमा क्लस्टरमा चलिरहेको स्रोतहरू हस्तान्तरण गर्दै»;
• «वेब अनुप्रयोगमा नोड आवंटन र लोडहरू बारे»;
• «dev साइटहरूमा पहुँच»;
• «ठूला डाटाबेसहरूको लागि बुटस्ट्र्यापको गति बढाउँदै"।

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «Istio संग microservices मा फर्कनुहोस्। भाग 1»;
• «[चित्रित] Kubernetes मा नेटवर्किङको लागि गाइड। भाग ३"।

स्रोत: www.habr.com