Implémentation de référence pour une entreprise numérique

native cloud
Version hiver-2020

Auteur original

 Lakmal Warusawithana | Directeur principal - | d’évangélisation technologique WSO2, Inc | | lakmal@wso2.com @lakwarus

Ce document présente une implémentation de référence pour une architecture d’entreprise numérique native cloud décrite dans
architecture  de référence pour une entreprise numérique cloud native.  Nous nous concentrerons sur une implémentation utilisant
Kubernetes et la plateforme d’intégration dirigée par API de WSO2.

Introduction
Les contraintes récentes imposées aux entreprises ont poussé les organisations à accélérer leurs plans de transfert des opérations
vers le monde numérique, réduisant souvent les délais de plusieurs années à plusieurs mois. Dans le processus, les API sont
apparues comme les produits du 21ème siècle. Comme indiqué dans l’architecture de référence pour une entreprise numérique
native du cloud,la combinaison de technologies natives du cloud et d’une plate-forme d’intégration dirigée par API augmente
considérablement la productivité en permettant l’agilité, la flexibilité et l’évolutivité grâce à l’automatisation et aux services.

Ce document traite d’une implémentation de référence pour une entreprise numérique native du cloud utilisant deux piles
technologiques open source de pointe : Kubernetes et la plate-forme d’intégration dirigée par API de WSO2.

Implémentation de référence : une entreprise numérique native du cloud

 Figure 1 : entreprise numérique native du cloud

Dans cette implémentation de référence, Kubernetes fournit les fonctionnalités de la plateforme cloud native, et la solution
d’intégration dirigée par API de WSO2 offre les capacités d’intégration et de gestion des API requises pour une entreprise
numérique.

Kubernetes peut s’installer sur n’importe quelle infrastructure de cloud privé, public ou hybride. La plateforme d’intégration dirigée
par API de WSO2 (WSO2 API Manager et WSO2 Enterprise Integrator) peut être installée sur Kubernetes avec une prise en charge
native via l’opérateur d’API Kubernetes WSO2. Cette intégration native fournit l’automatisation, l’évolutivité et les opérations
nécessaires, tout en offrant des fonctionnalités d’intégration dirigées par API.

Kubernetes
Kubernetes, une plateforme d’orchestration cloud native open source ou un framework, fournit un ensemble complet d’abstractions
cloud natives et une boîte à outils pour créer une solution évolutive et flexible qui s’aligne sur la croissance de l’entreprise. Il s’agit
d’un projet open source mature qui est régi par la Cloud Native Computing Foundation (CNCF). Les riches abstractions cloud natives
de Kubernetes aident à définir l’architecture évolutive. Sa boîte à outils permet d’orchestrer des applications conteneurisées dans
une plate-forme distribuée multi-hôtes et multi-cloud en fournissant l’infrastructure et l’automatisation nécessaires.

L’architecture Kubernetes se compose d’un plan de contrôle et d’un ensemble de nœuds de travail. En règle générale, les
composants du plan de contrôle sont déployés dans les nœuds maîtres (plan de contrôle) et les charges de travail sont déployées
sur les nœuds de travail. Le plan de contrôle est responsable du stockage des informations concernant les nœuds, de la surveillance
des nœuds, de la planification de la charge de travail du conteneur, etc. Si vous êtes nouveau sur Kubernetes, je vous recommande
de lire la section annexe Architecture Kubernetes.If you are new to Kubernetes, I would recommend reading the Kubernetes
Architecture appendix section.

Les riches abstractions natives cloud de Kubernetes offrent la flexibilité de créer une grande variété de plateformes cloud
natives. Les PDD, les services, les déploiements, les ConfigMaps, les étiquettes et la mise à l’échelle automatique horizontal POD
sont quelques-unes des principales abstractions natives du cloud. La section Abstractions cloud natives Kubernetes décrit en détail
les abstractions Kubernetes utilisées dans la plateforme d’intégration dirigée par API pour créer une entreprise numérique native
cloud.

Ressources personnalisées et contrôleurs personnalisés

Une ressource personnalisée est une extension de l’API Kubernetes ; il n’est pas livré avec l’installation Kubernetes par défaut. Un
administrateur de cluster Kubernetes peut ajouter/supprimer des ressources personnalisées indépendamment du cluster lui-même.
Une fois qu’une ressource personnalisée est installée, les utilisateurs peuvent créer et accéder à ses objets à l’aide de kubectl, tout
comme ils le font pour les ressources intégrées telles que les PODs.

