Kubernetes / Helm

tester une route Ingress

Collez du YAML déjà rendu puis indiquez l’hôte et le chemin d’une requête.

YAML ou JSON des manifestes

Rapport de routage

Collez les manifestes ou chargez un exemple.

Analyse dans ce navigateur, sans connexion au cluster ni requête HTTP.

Paramètres de requête

Hôte demandéChemin demandé

Exact et Prefix suivent Kubernetes; les règles du contrôleur sont exclues.

Limites : 300 000 caractères, 100 ressources, 500 chemins.

Collez les manifestes ou chargez un exemple.

Une règle Ingress peut correspondre au chemin tout en désignant un port absent du Service. Tester une route Ingress permet de suivre une requête précise jusqu’à ce point de rupture.

Le rapport décrit les manifestes fournis, sans requête HTTP ni accès au cluster. Il distingue les références manquantes des informations d’exécution indisponibles.

Pourquoi tester une route Ingress ?

Suivre une requête plutôt qu’un graphe entier

Pour tester une route Ingress, le moteur choisit le chemin correspondant le plus long, puis Exact en cas d’égalité. Il suit ensuite le port du Service vers targetPort.

Une ligne bleue suit le chemin Ingress sélectionné jusqu’au Service et à la charge de travail.

Ne pas confondre rupture et doute

Un port de Service absent est une rupture vérifiable. Sans manifeste Pod, le rapport indique une information inconnue et ne prétend pas que le service est en panne.

Une liaison orange interrompue montre la référence cassée; un pointillé indique les données d’exécution inconnues.

Trois vérifications avant de modifier le YAML

Joindre les objets liés

Séparez Ingress et Service par --- puis ajoutez éventuellement Deployment ou Pod. Un Service homonyme dans un autre namespace ne satisfait pas la référence.

Définir la requête exacte

Le chemin initial est /. Essayez /api/orders et renseignez l’en-tête Host si la règle en exige un. Un Host vide ne teste que les règles sans hôte.

Lire le niveau de preuve

Une correspondance concerne la règle statique. Une rupture montre une référence absente; un résultat incertain dépend du contrôleur. Après modification, relancez avant de copier.

Du chemin au port cible

Sélection Host et chemin

Tester une route Ingress couvre Exact, Prefix par segments, l’hôte exact et le joker sur un seul sous-domaine. /api ne correspond pas à /apix. Le routage Ingress Kubernetes est évalué selon les seules règles standard.

Deux ports aux rôles différents

Le backend Ingress cherche le port du Service par numéro ou nom. Ce Service mappe ensuite vers targetPort, ou vers le même numéro si targetPort manque.

Contexte de charge facultatif

Si un Pod ou un modèle Deployment est présent, le sélecteur du Service est comparé à ses labels. En leur absence, aucun endpoint actif n’est supposé.

Ce que le rapport statique ne garantit pas

Les contrôleurs gardent leurs propres règles: ImplementationSpecific, regex et annotations de réécriture dépendent du contrôleur. Tester une route Ingress les signale comme incertains sans leur attribuer un comportement Prefix.
Aucun trafic réel: Pour comprendre une erreur 404 Ingress, vérifiez aussi les journaux du contrôleur, DNS, EndpointSlice et la réponse HTTP. Cette page lit seulement le YAML local.
Un Pod absent du collage n’est pas une panne: Le cluster peut contenir d’autres Pods ou des endpoints manuels. Seul un Service ou un port référencé mais absent des manifestes fournis constitue une rupture certaine ici.
Périmètre borné: 300 000 caractères, 100 ressources et 500 chemins au maximum. Le YAML doit être rendu; Gateway API et modèles Helm ne sont pas interprétés.

Questions pour tester une route Ingress

Pourquoi mon Ingress renvoie-t-il 404 pour un chemin défini ?

Une réponse 404 peut provenir d’un hôte ou chemin différent, d’un backend par défaut, d’une réécriture ou de l’application. Le rapport éclaire les règles statiques; consultez les journaux pour la réponse réelle.

Le backend Ingress utilise-t-il le port du Service ou targetPort ?

Le backend vise le numéro ou le nom du port du Service. Le Service traduit ensuite ce port vers targetPort. Utiliser directement le port du Pod peut produire une référence absente.

Le préfixe /foo correspond-il à /foobar ?

Non. Prefix /foo correspond à /foo et /foo/bar, mais pas à /foobar. La casse compte également.

Quelle règle l'emporte entre Exact et Prefix ?

Le chemin correspondant le plus long gagne; à longueur égale, Exact l’emporte sur Prefix. Plusieurs règles équivalentes entre Ingress restent incertaines.

Un manifeste suffit-il à prouver qu'un Pod répond ?

Non. Le manifeste ne prouve ni la disponibilité du Pod, ni les EndpointSlices, DNS ou la connexion réseau.

Une autre question sur la route ?