Cunsiglii è trucchi Kubernetes: pagine d'errore persunalizate in NGINX Ingress

In questu articulu, vogliu parlà di duie caratteristiche di NGINX Ingress in relazione à a visualizazione di e pagine d'errore persunalizate, è ancu di e limitazioni chì esistenu in elli è e manere di travaglià intornu.

1. Cambia u backend predeterminatu

Per automaticamente, NGINX Ingress usa u backend predeterminatu, chì eseguisce a funzione currispondente. Questu significa chì quandu dumandate un Ingress chì specifica un òspite chì ùn hè micca in i risorse Ingress, ricevemu a pagina seguente cù un codice di risposta 404:

Tuttavia, sempre più spessu i nostri clienti venenu cù una dumanda di mustrà a so pagina cù un logu corporativu è altre amenità invece di u standard 404. Per fà questu, NGINX Ingress hà capacità integrata ridefinisce default-backend-service. Passemu l'entrata di formatu cum'è un argumentu à l'opzione di u listessu nome namespace/servicename. U portu di u serviziu deve esse 80.

Per fà questu, avete bisognu di creà u vostru propiu pod (implementazione) è serviziu cù a vostra applicazione (Esempiu di implementazione in YAML da u repository ingress-nginx), chì serà datu invece di u backend predeterminatu.

Eccu una piccula illustrazione:

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

Allora tutti i domini chì ùn sò micca esplicitamente creati via YAML cù kind: Ingress, caduta in default-backend. In u listinu sopra, stu duminiu hè diventatu sadsdasdas.

2. Trattamentu di l'errori HTTP in l'applicazione utilizendu u backend predeterminatu

Un'altra situazione hè e dumande chì finiscinu in errori HTTP (404, 500, 502...) à una applicazione chì ùn tratta micca tali situazioni (e belle pagine currispundenti ùn sò micca generate). Questu pò ancu esse dovutu à u desideriu di i sviluppatori di serve e stesse pagine di errore in parechje applicazioni.

Per implementà stu casu in u latu di u servitore avemu bisognu:

1. Segui l'istruzzioni sopra da u paragrafu nantu à u backend predeterminatu;
2. Aghjunghjite una chjave à a cunfigurazione nginx-ingress ConfigMap custom-http-errors, per esempiu, cù u valore 404,503 (ovviamente currisponde à i codici d'errore chì sò cuparti da a nova regula).

U risultatu previstu hè statu ottinutu: quandu l'applicazione cliente hè in esecuzione è riceve un errore cù un codice di risposta di 404 o 503, a dumanda serà automaticamente redirettata à u novu backend predeterminatu ...

Tuttavia, quandu si sviluppa una applicazione per backend predefinitu è ​​custom-http-errors, avete bisognu di piglià in contu una funzione impurtante:

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

U fattu hè chì quandu una dumanda hè ridiretta, l'intestazione cuntenenu infurmazioni utili cù u codice di risposta precedente è infurmazioni supplementari (a so lista completa hè dispunibule ccà).

Questu significa chì tù stessu devi cura di u codice di risposta curretta. Eccu un esempiu da a documentazione cumu funziona.

Diverse applicazioni anu backends predefiniti diffirenti

Per assicurà chì a suluzione ùn hè micca globale per u cluster sanu, ma s'applica solu à l'applicazioni specifiche, avete prima bisognu di verificà a versione Ingress. S'ellu currisponde 0.23 o più altu, utilizate l'annotazioni Ingress native:

1. Pudemu annullà default-backend di di ognunu Ingressu usendu annotazioni;
2. Pudemu annullà custom-http-errors di di ognunu Ingressu usendu annotazioni.

In u risultatu, a risorsa di l'Ingress sarà cusì cusì:

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

In questu casu, l'errori 404 è 502 seranu rediretti à u serviziu di e pagine d'errore cù tutti l'intestazione necessaria.

В versioni precedenti di Ingress ùn avianu micca sta funzione (commit fatale à 0.23). È s'è vo avete 2 appricazzioni cumplitamenti differente in u vostru cluster è vo vulete specificà un differente difettu-backend-service è trasfurmazioni di differente codice d'errore per ognuna di elli, per quessa vi tuccherà à aduprà workarounds, di quali avemu dui.

Ingressu < 0.23: avvicinà unu

Questa opzione hè più simplice. Cum'è una applicazione chì serve e so pagine, avemu HTML regulare, chì ùn sapi micca cumu guardà l'intestazione è torna i codici di risposta curretta. Una tale applicazione hè lanciata cù Ingress da l'url /error-pages, è in u catalogu ws serà u HTML restituitu.

Illustrazione in 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

U serviziu per questa implementazione deve esse di u tipu ClusterIP.

À u listessu tempu, in l'applicazione induve processeremu l'errore, in Ingress aghjunghjemu un servitore-snippet o cunfigurazione-snippet cù u seguente cuntenutu:

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

Ingressu < 0.23: seconda avvicinamentu

Una opzione per una applicazione chì pò processà intestazioni ... È in generale questu hè un modu più currettu, prestitu da custom-http-errors. Aduprà manualmente (copià) vi permetterà micca di cambià i paràmetri globale.

I passi sò i seguenti. Creemu a stessa implementazione cù una applicazione chì pò sente i tituli necessarii è risponde bè. Aghjunghjite un servitore-snippet à l'applicazione Ingress cù u cuntenutu seguente:

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

Comu pudete vede, per ogni errore chì vulemu processà, avemu bisognu di fà u nostru propiu locu, induve tutti l'intestazione necessarii seranu inseriti, cum'è in u "nativu". pagine d'errore persunalizate. Questu modu pudemu creà diverse pagine d'errore persunalizate ancu per locu individuali è servitori.

PS

Altru da a serie di cunsiglii è trucchi K8s:

• «Trasferimentu di risorse in esecuzione in u cluster sottu u cuntrollu di Helm 2";
• «Circa l'assignazione di nodi è i carichi nantu à l'applicazione web";
• «Accessu à i siti di sviluppu";
• «Accelerazione di bootstrap per grandi basa di dati».

Leghjite puru nant'à u nostru blog:

• «Torna à i microservizi cù Istio. Parte 1";
• «[Illustratu] Guida à a rete in Kubernetes. Parte 3».

Source: www.habr.com