Bienvenue dans cet article dédié à l’exposition d’applications sur un cluster Kubernetes. L’objectif est de combiner les fondamentaux avec des éléments plus récents liés au projet Kubernetes Gateway API.

Au programme :

• Introduction à l’exposition d’applications avec le Service Kubernetes

• Approfondissement avec l’Ingress

• Présentation rapide de la Gateway API en utilisant Cilium

Exposer des applications 101 : le service kubernetes  

Dans le paysage Kubernetes, les applications sont hébergées dans des pods. Un pod contient… un ou plusieurs containers, et est généralement inclut dans un autre controller comme un deployment ou un daemonset.  

Mais comment accéder à une application dans un pod ?  

Il est possible de chercher son IUP et essayer d’y accéder directement. Une simple commande kubectl get pod -o wide nous donnera cette information. 

 

Sauf que… Les pods sont en général regroupés sous un controller, et dans la majorité des cas, un network overlay est utilisé pour isoler les pods du reste du réseau. 

À noter : Il y a bien une option pour AKS qui permet de rendre les pods directement accessible depuis un workload connecté au Vnet. Il s’agit de Azure CNI, sans overlay.  

C’est pourquoi kubernetes inclut un objet natif appelé le service.  

Par exemple, un service exposant un pod demo, sur le port 8080 serait déclaré comme ci-dessous :  

 

 

Le service s’appuie sur les labels pour identifier vers quel(s) pod(s) rediriger le trafic. 

 

 

Notre pod demo est en fait un simple nginx, écoutant sur le port 80. Cela justifie le paramètre targetPort configuré sur 80, tandis que le port d’écoute du service est 8080. 

 

Le lecteur attentif remarquera sans doute la valeur <none> pour le champ EXTERNAL-IP, tandis que le service a une adresse sous le champ CLUSTER-IP.  Le pod vit dans un cluster AKS, configuré avec Azure CNI overlay, ce qui le rend par défaut, non accessible directement :

 

 

Dans ce contexte, le Cloud Controller Manager est utilisé pour permettre au control plane de Kubernetes la possibilité d’interagir avec la plateforme Cloud (ici Azure donc) et de créer un load balancer. En lieu et place du type ClusterIP, est remplacé par le type LoadBalancer.  

 

 

Dans un environnement Azure, si les flux ne sont pas bloqués par un NSG non managé par AKS, il devrait être possible d’accéder au service. 

 

 

 

Enfin, il est intéressant de noter les options de configurations du service de type LoadBalancer mis à disposition par le Cloud provider sous la forme d’annotations, comme dans l’exemple ci-dessous. 

 

 

Cette fois-ci, nous obtenons, à travers le Cloud Controller Manager, un Azure Internal Load Balancer :

 

 

L’aspect des services a été abordé. Et bien que cela soit une première option, elle s’avère insuffisante pour des applications web nécessitant des path http. Et c’est pour cela que l’utilisation = des objets ingress devient nécessaire. 

Exposer des applications mieux : l’ingress  

L’idée avec un Ingress est de donner des capacités de load balancing au niveau 7. Cette capacité n’est pas disponible dans le service kubernetes natif. 

 

 

 

Un ingress a besoin d’un Ingress Controller. Ce dernier doit être installé sur le cluster Kubernetes. Ici, les détails des installations ne seront pas abordés. Il existe déjà beaucoup de documentation sur le sujet, avec un Ingress Controller Nginx et dans un environnement Azure. 

Pour installer notre Ingress Controller, nous allons utiliser la commande Helm ci-dessous : 

 

 

Une fois l’installation réalisée, les ressources créées sont visibles dans le namespace cible. 

 

 

Il est également possible de constater une classe d’ingress par défaut.  Ce point sera approfondi ultérieurement.  

 

 

A présent, quelques applications seront créées pour illustrer notre propos. Nous utiliserons un déploiement nginx, avec une configuration map pour effectuer la customisation. 

 

 

Une fois l’application déployée, elle sera exposée dans le cluster avec un service. 

 

 

Il est possible de vérifier l’accessibilité de nos services sur le cluster depuis un pod. 

 

 

À présent, pour rendre notre application disponible avec une page main disponible sur le path http /main, et une page doc sur le path http /doc, il est nécessaire d’ajouter un ingress. 

 

 

À ce stade, nous sommes en mesure d’exposer des applications de manière public. Si l’exposition doit être uniquement en interne, dans la mesure ou l’Ingress Controller s’appuie sur un service kubernetes, il est normalement possible de configurer un ingress controller privé. 

Pour cela, il suffit d’ajouter les arguments : 

 controller.ingressClassResource.name= »internal-nginx » et controller.ingressClassResource.controllerValue= »k8s.io/ingress-nginx-internal ». 

Pour utiliser les annotations vues précédemment, on ajoute également : 

• controller.service.annotations. »service\.beta\.kubernetes\.io/azure-load-balancer-internal »=true 
• controller.service.annotations. »service\.beta\.kubernetes\.io/azure-load-balancer-internal-subnet »= »sub2-vnet-sbx-spokeaks1″ 

 

 

