Activer Oracle Cloud Infrastructure Service Mesh pour vos applications Kubernetes
Les clients Oracle Cloud Infrastructure (OCI) sont de plus en plus passés à une architecture de microservices qui, avec ses avantages, apporte également de nouveaux défis. Dans une architecture de microservices, les applications monolithiques sont divisées en microservices plus petits qui communiquent via le réseau à l'aide d'une API. Cela entraîne une augmentation du trafic réseau et augmente la complexité et la surface d'attaque globale dans l'architecture.
- Permet de contrôler le flux de trafic des microservices.
- Offre une visibilité sur vos applications.
- Permet aux microservices de se connecter en toute sécurité sans modifier le code de l'application.
Fonctionnalités d'OCI Service Mesh
- Application des politiques liées à la sécurité
OCI Service Mesh utilise des stratégies d'accès pour définir des règles d'accès. Les stratégies d'accès appliquent la communication entre les microservices et autorisent uniquement les demandes validées provenant de l'application et de l'extérieur. Les stratégies d'accès sont également utilisées pour définir les communications autorisées avec les services externes.
- Zéro confiance
OCI Service Mesh implémente automatiquement une architecture de sécurité de confiance zéro sur tous les microservices. Les données entre les microservices sont cryptées. L'identification du microservice au microservice est requise au début de la communication. Les deux parties doivent échanger leurs identifiants avec leurs informations d'identité. Cela permet aux services de s'identifier mutuellement pour déterminer s'ils sont autorisés à interagir. Cette opération est implémentée avec TLS mutuel avec rotation automatisée des certificats et des clés à l'aide du service Oracle Cloud Infrastructure Certificates (OCI Certificates) et d'Oracle Key Management Cloud Service pour gérer les certificats et les clés.
- Déplacement de trafic
OCI Service Mesh vous permet d'effectuer des déploiements de canari. Lorsque vous publiez une nouvelle version de votre code en production, vous autorisez seulement une partie du trafic à l'atteindre. Cette fonctionnalité vous permet d'effectuer un déploiement rapide et de perturber au minimum votre application. Vous pouvez définir des règles de routage qui régissent toutes les communications entre microservices à l'intérieur du maillage. Vous pouvez acheminer une partie du trafic vers une certaine version du service.
- Surveillance et journalisation
OCI Service Mesh est particulièrement bien placé pour fournir des informations de télémétrie car toutes les communications inter-microservices doivent passer par elle. Cela permet au maillage de service de capturer des données de télémétrie telles que la source, la destination, le protocole, l'URL, la durée, le code de statut, la latence, la journalisation et d'autres statistiques détaillées. Vous pouvez exporter les informations de journalisation vers le service Oracle Cloud Infrastructure Logging (OCI Logging). OCI Service Mesh fournit deux types de journaux : les journaux d'erreurs et les journaux de trafic. Vous pouvez utiliser ces journaux pour déboguer les problèmes 404 ou 505 ou générer des statistiques basées sur les journaux. Les mesures et les données de télémétrie peuvent être exportées vers Prometheus et visualisées avec Grafana. Les deux peuvent être déployés directement dans un cluster OKE.
Architecture
Oracle Cloud Infrastructure Service Mesh (OCI Service Mesh) utilise un modèle sidecar. Cette architecture encapsule le code implémentant la fonctionnalité réseau dans un proxy réseau, puis s'appuie sur le trafic depuis et vers les services à rediriger vers le proxy sidecar. Il est appelé sidecar parce qu'un proxy est attaché à chaque application, un peu comme un sidecar attaché à une moto. Dans OKE, le conteneur d'application se trouve à côté du conteneur sidecar proxy dans le même pod. Comme ils se trouvent dans le même pod, ils partagent le même espace de noms réseau et la même adresse IP, ce qui permet aux conteneurs de communiquer via "localhost".
- Plan de contrôle
Le plan de contrôle OCI Service Mesh gère et configure l'ensemble des proxies pour acheminer le trafic. Il gère le transfert, la vérification de l'état, l'équilibrage de charge, l'authentification, l'autorisation et l'agrégation de la télémétrie. Le plan de contrôle interagit avec le service de certificat OCI et le service de gestion des clés OCI pour fournir à chaque proxy son certificat.
- Plan de données
Le plan de données est composé de la collection de proxies sidecar déployés dans l'environnement et est responsable de la sécurité, des fonctions réseau et de l'observabilité de l'application. Ils collectent et signalent également la télémétrie sur tout le trafic maillé. Le proxy Envoy est utilisé pour le plan de données d'OCI Service Mesh.
Le schéma suivant illustre cette architecture de référence.
oci_service_mesh_oke_arch-oracle.zip
Cette architecture de référence présente une application déployée dans un cluster OKE avec trois services. L'espace de noms dans lequel l'application est déployée a été "maillé". Un espace de noms "maillé" indique que les services déployés dans l'espace de noms feront partie d'un maillage de services et que chaque nouveau pod déployé sera injecté avec un conteneur de proxy envoyé. A mesure que chaque pod est déployé, les configurations et les certificats sont envoyés à chacun des conteneurs proxy par le plan de contrôle OCI Service Mesh. Le plan de contrôle OCI Service Mesh communique avec le service OCI Certificates et Oracle Key Management Cloud Service afin d'obtenir des certificats pour chaque proxy.
Une passerelle entrante est déployée pour fournir un accès externe à l'application. La passerelle entrante fait partie du plan de données OCI Service Mesh et est également un proxy envoyé qui reçoit la configuration et les certificats du plan de contrôle OCI Service Mesh.
Il incombe au conteneur proxy d'effectuer le repérage de service, le cryptage du trafic et l'authentification auprès du service de destination. Les conteneurs proxy appliquent également des stratégies réseau telles que la répartition du trafic entre les différentes versions de service et appliquent des stratégies d'accès. La passerelle entrante effectue la même fonction pour le trafic en dehors du maillage de service.
Prometheus et Grafana sont déployés dans le cluster OKE dans un espace de noms distinct qui ne fait pas partie du maillage de services. Le plan de données du maillage de services envoie des statistiques d'exploitation clés telles que la latence, les échecs, les demandes et la télémétrie au déploiement Prometheus. Grafana extrait les données du déploiement Prometheus, qui peut être utilisé pour créer des tableaux de bord pour la visualisation.
OCI Service Mesh est intégré au service OCI Logging et la journalisation peut être activée lors de la création du maillage de service. OCI Service Mesh fournit deux types de journaux : les journaux d'erreurs et les journaux de trafic. Ces journaux peuvent être utilisés pour déboguer 404 ou 505 problèmes ou générer des statistiques basées sur les journaux.
Cette architecture comporte les services OCI suivants :
- OCI Kubernetes Engine (OKE)
Offre un cluster Kubernetes hautement disponible et évolutif prêt à l'emploi pour le déploiement de vos applications en conteneur dans le cloud.
- équilibreur de charge
Permet d'accéder à la passerelle entrante dans le cluster OKE. L'entrée dirige le trafic vers les services demandés dans le cluster OKE.
- Autorité de certification
Gère les certificats TLS pour le service OCI Service Mesh.
- Key Management
Gère les clés utilisées par le service d'autorité de certification.
L'architecture comprend les composants suivants :
- Région
Une région Oracle Cloud Infrastructure est une zone géographique précise, incluant un ou plusieurs centres de données, appelés domaines de disponibilité. Les régions sont indépendantes les unes des autres et de grandes distances peuvent les séparer (entre pays, voire continents).
- Réseau cloud virtuel (VCN) et sous-réseaux
Un VCN est un réseau personnalisable défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux de centre de données traditionnels, les réseaux cloud virtuels vous donnent le contrôle sur l'environnement réseau. Un réseau cloud virtuel peut comporter plusieurs blocs CIDR qui ne se chevauchent pas et que vous pouvez modifier après l'avoir créé. Vous pouvez segmenter un réseau cloud virtuel en plusieurs sous-réseaux ciblant une région ou un domaine de disponibilité. Chaque sous-réseau est composé d'une plage contiguë d'adresses qui ne chevauchent pas celles des autres sous-réseaux du réseau cloud virtuel. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.
- Liste de sécurité
Pour chaque sous-réseau, vous pouvez créer des règles de sécurité qui indiquent la source, la destination et le type de trafic qui doivent être autorisés à entrer et à sortir du sous-réseau.
Ressources OCI Service Mesh
| Ressources Kubernetes | Description |
| Maillage | Le maillage de niveau supérieur est le conteneur logique pour tous les microservices de votre application. |
| Service virtuel | Un service virtuel est une représentation logique d'un microservice dans un maillage de services. |
| Déploiements virtuels | Un déploiement virtuel est une représentation logique d'un déploiement qui peut être regroupé dans un service virtuel. Cela permet à un service virtuel de distribuer le trafic entre différentes versions du microservice. Un microservice Kubernetes peut avoir plusieurs versions qui sont des déploiements distincts dans le cluster. |
| Liaisons de déploiement virtuel | Les liaisons virtuelles sont utilisées pour associer un ensemble de pods à un déploiement virtuel. |
| Tables de routage de service virtuel | Une table de routage virtuelle définit la façon dont le trafic est distribué entre les déploiements virtuels dans un service virtuel en fonction du protocole et du chemin. Chaque service virtuel aura une table de routage virtuelle. |
| Déploiement de passerelle entrante | Un déploiement de passerelle entrante créera des pods entrants qui agissent en tant qu'équilibreurs de charge pour le trafic entrant vers le maillage. |
| Passerelles entrantes | Les passerelles entrantes gèrent le trafic entrant dans le maillage. Les passerelles entrantes définissent un ensemble de règles pour la façon dont le trafic externe communique avec le maillage, par exemple si le cryptage est requis pour tout le trafic entrant et sortant. Ces règles sont appliquées au déploiement de passerelle entrante. |
| Tables de routage de passerelle entrante | Les tables de routage de passerelle entrante sont associées à un déploiement de passerelle entrante. La table de routage définit les services virtuels du maillage accessibles à partir du déploiement de passerelle entrante. |
| Stratégies d'accès | Les stratégies d'accès sont des règles définies qui définissent la communication autorisée entre les microservices du maillage et les applications externes. |
Le diagramme suivant illustre la mise en correspondance des ressources OCI Service Mesh configurées : stratégies d'accès, passerelle entrante, service virtuel et déploiement virtuel avec les ressources d'application : service K8s, équilibreur de charge de service K8s, déploiements et pods.
Recommandations
- VCN
Lorsque vous créez un VCN, déterminez le nombre de blocs CIDR requis et la taille de chaque bloc en fonction du nombre de ressources que vous prévoyez d'attacher à des sous-réseaux dans le VCN. Utilisez des blocs CIDR qui se trouvent dans l'espace d'adresse IP privée standard.
Sélectionnez les blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données sur site ou un autre fournisseur cloud) auquel vous avez l'intention de configurer des connexions privées.
Après avoir créé un VCN, vous pouvez modifier, ajouter et supprimer ses blocs CIDR.
Lorsque vous concevez les sous-réseaux, tenez compte du flux de trafic et des exigences de sécurité. Attachez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau, qui peut servir de limite de sécurité.
- Bande passante d'équilibreur de charge
Lors de la création de l'équilibreur de charge, vous pouvez sélectionner une forme prédéfinie qui fournit une bande passante fixe ou indiquer une forme personnalisée (flexible) dans laquelle vous définissez une plage de bande passante et laisser le service redimensionner automatiquement la bande passante en fonction des modèles de trafic. Dans l'une ou l'autre approche, vous pouvez modifier la forme à tout moment après avoir créé l'équilibreur de charge.
Points à prendre en compte
Tenez compte des options suivantes lors du déploiement de cette architecture de référence.
- Coût
Le plan de contrôle d'OCI Service Mesh sur le cluster OKE est gratuit. Les clients sont facturés pour l'utilisation des ressources des conteneurs proxy du plan de données Service Mesh. Dans la pratique, toutefois, les clients paient déjà pour les ressources du pool de noeuds dans un cluster OKE. Sauf si l'utilisation des conteneurs proxy pousse l'utilisation du pool de noeuds à plus de 100 %, il n'y a pas de frais supplémentaires pour l'ajout d'OCI Service Mesh à votre architecture de microservices.
- Disponibilité
Le plan de contrôle du maillage de services OCI est toujours déployé avec une haute disponibilité.