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 :
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.
Pour avoir une API gateway fonctionnelle, nous allons procéder en 3 étapes :
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 :
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 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.
Un KongConsumer est une ressource statique permettant de définir le consumer qui utilisera les routes définies derrière l’API gateway.
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.comAvant 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-postgresqlDans ces valeurs, je configure Kong avec quelques variables d'environnement grâce au paramètre env :
Automatiquement, le chart met cette variable à "off" car la base de données PostgreSQL est désactivée par défaut.
Ensuite, j'ajoute la configuration de PostgreSQL en dessous de la clé postgresql :
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.yamlVous avez déployé votre première version kong-ingress-controller ! Vous pouvez maintenant configurer votre Kong API gateway avec des plugins et des 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: 300Vous 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.
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-consumerEt 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.
Pour les mettre en œuvre, nous avons plusieurs choix :
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: 80Cet ingress définit certains paramètres importants :
Si vous avez plusieurs plugins, séparez-les par une virgule comme :
konghq.com/plugins: rate-limiting,plugin2,plugin3Créez cet ingress dans votre cluster Kubernetes, et voilà, votre Kong API gateway est prête !
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.