kong_api_gateway
Technology
• 5 min

Comment déployer une Kong API gateway dans un cluster Kubernetes ?

Nicolas Bax
Nicolas Bax

Publié le 19 mai 2022.

Dans mon dernier projet, je voulais déployer une Kong API gateway dans mon cluster Kubernetes. Cependant, j'ai réalisé que ce n’était pas la chose la plus facile à faire. Cet article a donc pour vocation de vous partager mon expérience du déploiement d’une Kong API gateway dans un cluster Kubernetes. Il ne parlera pas des autres API gateway.

Qu’est-ce que Kong ?

Kong est une application Lua utilisant Nginx pour avoir une API gateway devant de vos APIs. Grâce aux plugins Kong, vous pouvez personnaliser l'API gateway avec de nombreuses règles comme le rate-limiting, l'oauth2 ... Vous trouverez toutes les possibilités dans le hub Kong.

Imaginez que vous avez deux APIs : API 1 et API 2. Dans ces deux APIs, la première est un client de la seconde et l'API 2 n’est accessible qu’en passant par la Kong API gateway. Pour ce faire, vous devez créer les ressources suivantes :

Kong_apigateway

Consumer : L'utilisateur défini pour les routes de l'API 2

Routes : Les routes de l'API 2, qui seront derrière l’API gateway

Service : Composant qui représente votre API 2 au sein de la Kong API gateway

Load Balancer : Le load balancer de Kong

Plugins : Les plugins Kong pour définir les règles pour les routes API 2

Les consumers, routes, service et plugins doivent être créés par vos soins.

Comment déployer une Kong API gateway dans un cluster Kubernetes ?

Pour avoir une API gateway fonctionnelle, nous allons procéder en 3 étapes :

  • Déployer le Kong Ingress Controller
  • Configurer les plugins et les consumers Kong
  • Configurer les routes de l'API gateway

Déployer le Kong Ingress Controller

Un déploiement Kubernetes de Kong contient un ingress controller pour la gestion du trafic réseau. Vous avez différentes possibilités pour le déployer avec le manifeste YAML directement ou avec le chart helm.

Cet article vous montre comment le déployer avec Helm. Ce schéma déploie un contrôleur Ingress Kong. Il peut gérer le trafic réseau à l'intérieur du cluster.

À la fin de cet article, nous obtiendrons l'architecture suivante :

kong_cluster

Le cœur de cette configuration est le Kong Ingress Controller. Il a pour but de gérer toutes les routes de l'API gateway.

Pour stocker sa configuration, nous allons utiliser une base de données PostgreSQL.

Pour information, vous pouvez déployer une Kong API gateway sans base de données. Vous devez gérer la configuration d'une autre manière, comme une configmap.

Personnellement, je préfère utiliser une base de données car le mode sans base de données demande plus d'attention, surtout pour la mise à jour de la configuration.

Le Kong Ingress controller a besoin de quelques ressources statiques :

  • KongPlugins et KongClusterPlugin

KongPlugins et KongClusterPlugin vous permettent de créer des plugins Kong à l'intérieur du cluster. La seule différence est leur portée. KongPlugins agit dans son namespace, tandis que KongClusterPlugins agit partout.

Dans cet article, nous allons implémenter un rate-limiting. Le rate-limiting peut être configurée avec un Redis, et c'est ce que j'ai choisi.

  • KongConsumer

Un KongConsumer est une ressource statique permettant de définir le consumer qui utilisera les routes définies derrière l’API gateway.

  • Ingress

L'ingress est utilisé pour définir les routes de l’API gateway pour l'API 1. Kong vous permet de créer une ressource équivalente : KongIngress.

Elle offre plus de possibilités que l'ingress commun. Par exemple, vous pouvez définir une règle d'ingress pour ne répondre qu'à des requêtes de méthodes spécifiques comme GET, POST...

Dans notre cas, nous n'avons pas besoin d'une configuration spécifique pour les routes, donc j'ai choisi la ressource Ingress.

Maintenant, nous allons pouvoir commencer cette implémentation.

D'abord, nous avons besoin du repository du chart helm de Kong :

helm repo add kong https://charts.konghq.com

Avant d'installer le Kong Ingress Controller dans votre cluster, créez votre fichier values.yaml pour configurer le chart helm comme vous le souhaitez. Si vous utilisez les valeurs par défaut, vous n'avez pas besoin d'implémenter le fichier values.yaml suivant. Pour décider, vous pouvez vérifier les valeurs par défaut directement dans le repository Github.

env:
 pg_database: kong
 pg_host: kong-ingress-controller-postgresql
 database: postgres
 pg_user: kong
 pg_password:
  valueFrom:
   secretKeyRef:
    key: postgresql-password
    name: kong-ingress-controller-postgresql
postgresql:
 enabled: true
 postgresqlUsername: kong
 postgresqlDatabase: kong
 service:
  port: 5432
 existingSecret: kong-ingress-controller-postgresql

Dans ces valeurs, je configure Kong avec quelques variables d'environnement grâce au paramètre env :

  • pg_database : nom de la base de données
  • pg_host : le nom de domaine de la base de données
  • database : type de base de données

Automatiquement, le chart met cette variable à "off" car la base de données PostgreSQL est désactivée par défaut.

  • pg_user : utilisateur de la base de données
  • pg_password : mot de passe de la base de données

