في هذه المقالة ، أود أن أتحدث عن اثنين من ميزات NGINX Ingress المتعلقة بعرض صفحات الأخطاء الشخصية ، وكذلك القيود الموجودة فيها وطرق الالتفاف عليها.
1. تغيير الخلفية الافتراضية
افتراضيًا ، يستخدم NGINX Ingress الواجهة الخلفية الافتراضية ، التي تؤدي الوظيفة المناظرة. هذا يعني أننا عندما نستفسر عن Ingress مع مضيف غير موجود في موارد Ingress ، نحصل على صفحة بها رمز استجابة 404:
ومع ذلك ، في كثير من الأحيان يقدم عملائنا طلبًا بدلاً من معيار 404 لإظهار صفحتهم بشعار الشركة ووسائل الراحة الأخرى. للقيام بذلك ، تتمتع NGINX Ingress بقدرة مضمنة لتجاوز
default-backend-service . يتم
namespace/servicename خيار يحمل نفس الاسم ، كوسيطة ،
namespace/servicename سجل تنسيق
namespace/servicename . يجب أن يكون منفذ الخدمة 80.
للقيام بذلك ، قم بإنشاء ملف pod (النشر) الخاص بك وخدمة باستخدام التطبيق الخاص بك (تطبيق
مثال في 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 يقع
kind: Ingress في الواجهة الخلفية الافتراضية. في القائمة أعلاه ، أصبح
sadsdasdas هذا المجال.
2. معالجة أخطاء HTTP في التطبيق باستخدام الخلفية الافتراضية
الموقف الآخر هو الطلبات إلى التطبيق التي تنتهي بأخطاء HTTP (404 ، 500 ، 502 ...) ، حيث لا تتم معالجة مثل هذه المواقف (لا يتم إنشاء الصفحات الجميلة المقابلة). كما يمكن أن يكون سبب رغبة المطورين في إعطاء صفحات الخطأ نفسها في العديد من التطبيقات.
لتنفيذ هذه الحالة على جانب الخادم ، نحتاج إلى:
- اتبع الإرشادات المذكورة أعلاه من العنصر حول الواجهة الخلفية الافتراضية ؛
- أضف مفتاح
custom-http-errors إلى التكوين ConfigMap nginx-ingress ، على سبيل المثال ، بقيمة 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:
- يمكننا إعادة تعريف
default-backend لكل Ingress عن طريق التعليق التوضيحي ؛ - يمكننا تخطي
custom-http-errors المخصصة لكل Ingress باستخدام التعليقات التوضيحية .
نتيجة لذلك ، سيبدو مورد Ingress كما يلي:
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 مع
/error-pages url
/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.
في نفس الوقت ، في التطبيق الذي سنتعامل فيه مع الخطأ ، في 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-custom. سيسمح لك استخدامه يدويًا (النسخ) بعدم تغيير الإعدادات العامة.
الخطوات هي كما يلي. نقوم بإنشاء
نفس النشر مع تطبيق يمكنه الاستماع إلى الرؤوس اللازمة والرد بشكل صحيح. أضف تطبيقات مقتطف الخادم إلى 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; }
كما ترون ، في كل خطأ نرغب في معالجته ، يلزمك إنشاء موقعك ، حيث سيتم استبدال جميع الرؤوس اللازمة ، كما هو الحال في
صفحات الأخطاء المخصصة "الأصلية". حتى نتمكن من إنشاء صفحات مخصصة مختلفة مع وجود أخطاء حتى بالنسبة للمواقع الفردية والخوادم.
PS
بخلاف دورة نصائح وحيل K8s:
اقرأ أيضًا في مدونتنا: