Kong

Ce que couvre le produit

Kong Gateway est une passerelle API. Elle reçoit les appels, leur applique des plugins, puis les transmet à un service amont. La documentation publique du produit est regroupée sur developer.konghq.com/gateway. L’édition open source se concentre sur ce proxy. Kong propose par ailleurs des éditions commerciales et Kong Konnect, un plan de contrôle opéré par l’éditeur, avec des fonctions de gestion et de portail qui ne sont pas le cœur de la passerelle open source.

Cette page décrit le rôle du produit et les critères de mise en œuvre, à vérifier dans la documentation de l’édition réellement retenue : les écarts entre l’open source, l’édition entreprise et Konnect sont précisément le sujet à clarifier avant un choix.

Architecture typique

Le plan de données est le processus qui proxyfie le trafic. Le plan de contrôle porte la configuration : services, routes, consommateurs, plugins et certificats. Deux modes reviennent dans la documentation. Avec une base, souvent PostgreSQL, le plan de contrôle stocke la configuration et les nœuds de passerelle la récupèrent. En mode déclaratif, sans base, la configuration est un fichier appliqué au démarrage ou poussé vers l’Admin API. Le mode déclaratif simplifie la revue des changements, parce que la configuration peut vivre dans un dépôt. Il demande une discipline de déploiement : un fichier partiel ou un mauvais ordre d’application retire des routes encore utilisées.

Sur Kubernetes, Kong s’emploie aussi comme contrôleur d’ingress. Les routes sont alors déclarées par des ressources du cluster, en plus ou à la place de l’Admin API. Ce mode convient aux équipes qui publient déjà leurs services par l’API Kubernetes. Il se combine mal avec des modifications manuelles dans l’interface : une ressource reconvergée écrase le changement fait à la main.

Les plugins couvrent, selon l’édition, l’authentification, la limitation de débit, la journalisation, les transformations d’en-têtes et l’observabilité. La liste exacte dépend de la version et de la licence. Une conception saine nomme les plugins nécessaires et la version cible, plutôt que de supposer qu’un tutoriel d’une autre édition s’applique.

Points forts et limites

La passerelle est un processus spécialisé, avec un modèle d’extension par plugins et une configuration que l’on peut rendre déclarative. Elle s’insère devant des services HTTP, et la documentation décrit d’autres protocoles selon les versions, notamment gRPC. Le plan de données se réplique horizontalement. Le mode sans base retire un composant d’état de la chaîne d’appel.

La limite principale tient au périmètre. Une passerelle ne tient pas lieu, à elle seule, de portail développeur, de catalogue d’abonnements ni de suite d’analytique. Ces fonctions existent dans les offres Kong qui les incluent. Les ajouter plus tard change le mode d’exploitation et, souvent, l’édition du produit. L’autre limite est la dispersion de la logique dans les plugins : une transformation de corps de requête, une règle d’authentification spécifique et un routage conditionnel finissent par constituer un programme non testé, déployé au milieu du trafic.

L’Admin API est un point sensible. Exposée sans contrôle réseau, elle permet de modifier les routes. Elle se place sur un réseau d’administration, distinct du port qui reçoit le trafic des clients.

Quand le retenir

Kong convient lorsqu’il faut un proxy que l’équipe exploite elle-même, avec des plugins identifiés, sur machines virtuelles, conteneurs ou Kubernetes. Il convient aussi lorsqu’une configuration déclarative et un contrôleur d’ingress suffisent, et que le portail développeur n’est pas un prérequis du premier incrément.

Il convient moins lorsqu’il faut, dès le départ, un portail, une gestion d’abonnements et un cycle de vie d’API dans le même produit installé. WSO2 API Manager et Gravitee se présentent comme des plateformes plus larges. Le détail du choix entre Kong et WSO2 est repris dans l’article Kong vs WSO2 et dans le comparatif.

Migration et intégration

La migration vers Kong consiste à traduire des routes, des upstreams et des contrôles en services, routes et plugins. Les certificats, les noms de domaine et les politiques de limite de débit se reprennent un par un. Les comptes d’un portail source, les plans tarifaires et les tableaux de bord d’un autre produit ne se transportent pas avec la configuration du proxy.

L’identité se branche par plugin : clé d’API, OAuth 2.0, OpenID Connect ou un service d’autorisation externe, selon ce que l’édition fournit. Le fournisseur d’identité reste en général celui déjà utilisé par les applications. La passerelle vérifie le jeton. Elle ne remplace pas l’annuaire.

Les backends se déclarent comme upstreams, avec contrôles de santé si la version le permet. Un timeout, une nouvelle tentative et un code de coupure se fixent par upstream, pas par une valeur unique pour tout le parc. Les appels qui ne sont pas idempotents ne doivent pas être rejoués automatiquement.

Ce que Technocify peut prendre en charge

Le travail commence par un audit : routes actuelles, méthodes d’authentification, besoins de portail, cible Kubernetes ou machines virtuelles, édition envisagée. La conception choisit le mode avec ou sans base, le réseau de l’Admin API et la liste courte de plugins. La mise en œuvre déploie la passerelle, importe les premières routes et vérifie un appel authentifié de bout en bout. Le run couvre les montées de version des nœuds, la revue des changements déclaratifs et les alertes sur les erreurs amont.

Les équipes Technocify s’appuient sur une pratique de l’intégration et des API depuis 2009. Nos consultants sont certifiés WSO2 API Manager Practitioner V4 (2023), WSO2 API Manager Developer V3 (2021), MuleSoft Developer V4 (2022), Workato Automation Pro I, II, III (2025, valides jusqu’en 2027) et ITIL V4 (2020). Voir la page À propos.

Les pages plateformes API et cloud, cybersécurité et DevSecOps décrivent le périmètre d’ingénierie dans lequel cette passerelle s’insère.