Les contrôleurs personnalisés permettent de synchroniser l’état actuel des objets Kubernetes (définis dans CR) avec l’état souhaité.
Le contrôleur interprète les données structurées comme un enregistrement de l’état souhaité par l’utilisateur et le maintient
continuellement. Par conséquent, les ressources personnalisées fournissent une API déclarative dédiée lorsque vous combinez une
ressource personnalisée avec un contrôleur personnalisé.

Les ressources personnalisées et les contrôleurs personnalisés offrent une flexibilité et une immense puissance aux architectes pour
créer des plateformes cloud natives sur Kubernetes.

Plate-forme d’intégration dirigée par API de WSO2

La plate-forme d’intégration dirigée par API de WSO2 est une solution d’entreprise open source leader sur le marché qui prend en
charge la gestion et l’intégration complètes du cycle de vie des API. La plate-forme a été nommée leader dans the Forrester Wave™:
API Management Solutions, rapportQ3 2020 .

L’offre de WSO2 est fournie avec un concepteur et un éditeur d’API, un portail de développeurs, un gestionnaire de clés, un serveur
d’analyse d’API, une passerelle API, un intégrateur d’entreprise et un opérateur d’API Kubernetes.

Gestion complète du cycle de vie des API

À l’ère de la transformation numérique, les API sont un investissement stratégique pour toute organisation. Ils jouent un rôle
important à la fois en tant que facilitateurs techniques et moteurs d’affaires. WSO2 API Manager fournit des interfaces Web de
pointe, par exemple, WSO2 API Designer et Publisher, pour le développement et la gestion d’API. Il est 100 % conforme à la
spécification open API, aidant les créateurs d’API à développer, documenter, mettre à l’échelle et versionner des API, tout en
facilitant davantage de tâches liées à la gestion des API telles que la publication, la monétisation et la promotion des API.
 Figure 2 : concepteur et éditeur d’API WSO2

En plus de l’interface graphique, la plate-forme dirigée par API de WSO2 dispose d’un outil de ligne de commande, c’est-à-dire
apictl, qui automatise les fonctionnalités complètes de gestion du cycle de vie des API.

Le hub de communication pour un écosystème d’API

Le portail des développeurs d’API est un hub pour découvrir et intégrer des développeurs avec des expériences à faible friction. Le
portail d’API développeur de WSO2 permet aux développeurs de trouver des API, de les tester avant l’abonnement et la
consommation, de calculer la monétisation avec des métriques spécifiques, d’afficher les commentaires et les demandes de
fonctionnalités des consommateurs via des forums, etc.
 Figure 3 : portail des développeurs d’API WSO2

L’interface utilisateur Web du portail des développeurs est une application React d’une seule page écrite sur des API bien définies.
Les organisations peuvent personnaliser l’interface utilisateur web pour s’aligner sur les besoins de l’organisation ou créer leur
propre portail de développeur de marque en consommant ces API de développeur.

Activation de qos via la régulation du trafic

Lors de la productisation d’API, il est essentiel de disposer de fonctionnalités de régulation du trafic d’API pour fournir aux
consommateurs différents niveaux de service. WSO2 Traffic Manager permet de définir des stratégies de limitation et de les
appliquer dans les passerelles API. WSO2 Traffic Manager est fourni avec un moteur de limitation dynamique qui traite les stratégies
de limitation en temps réel et permet de limiter le débit des demandes d’API pour empêcher les API d’être submergées, ce qui
permet aux propriétaires d’API d’appliquer une limite sur le nombre de demandes.

informatique décisionnelle
L’obtention d’informations commerciales significatives sur le comportement des API est essentielle dans chaque entreprise. WSO2
API Analytics Server est capable de générer toutes sortes d’informations d’affaires. En plus des graphiques statistiques, son moteur
de traitement des événements en temps réel peut identifier les anomalies et alerter les utilisateurs sur les attaques malveillantes
potentielles.

Sécurité des API et détection des anomalies

La sécurité est primordiale lors de l’exposition des capacités de l’entreprise via des API. Le Gestionnaire de clés WSO2 gère tous les
clients, la sécurité et les opérations liées aux jetons d’accès. Il prend en charge OAuth 2.0, JWT, Basic Auth, Mutual SSL et les
mécanismes d’authentification basés sur la clé API.
Figure 4 : gestionnaire de clés API WSO2
Parfois, les mesures de sécurité traditionnelles, telles que l’authentification et l’autorisation, ne suffisent pas à elles seules. Les jetons
de sécurité compromis peuvent provoquer une violation de données ou des activités malveillantes. Vous pouvez utiliser les solutions
intégrées basées sur l’intelligence artificielle de WSO2 pour contrôler ce type d’incidents.

Les charges utiles malveillantes peuvent être associées à des demandes autorisées et authentifiées, et il est essentiel de les identifier
et de les arrêter immédiatement à un stade précoce. Vous pouvez définir des règles pour analyser la charge utile de la demande
(par exemple, JSON ou XML) et les empêcher de passer par la passerelle vers les backends respectifs.

Les anomalies peuvent être identifiées en analysant les modèles d’accès aux API. L’intelligence artificielle et les techniques
d’apprentissage automatique aident à identifier ces types de menaces de sécurité. Ces techniques avancées aident les entreprises
numériques à surveiller et à prévenir de manière proactive les risques possibles et les activités malveillantes.

Composition, intégration et médiation

WSO2 Enterprise Integrator est capable de jouer plusieurs rôles dans votre architecture d’entreprise. Il peut être utilisé comme un
ESB (Enterprise Service Bus), un processeur de données de streaming et un intégrateur de microservices. WSO2 Micro Integrator
prend en charge les styles architecturaux centralisés (style ESB) et décentralisés (microservices, cloud natif). WSO2 Streaming
Integrator vous permet d’implémenter l’ETL en continu (extraction, transformation et chargement), de modifier la capture de
données (CDC) et de traiter des fichiers volumineux et des API en temps réel.

WSO2 Micro Integrator fournit une approche low code unique pour l’intégration de microservices. Ses connecteurs riches et
complets permettent de s’intégrer à une large gamme de systèmes hérités. L’approche d’intégration de code facile à utiliser de
l’offre accélère la création de microservices d’intégration composites, tout en permettant aux utilisateurs de profiter des avantages
de MSA.
Figure 5 - Micro-intégration
Application des stratégies à grande échelle
API Gateway est le principal point d’application des stratégies. Il prend en charge les mécanismes d’authentification basés sur OAuth
2.0, JWT, Basic Auth, Mutual SSL et API-Key et permet aux organisations informatiques d’appliquer des limites de débit et des
stratégies de limitation.

En plus des applications de stratégie, vous pouvez effectuer des intégrations de périphérie, telles que la médiation, la
transformation, etc., en fonction de vos besoins. Supposons que votre intégration soit complexe ou qu’elle souhaite disposer d’une
architecture hautement évolutive. Dans ce cas, WSO2 recommande d’utiliser un modèle de façade à l’aide d’un micro-intégrateur
d’entreprise avec la passerelle API.

WSO2 API Micro Gateway est optimisé pour les microservices et prend en charge les trois modèles de déploiement : passerelle
partagée, passerelle jet privé et passerelle side-car (décrit dans le document d’architecture deréférence).
 Figure 6 : modèles de déploiement de l’API Micro Gateway WSO2

Selon la stratégie d’API, les utilisateurs peuvent choisir un modèle de déploiement de passerelle API efficace. Dans certains cas
d’utilisation, nous pouvons gérer tout le trafic d’API à l’aide d’un cluster API Gateway partagé. Les utilisateurs peuvent également
regrouper des API et les distribuer dans différents clusters API Gateway. Ces regroupements peuvent être effectués en fonction des
fonctionnalités de l’API ou des régions auxquelles ils accèdent. Ceux-ci peuvent être déployés en mode jet privé ou en mode
partagé en fonction des exigences évolutives.

Vous pouvez automatiser le déploiement de la passerelle à l’aide d’une plateforme Kubernetes qui se déploie dans plusieurs
régions. Disposer d’un cluster de passerelle évolutif est essentiel si vous recherchez une entreprise numérique opérationnelle
mondiale.

Automatisation via le modèle d’opérateur Kubernetes

L’opérateur d’API Kubernetes WSO2 fournit une expérience entièrement automatisée pour la gestion des API natives dans le cloud.
Il introduit un ensemble de ressources personnalisées pour déployer et gérer facilement des artefacts d’intégration dirigés par API
dans Kubernetes.It introduces a set of custom resources to deploy and manage API-led integration artifacts into Kubernetes easily.
 Figure 7 : opérateur d’API Kubernetes WSO2

L’opérateur d’API Kubernetes WSO2 peut créer et déployer WSO2 API Micro Gateway et WSO2 Micro Integrator en lisant les
définitions Swagger ou les définitions d’intégration fournies par le développeur/éditeur d’API. Ces passerelles et intégrateurs se
déploient automatiquement dans le cluster Kubernetes défini avec les artefacts de déploiement Kubernetes nécessaires.

Observabilité de l’API
Contrairement à l’architecture monolithique, l’audit et le traçage sont des problèmes difficiles dans les architectures décentralisées
telles que MSA. Les problèmes de performances, les erreurs et les exceptions sont des événements regrettables qui peuvent se
produire dans un environnement de production. Pour identifier un tel événement, l’observation de l’environnement de production
est essentielle.