Après l’installation, 2 classes d’Ingress Controller, et 2 instances d’Ingress Controller, sont présentes dans deux namespaces. 

 

 

À présent, un nouvel ingress pour l’application, avec la nouvelle classe d’ingress controller. 

 

 

Depuis un réseau connecté au Vnet du cluster, l’accès à l’application peut être vérifié : 

 

 

Voilà qui conclut l’overview de l’ingress. Ceci étant, l’évolution de l’ingress est associée au projet Gateway API. 

Rapide overview de la Gateway API avec Cilium 

Jusqu’ici, le service kubernetes, ainsi que l’ingress pour gérer des path L7 ont été abordés. 

Il a également été démontré comment obtenir plus d’une instance d’ingress controller à l’aide des ingress class. 

 

Ce dernier point est l’une des limites de l’ingress controller, qui répond mal aux besoins de multi-tenancy dans un cluster unique. En effet, une équipe gérant l’ingress controller doit par design avoir accès aux ressources associées. Dans le cas où une seconde équipe a besoin de gérer également l’ingress controller, il faut de nouveau accorder des droits, et encourir le risque de conflits de configuration, ou ajouter une autre classe d’ingress avec un nouveau déploiement. 

 

De par l’âge de l’ingress controller, la plupart des providers ont développées leurs propres spécifications, à travers des annotations, ou des CRDs. 

 

Ce sont ces sujets que le projet Gateway API tente d’adresser.  

 

Alors que l’Ingress Controller requiert une installation spécifique, La Gateway API est définie à travers un ensemble de CRDs commune à toutes les implémentations de Gateway. De plus, le design prévoit par défaut une utilisation par plusieurs équipes, comme illustré par la documentation. 

 

 

• Les opérateurs d’infrastructure définissent la classe de Gateway et les fonctionnalités associées. 

• Les opérateurs de cluster, voire des développeurs avancés, créent et gèrent les gateway, basées sur les définitions des classes de Gateway. Chaque gateway utilise son propre service kubernetes sous-jacent. 

• Les équipes de développement utilisent les gateway disponibles, à travers les objets du projets Gateway API, comme les http routes. 

Concernant les CRDs de la Gateway API,il est possible de trouver davantage d’information dans la documentation du projet, ainsi que sur le repository Github associé. 

 

  Les ressources suivantes sont à noter :  

• Gateway Classs 

• Gateway 

• HTTPRoute 

• grpcRoute 

• TLSRoute 

 

Ces CRDs doivent être installées sur le cluster pour l’utilisation de la Gateway API. Les commandes suivantes permettent cette installation. 

 

 

Pour tester les fonctionnalités de la Gateway API, Cilium sera utilisé, avec un cluster AKS en mode byocni, et le remplacement de kube-proxy. 

 

 

Si tout est installé correctement, l’output suivante est obtenu avec le cilium. 

 

 

Et la Gateway class devrait être disponible. 

 

 

Dans le cas où la classe reste en status pending, il peut être nécessaire de redémarrer certains pods cilium. Ou de redémarrer le cluster AKS. 

 

 

Lorsque tout fonctionne, gateway peut être créer.

 

 

Et le service kubernetes sous-jacent. 

 

 

Il est possible d’avancer ensuite avec la création d’une application. 

 

 

Puis une HTTPRoute pour définir l’exposition de l’application. 

 

 

L’application devrait être disponible sur le path http://gapi.app.teknews.cloud, à la condition qu’un DNS record existe. 

 

 

Avant d’arriver à une conclusion temporaire, deux choses :  

 

Tout d’abord, il existe une option native dans les HTTPRoutes pour gérer le poids du trafic dans une application. Un exemple très clair est disponible dans la documentation cilium. 

 

 

Ensuite, il est possible de personnaliser les paramètres d’une Gateway avec une CRD supplémentaire. Dans le cas de cilium, il s’agit de la CiliumGatewayClassConfig. 

 

 

À travers cette CRD, il est possible par exemple de changer le type de service sous-jacent à la Gateway. En revanche, il n’y a pas actuellement d’option pour passer des annotations spécifiques sur le service. De fait, à moins d’utiliser un admission controller, la Gateway sera toujours publique. 

 

Conclusion 

 

L’exposition des applications est une chose à la fois simple et compliquée, en fonction des besoins et des moyens mis en œuvre. 

 

Un service kubernetes peut faire le travail, mais avec des limitations sur la couche 4 du réseau. 

 

Pour permettre une gestion des path http, il faut une autre approche qui s’appuiera dans le futur sur la Gateway API.  

 

Cette dernière permet de répondre à de nombreux cas d’usage grâce à ses différentes ressources, mais pèche encore sur des fonctionnalités présentes sur l’ingress controller ou le service. 

 

Dans une prochaine publication, nous regarderons plus en détails ces fonctionnalités, ainsi que différents providers de Gateway API. 

 

 

Vous avez envie de rejoindre Cellenza ?

Vous souhaitez rejoindre un cabinet de conseil engagé dans la RSE, reconnu pour son très haut niveau d’expertise ? Retrouvez tous nos postes ouverts sur notre site Carrière et n’hésitez pas à contacter notre équipe Recrutement !