ຄຳແນະນຳ ແລະເຄັດລັບ Kubernetes: ໜ້າຂໍ້ຜິດພາດແບບກຳນົດເອງໃນ NGINX Ingress

ໃນບົດຄວາມນີ້, ຂ້ອຍຕ້ອງການເວົ້າກ່ຽວກັບສອງລັກສະນະຂອງ NGINX Ingress ທີ່ກ່ຽວຂ້ອງກັບການສະແດງຫນ້າຄວາມຜິດພາດສ່ວນບຸກຄົນ, ເຊັ່ນດຽວກັນກັບຂໍ້ຈໍາກັດທີ່ມີຢູ່ໃນພວກມັນແລະວິທີການເຮັດວຽກອ້ອມຂ້າງພວກເຂົາ.

1. ການປ່ຽນແປງ backend ເລີ່ມຕົ້ນ

ໂດຍຄ່າເລີ່ມຕົ້ນ, NGINX Ingress ໃຊ້ backend ເລີ່ມຕົ້ນ, ເຊິ່ງປະຕິບັດຫນ້າທີ່ທີ່ສອດຄ້ອງກັນ. ນີ້ຫມາຍຄວາມວ່າເມື່ອຮ້ອງຂໍ Ingress ລະບຸໂຮດທີ່ບໍ່ຢູ່ໃນຊັບພະຍາກອນ Ingress, ພວກເຮົາໄດ້ຮັບຫນ້າຕໍ່ໄປນີ້ດ້ວຍລະຫັດຕອບໂຕ້ 404:

ຢ່າງໃດກໍ່ຕາມ, ເລື້ອຍໆລູກຄ້າຂອງພວກເຮົາມາພ້ອມກັບຄໍາຮ້ອງຂໍເພື່ອສະແດງຫນ້າຂອງພວກເຂົາດ້ວຍໂລໂກ້ຂອງບໍລິສັດແລະສິ່ງອໍານວຍຄວາມສະດວກອື່ນໆແທນທີ່ຈະເປັນມາດຕະຖານ 404. ເພື່ອເຮັດສິ່ງນີ້, NGINX Ingress ມີ ຄວາມສາມາດໃນຕົວ ນິຍາມໃໝ່ default-backend-service. ພວກເຮົາຜ່ານລາຍການຮູບແບບເປັນການໂຕ້ຖຽງກັບທາງເລືອກຂອງຊື່ດຽວກັນ namespace/servicename. ພອດຂອງບໍລິການຄວນຈະເປັນ 80.

ເພື່ອເຮັດສິ່ງນີ້, ທ່ານຈໍາເປັນຕ້ອງສ້າງ pod ຂອງທ່ານເອງ (ການນໍາໃຊ້) ແລະການບໍລິການກັບຄໍາຮ້ອງສະຫມັກຂອງທ່ານ (ຕົວຢ່າງການປະຕິບັດໃນ YAML ຈາກ ingress-nginx repository), ເຊິ່ງຈະຖືກມອບໃຫ້ແທນ 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, ຕົກຢູ່ໃນ default-backend. ໃນລາຍຊື່ຂ້າງເທິງ, ໂດເມນນີ້ໄດ້ກາຍເປັນ sadsdasdas.

2. ການຈັດການຄວາມຜິດພາດ HTTP ໃນແອັບພລິເຄຊັນໂດຍໃຊ້ backend ເລີ່ມຕົ້ນ

ສະຖານະການອື່ນແມ່ນການຮ້ອງຂໍທີ່ສິ້ນສຸດໃນຄວາມຜິດພາດ HTTP (404, 500, 502 ... ) ກັບແອັບພລິເຄຊັນທີ່ບໍ່ດໍາເນີນການສະຖານະການດັ່ງກ່າວ (ຫນ້າທີ່ສວຍງາມທີ່ສອດຄ້ອງກັນບໍ່ໄດ້ຖືກສ້າງຂຶ້ນ). ນີ້ອາດຈະເປັນຍ້ອນຄວາມປາຖະຫນາຂອງນັກພັດທະນາທີ່ຈະຮັບໃຊ້ຫນ້າຄວາມຜິດພາດດຽວກັນໃນຫຼາຍຄໍາຮ້ອງສະຫມັກ.