Souvent, les microservices n’agissent pas seuls et ils s’interconnectent les uns aux autres via les appels d’API. WSO2 API Gateway
peut fonctionner avec des outils d’observabilité natifs du cloud, tels que Prometheus, Jaeger et Fluentd, pour analyser ces métriques,
statistiques et données capturées afin de produire des visualisations significatives pour comprendre le comportement du système.

Prométhée

Prometheus est une boîte à outils de surveillance et d’alerte de système open source qui est régie par la CNCF. Prometheus peut
configurer pour fonctionner en mode natif avec un cluster Kubernetes.Prometheus can set up to work natively with a Kubernetes
cluster.

La passerelle API expose un point de terminaison de métriques qui fournit des métriques liées aux données de niveau de service,
aux données côté client et à certaines données liées aux processus, telles que l’utilisation de la mémoire et de l’UC. Ces métriques
peuvent ensuite alimenter Prometheus. En plus de cela, les utilisateurs peuvent configurer un tableau de bord analytique, tel que
Grafana, pour visualiser les métriques de Prometheus.

En plus des tableaux de bord d’observabilité, vous pouvez utiliser ces métriques collectées pour mettre à l’échelle les services
backend et les passerelles API en étendant la mise à l’échelle automatique du pod horizontal Kubernetes.In addition to observability
dashboards, you can use these collected metrics to scale backend services and API gateways by extending the Kubernetes
Horizontal Pod Autoscaler.
 Figure 8 : mise à l’échelle automatique basée sur des métriques personnalisées

Jaeger

Jaeger est une boîte à outils de système de traçage distribué qui est régie par la CNCF. La prise en charge de Jaeger est sortie de
l’emballage dans WSO2 API Gateway. Il est bien adapté à la surveillance des transactions distribuées, à l’optimisation des
performances et de la latence, à l’analyse des dépendances de service et à de nombreux problèmes opérationnels lors du passage à
une architecture distribuée.

Fluentd

Fluentd est un collecteur de données open source pour les couches de journalisation unifiées. La CNCF régit le projet Fluentd. Par
défaut, les conteneurs ne conservent aucune donnée opérationnelle (telle que les journaux, etc.), et lorsque les conteneurs se
terminent, ils perdent des données. Vous pouvez configurer le cluster Kubernetes pour envoyer tous les journaux agrégés des
microservices, des passerelles d’API et des intégrateurs d’API vers Fluentd.You can configure the Kubernetes cluster to push all
aggregated logs from microservices, API gateways, and API integrators to Fluentd. Ces données agrégées peuvent être utilisées pour
effectuer différentes analyses afin d’identifier tout problème opérationnel.

GitOps
GitOps est un moyen d’implémenter un déploiement continu pour les applications cloud natives. Il combine les fonctionnalités de
Git et des outils de déploiement continu et offre une expérience centrée sur le développeur lors de l’exploitation de l’infrastructure.

Dans une entreprise numérique, la publication d’une API n’est pas qu’un processus simple. Cela implique la création d’API, puis leur
déploiement dans un environnement de gestion d’API inférieur pour passer par différents cycles de test (tests de développeur, tests
de contrainte, tests d’assurance qualité, etc.). Une fois ces tests réussis, ils passent à l’environnement de production.
 Figure 9 : automatisation ci/cd de l’API avec GitOps

Chaque environnement de déploiement possède un cluster Kubernetes spécifique configuré avec l’opérateur d’API Kubernetes
WSO2 et les composants de gestion d’API WSO2. Selon les besoins de l’entreprise, les composants de gestion des API, tels que
l’éditeur d’API WSO2, WSO2 API Traffic Manager, le gestionnaire de clés API WSO2 et le portail de développeur d’API WSO2,
peuvent être configurés.

WSO2 API Manager est 100% compatible avec la conception et le développement d’API basées sur la spécification Open API
(anciennement Swagger). Les développeurs créent des artefacts d’API et les valident dans un système de contrôle de version
Git.Developers create API artifacts and commit them to a Git version control system. Ensuite, un pipeline de génération CI/CD, tel
que Jenkins, CircleCI, Bamboo, peut être configuré pour extraire des artefacts et créer des images de conteneur et des descripteurs
de déploiement d’API/intégration. L’outil apictl (API control CLI tool) permet de créer un script pour l’automatisation. Les
descripteurs de déploiement générés peuvent être validés et envoyés au référentiel de déploiement.

