עצות וטריקים של Kubernetes: דפי שגיאה מותאמים אישית ב-NGINX Ingress

במאמר זה, אני רוצה לדבר על שתי תכונות של NGINX Ingress הקשורות להצגת דפי שגיאה מותאמים אישית, כמו גם על המגבלות הקיימות בהם והדרכים לעקוף אותן.

1. שינוי ברירת המחדל האחורי

כברירת מחדל, NGINX Ingress משתמש ב-backend ברירת המחדל, שמבצע את הפונקציה המתאימה. משמעות הדבר היא שכאשר מבקשים Ingress המציין מארח שאינו נמצא במשאבי Ingress, אנו מקבלים את הדף הבא עם קוד תגובה 404:

עם זאת, לעתים קרובות יותר ויותר הלקוחות שלנו מגיעים עם בקשה להציג את הדף שלהם עם לוגו תאגידי ושירותים אחרים במקום 404 הסטנדרטי. כדי לעשות זאת, יש ל-NGINX Ingress יכולת מובנית להגדיר מחדש default-backend-service. אנו מעבירים את ערך הפורמט כארגומנט לאופציה של אותו שם namespace/servicename. היציאה של השירות צריכה להיות 80.

כדי לעשות זאת, עליך ליצור פוד משלך (פריסה) ושירות עם היישום שלך (יישום לדוגמה ב-YAML ממאגר ingress-nginx), שיינתן במקום ה-backend המוגדר כברירת מחדל.

הנה המחשה קטנה:

~$ 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, נופל ברירת המחדל-backend. ברשימה למעלה, תחום זה הפך sadsdasdas.

2. טיפול בשגיאות HTTP באפליקציה באמצעות ה-backend המוגדר כברירת מחדל

מצב נוסף הוא בקשות המסתיימות בשגיאות HTTP (404, 500, 502...) לאפליקציה שלא מעבדת מצבים כאלה (הדפים היפים המתאימים לא נוצרים). ייתכן שהדבר נובע גם מהרצון של מפתחים לשרת את אותם דפי שגיאה במספר יישומים.

כדי ליישם מקרה זה בצד השרת אנו צריכים:

1. בצע את ההוראות למעלה מהפסקה על ברירת המחדל האחורית;
2. הוסף מפתח לתצורת nginx-ingress ConfigMap custom-http-errors, למשל, עם הערך 404,503 (כמובן מתאים לקודי השגיאה שמכוסים על ידי הכלל החדש).

התוצאה הצפויה הושגה: כאשר אפליקציית הלקוח פועלת ומקבלת שגיאה עם קוד תגובה 404 או 503, הבקשה תופנה אוטומטית ל-backend החדש המוגדר כברירת מחדל...

עם זאת, כאשר מפתחים אפליקציה עבור ברירת מחדל של backend ו-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 עבור כל של אינגרס באמצעות הערות.

כתוצאה מכך, המשאב של 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). ואם יש לך 2 יישומים שונים לחלוטין שפועלים באשכול שלך ואתה רוצה לציין שירות ברירת מחדל אחר ועיבוד של קודי שגיאה שונים עבור כל אחד מהם, לשם כך תצטרך להשתמש בדרכים לעקיפת הבעיה, מהן יש לנו שניים.

כניסה < 0.23: גישה אחת

אפשרות זו פשוטה יותר. כאפליקציה המשרתת את הדפים שלה, יש לנו HTML רגיל, שלא יודע להסתכל על הכותרות ולהחזיר את קודי התגובה הנכונים. יישום כזה מתגלגל עם 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

השירות עבור פריסה זו חייב להיות מסוג 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: גישה שנייה

אפשרות לאפליקציה שיכולה לעבד כותרות... ובכלל זו דרך נכונה יותר, מושאלת מ-custom-http- errors. שימוש ידני (העתקה) יאפשר לך לא לשנות הגדרות גלובליות.

השלבים הם כדלקמן. אנחנו יוצרים אותה פריסה עם אפליקציה שיכולה להאזין לכותרות הדרושות ולהגיב נכון. הוסף קטע שרת ליישום 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:

• «העברת משאבים הפועלים באשכול לניהול Helm 2";
• «על הקצאת צמתים ועומסים ביישום אינטרנט";
• «גישה לאתרי פיתוח";
• «זירוז אתחול עבור מסדי נתונים גדולים".

קרא גם בבלוג שלנו:

• «חזרה לשירותי מיקרו עם Istio. חלק 1";
• «[מצויר] מדריך לרשת ב-Kubernetes. חלק 3".

מקור: www.habr.com