A propos de la Kubernetes Gateway API

Bonjour à tous, 

Faisant suite à notre dernier post à propos de l’exposition des applications sur Kubernetes,  ce nouvel article propose de creuser davantage ce sujet que nous avons effleuré : la Kubernetes Gateway API. 

 Nous commencerons par un aperçu des options disponibles pour implémenter cette Gateway API, puis nous nous concentrerons sur 2 objets de l’API : la Gateway Class, et la Gateway. 

 L’agenda :  

• Quelques Gateway API providers 

• A propos de la Gateway Class 

• A propos de la Gateway 

1. Quelques Gateway API providers 

Les discussions autour de la Gateway API ont débuté dans un article dont le but était de discuter des moyens disponibles pour l’exposition d’application. 

Comme mentionné dans la documentation Kubernetes, l’API Ingress est à présent gelée, et la Gateway API en est son successeur officiel. 

Toujours dans la documentation, une liste des implémentations de cette Gateway est disponible parmis lesquelles , et de manière non exhaustive :  

• Nginx Gateway Fabric 

• Traefik Proxy 

• Istio 

• Application Gateway for Containers 

• Cilium 

A l’exception Cillium qui est encore en beta, tous les autres providers de cette liste sont en GA. 

Il est également possible de mentionner Hashicorp Consul qui pourrait être une alternative intéressante. 

Pour utiliser une implémentation de la Gateway API, il est nécessaire de disposer de quelques CRDs à priori. Ces CRDs sont :  

• La Gateway Class 

• La Gateway 

• La Http Route 

Il convient également de mentionner les objets suivants :  

• La gRPC Route 

• La TLS Route 

• Le Referent Grant 

Il convient de noter, point important, que toutes ces CRDs ne sont pas nécessairement au même état dans leur cycle de vie (GA vs Beta…) 

Les informations détaillées sur ces CRDs sont disponibles sur le github repository dédié. 

 A noter que la version stable actuelle est 1.3. 

La présence des CRDs sur un cluster, peut être vérifié à l’aide d’une commande kubectl 

Une fois ce point validé, il est temps d’installer un Gateway provider. 

Dans le cadre de cet article, malgré le statut Beta de sa Gateway API, nous utilisons un cluster avec Cilium comme CNI et procédons à l’activation de la feature avec un argument additionnel.

Si l’installation est complète, après le redémarrerage des pods Cilium, une Gateway Class devrait être disponible. 

Pour l’installation d’un provider, malgré toute la qualité de la documentation Kubernetes, il est préférable de consulter la documentation dédiée du provider choisi afin, entre autres, de valider la version des CRDs suppportée par le provider. 

 Par exemple, à la date d’écriture de cet article, la documentation pour la Gateway API de Traefik mentionne un support des CRDs en version 1.2.1. 

Dans le cas de Cilium,  la version stable actuelle supporte la version 1.2.0. 

Le remier point d’attention consiste donc, à valider la version des CRDs supportée par le Gateway API provider. 

De fait, il faudra donc être particulièrement prudent si l’on souhaite faire co-exister 2 providers de Gateway AP. 

Ces premiers points vus, passons à présent à la Gateway Class. 

2. A propos de la Gateway Class 

2.1. Quelques concepts 

L’installation d’un provider de Gateway API fournit une première Gateway Class. Avec un cluster AKS et Cilium en BYO CNI, la classe suivante est disponible. 

L’affichage en yaml  fournit des informations importantes sur le statut de la Gateway Class. 

La section conditions doit afficher type: Accepted et status: « True ». 

La section spec contient le  controllerName qui spécifie le provider utilisé. Ici, nous notons la valeur io.cilium/gateway-controller.  

En se référant au schéma de l’organisation rôle-centrique de la gateway API, on note que la Gateway Class est gérée côté Infrastructure Provider 

Ainsi, un Infrastructure Provider est en théorie est capable de définir une classe pour le trafic public et une autre pour le trafic privé. 

Regardons à présent l’objet API dans la documentation, afin de déterminer quelles sont nos options pour configurer davantage une Gateway Class. Le premier niveau de paramètres contient les éléments suivants :  

La section parametersRef est utilisée pour des configurations spécifiques au provider, et peut renvoyer vers une CRD ou une configmap. 

Dans le cas de Cilium, il y a effectivement une CRD appelé CiliumGatewayClassConfig qui peut être utilisé pour donner des paramètres supplémentaires, spécifique à Cilium. 

 Examinons comment utiliser ces différents paramètres. 

2.2. Expérimentations avec la GatewayClass 

Une commande kubectl nous a permis précédemment d’identifier la GatewayClass Cilium par défaut. 

Pour créer davantage de GatewayClass, par exemple pour du trafic interne et externe les définitions ci-dessous peuvent être utilisées :  

Après application du fichier, nous obtenons 2 nouvelles GatewayClass. 

A ce stade cependant, rien ne permet de spécifier dans les futures Gateway si celles-ci devraient être privées ou publiques. 

Dans le cadre de Cilium, il est possible d’utiliser la CRD CiliumGatewayClassConfig mentionnée précédemment. 

La section spec de cette CRD, visible sur la documentation Cilium est comme suit :  

Il convient de noter que la ressource est namespaced, et que son nom court est cgccc. 

Cette CRD permet de manipuler le type de service. il est possible d’écrire la définition suivante pour changer le type de service des Gateway d’une classe donnée. 

Au passage, la documentation Cilium réfère des exemples avec un service de type NodePort, utile pour des sandbox local sans Cloud Controller Manager, mais pas avec du ClusterIP comme dans notre exemple.  

 D’autre part, pour faire un peu de lien avec notre plateforme Cloud (ici Azure), il n’y a pas au niveau de la GatewayClass de moyen de passer des annotations comme service.beta.kubernetes.io/azure-load-balancer-internal: « true » pour forcer des Gateway avec des services de type LoadBalancer mais utilisant un service Azure LoadBalancer Internal.  

La GatewayClass est un équivalent à l’IngressClass des ingress controllers, et on verra que les annotations sont plutôt gérées au niveau de la Gateway.  

A présent, l’étape suivante concerne Gateway.  

3. A propos de la Gateway 

3.1. Concepts de base de la Gateway 

Comme le schéma ci-dessous le représente, la Gateway est le premier élément auquel accède un client qui veut atteindre une application exposée dans un environnement Kubernetes. 

Tenant compte de cette représentation, ainsi que de l’organisation Role-Based de la Gateway API,les divergences avec le modèle Ingress deviennent plus claires. 

En effet, avec un Ingress Controller, un unique point d’accès a été défini (sous la forme d’un service Kubernetes finalement, toute la partie L7 étant prise en charge par le dit controller), alors chaque Gateway est un point d’accès, obtenu d’une ou plusieurs GatewayClass. 

 Ci-dessous une définition de Gateway, avec la GatewayClass Cilium par défaut. 

La création de cette Gateway entrainera la création d’un service correspondant, préfixé avec cilium–gateway-. 

À noter par ailleurs que l’on a bien un service de type LoadBalancer. 

Également, on remarque le paramètre metadata.ownerReferences qui indique la dépendance à une Gateway. 

Essayons à présent de customiser un peu notre Gateway. 

3.2. Utilisation d’une GatewayClass avec une configuration Custom 

Dans cette section, la CRD  

CiliumGatewayClassConfig présenté précédemment est réexaminée  

Une GatewayClass custom est disponible utilisant une CRD pour changer le type de service. 

Et la définition de Gateway associée. 

La Gateway attendue devrait avoir un service sous-jacent de type ClusterIP, sans valeur attribuée pour l’adresse externe. Toutefois, on se rend compte que ce n’est pas le cas. 

Dans ce cas spécifique, la CRD CiliumGatewayClassConfig  n’a pas donné le résultat escompté. 

Est-il tout de même possible d’obtenir une Gateway s’appuyant sur un Azure Internal Load Balancer ? 

Essayons d’éditer le service associé d’une Gateway, en ajoutant l’annotation appropriée,  

 Après un peu d’attente, le service est mis à jour et s’appuie sur un Internal LoadBalancer. 

Nous avons donc obtenu le résultat attendu, mais cela n’est pas très satisfaisant. Observons nos options en analysant un peu plus l’API correspondant à la Gateway. 

 3.3. Analyse de l’objet Gateway 

Comme pour la GatewayClass, la documentation de la Gateway API donne les détails de l’objet Gateway. 

Dans la section spec, la sous-section infrastructure, contient les paramètres AnnotationKey et AnnotationValue.  

 Une nouvelle Gateway peut être créer avec cette section infrastructure. 

Une Gateway est obtenue avec une adresse privée, et son service associé qui hérite de l’annotation passée. 

La Gateway créée est finalement de type interne, mais sa nature n’a pas été hérité de la GatewayClass. 

Faisons un petit résumé. 

Conclusion 

Nous avons vu un peu plus en profondeur les 2 objets de la Gateway API suivant :  

• La GatewayClass 

• La Gateway 

 La GatewayClass, comme pour l’IngressClass, est utilisé pour définir des propriétés qui seront héritées par les Gateway enfants. 

La Gateway n’a pas d’équivalent dans l’architecture Ingress Controller. Elle constitue le point d’entrée pour les applications qui sont exposées. Il est possible de partager des Gateway sur différents namespaces, mais ce sera un sujet pour une autre fois. 

De la même manière, les détails pour l’exposition d’une application, et notamment l’usage de la http Route, seront vu prochainement.