Ensuite, le pipeline de déploiement déclenche et appelle l’opérateur d’API KUBERNetes WSO2 (à l’aide des commandes
apictl/kubectl) et déploie les passerelles API et les intégrateurs d’entreprise nécessaires dans le cluster Kubernetes d’environnement
donné. Ce processus automatisé permet d’effectuer différents cycles de tests (tests de développement, tests de stress, tests
d’assurance qualité, etc.).

Après avoir terminé les tests d’environnement, vous pouvez ensuite promouvoir vers des environnements supérieurs (par exemple,
stage to prod) en fusionnant dans la branche Git appropriée. Avec ce mode, si vous souhaitez déployer une nouvelle application ou
mettre à jour une application existante, il vous suffit de mettre à jour le référentiel; le processus automatisé gère tout le reste.

conclusion
En devenant des entreprises numériques et en numérisant les chaînes de valeur, les entreprises de tous les secteurs peuvent intégrer
et exposer leurs capacités commerciales en tant qu’API. Ces API doivent être sécurisées, gérées, observées et monétisées. Une plate-
forme d’intégration dirigée par API est essentielle pour les entreprises numériques, qu’elles commencent par des projets de création
ou de friches industrielles.
Kubernetes, une plateforme d’orchestration cloud native open source, fournit un ensemble complet d’abstractions cloud natives et
une boîte à outils pour créer une solution évolutive et flexible qui s’aligne sur la croissance de l’entreprise.

La plate-forme d’intégration dirigée par API de WSO2 est une solution d’entreprise open source leader sur le marché qui prend en
charge la gestion et l’intégration complètes du cycle de vie des API.

La plate-forme et ses capacités d’intégration Kubernetes natives fournissent une architecture d’entreprise numérique efficace pour
augmenter la productivité en permettant l’agilité, la flexibilité et l’évolutivité grâce à l’automatisation et aux services.

appendice

Kubernetes Architecture
 Figure 10 : architecture Kubernetes

Composants du plan de contrôle

Les composants dédiés gèrent les fonctionnalités du plan de contrôle.

ETCD: est une base de données qui stocke toutes les informations de nœud et les informations de charge de travail de conteneur en
tant que paire clé-valeur d’une manière hautement disponible.

Kube-scheduler: est responsable de la planification des charges de travail de conteneur pour les nœuds de travail en tenant
compte de la demande de ressources informatiques des charges de travail, des ressources disponibles dans les nœuds, du type de
charge de travail autorisée dans les nœuds de travail et des autres politiques et contraintes de gestion.

Kube-controller manager: se compose de plusieurs gestionnaires de contrôleurs. Le contrôleur de nœud est responsable de
l’intégration des nouveaux nœuds au cluster et de la gestion de l’indisponibilité des nœuds. Le contrôleur de réplication garantit
que le nombre souhaité de charges de travail de conteneur est en cours d’exécution tout le temps. En plus de ces deux contrôleurs,
de nombreux autres contrôleurs aident à gérer différentes fonctionnalités.

Serveur Kube-API: est le principal centre de communication pour tous les composants du cluster. Il est chargé d’orchestrer toutes
les opérations au sein des composants du cluster et expose également l’API Kubernetes utilisée par les utilisateurs externes qui
gèrent les charges de travail de conteneur. Les composants du nœud de travail communiquent également avec le plan de contrôle
via le serveur d’API Kube.

Composants du nœud de travail

Les nœuds de travail doivent être en mesure de communiquer avec les composants du plan de contrôle et de fournir les
informations nécessaires pour gérer les charges de travail de conteneur. Les nœuds de travail ont deux composants de gestion
principaux.

Kubelet: est un agent en cours d’exécution dans chaque nœud et responsable de la planification des charges de travail de
conteneur avec les instructions du plan de contrôle et du rapport sur l’état des nœuds et des charges de travail des conteneurs.

Kube-Proxy: s’exécute dans chaque nœud de travail et assure toutes les communications entre les charges de travail de conteneur
exécutées dans plusieurs nœuds.
Abstractions natives cloud Kubernetes Kubernetes cloud native abstractions
Les riches abstractions natives cloud de Kubernetes offrent la flexibilité de créer une grande variété de plateformes cloud natives.
Cette section traite uniquement des abstractions (ou blocs de construction) utilisées dans la plateforme d’intégration dirigée par API
pour créer l’entreprise numérique native cloud.

cosse

Figure 11 - POD

Un POD est une instance unique de notre application conteneurisée. Kubernetes ne déploiera pas directement de conteneurs, et il
encapsule dans un POD. Un POD est la plus petite unité qui évolue en fonction de la charge. Un POD peut être constitué de
plusieurs conteneurs. Les conteneurs d’un POD sont automatiquement colocalisés et coprogrammés sur le même nœud du cluster.
Les conteneurs vivant dans le POD peuvent partager le même espace réseau, espace de stockage et espace de processus.
ReplicaSet

