គន្លឹះ និងល្បិច Kubernetes៖ ទំព័រកំហុសផ្ទាល់ខ្លួននៅក្នុង NGINX Ingress

នៅក្នុងអត្ថបទនេះ ខ្ញុំចង់និយាយអំពីលក្ខណៈពិសេសពីររបស់ NGINX Ingress ទាក់ទងនឹងការបង្ហាញទំព័រកំហុសផ្ទាល់ខ្លួន ក៏ដូចជាដែនកំណត់ដែលមាននៅក្នុងពួកវា និងវិធីដើម្បីធ្វើការជុំវិញពួកគេ។

1. ការផ្លាស់ប្តូរកម្មវិធីខាងក្រោយលំនាំដើម

តាមលំនាំដើម NGINX Ingress ប្រើកម្មវិធីខាងក្រោយលំនាំដើម ដែលដំណើរការមុខងារដែលត្រូវគ្នា។ នេះមានន័យថានៅពេលស្នើសុំ Ingress បញ្ជាក់ម៉ាស៊ីនដែលមិនមាននៅក្នុងធនធាន Ingress យើងទទួលបានទំព័រខាងក្រោមជាមួយនឹងលេខកូដឆ្លើយតប 404៖

ទោះជាយ៉ាងណាក៏ដោយ អតិថិជនរបស់យើងកាន់តែច្រើនឡើងៗមកជាមួយសំណើដើម្បីបង្ហាញទំព័ររបស់ពួកគេជាមួយនឹងនិមិត្តសញ្ញាសាជីវកម្ម និងគ្រឿងបរិក្ខារផ្សេងទៀតជំនួសឱ្យស្តង់ដារ 404 ។ ដើម្បីធ្វើដូចនេះ NGINX Ingress មាន សមត្ថភាពដែលភ្ជាប់មកជាមួយ កំណត់ឡើងវិញ default-backend-service. យើងបញ្ជូនធាតុទម្រង់ជាអាគុយម៉ង់ទៅជម្រើសនៃឈ្មោះដូចគ្នា។ namespace/servicename. ច្រករបស់សេវាកម្មគួរតែមាន 80 ។

