Kubernetes maslahatlari va fokuslari: NGINX kirishidagi maxsus xato sahifalari

Ushbu maqolada men NGINX Ingress-ning shaxsiylashtirilgan xato sahifalarini ko'rsatish bilan bog'liq ikkita xususiyati, shuningdek ulardagi cheklovlar va ularni hal qilish usullari haqida gapirmoqchiman.

1. Standart backendni o'zgartirish

Odatiy bo'lib, NGINX Ingress mos keladigan funktsiyani bajaradigan standart backenddan foydalanadi. Bu shuni anglatadiki, kirish manbalarida bo'lmagan xostni ko'rsatuvchi kirish so'rovida biz 404 javob kodi bilan quyidagi sahifani olamiz:

Biroq, mijozlarimiz tobora ko'proq o'z sahifalarini standart 404 o'rniga korporativ logotip va boshqa qulayliklar bilan ko'rsatishni so'rashmoqda. Buning uchun NGINX Ingress mavjud o'rnatilgan qobiliyat qayta belgilang default-backend-service. Biz format yozuvini bir xil nomdagi variantga argument sifatida o'tkazamiz namespace/servicename. Xizmat porti 80 bo'lishi kerak.

Buning uchun siz ilovangiz bilan o'z pod (tarqatish) va xizmat yaratishingiz kerak (YAMLda amalga oshirish misoli ingress-nginx omboridan), bu standart backend o'rniga beriladi.

Mana kichik rasm:

~$ 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>

Shunday qilib, YAML orqali aniq yaratilmagan barcha domenlar kind: Ingress, default-backend ichiga tushadi. Yuqoridagi ro'yxatda bu domen bo'ldi sadsdasdas.

2. Standart backend yordamida ilovadagi HTTP xatolarini boshqarish

Yana bir holat - HTTP xatolari (404, 500, 502...) bilan tugaydigan so'rovlar, bunday holatlarga ishlov bermaydigan dasturga (tegishli chiroyli sahifalar yaratilmaydi). Bu, shuningdek, ishlab chiquvchilarning bir nechta ilovalarda bir xil xato sahifalariga xizmat ko'rsatish istagi bilan bog'liq bo'lishi mumkin.

Ushbu ishni server tomonida amalga oshirish uchun bizga kerak:

1. Standart backend haqidagi paragrafdagi yuqoridagi ko'rsatmalarga amal qiling;
2. ConfigMap nginx-ingress konfiguratsiyasiga kalit qo'shing custom-http-errors, masalan, qiymat bilan 404,503 (shubhasiz, yangi qoida bilan qamrab olingan xato kodlariga mos keladi).

Kutilgan natijaga erishildi: mijoz ilovasi ishlayotganda va 404 yoki 503 javob kodi bilan xatolik paydo bo'lganda, so'rov avtomatik ravishda yangi standart backendga yo'naltiriladi...

Biroq, standart backend va maxsus-http-xatolar uchun dasturni ishlab chiqishda siz muhim xususiyatni hisobga olishingiz kerak:

!!! 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.

Gap shundaki, so'rov qayta yo'naltirilganda sarlavhalar oldingi javob kodi va qo'shimcha ma'lumotlar bilan foydali ma'lumotlarni o'z ichiga oladi (ularning to'liq ro'yxati mavjud) shu yerda).

Bu o'zingiz qilishingiz kerak degan ma'noni anglatadi to'g'ri javob kodiga e'tibor bering. Mana bir misol qanday ishlashini hujjatlardan.

Turli xil ilovalarda turli xil standart backendlar mavjud

Yechim butun klaster uchun global emas, balki faqat ma'lum ilovalar uchun qo'llanilishini ta'minlash uchun avval Ingress versiyasini tekshirishingiz kerak. Agar mos kelsa 0.23 yoki undan yuqori, mahalliy kirish izohlaridan foydalaning:

1. Biz bekor qila olamiz default-backend uchun har birining Kirish izohlardan foydalanish;
2. Biz bekor qila olamiz custom-http-errors uchun har birining Kirish izohlardan foydalanish.

Natijada, Ingress resursi quyidagicha ko'rinadi:

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

Bunday holda, 404 va 502 xatolar barcha kerakli sarlavhalar bilan xato sahifalari xizmatiga yo'naltiriladi.

В Ingressning oldingi versiyalarida bu xususiyat yo'q edi (0.23 da taqdirli majburiyat). Va agar sizning klasteringizda ikkita mutlaqo boshqa dastur ishlayotgan bo'lsa va siz ularning har biri uchun turli xil standart-backend-servis va turli xil xato kodlarini qayta ishlashni belgilamoqchi bo'lsangiz, buning uchun vaqtinchalik echimlardan foydalanishingiz kerak bo'ladi, ulardan ikkitasi bor.

Kirish < 0.23: birinchisiga yaqinlashish

Bu variant oddiyroq. O'z sahifalariga xizmat ko'rsatadigan dastur sifatida bizda oddiy HTML mavjud, u sarlavhalarga qanday qarashni va to'g'ri javob kodlarini qaytarishni bilmaydi. Bunday ilova url-dan Ingress bilan chiqariladi /error-pages, va katalogda ws qaytarilgan HTML bo'ladi.

YAMLdagi rasm:

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

Ushbu joylashtirish uchun xizmat ClusterIP turida bo'lishi kerak.

Shu bilan birga, biz xatoni qayta ishlaydigan dasturda, Ingress-da biz quyidagi tarkibga ega server-snippet yoki konfiguratsiya-snippetini qo'shamiz:

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;
      }

Kirish < 0.23: ikkinchi yondashuv

Sarlavhalarni qayta ishlay oladigan dastur uchun variant ... Va umuman olganda, bu maxsus-http-xatolardan olingan yanada to'g'ri yo'l. Uni qo'lda ishlatish (nusxalash) global sozlamalarni o'zgartirmaslikka imkon beradi.

Bosqichlar quyidagicha. Biz yaratamiz bir xil joylashtirish kerakli sarlavhalarni tinglashi va to'g'ri javob berishi mumkin bo'lgan ilova bilan. Ingress ilovasiga quyidagi tarkibga ega server-snippet qo'shing:

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;
      }

Ko'rib turganingizdek, biz qayta ishlamoqchi bo'lgan har bir xato uchun biz o'z joylashuvimizni belgilashimiz kerak, bu erda barcha kerakli sarlavhalar "mahalliy" sarlavhada bo'lgani kabi kiritiladi. maxsus xato sahifalari. Shunday qilib, biz hatto alohida manzillar va serverlar uchun ham turli shaxsiylashtirilgan xato sahifalarini yaratishimiz mumkin.

PS

K8s maslahatlar va fokuslar seriyasidan boshqa:

• «Klasterda ishlaydigan resurslarni Helm 2 boshqaruviga o'tkazish";
• «Veb-ilovada tugunlarni taqsimlash va yuklash haqida";
• «Dev saytlariga kirish";
• «Katta ma'lumotlar bazalari uchun yuklash tezligini oshirish".

Shuningdek, bizning blogimizda o'qing:

• «Istio bilan mikroservislarga qaytish. 1-qism";
• «[Illustrated] Kubernetes-da tarmoqqa ulanish bo'yicha qo'llanma. 3-qism".

Manba: www.habr.com