ReplicaSet permet de définir le nombre de POD de réplica en cours d’exécution à un moment donné. Il surveille les PODs et en crée
un nouveau lorsqu’une défaillance se produit dans l’ensemble actuel. Il permet également de faire évoluer l’application en
augmentant le nombre de réplicas.

déploiement

À l’aide de l’objet Kubernetes Deployment, nous pouvons définir l’état souhaité (par exemple, le nombre de réplicas d’une version
donnée). Le contrôleur de déploiement modifie l’état réel à l’état souhaité à un taux contrôlé et la stratégie de déploiement. Nous
pouvons utiliser les déploiements de déploiement pour provisionner des versions plus récentes et restaurer si l’état actuel du
déploiement n’est pas stable.

Espaces de noms

L’espace de noms permet de diviser les clusters physiques en plusieurs clusters virtuels. L’espace de noms fournit une étendue aux
objets d’affectation de noms Kubernetes.The namespace provides a scope to Kubernetes naming objects. Les noms des ressources
doivent être uniques dans un espace de noms, mais pas entre les espaces de noms. Les espaces de noms ne peuvent pas être
imbriqués les uns dans les autres, et chaque ressource Kubernetes ne peut être que dans un espace de noms.

Quota de ressources

Le quota de ressources fournit des contraintes qui limitent la consommation agrégée de ressources par espace de noms. Les
administrateurs de cluster peuvent définir un quota de ressources alloué à un espace de noms, puis le système de quotas suit
l’utilisation pour s’assurer qu’il ne dépasse pas les limites de ressources concrètes définies.

services
Kubernetes Service expose une application s’exécutant sur un ensemble de PODs en tant que service réseau. Lorsque nous
déployons une application, chaque POD obtient son adresse IP. Toutefois, pour maintenir l’état souhaité dans un déploiement,il peut
créer et détruire des POD dynamiquement. Kubernetes Service fournit une adresse IP unique et un nom DNS à un ensemble
de PODs en déploiement et peut surveiller les comportements pod et mettre à jour leurs adresses IP dynamiquement. En outre, ce
point de terminaison de service donné est capable de router le trafic vers les PODs de manière à équilibrer la charge. En plus de cela,
Kubernetes Services est essentiel pour avoir un mécanisme de découverte de service sans modifier votre code d’application.

Selon la façon dont vous souhaitez exposer votre application, vous pouvez configurer Kubernetes Services pour qu’il se comporte
dans les trois modes principaux. Le type de service ClusterIP permet d’exposer vos applications au sein du cluster.
 Figure 12 : service ClusterIP

Si vous souhaitez exposer des applications en dehors du cluster, vous pouvez utiliser le type NodePort ou le type Loadbalancer.
NodePort expose les applications en ouvrant un port dans chaque nœud du cluster et mappe et transfère le trafic vers le port
d’application.
Figure 13 : service NodePort
Le type Loadbalancer crée un point de terminaison d’équilibrage de charge configuré avec le fournisseur de cloud approprié du
cluster et exposé via l’équilibreur de charge du fournisseur de cloud.

ConfigMaps

Chaque application réutilisable a une sorte de configuration. Le découplage de la configuration avec le code d’application permet
d’utiliser le même code d’application dans différents environnements. ConfigMaps vous permet de découpler les artefacts de
configuration du contenu de l’image conteneur pour garder les applications conteneurisées portables. Secrets

Comme les configurations, nous devons transmettre des informations sensibles, telles que des mots de passe, des jetons OAuth et
des clés ssh, à l’application pour effectuer les tâches requises. Plutôt que de placer des informations sensibles dans une image
conteneur, nous pouvons utiliser un objet Kubernetes Secret.Rather than placing sensitive information in a container image, we can
use a Kubernetes Secret object. Par défaut, les secrets obscurcissent avec l’encodage Base64, mais vous pouvez les rendre plus
sécurisés (chiffrer) à l’aide de techniques de déférence.

Mise à l’échelle automatique des POD horizontaux

 Figure 14 : mise à l’échelle automatique du pod horizontal

La possibilité de mettre à l’échelle chaque microservice offre l’avantage réel du MSA. Kubernetes Horizontal POD Autoscaler permet
de mettre automatiquement à l’échelle les microservices en mettant à l’échelle le nombre de Pods dans un déploiement, un jeu de
réplicas ou un ensemble avec état en fonction de l’utilisation de l’UC observée (ou, avec la prise en charge des métriques
personnalisées, sur d’autres métriques fournies par l’application).

