Cette architecture de référence décrit comment répartir WSO2 API Manager 4.3 sur Kubernetes à partir des composants documentés par l’éditeur. Elle ne fixe pas un nombre de réplicas universel, ni une taille de cluster. Ces valeurs dépendent du trafic, des exigences de disponibilité et du mode d’exploitation retenu. La source à garder ouverte est la documentation Deploying API Manager with Kubernetes or OpenShift resources, lue avec la page d’architecture. La page WSO2 API Manager revient sur le produit lui-même.
Les plans à ne pas fusionner
La documentation 4.3 sépare le plan de gestion, le plan de données et le plan de contrôle. Le plan de gestion comprend l’API Publisher, le portail développeur, le catalogue de services et l’analytique. Le plan de données porte les appels : passerelle API, Micro Integrator et Streaming Integrator. Le plan de contrôle comprend le Key Manager et le Traffic Manager. Sur Kubernetes, cette séparation se traduit par des déploiements distincts, ou au minimum par des services distincts, plutôt que par un unique pod qui cumule tous les rôles en production.
Un runtime unique reste documenté pour un démarrage ou un environnement de développement. Il simplifie la prise en main. Il concentre aussi les pannes : redémarrer le pod pour une mise à jour du Publisher redémarre la passerelle qui sert le trafic. L’architecture de référence pour une production sépare donc la passerelle des consoles. La passerelle se réplique avec le volume d’appels. Le Publisher et le portail se répliquent, plus modestement, avec le nombre de personnes qui publient ou consultent le catalogue.
Ingress et noms
L’ingress du cluster est le point d’entrée. Il termine ou relaie TLS, puis oriente vers le bon service. Trois noms, au moins, méritent d’être distincts : le nom public de la passerelle, celui du portail développeur s’il est accessible aux partenaires, et celui du Publisher, réservé à l’administration. Les placer sur le même hôte avec des chemins voisins facilite les erreurs de règle d’ingress et élargit la surface exposée.
Le Publisher n’a pas vocation à être publié sur Internet au même titre que la passerelle. Un réseau d’administration, un VPN ou une restriction d’adresses suffisent dans la plupart des organisations. Le portail, lui, est fait pour des développeurs externes lorsqu’il y en a. S’il n’y en a pas, il peut rester interne. La passerelle, enfin, porte les noms que les applications consommatrices appellent. Changer ce nom plus tard oblige tous les clients à suivre. Il se choisit avant la première publication.
Les certificats vivent dans des secrets du cluster, renouvelés par la procédure déjà en place pour les autres ingress. Un keystore embarqué dans l’image du produit fige un secret dans un artefact versionné. Ce n’est pas un mode d’exploitation durable.
Passerelle, bac à sable et révisions
La documentation décrit la possibilité de maintenir une passerelle de production et une passerelle de bac à sable. Sur le cluster, ce sont deux cibles de déploiement, avec des backends différents. Une API publiée en bac à sable pointe vers des services de test. La même API, une fois promue, pointe vers les services de production. Mélanger les deux dans un seul déploiement « pour aller plus vite » produit des appels réels vers des bouchons, ou l’inverse.
Les révisions d’API, documentées dans le produit, permettent de préparer une configuration puis de la déployer sur la passerelle choisie. Dans un flux de travail sobre, la révision est le livrable. On ne modifie pas à la main une API déjà servie sans laisser de trace de la révision précédente. Le retour arrière consiste à redéployer la révision antérieure, pas à éditer un écran sous la pression d’un incident.
Key Manager et Traffic Manager
Le Key Manager délivre et valide les jetons. Il peut être celui du produit ou un gestionnaire tiers, les deux cas étant documentés. Sur Kubernetes, il est un déploiement à part, avec sa propre base, joignable par la passerelle et par les applications qui demandent un jeton. L’URL de jeton fait partie du contrat public au même titre que l’URL de la passerelle. La changer casse les clients.
Le Traffic Manager porte les décisions de quota. Les nœuds de passerelle le consultent. S’il est indisponible, le comportement attendu, refuser ou laisser passer, se décide et se teste avant la production. Un quota qui n’est évalué que lorsque le composant répond crée une surprise le jour d’une panne. Les limites se définissent par API et par application, à partir d’un usage prévisible, puis s’ajustent avec les mesures. Un plafond recopié d’un exemple de documentation n’a pas de sens opérationnel.
Bases externalisées
La documentation d’installation permet de remplacer les bases par défaut par MySQL, PostgreSQL, SQL Server, Oracle ou DB2. Sur Kubernetes, ces bases ne devraient pas être un simple répertoire dans le conteneur de la passerelle. Un pod qui disparaît emporte alors la configuration, les abonnements et les jetons. Les bases se placent hors du cycle de vie des pods applicatifs, avec sauvegarde, restauration testée et comptes distincts par environnement.
Le plan de gestion et la passerelle doivent voir la même configuration d’API. Une base de développement recopiée partiellement vers la production, ou l’inverse, désynchronise ce que le Publisher affiche et ce que la passerelle exécute. Les promotions passent par des définitions d’API revues, pas par une copie de schéma.
Analytique et journaux
L’analytique est un composant du plan de gestion dans le découpage documenté, avec des options sur site ou via l’offre cloud de l’éditeur selon les guides. Elle ne remplace pas les journaux de la passerelle ni les métriques du cluster. Au minimum, on conserve les codes de réponse, les temps passés dans la passerelle et chez le backend, et l’identité de l’application appelante, sans écrire dans le journal des secrets ni des corps de requête complets.
Les sondes de vie et de disponibilité des pods se règlent sur des points qui répondent sans dépendre d’un backend métier. Une sonde qui appelle une API externe fait redémarrer la passerelle lorsque ce backend tousse. Les limites de mémoire se fixent à partir d’essais de charge sur le parcours réel, pas à partir d’une valeur unique recopiée d’un exemple.
Ce que cette référence ne promet pas
Elle ne promet pas une haute disponibilité parce que le schéma contient plusieurs rectangles. Deux réplicas dans la même zone tombent ensemble si la zone tombe. Elle ne promet pas qu’un chart ou un manifeste d’exemple convienne à la production sans relecture des secrets, des ressources et des règles d’ingress. Elle ne promet pas non plus que Micro Integrator ou Streaming Integrator soient nécessaires : ils font partie de la distribution, et on ne les déploie que si des flux d’intégration ou de streaming sont dans le périmètre.
Le détail des manifestes Kubernetes et OpenShift se trouve dans la documentation d’installation citée plus haut. Les noms de ressources et les versions d’images y sont plus fiables que dans un article. L’article fixe le découpage. La documentation fixe les fichiers.
Ce que Technocify peut prendre en charge
L’audit regarde le cluster déjà en place, les noms exposés, les bases et le mode d’identité. La conception sépare les plans, choisit les bases et les règles d’ingress, et décide si le Key Manager est celui du produit. La mise en œuvre déploie les composants retenus, publie une API de bout en bout et vérifie quota, jeton et journal. Le run porte les mises à jour d’image, le renouvellement des certificats et la restauration des bases.
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 À propos. Le cadre d’hébergement est celui des pages plateformes API et cloud et DevSecOps.
Un échange sur ce schéma part du cluster existant et des API déjà à exposer.