Kubernetes-ის რჩევები და ხრიკები: მორგებული შეცდომების გვერდები NGINX Ingress-ში

ამ სტატიაში მინდა ვისაუბრო NGINX Ingress-ის ორ მახასიათებლებზე, რომლებიც დაკავშირებულია პერსონალიზებული შეცდომის გვერდების ჩვენებასთან, ასევე მათში არსებულ შეზღუდვებზე და მათ გარშემო მუშაობის გზებზე.

1. ნაგულისხმევი ბექენდის შეცვლა

ნაგულისხმევად, NGINX Ingress იყენებს ნაგულისხმევ backend-ს, რომელიც ასრულებს შესაბამის ფუნქციას. ეს ნიშნავს, რომ 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, მოხვდება default-backend-ში. ზემოთ ჩამოთვლილ ჩამონათვალში ეს დომენი გახდა sadsdasdas.

2. HTTP შეცდომების დამუშავება აპლიკაციაში ნაგულისხმევი ბექენდის გამოყენებით

სხვა სიტუაციაა მოთხოვნები, რომლებიც მთავრდება HTTP შეცდომით (404, 500, 502...) აპლიკაციისთვის, რომელიც არ ამუშავებს ასეთ სიტუაციებს (შესაბამისი ლამაზი გვერდები არ გენერირებულია). ეს ასევე შეიძლება გამოწვეული იყოს დეველოპერების სურვილით, მოემსახურონ იგივე შეცდომის გვერდებს მრავალ აპლიკაციაში.

სერვერის მხარეს ამ შემთხვევის განსახორციელებლად ჩვენ გვჭირდება:

1. მიჰყევით ზემოთ მოცემულ ინსტრუქციას აბზაციდან ნაგულისხმევი ბექენდის შესახებ;
2. დაამატეთ გასაღები nginx-ingress კონფიგურაციის ConfigMap-ში custom-http-errorsმაგალითად, ღირებულებით 404,503 (აშკარად შეესაბამება შეცდომის კოდებს, რომლებიც დაფარულია ახალი წესით).

მოსალოდნელი შედეგი მიღწეულია: როდესაც კლიენტის აპლიკაცია გაშვებულია და მიიღებს შეცდომას საპასუხო კოდით 404 ან 503, მოთხოვნა ავტომატურად გადამისამართდება ახალ ნაგულისხმევ ფონზე...

თუმცა, აპლიკაციის შემუშავებისას ნაგულისხმევი backend და Custom-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 სრულიად განსხვავებული აპლიკაცია გაშვებული თქვენს კლასტერში და გსურთ მიუთითოთ სხვადასხვა ნაგულისხმევი backend-სერვისი და თითოეული მათგანისთვის შეცდომის სხვადასხვა კოდის დამუშავება, ამისთვის მოგიწევთ გამოსავლის გამოყენება, რომელთაგან ორი გვაქვს.

შემოსვლა < 0.23: მიდგომა ერთი

ეს ვარიანტი უფრო მარტივია. როგორც აპლიკაციას, რომელიც ემსახურება თავის გვერდებს, გვაქვს ჩვეულებრივი HTML, რომელმაც არ იცის როგორ დაათვალიეროს სათაურები და დააბრუნოს სწორი პასუხების კოდები. ასეთი აპლიკაცია შემოვიდა Ingress-თან ერთად 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: მეორე მიდგომა

ვარიანტი აპლიკაციისთვის, რომელსაც შეუძლია სათაურების დამუშავება... და ზოგადად ეს უფრო სწორი გზაა, ნასესხები 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;
      }

როგორც ხედავთ, თითოეული შეცდომისთვის, რომლის დამუშავებაც გვინდა, უნდა შევქმნათ საკუთარი მდებარეობა, სადაც ყველა საჭირო სათაური იქნება ჩასმული, როგორც "მშობლიურში". მორგებული შეცდომის გვერდები. ამ გზით ჩვენ შეგვიძლია შევქმნათ სხვადასხვა პერსონალიზებული შეცდომის გვერდები, თუნდაც ცალკეული მდებარეობებისა და სერვერებისთვის.

PS

სხვა K8s რჩევებისა და ხრიკების სერიიდან:

• «კლასტერში გაშვებული რესურსების გადაცემა Helm 2 მენეჯმენტზე";
• «ვებ აპლიკაციაში კვანძების განაწილებისა და ჩატვირთვის შესახებ";
• «დეველოპერის საიტებზე წვდომა";
• «ჩატვირთვის დაჩქარება დიდი მონაცემთა ბაზებისთვის".

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «დაუბრუნდით მიკროსერვისებს Istio-სთან ერთად. Მე -1 ნაწილი";
• «[ილუსტრირებული] გზამკვლევი ქსელში Kubernetes-ში. ნაწილი 3".

წყარო: www.habr.com