Kubectl
L’outil en ligne de commande kubectl vous permet d’interagir et de contrôler les clusters Kubernetes.The kubectl command-line tool
lets you interact and control Kubernetes clusters. Vous pouvez utiliser kubectl pour déployer des applications, inspecter et gérer les
ressources du cluster et afficher les journaux. Kubectl peut être utilisé en mode impératif ou de manière déclarative.

impératif

En mode impératif, nous devons exécuter une série de commandes et suivre une étape donnée pour terminer une tâche. Dans
Kubernetes, vous pouvez utiliser la commande kubectl pour faire les choses en mode impératif. Voici quelques exemples :

 Créer un POD : kubectl run --image=nginx nginx

 Créer un déploiement : kubectl create deployment --image=nginx nginx
 Créer un Service : kubectl expose deployment nginx --port 80
 Modifier l’objet existant : kubectl edit deployment nginx
 Mise à l’échelle d’un déploiement : kubectl scale deployment nginx --replicas=3

Tout ce qui précède sont des approches impératives pour gérer des objets dans Kubernetes.All of the above are imperative
approaches to managing objects in Kubernetes.

déclaratif

Dans le modèle déclaratif, nous pouvons répertorier nos exigences (dans un format requis) et le système sera capable d’effectuer la
tâche requise. Dans ce mode, nous pouvons créer un ensemble de fichiers qui définissent l’état attendu des applications et des
services sur un cluster Kubernetes.In this mode, we can create a set of files that define the expected state of applications and
services on a Kubernetes cluster. Avec une seule commande kubectl apply et Kubernetes devrait définir l’état souhaité en lisant les
fichiers de configuration donnés.

exemple: kubectl apply -f nginx.yaml

Étiquettes et sélecteurs
Les étiquettes sont des paires clé/valeur attachées à des objets, tels que des pods. Les étiquettes peuvent être utilisées pour
organiser et sélectionner des sous-ensembles d’objets de manière faiblement couplée. Le déploiement et la gestion des applications
se composent souvent d’entités multidimensionnelles, telles que plusieurs pistes de version, plusieurs niveaux, des environnements,
etc. Leur mise en correspondance dans les étiquettes aidera à la gestion quotidienne et aux activités opérationnelles.

Exemples d’étiquettes :

 « release » : « stable », « release » : « canary »

 « environnement » : « dev », « environnement » : « qa », « environnement » : « production »
 « tier » : « frontend », « tier » : « backend », « tier » : « cache »
 « partition » : « customerA », « partition » : « customerB »
 « track » : « daily », « track » : « weekly »

The label selector is the core grouping primitive in Kubernetes. Vous pouvez utiliser des secteurs d’étiquettes pour effectuer des
activités opérationnelles telles que la mise à jour propagée, la restauration, les nœuds de vidange à mettre en maintenance, la mise
à l’échelle, etc.

Sondes de vérification de l’état

Les sondes Heath sont essentielles pour atteindre la haute disponibilité requise pour exécuter notre application en production.
Kubernetes utilise trois sondes de vérification de l’état pour déterminer l’action nécessaire pour obtenir une réparation automatique
et une haute disponibilité.

Sonde de vivacité

La définition de sondes d’activité permet de déterminer les scénarios de blocage, où une application est en cours d’exécution mais
ne peut pas progresser, et de redémarrer le conteneur pour surmonter la situation.
Sonde de préparation

Les sondes de préparation aident à déterminer quand un conteneur est prêt à commencer à accepter le trafic. Une utilisation de ce
signal est de contrôler quels PODs utilisent des backends pour les services. Lorsqu’un POD n’est pas prêt, il est supprimé des
équilibreurs de charge de service.

Sondes de démarrage

Certaines applications ont des temps de démarrage plus longs. Dans de telles situations, la configuration d’une sonde de démarrage
permet de désactiver les vérifications d’état de vie et de préparation jusqu’à ce qu’elles réussissent, en s’assurant que ces sondes
n’interfèrent pas avec le démarrage de l’application.

Déploiement

Lorsque vous créez un déploiement, Kubernetes attache une révision qui lui est associée. Lorsque vous déployez une nouvelle
version de votre déploiement, elle met à jour l’historique des révisions. Vous pouvez voir toutes les versions de déploiement à l’aide
des commandes suivantes.

kubectl rollout status deployment.v1.apps/nginx-deployment

kubectl rollout history deployment.v1.apps/nginx-deployment
Kubernetes prend en charge deux stratégies de déploiement. La première stratégie consiste à recréer, détruire toutes les instances
en cours d’exécution et créer le même nombre de nouvelles instances, et non une stratégie de déploiement sans temps d’arrêt.

