Introduction : Le moment de vérité Depuis son lancement, Microsoft 365 Copilot divise. D’un côté, des promesses d’une révolution de...
20 novembre 2025
Toujours à propos de la Kubernetes Gateway API
Bonjour !
Dans un article précédent, l’attention était porté sur la GatewayClass, et la Gateway, deux objets de l’API de la… Gateway API. L’analyse s’est arrêtée avant de réellement répondre à la question de l’exposition d’application.
Ce nouvel article, poursuit l’exploration des objets relatifs à la Gateway API et nous attaquons plus précisément comment exposer les applications, avec la HTTPRoute.
L’agenda :
- Introduction à la HTTPRoute
- Ajouter la prise en charge de TLS
- Conclusion
Pour rappel, une GatewayClass, et quelques Gateways ont été crées
Ce qui a ppermisd’identifier la possibilité de passer des annotations au Service kubernetes créé avec la Gateway, à travers la propriété spec.infrastructure.annotations. Bien qu’il soit possible, dans le cas de la Gateway API Cilium, d’utiliser la crd spécifique pour customiser la GatewayClass, nous avons finalement utilisé la propriété au niveau de la Gateway.
A ce stade, le manifest yaml de laGateway prends la forme suivante
Et nous utilisons les capacités d’Azure pour avoir un load balancer de type internal avec un manifest comme ci-dessous :
A présent, regardons comment effectivement gérer l’exposition de nos applications.
1. Introduction à la HTTPRoute
1.1. Les bases
L’exposition d’application dans Kubernetes est donc réalisée avec un objet appelé HTTPRoute.
Considérons une application basée sur un simple Deployment, ainsi qu’un Service :
Avec un Service de type ClusterIP, l’application n’est accessible que depuis l’intérieur du cluster.
Ajoutons une HTTPRoute.
Dans la section hostnames,un nom d’hôte doit être spécifié et résolvable d’un point de vue DNS. Dans le cas présent, un enregistrement est utilisé sur une Azure DNS zone. Cette étape n’est pas détaillée, puisque c’est un peu hors sujet.
Depuis un navigateur, le résultat est le suivant.
Ajoutons à présent quelques services à notre application, et voyons comment nous pouvons gérer cela.
1.2. Gestion de path avec la HTTPRoute
Avant de d’aborder dans ce sujet, prenons un peu de recul.
Avec un Nginx Ingress Controller,pour exposer, disons, 3 services,
un Ingress est défini de la manière suivante :
Sous réserve que les services existent, (et les deployments associés), lacommande curl devrait produire le résultat suivant
Mais la partie la plus intéressante ici est l’annotation ‘nginx.ingress.kubernetes.io/rewrite-target: /’ qui, comme on peut le supposer, ré-écrit les path depuis l’ingress vers le path ‘/’.
Tentons d’obtenir un résultat similaire avec une HTTPRoute.
Quelques deployments et services supplémentaires ont été crées.
L’objectif est d’exposer l’application barbatos via une HTTPRoute. une règle supplémentaire est ajoutée dans la section spec.rules.
Est-ce que cela fonctionne ?
Une réponse Not Found est obtenue d’un pod nginx constituant l’application. Ce qui est au demeurant logique, puisque qu’aucune ré-écriture du path n’a été spécifié. Le trafic est donc dirigé vers les pods de l’application sur le path /barbatos, alors que les pods en question ne servent que le path ‘/’.
Il est possible de confirmer cette affirmation en regardant les logs du pod correspondant.
La documentation de l’API de la HTTPRoute est consultée afin de trouver une solution.
Dans la section spec.rules, nous avons déjà ajouté une section matches, qui contient notre path cible.
La documentation de la HTTPRoute, mentionne l’existence d’une section filters qui peut être ajouter. Plus spécifiquement, le type URLRewrite présente un intérêt particulier.
| Field | Description | Default | Validation |
| type | Type defines the type of path modifier. | Enum: [ReplaceFullPath ReplacePrefixMatch] | |
| replaceFullPath | Specifies the value with which to replace the full path of a request during a rewrite or redirect. | MaxLength: 1024 | |
| replacePrefixMatch | Specifies the value with which to replace the prefix match of a request during a rewrite or redirect. | MaxLength: 1024 |
Dans notre cas, nous allons donc utiliser ces propriétés pour modifier notre path avec :
- Un type avec la valeur ReplacePrefixMatch
- La propriété ReplacePrefixMatch configurée avec la valeur ‘/’ pour remplacer le path de la HTTPRoute vers le path ‘/’ sur le container.
Ce qui nous donne le résultat ci-après.
Et une HTTPRoute fonctionnelle sur l’url http://gundam.app.teknews.cloud/barbatos.
Le lecteur attentif (ou l’utilisateur d’Ingress expérimenté) aura remarqué que la configuration pour la ré-écriture du path est ici gérée pour chaque backend. Ce n’était pas forcément le cas avec un Ingress Controller, qui s’appuyait sur des annotations au niveau de l’Ingress, comme pour Nginx avec ‘nginx.ingress.kubernetes.io/rewrite-target: /’ que nous avons utilisé plus haut.
On peut donc noter que si la configuration de rewrite est peut etre un peu plus complexe, elle permet d’être également plus granulaire que dans le cas d’un Ingress.
Avant de passer à la gestion du TLS, observons la notion de gestion du poids.
1.3. Gérer le poids avec une HTTPRoute
Cette fonctionnalité a été abordé dans un article précédemment : la HTTPRoute peut nativement gérer le poids entres différents backend.
En recherchant dans la documentation, nous pouvons trouver la propriété spec.rules.backendRefs.weigh.
| Field | Description | Default | Validation |
| weight | Weight specifies the proportion of requests forwarded to the referenced backend. This is computed as weight/(sum of all weights in this BackendRefs list). | 1 | Max 1e+06
Min 0 |
En transposant cette propriété dans une HTTPRoute, nous obtenons une configuration comme ci-après.
L’équilibrage se vérifie à l’aide d’une simple commande bash.
Ici, la répartition de poids est d’environ 50/50.
En modifiant la configuration comme ceci :
La répartition devient beaucoup plus déséquilibrée comme attendu par les poids des backends respectifs.
Le sujet est à présent terminé. Passons à la gestion de TLS
2. Ajouter la prise en charge de TLS
2.1. Considérations pour l’usage de TLS avec la Gateway API
Comme pour les parties précédentes, la documentation de la Gateway Api sert de référence
Depuis le point de vue de la Gateway, :
- La connexion downstream, qui a lieu entre le client et la Gateway
- La connexion upstream, qui a lieu entre la Gateway et le Service en backend.
De ce point de vue, la gestion de la connectivité avec TLS, plus exactement avec HTTPS, est limitée, dans le cas de la HTTPRoute, a une terminaison TLS au niveau de la Gateway.
On notera que ce n’est pas l’unique scenario, comme le résume le tableau ci-après.
Dans cette section, nous nous limiterons toutefois à l’usage de la HTTPRoute et donc au scénario de terminaison TLS sur la Gateway.
Note : On utilisera ici TLS ou HTTPS de manière interchangeable, bien que les deux ne soient pas tout à fait équivalent. Ici, TLS avec HTTPRoute est forcément avec HTTPS.
| Listener Protocol | TLS Mode | Route Type supported |
| TLS | Passthrough | TLSRoute |
| TLS | Terminate | TCPRoute |
| HTTPS | Terminate | HTTPRoute |
| gRPC | Terminate | GRPCRoute |
Regardons à présent comment effectivement configurer HTTPS sur notre HTTPRoute.
2.2 Configuration de HTTPS
La configuration TLS est réalisée en premier lieu au niveau de la Gateway.
La documentation de la Gateway foiurnit des informations sur le paramètre spec.listeners.tls.
| Field | Description | Default | Validation |
| mode | Mode defines the TLS behavior for the TLS session initiated by the client. There are two possible modes:
– Terminate: The TLS session between the downstream client and the Gateway is terminated at the Gateway. This mode requires certificates to be specified in some way, such as populating the certificateRefs field. – Passthrough: The TLS session is NOT terminated by the Gateway. This implies that the Gateway can’t decipher the TLS stream except for the ClientHello message of the TLS protocol. The certificateRefs field is ignored in this mode. |
Terminate | Enum: [Terminate Passthrough] |
| certificateRefs | CertificateRefs contains a series of references to Kubernetes objects that contains TLS certificates and private keys.
These certificates are used to establish a TLS handshake for requests that match the hostname of the associated listener. A single CertificateRef to a Kubernetes Secret has « Core » support. Implementations MAY choose to support attaching multiple certificates to a Listener, but this behavior is implementation-specific. References to a resource in different namespace are invalid UNLESS there is a ReferenceGrant in the target namespace that allows the certificate to be attached. If a ReferenceGrant does not allow this reference, the « ResolvedRefs » condition MUST be set to False for this listener with the « RefNotPermitted » reason. This field is required to have at least one element when the mode is set to « Terminate » (default) and is optional otherwise. CertificateRefs can reference to standard Kubernetes resources, i.e. Secret, or implementation-specific custom resources. |
MaxItems: 64 |
Puis sur l’objet enfant spec.listenrers.tls.certificateRefs.
| Field | Description | Default | Validation |
| group | Group is the group of the referent. For example, « gateway.networking.k8s.io ». When unspecified or empty string, core API group is inferred. | MaxLength: 253
|
|
| kind | Kind is kind of the referent. For example « Secret ». | Secret | MaxLength: 63
MinLength: 1 |
| name | Name is the name of the referent. | ||
| namespace | Namespace is the namespace of the referenced object. When unspecified, the localnamespace is inferred.
Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace’s owner to accept the reference. |
MaxLength: 63
MinLength: 1 |
Ce qui permet de définir une configuration comme ci-dessous :
Dans le cas présent, le secret a été créer à l’aide de kubectl :
Une fois les objets kubernetes créés, une Gateway et une HTTPRoute sont disponibles.
A l’aide de curl, on peut vérifier la connectivité.
Voilà qui finalise notre exploration de la HTTPRoute.
Passons à la conclusion.
Conclusion
Cette fois-ci, l’accent a été mis sur comment effectivement exposer une application à travers l’usage d’une Gateway et d’un HTTPRoute.
La gestion de certificat est définie au niveau de la Gateway, à travers un objet référent qui est jusqu’ici un kubernetes Secret.
Apparaît également la mention de namespace dans les différents objets utilisés, ce qui laisse sous-entendre une prise en charge cross-namespace pour par exemple, des scenarios de Gateway et de certificat mutualisé.
Mais ce sera un sujet pour un autre article.