ເພື່ອປະຕິບັດກໍລະນີນີ້ໃນດ້ານເຊີຟເວີພວກເຮົາຕ້ອງການ:

1. ປະຕິບັດຕາມຄໍາແນະນໍາຂ້າງເທິງຈາກວັກກ່ຽວກັບ backend ເລີ່ມຕົ້ນ;
2. ເພີ່ມກະແຈໃສ່ການຕັ້ງຄ່າ nginx-ingress ConfigMap custom-http-errors, ສໍາລັບການຍົກຕົວຢ່າງ, ກັບມູນຄ່າ 404,503 (ແນ່ນອນກົງກັນກັບລະຫັດຂໍ້ຜິດພາດທີ່ຖືກຄຸ້ມຄອງໂດຍກົດລະບຽບໃຫມ່).

ຜົນໄດ້ຮັບທີ່ຄາດໄວ້ແມ່ນບັນລຸໄດ້: ເມື່ອຄໍາຮ້ອງສະຫມັກຂອງລູກຄ້າກໍາລັງແລ່ນແລະໄດ້ຮັບຂໍ້ຜິດພາດທີ່ມີລະຫັດຕອບສະຫນອງຂອງ 404 ຫຼື 503, ຄໍາຮ້ອງຂໍຈະຖືກໂອນໄປຫາ backend ເລີ່ມຕົ້ນໃຫມ່ໂດຍອັດຕະໂນມັດ ...

ຢ່າງໃດກໍຕາມ, ໃນເວລາທີ່ການພັດທະນາຄໍາຮ້ອງສະຫມັກສໍາລັບ backend ເລີ່ມຕົ້ນແລະ custom-http-errors, ທ່ານຈໍາເປັນຕ້ອງໄດ້ພິຈາລະນາຄຸນນະສົມບັດທີ່ສໍາຄັນ:

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

ຄວາມຈິງແລ້ວແມ່ນວ່າເມື່ອຄໍາຮ້ອງຂໍຖືກປ່ຽນເສັ້ນທາງ, headers ຈະມີຂໍ້ມູນທີ່ເປັນປະໂຫຍດກັບລະຫັດຕອບສະຫນອງທີ່ຜ່ານມາແລະຂໍ້ມູນເພີ່ມເຕີມ (ບັນຊີລາຍຊື່ເຕັມຂອງພວກເຂົາແມ່ນມີຢູ່. ທີ່ນີ້).

ນີ້ຫມາຍຄວາມວ່າຕົວທ່ານເອງຕ້ອງ ເບິ່ງແຍງລະຫັດການຕອບໂຕ້ທີ່ຖືກຕ້ອງ. ນີ້ແມ່ນຕົວຢ່າງ ຈາກເອກະສານວິທີການເຮັດວຽກ.

ແອັບພລິເຄຊັນທີ່ແຕກຕ່າງກັນມີ backends ເລີ່ມຕົ້ນທີ່ແຕກຕ່າງກັນ

ເພື່ອໃຫ້ແນ່ໃຈວ່າການແກ້ໄຂບໍ່ແມ່ນທົ່ວໂລກສໍາລັບກຸ່ມທັງຫມົດ, ແຕ່ໃຊ້ກັບຄໍາຮ້ອງສະຫມັກສະເພາະ, ທ່ານຈໍາເປັນຕ້ອງກວດເບິ່ງສະບັບ Ingress. ຖ້າມັນກົງກັນ 0.23 ຫຼືສູງກວ່າ, ໃຊ້ຄໍາບັນຍາຍ Ingress ພື້ນເມືອງ:

1. ພວກເຮົາສາມາດ override default-backend ການ ແຕ່ລະຄົນ Ingress ຂອງ ການ​ນໍາ​ໃຊ້​ຄໍາ​ອະ​ທິ​ບາຍ​;
2. ພວກເຮົາສາມາດ override 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). ແລະຖ້າທ່ານມີ 2 ແອັບພລິເຄຊັນທີ່ແຕກຕ່າງກັນຫມົດທີ່ແລ່ນຢູ່ໃນກຸ່ມຂອງທ່ານແລະທ່ານຕ້ອງການກໍານົດຄ່າເລີ່ມຕົ້ນ - backend-service ທີ່ແຕກຕ່າງກັນແລະການປຸງແຕ່ງລະຫັດຂໍ້ຜິດພາດທີ່ແຕກຕ່າງກັນສໍາລັບແຕ່ລະພວກມັນ, ສໍາລັບນີ້, ທ່ານຈະຕ້ອງໃຊ້ວິທີການແກ້ໄຂບັນຫາ, ເຊິ່ງພວກເຮົາມີສອງອັນ.

Ingress < 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 ພວກເຮົາເພີ່ມ server-snippet ຫຼື configuration-snippet ທີ່ມີເນື້ອຫາຕໍ່ໄປນີ້:

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

Ingress < 0.23: ວິທີທີສອງ

ທາງ​ເລືອກ​ສໍາ​ລັບ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ທີ່​ສາ​ມາດ​ປະ​ມວນ​ຜົນ headers ... ແລະ​ໂດຍ​ທົ່ວ​ໄປ​ນີ້​ແມ່ນ​ເປັນ​ວິ​ທີ​ທີ່​ຖືກ​ຕ້ອງ​ຫຼາຍ​, ຢືມ​ຈາກ custom-http-errors​. ການນໍາໃຊ້ມັນດ້ວຍຕົນເອງ (ການຄັດລອກ) ຈະຊ່ວຍໃຫ້ທ່ານບໍ່ປ່ຽນແປງການຕັ້ງຄ່າທົ່ວໂລກ.

ຂັ້ນ​ຕອນ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​. ພວກເຮົາສ້າງ ການ​ນໍາ​ໃຊ້​ດຽວ​ກັນ​ ກັບຄໍາຮ້ອງສະຫມັກທີ່ສາມາດຟັງຫົວຂໍ້ທີ່ຈໍາເປັນແລະຕອບສະຫນອງຢ່າງຖືກຕ້ອງ. ເພີ່ມ server-snippet ໃສ່ແອັບພລິເຄຊັນ 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;
      }

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ສໍາລັບແຕ່ລະຂໍ້ຜິດພາດທີ່ພວກເຮົາຕ້ອງການທີ່ຈະດໍາເນີນການ, ພວກເຮົາຈໍາເປັນຕ້ອງສ້າງສະຖານທີ່ຂອງພວກເຮົາເອງ, ບ່ອນທີ່ສ່ວນຫົວທີ່ຈໍາເປັນທັງຫມົດຈະຖືກໃສ່, ຄືກັບ "native" ຫນຶ່ງ. custom-error-pages. ວິທີນີ້ພວກເຮົາສາມາດສ້າງຫນ້າຄວາມຜິດພາດສ່ວນບຸກຄົນທີ່ແຕກຕ່າງກັນເຖິງແມ່ນວ່າສໍາລັບສະຖານທີ່ສ່ວນບຸກຄົນແລະເຄື່ອງແມ່ຂ່າຍ.

PS

ອື່ນໆຈາກຊຸດເຄັດລັບ ແລະເຄັດລັບຂອງ K8s:

• «ການໂອນຊັບພະຍາກອນທີ່ເຮັດວຽກຢູ່ໃນກຸ່ມໄປຫາການຈັດການ Helm 2"
• «ກ່ຽວກັບການຈັດສັນ node ແລະການໂຫຼດໃນແອັບພລິເຄຊັນເວັບ"
• «ການເຂົ້າເຖິງເວັບໄຊທ໌ dev"
• «ເລັ່ງ bootstrap ສໍາລັບຖານຂໍ້ມູນຂະຫນາດໃຫຍ່".

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ກັບໄປຫາບໍລິການຈຸລະພາກກັບ Istio. ພາກທີ 1"
• «[ຮູບແຕ້ມ] ຄູ່ມືກ່ຽວກັບເຄືອຂ່າຍໃນ Kubernetes. ພາກທີ 3".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com