Astuces et astuces Kubernetes : pages d'erreur personnalisées dans NGINX Ingress

Dans cet article, je veux parler de deux possibilités d'NGINX Ingress liées à l'affichage de pages d'erreur personnalisées, ainsi que des limitations existantes et des moyens de les contourner.

1. Modification du backend par défaut

Par défaut, NGINX Ingress utilise un backend par défaut, qui remplit la fonction correspondante. Cela signifie que lorsqu'une requête Ingress est effectuée avec un hôte qui n'existe pas dans les ressources Ingress, nous obtenons une page avec le code de réponse 404 :

Cependant, de plus en plus de nos clients demandent de montrer leur propre page avec le logo de l'entreprise et d'autres commodités au lieu du standard 404. Pour cela, NGINX Ingress dispose d'une fonctionnalité intégrée pour remplacer default-backend-service. Nous passons en argument à l'option éponyme une entrée au format namespace/servicename. Le port du service doit être 80.

Pour cela, il est nécessaire de créer votre propre pod (déploiement) et service avec votre application (exemple de mise en œuvre en YAML du dépôt ingress-nginx), qui sera renvoyé à la place du backend par défaut.

Voici une petite illustration :

~$ 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>La page que vous recherchez est introuvable.</span>

Ainsi, tous les domaines qui ne sont pas explicitement créés via YAML avec kind: Ingress, tombent dans le backend par défaut. Dans la liste ci-dessus, ce domaine est devenu sadsdasdas.

2. Traitement des erreurs HTTP dans l'application par le backend par défaut

Une autre situation concerne les requêtes se terminant par des erreurs HTTP (404, 500, 502…) vers une application qui ne gère pas de telles situations (les pages d'erreur correspondantes ne sont pas générées). Cela peut également être dû au désir des développeurs de renvoyer des pages d'erreur identiques dans plusieurs applications.

Pour réaliser ce cas du côté serveur, nous devons :

1. Exécuter l'instruction ci-dessus du point concernant le backend par défaut ;
2. Ajouter la clé custom-http-errorsau ConfigMap de nginx-ingress, par exemple, avec la valeur 404,503 (clairement, correspond aux codes d'erreur auxquels la nouvelle règle s'applique).

Le résultat attendu est atteint : lors du fonctionnement de l'application client, si une erreur avec un code de réponse 404 ou 503 est obtenue, la requête sera automatiquement redirigée vers le nouveau backend par défaut…

Cependant, lors du développement d'une application pour le backend par défaut et les custom-http-errors, il est important de prendre en compte un aspect essentiel :

!!! Important Le backend personnalisé est censé renvoyer le code d'état HTTP correct au lieu de 200. NGINX ne change pas la réponse du backend par défaut personnalisé.

Le fait est qu'en redirigeant la requête, des informations utiles sur l'ancien code de réponse et des informations supplémentaires seront dans les en-têtes (liste complète disponible ici).

Cela signifie que vous devez vous-même vous assurer que le code de réponse est correct. Voici un exemple de la documentation sur le fonctionnement de cela.

Différentes applications nécessitent un backend par défaut différent

Pour que la solution ne soit pas globale à tout le cluster, mais soit uniquement liée à des applications spécifiques, il faut d'abord vérifier la version de l'Ingress. Si elle est conforme à 0.23 ou supérieure, utilisez les annotations "natales" d'Ingress :

1. Nous pouvons redéfinir default-backend pour chaque d'Ingress en utilisant l'annotation En conséquence, la ressource Ingress ressemblera à peu près à cela :;
2. Nous pouvons redéfinir custom-http-errors pour chaque d'Ingress en utilisant l'annotation En conséquence, la ressource Ingress ressemblera à peu près à cela :.

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

Dans ce cas, les erreurs 404 et 502 seront redirigées vers le service error-pages avec tous les en-têtes nécessaires.

dans les versions précédentes d'Ingress, cette possibilité n'était pas disponible

Dans le commit marquant dans 0.23 (). Et si vous avez 2 applications complètement différentes dans votre cluster et que vous souhaitez spécifier différentes default-backend-service et gérer différents codes d'erreur pour chacune d'elles, vous devrez utiliser des solutions de contournement, dont nous en avons deux.Ingress < 0.23 : première approche

Cette option est plus simple. En tant qu'application qui fournit ses pages, nous avons un simple HTML qui ne sait pas lire les en-têtes et fournir des codes de réponse corrects. Cette application est déployée avec Ingress à l'url

, et dans le répertoire /error-pagesws se trouvera le HTML fourni. Illustration en 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

Le service pour ce déploiement doit être de type ClusterIP.

Dans l'application où nous traiterons l'erreur, nous ajoutons un server-snippet ou un configuration-snippet dans l'Ingress avec le contenu suivant :

Dans l'application où nous allons traiter l'erreur, nous ajoutons un server-snippet ou un configuration-snippet dans l'Ingress avec le contenu suivant :

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: deuxième approche

Option pour une application capable de traiter les en-têtes… D'ailleurs, c'est un chemin plus correct, emprunté à custom-http-errors. Son utilisation manuelle (copie) permettra de ne pas modifier les paramètres globaux.

Les étapes suivantes. Créons un déploiement similaire avec une application capable d'écouter les en-têtes requis et de répondre correctement. Ajoutons dans l'Ingress de l'application le server-snippet avec le contenu suivant :

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

Comme on peut le voir, pour chaque erreur que nous voulons traiter, il est nécessaire de créer un emplacement où tous les en-têtes nécessaires seront insérés, comme dans le « natif » custom-error-pages. Ainsi, nous pouvons créer différentes pages d'erreur personnalisées même pour des emplacements et des serveurs distincts.

P.S.

Autre extrait de la série K8s tips & tricks :

• «Migration des ressources en cours d'exécution dans le cluster sous Helm 2»;
• «Sur la déallocation des nœuds et la charge sur les applications web»;
• «Accès aux environnements de développement»;
• «Accélération du bootstrap de grandes bases de données».

Lisez aussi dans notre blog :

• «Retour aux microservices avec Istio. Partie 1»;
• «[Illustré] Guide sur l'architecture du réseau dans Kubernetes. Partie 3».

Source : habr.com