نصائح وحيل Kubernetes: صفحات خطأ مخصصة في NGINX Ingress

في هذه المقالة ، أريد أن أتحدث عن ميزتين من ميزات NGINX Ingress المتعلقة بعرض صفحات الخطأ المخصصة ، بالإضافة إلى قيودها وطرق التغلب عليها.

1. تغيير الخلفية الافتراضية

بشكل افتراضي ، يستخدم NGINX Ingress الواجهة الخلفية الافتراضية ، والتي تؤدي الوظيفة المقابلة. هذا يعني أنه عند طلب Ingress مع مضيف غير موجود في موارد Ingress ، نحصل على هذه الصفحة برمز استجابة 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. أضف المفتاح إلى ConfigMap ConfigMap 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.

الحقيقة هي أنه عند إعادة توجيه الطلب ، ستحتوي الرؤوس على معلومات مفيدة مع رمز الاستجابة السابق ومعلومات إضافية (القائمة الكاملة متاحة هنا).

هذا يعني أنه يجب عليك اعتني بكود الاستجابة الصحيح. وهنا مثال من وثائق كيف يعمل.

تطبيقات مختلفة - خلفية افتراضية مختلفة

حتى لا يكون الحل عالميًا للمجموعة بأكملها ، ولكنه ينطبق فقط على تطبيقات محددة ، فأنت بحاجة أولاً إلى التحقق من إصدار Ingress. إذا كان يتطابق 0.23 أو أعلى، استخدم تعليقات Ingress التوضيحية الأصلية:

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). وإذا كان لديك تطبيقان مختلفان تمامًا يعملان في مجموعتك وتريد تحديد خدمات خلفية افتراضية مختلفة والتعامل مع رموز خطأ مختلفة لكل منهما ، فسيتعين عليك استخدام الحلول لذلك ، والتي لدينا اثنان منها.

دخول <0.23: اقترب من واحد

هذا الخيار أبسط. كتطبيق يعرض صفحاته ، لدينا HTML عادي ، والذي لا يعرف كيف ينظر إلى الرؤوس ويعيد رموز الاستجابة الصحيحة. يتم طرح مثل هذا التطبيق مع Ingress with 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.

في الوقت نفسه ، في التطبيق حيث سنتعامل مع الخطأ ، في 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:

• «نقل الموارد التي تعمل في الكتلة الخاضعة لسيطرة حلم 2"؛
• «حول تخصيص العقد والأحمال على تطبيق الويب"؛
• «الوصول إلى مواقع التطوير"؛
• «تسريع التمهيد لقواعد البيانات الكبيرة".

اقرأ أيضًا على مدونتنا:

• «العودة إلى الخدمات المصغرة مع Istio. الجزء 1"؛
• «[مصور] دليل شبكات Kubernetes. الجزء 3".

المصدر: www.habr.com