Activer Oracle Cloud Infrastructure Service Mesh sur vos applications Kubernetes
Les clients d'Oracle Cloud Infrastructure (OCI) sont de plus en plus orientés vers une architecture de microservices qui, avec ses avantages, apporte également de nouveaux défis. Dans une architecture de microservices, les applications monolithiques sont décomposées en microservices plus petits qui communiquent sur le réseau à l'aide d'une API. Cela provoque une augmentation du trafic réseau et augmente la complexité et la surface d'attaque globale de l'architecture.
- Permet de contrôler le flux de trafic des microservices.
- Fournit une visibilité sur vos applications.
- Permet aux microservices de se connecter en toute sécurité sans aucune modification du code d'application.
Capacités du maillage de services OCI
- Application des politiques relatives à la sécurité
Le maillage de services OCI utilise des politiques d'accès pour définir des règles d'accès. Les politiques d'accès appliquent la communication entre les microservices et n'autorisent que les demandes validées provenant de l'intérieur et de l'extérieur de l'application. Les politiques d'accès sont également utilisées pour définir les communications autorisées aux services externes.
- Fiducie zéro
Le maillage de services OCI met en oeuvre automatiquement une architecture de sécurité sans confiance pour tous les microservices. Les données entre microservices sont chiffrées. L'identification du microservice au microservice est requise au début de la communication. Les deux parties doivent échanger des informations d'identification avec leurs informations d'identité. Cela permet aux services de s'identifier pour déterminer s'ils sont autorisés à interagir. Ceci est mis en oeuvre avec le protocole TLS mutuel avec rotation automatisée des certificats et des clés à l'aide du service Oracle Cloud Infrastructure Certificates (Certificats OCI) et d'Oracle Key Management Cloud Service pour gérer les certificats et les clés.
- Déplacement du trafic
Le maillage de services OCI vous permet d'effectuer des déploiements de test canari. Lorsque vous publiez une nouvelle version de votre code en production, vous n'autorisez qu'une partie du trafic à y accéder. Cette fonction permet un déploiement rapide et réduit au minimum les perturbations de l'application. Vous pouvez définir des règles de routage qui régissent toutes les communications inter-microservices à l'intérieur du maillage. Vous pouvez acheminer une partie du trafic vers une certaine version du service.
- Surveillance et journalisation
Le maillage de services OCI occupe une position unique pour fournir des informations de télémétrie, car toutes les communications inter-microservices doivent passer par celui-ci. Cela permet au maillage de services de saisir des données de télémétrie telles que la source, la destination, le protocole, l'URL, la durée, le code d'état, 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 (Journalisation OCI). Le maillage de services OCI fournit deux types de journaux : journaux d'erreurs et journaux de trafic. Vous pouvez utiliser ces journaux pour déboguer des problèmes 404 ou 505 ou générer des statistiques basées sur des 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
Le maillage de services Oracle Cloud Infrastructure (maillage de services OCI) utilise un modèle side-car. 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é side-car parce qu'un proxy est attaché à chaque application, un peu comme un side-car attaché à une moto. Dans OKE, le conteneur d'application se trouve à côté du conteneur sidecar proxy dans le même pod. Comme ils sont 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 du maillage de services OCI gère et configure l'ensemble de la collection de mandataires 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 certificats OCI et le service de gestion des clés OCI pour fournir à chaque mandataire son certificat.
- Plan de données
Le plan de données est composé de la collection de mandataires secondaires 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 mandataire Envoy est utilisé pour le plan de données du maillage de services OCI.
Le diagramme 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 mandataire envoyé. Au fur et à mesure du déploiement de chaque pod, les configurations et les certificats sont envoyés à chacun des conteneurs mandataires par le plan de contrôle du maillage de services OCI. Le plan de contrôle du maillage de services OCI communique avec le service Certificats OCI et Oracle Key Management Cloud Service pour obtenir des certificats pour chaque mandataire.
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 du maillage de services OCI et est également un mandataire envoyé qui reçoit la configuration et les certificats du plan de contrôle du maillage de services OCI.
Il incombe au conteneur mandataire d'effectuer la détection des services, le chiffrement 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 différentes versions de service et l'application de stratégies d'accès. La passerelle entrante effectue la même fonction pour le trafic en dehors du maillage de services.
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 défaillances, les demandes et la télémétrie au déploiement Prometheus. Grafana extrait des données du déploiement Prometheus, qui peut être utilisé pour créer des tableaux de bord pour la visualisation.
Le maillage de services OCI est intégré au service de journalisation OCI et la journalisation peut être activée lors de la création du maillage de services. Le maillage de services OCI fournit deux types de journaux : journaux d'erreurs et journaux de trafic. Ces journaux peuvent être utilisés pour déboguer des problèmes 404 ou 505 ou pour générer des statistiques basées sur les journaux.
Cette architecture comprend les services OCI suivants :
- OCI Kubernetes Engine (OKE)
Offre une grappe Kubernetes prête pour la production hautement disponible et évolutive pour déployer vos applications en conteneur dans le nuage.
- Équilibreur de charge
Fournit un accès à la passerelle entrante dans la grappe OKE. Le trafic entrant dirige le trafic vers les services demandés dans la grappe OKE.
- Autorité de certification
Gère les certificats TLS pour le service de maillage de services OCI.
- Gestion des clés
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 localisée qui contient 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 (dans différents pays ou continents).
- Réseau en nuage virtuel (VCN) et sous-réseau
Un VCN est un réseau défini par logiciel personnalisable que vous avez configuré dans une région Oracle Cloud Infrastructure. Comme les réseaux en nuage virtuels traditionnels, ils vous offrent un contrôle sur votre environnement de réseau. Un VCN peut disposer de plusieurs blocs CIDR sans chevauchement que vous pouvez modifier après avoir créé le VCN. Vous pouvez segmenter un VCN en sous-réseaux, dont la portée peut concerner une région ou un domaine de disponibilité. Un sous-réseau est constitué d'un intervalle contigu d'adresses qui ne chevauchent pas les autres sous-réseaux dans le réseau en nuage 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 spécifient la source, la destination et le type de trafic qui doivent être autorisés à entrer et à sortir du sous-réseau.
Ressources du maillage de services OCI
| 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 de 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 répartir le trafic entre les différentes versions du microservice. Un microservice Kubernetes peut avoir plusieurs versions qui sont des déploiements distincts dans la grappe. |
| Liaisons de déploiement virtuel | Les liaisons virtuelles permettent d'associer un jeu de pods à un déploiement virtuel. |
| Tables de routage de service virtuel | Une table de routage virtuelle définit la répartition du trafic entre les déploiements virtuels d'un service virtuel en fonction du protocole et du chemin. Chaque service virtuel aura une table de routage virtuelle. |
| Déploiement de la 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 jeu de règles pour la façon dont le trafic externe communique avec le maillage, par exemple si le chiffrement est requis pour tout le trafic entrant et sortant. Ces règles sont appliquées au déploiement de la 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 qui sont accessibles à partir du déploiement de la passerelle entrante. |
| Politiques d'accès | Les politiques d'accès sont des règles définies qui définissent les communications autorisées entre les microservices du maillage et les applications externes. |
Le diagramme suivant décrit comment les ressources configurées du maillage de services OCI : politiques d'accès, passerelle entrante, service virtuel et mappage de déploiement virtuel à vos ressources d'application : service K8s, équilibreur de charge de service K8s, déploiements et pods.
Description de l'illustration oci_service_mesh_oke_config.png
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 aux sous-réseaux du VCN. Utilisez des blocs CIDR qui se trouvent dans l'espace d'adresses IP privées standard.
Sélectionnez les blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données sur place ou un autre fournisseur de nuage) auquel vous voulez 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 de vos exigences en matière de flux de trafic et 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 de l'é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 spécifier une forme personnalisée (flexible) dans laquelle vous définissez une plage de bande passante et laissez le service ajuster la bande passante automatiquement en fonction des modèles de trafic. Avec l'une ou l'autre approche, vous pouvez modifier la forme en tout temps après avoir créé l'équilibreur de charge.
Points à considérer
Tenez compte des options suivantes lors du déploiement de cette architecture de référence.
- Coût
Il n'y a aucuns frais pour le plan de contrôle du maillage de services OCI dans la grappe OKE. Les clients sont facturés pour l'utilisation des ressources des conteneurs mandataires pour le plan de données du maillage de services. En pratique, cependant, les clients paient déjà pour les ressources du groupe de noeuds dans une grappe OKE. À moins que l'utilisation des conteneurs mandataires ne pousse l'utilisation du groupe de noeuds à plus de 100 %, il n'y a pas de frais supplémentaires pour l'ajout du maillage de services OCI à votre architecture de microservices.
- Disponibilité
Le plan de contrôle du maillage de services OCI est toujours déployé avec une haute disponibilité.