La valeur par défaut de Kubernetes est la stratégie de déploiement de mise à jour propagée. Cette stratégie ne prendra pas toutes
les instances en cours d’exécution à la fois ; au lieu de cela, il supprimera une version actuelle et fera apparaître une version plus
récente une par une. La meilleure façon de le faire est de mettre à jour le fichier d’application déclaratif (fichier yaml) et d’exécuter la
commande kubectl apply. Il déclenchera un nouveau déploiement et une nouvelle révision est créée.

Restaurations
Même si nous effectuons des tests approfondis, nous devons parfois revenir à un état stable en raison d’une erreur trouvée
tardivement. Vous pouvez utiliser la commande suivante pour restaurer une version déployée.

kubectl rollout undo deployment.v1.apps/nginx-deployment

Vous pouvez également revenir à une révision spécifique en la spécifiant avec --to-revision :

kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2

Abstractions
icône nom description

Microservices et Logique métier de base, agrégation et composition du service,

composants sans serveur transformation.

Passerelles API, passerelles d’entrée, passerelles maillées, micro-

Passerelles intégrateurs, API exposées, événements et flux, points d’application des
stratégies
icône nom description

Services hérités et de Bases de données, systèmes existants, registres et référentiels, magasins

données d’utilisateurs, processus métier

Point de terminaison Accès à l’aide d’API, d’événements et de flux, de systèmes cloud et de

externe SaaSAccess using APIs, events, and streams, cloud systems, and SaaS

Consommateurs d’API Applications mobiles, applications réactives, consommateurs d’API

icône nom description

Consommateurs d’API Applications mobiles, applications réactives, consommateurs d’API

Consommateurs d’API Applications mobiles, applications réactives, consommateurs d’API

Consommateurs d’API Bots, consommateurs d’API

icône nom description

Consommateurs d’API Appareils IoT, applications, consommateurs d’API

Passerelle API WSO2 Passerelle API WSO2, passerelle d’API WSO2 Micro

Portail des développeurs Portail des développeurs pour la découverte d’API, une place de marché
d’API WSO2 d’API
icône nom description

Portail de l’éditeur d’API, conception, développement, package d’API,

Éditeur d’API WSO2
publication d’API

Gestionnaire de clés API Gérer les clés API et tous les jetons de sécuritéManage API keys and all
WSO2 security tokens

Gestionnaire de trafic d’API Limitation de débit, politique de contrôle de la circulation définissant le

WSO2 portail
icône nom description

Serveur d’analyse d’API Serveur d’analyse en temps réel, génération d’informations d’entreprise
WSO2 d’API, moteur de détection d’anomalies et modification

Micro-intégrateur WSO2 Intégrateur d’entreprise, médiation, moteur de transformation

Intégrateur de flux WSO2 Intégration de flux d’entreprise

icône nom description

Flux de travail d’entreprise

Moteur de workflow
WSO2

Objet qui gère les jeux de réplicas, les déploiements et les vérifications
Déploiement Kubernetes
de l’état

Kubernetes POD Une seule instance de notre application conteneurisée

icône nom description

Expose une application s’exécutant sur un ensemble de Pods en tant que

Kubernetes Service
service réseau

Ressources personnalisées
Une ressource personnalisée est une extension de l’API Kubernetes
Kubernetes

Kubernetes ConfigMap Contient les données de configuration

icône nom description

Contenir des données sensibles telles que des clés, des informations
Kubernetes Secret
d’identification, des certificats

Kubernetes Horizontal POD Mise à l’échelle de la charge de travail en fonction de l’UC observée, de
Autoscaler l’utilisation de la mémoire

Espace de noms
Diviser les clusters physiques en plusieurs clusters virtuels
Kubernetes
icône nom description

Une base de données qui stocke toutes les informations de nœud et les
ETCD informations de charge de travail de conteneur sous forme de paires clé-
valeur

Gestionnaire de contrôle
Gestionnaire de contrôle cloud Kubernetes
cloud Kubernetes

Gestionnaire de contrôle
Gestionnaire de contrôle Kubernetes
Kubernetes
icône nom description

Exécution dans chaque nœud de travail et assure toutes les

Kubernetes Kube Proxy
communications entre les charges de travail de conteneur

Kubernetes Kubelet Un agent en cours d’exécution dans chaque nœud

Planification des charges de travail de conteneur pour les nœuds de

Planificateur Kubernetes
travail
 icône nom description

Serveur d’API Kubernetes Centre de communication principal pour tous les composants du cluster.

références
 https://kubernetes.io/
 https://wso2.com/api-management/
 https://wso2.com/integration/micro-integrator/
 https://github.com/wso2/k8s-api-operator
 https://www.gitops.tech/