ដើម្បីធ្វើដូច្នេះ អ្នកត្រូវបង្កើត pod ផ្ទាល់ខ្លួនរបស់អ្នក (ការដាក់ពង្រាយ) និងសេវាកម្មជាមួយនឹងកម្មវិធីរបស់អ្នក (ការអនុវត្តឧទាហរណ៍នៅក្នុង 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ធ្លាក់ចូលទៅក្នុង default-backend ។ នៅក្នុងបញ្ជីខាងលើ ដែននេះបានក្លាយជា sadsdasdas.

2. ដោះស្រាយកំហុស HTTP នៅក្នុងកម្មវិធីដោយប្រើកម្មវិធីខាងក្រោយលំនាំដើម

ស្ថានភាពមួយទៀតគឺសំណើដែលបញ្ចប់ដោយកំហុស HTTP (404, 500, 502...) ទៅកម្មវិធីដែលមិនដំណើរការស្ថានភាពបែបនេះ (ទំព័រដ៏ស្រស់ស្អាតដែលត្រូវគ្នាមិនត្រូវបានបង្កើតទេ)។ នេះក៏អាចដោយសារតែបំណងប្រាថ្នារបស់អ្នកអភិវឌ្ឍន៍ដើម្បីបម្រើទំព័រដែលមានកំហុសដូចគ្នានៅក្នុងកម្មវិធីជាច្រើន។

ដើម្បីអនុវត្តករណីនេះនៅផ្នែកខាងម៉ាស៊ីនមេ យើងត្រូវការ៖

1. អនុវត្តតាមការណែនាំខាងលើពីកថាខណ្ឌអំពីកម្មវិធីខាងក្រោយលំនាំដើម។
2. បន្ថែមសោទៅការកំណត់រចនាសម្ព័ន្ធ nginx-ingress ConfigMap custom-http-errorsឧទាហរណ៍ជាមួយនឹងតម្លៃ 404,503 (ច្បាស់​ណាស់​ត្រូវ​គ្នា​នឹង​កូដ​កំហុស​ដែល​គ្រប​ដណ្តប់​ដោយ​ច្បាប់​ថ្មី)។

លទ្ធផលរំពឹងទុកត្រូវបានសម្រេច៖ នៅពេលដែលកម្មវិធីអតិថិជនកំពុងដំណើរការ និងទទួលបានកំហុសជាមួយនឹងលេខកូដឆ្លើយតប 404 ឬ 503 សំណើនឹងត្រូវបានបញ្ជូនបន្តដោយស្វ័យប្រវត្តិទៅកម្មវិធីខាងក្រោយលំនាំដើមថ្មី...

ទោះយ៉ាងណាក៏ដោយ នៅពេលបង្កើតកម្មវិធីសម្រាប់កម្មវិធីខាងក្រោយលំនាំដើម និងកំហុសផ្ទាល់ខ្លួន 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.

ការពិតគឺថានៅពេលដែលសំណើត្រូវបានបញ្ជូនបន្ត បឋមកថានឹងមានព័ត៌មានមានប្រយោជន៍ជាមួយនឹងលេខកូដឆ្លើយតបពីមុន និងព័ត៌មានបន្ថែម (បញ្ជីពេញលេញរបស់ពួកគេអាចរកបាន នៅទីនេះ).

នេះមានន័យថាអ្នកត្រូវតែខ្លួនឯង ថែរក្សាលេខកូដឆ្លើយតបត្រឹមត្រូវ។. នេះគឺជាឧទាហរណ៍មួយ ពីឯកសារពីរបៀបដែលវាដំណើរការ។

កម្មវិធីផ្សេងគ្នាមានកម្មវិធីខាងក្រោយលំនាំដើមខុសៗគ្នា

ដើម្បីធានាថាដំណោះស្រាយមិនមានលក្ខណៈសកលសម្រាប់ចង្កោមទាំងមូល ប៉ុន្តែអនុវត្តចំពោះតែកម្មវិធីជាក់លាក់ប៉ុណ្ណោះ អ្នកត្រូវពិនិត្យមើលកំណែ Ingress ជាដំបូង។ ប្រសិនបើវាត្រូវគ្នា។ 0.23 ឬខ្ពស់ជាងនេះ។ប្រើចំណារពន្យល់ Ingress ដើម៖

1. យើងអាចបដិសេធបាន។ default-backend សម្រាប់ នៃគ្នា របស់ Ingress ដោយប្រើចំណារពន្យល់;
2. យើងអាចបដិសេធបាន។ 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 ដែលកំពុងដំណើរការនៅក្នុងចង្កោមរបស់អ្នក ហើយអ្នកចង់បញ្ជាក់សេវា default-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៖ វិធីសាស្រ្តទីពីរ

ជម្រើសសម្រាប់កម្មវិធីដែលអាចដំណើរការបឋមកថា... ហើយជាទូទៅនេះគឺជាវិធីដែលត្រឹមត្រូវជាង ដែលត្រូវបានខ្ចីពី 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;
      }

ដូចដែលអ្នកអាចឃើញសម្រាប់កំហុសនីមួយៗដែលយើងចង់ដំណើរការ យើងត្រូវបង្កើតទីតាំងរបស់យើង ដែលបឋមកថាចាំបាច់ទាំងអស់នឹងត្រូវបានបញ្ចូល ដូចជានៅក្នុង "ដើម" មួយ។ ទំព័រកំហុសផ្ទាល់ខ្លួន. វិធីនេះយើងអាចបង្កើតទំព័រកំហុសផ្ទាល់ខ្លួនផ្សេងៗគ្នា សូម្បីតែសម្រាប់ទីតាំងនីមួយៗ និងម៉ាស៊ីនមេក៏ដោយ។

PS

ផ្សេងទៀតពីស៊េរីគន្លឹះ និងល្បិច K8s៖

• «ការផ្ទេរធនធានដែលកំពុងដំណើរការក្នុងចង្កោមទៅការគ្រប់គ្រង Helm 2»
• «អំពីការបែងចែកថ្នាំង និងការផ្ទុកនៅលើកម្មវិធីបណ្តាញ»
• «ការចូលប្រើគេហទំព័រអភិវឌ្ឍន៍»
• «បង្កើនល្បឿន Bootstrap សម្រាប់មូលដ្ឋានទិន្នន័យធំ"។

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• «ត្រឡប់ទៅ សេវាមីក្រូ ជាមួយ Istio ។ ផ្នែកទី 1»
• «[រូបភាព] ការណែនាំអំពីបណ្តាញនៅក្នុង Kubernetes ។ ផ្នែកទី 3"។

ប្រភព: www.habr.com