Ensuite, j'ajoute la configuration de PostgreSQL en dessous de la clé postgresql :

  • enabled : Activer la base de données PostgreSQL pour kong
  • postgresqlUsername : Nom d'utilisateur de la base de données
  • postgresqlDatabase : Nom de la base de données
  • service.port : Numéro de port du service Kubernetes de la base de données
  • existingSecret : Secret existant dans lequel se trouve le mot de passe de la base de données

Pour information, j'utilise un secret existant pour le mot de passe de la base de données, mais le chart peut créer un mot de passe pour votre base de données kong. Ainsi, il n'est pas nécessaire de spécifier les clés postgresql.existingSecret et env.pg_password.

Maintenant, installez la carte :

helm install kong-ingress-controller kong/kong-ingress-controller -f values.yaml

Vous avez déployé votre première version kong-ingress-controller ! Vous pouvez maintenant configurer votre Kong API gateway avec des plugins et des consumers.

Configurer les plugins et consumers

Dans mon cas, je n'ai choisi qu'un seul plugin pour vous montrer comment en créer un : le rate-limiting. Vous avez donc deux choix pour créer un plugin : KongClusterPlugin et KongPlugin. Le second ne s’utilise que dans son namespace, alors que le premier est disponible dans tous les namespaces. Dans mon exemple, je vais implémenter un KongPlugin, mais la configuration est la même pour une ressource KongClusterPlugin. Ainsi, vous pouvez simplement changer le type de la ressource Kubernetes pour transformer un KongPlugin en KongClusterPlugin.

Pour créer le KongPlugin pour le rate-limiting, j'utilise le fichier yaml suivant :

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limiting
  plugin: rate-limiting
config:
  policy: redis
  redis_host: redis-instance
  redis_port: 6379
  second: 300
  • plugin : c’est le type de plugin
  • config : la configuration du plugin
  • config.policy :

Vous avez trois possibilités pour ce paramètre : local, cluster et Redis.

Local signifie que le compteur sera stocké en mémoire.

Cluster signifie que la base de données kong stockera le compteur.

Redis signifie qu'un Redis stockera le compteur.

config.redis_host : le nom de domaine Redis.

  • config.second : Le nombre maximum de requêtes par seconde

J'ai choisi la valeur Redis parce que j'avais déjà un Redis dans mon cluster. Si vous voulez déployer un Redis, par exemple, vous pouvez utiliser le chart helm officielle de Redis.

Maintenant, nous avons notre plugin de rate-limiting, mais il manque un consumer !

La création d'un consumer Kong pour votre API gateway est très simple. Vous pouvez utiliser cette configuration :

apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: my-great-consumer
username: my-great-consumer
custom_id: my-great-consumer

Et voilà, c'est fait ! Votre consumer est prêt à être utilisé ! Cependant, je ne recommande pas d'utiliser cette configuration pour les environnements de production, car elle n'est pas totalement sûre. Dans cette configuration, nous n'avons pas d'authentification pour nos futures routes. Vous pouvez utiliser un autre plugin comme oauth2 pour configurer l'authentification sur votre consumer.

Pour l'instant, nous avons un ingress controller kong, un plugin de rate-limiting, et un consumer. Ainsi, notre API gateway.

À présent, il faut implémenter les routes.

Configurer les routes de l’API gateway

Pour les mettre en œuvre, nous avons plusieurs choix :

  • Utiliser l'ingress standard de Kubernetes
  • Utiliser les ressources KongIngress

Mon conseil est d'utiliser la première option lorsque vous souhaitez que toutes les requêtes pour une URL spécifique soient acheminées par la passerelle API Kong.

Si seules les requêtes POST doivent être acheminées par l’API gateway, choisissez la deuxième solution.

Dans mon cas, je veux juste acheminer toutes les requêtes par Kong. J'ai donc choisi une ressource Kubernetes Ingress standard.

Concernant mon architecture cible, je dois avoir seulement deux routes d'API derrière la passerelle API Kong : /users et /groups. Pour ce faire, j'ai implémenté l'ingress suivant :

apiVersion:
kind:
metadata:
 name: api-gateway-routes
 annotations:
  konghq.com/plugins: rate-limiting
spec:
 ingressClassName: "kong"
 rules:
  - host: myproject.api.me
    http:
     paths:
      - path: /users
        backend:
         serviceName: myproject
         servicePort: 80
      - path: /groups
        backend:
         serviceName: myproject
         servicePort: 80

Cet ingress définit certains paramètres importants :

  • ingressClassName : La classe de l'ingress.
  • annotations.konghq.com/plugins : La liste des plugins Kong
  • rules[].host : Le nom de domaine de l'API
  • rules[].host.http.paths[] : Les chemins des routes
  • rules[].host.http.paths[].backend : Le service d'API

Si vous avez plusieurs plugins, séparez-les par une virgule comme :

konghq.com/plugins: rate-limiting,plugin2,plugin3

Créez cet ingress dans votre cluster Kubernetes, et voilà, votre Kong API gateway est prête !

Conclusion

J'espère que cet article vous a aidé à faire ce que vous voulez. Vous connaissez désormais toutes les étapes de base du déploiement d'une Kong API gateway dans un cluster Kubernetes. Cependant, Kong vous offre de nombreuses possibilités avec ses plugins. Vous pouvez ajouter de multiples règles à votre API gateway, comme des règles de sécurité. Par conséquent, rendez-vous sur le hub des plugins Kong pour découvrir toutes les possibilités pour votre infrastructure.

Je pense que Kong est très intéressant lorsque vous voulez placer chaque route derrière une API gateway avec de nombreuses règles. Mais il peut être excessif si vous voulez juste une simple API gateway en raison de la complexité du déploiement.