Introduction
Lorsqu’on parle de Serverless, Kubernetes est un sujet incontournable.
Dans la leçon d’aujourd’hui, nous allons continuer à apprendre comment configurer un environnement Serverless privé. Plus précisément, nous allons construire l’infrastructure Serverless basée sur le déploiement local de K8s de la dernière leçon. Ensuite, nous installerons des composants supplémentaires pour étendre les capacités du cluster K8s, permettant ainsi au cluster K8s local de prendre en charge Serverless.
Prérequis pour la construction de Serverless
Avant de commencer, clarifions une question qui a été soulevée lors du cours fondamental sur le calcul Serverless, en particulier le FaaS. Certains étudiants ont demandé : « Quelle est la relation entre les microservices, Service Mesh et Serverless ? »
Ces concepts apparaissent fréquemment dans les discussions, mais ne vous mettez pas la pression. J’étais également confus par ces concepts lorsque j’ai commencé à apprendre Serverless. Revenons d’abord aux microservices. Lorsque vous utilisez des microservices pour créer un BaaS, vous avez peut-être remarqué que de nombreux concepts des microservices sont assez similaires à ceux de Serverless.
En termes simples, Service Mesh est une solution de communication réseau pour microservices qui fonctionne sans que les microservices eux-mêmes en aient conscience. Nous pouvons également déléguer la communication réseau dans une architecture Serverless à un Service Mesh. Grâce à Service Mesh, les composants Serverless peuvent travailler étroitement avec le cluster K8s, permettant finalement de prendre en charge nos applications déployées de manière Serverless. Examinons le diagramme d’architecture suivant :
À partir du diagramme, nous pouvons clairement voir que l’infrastructure sous-jacente de Serverless peut être construite sur Service Mesh. Cependant, Service Mesh n’est qu’une des solutions pour implémenter la communication réseau Serverless. Il existe d’autres options comme RSocket, gRPC et Dubbo. J’ai choisi Service Mesh car cette solution peut être basée sur les composants K8s et fournit des outils de visualisation pour nous aider à comprendre le mécanisme de fonctionnement de Serverless, par exemple comment atteindre un temps de démarrage nul et contrôler le trafic pour les versions progressives. Si vous voulez pratiquer, Service Mesh est sans aucun doute le premier choix.
Infrastructure Serverless : Service Mesh
Certaines personnes qualifient Kubernetes, Service Mesh et les technologies Serverless de « trois piliers » du développement d’applications cloud-native. À ce stade, je suppose que vous comprenez la raison derrière cela. Cependant, je dois clarifier que dans les leçons suivantes, nous introduirons de nombreux nouveaux termes. Je vous ai donné un aperçu général de ces termes afin que vous puissiez avoir une compréhension large. Si vous avez le temps, vous devriez approfondir ces sujets.
Maintenant, revenons au sujet principal et examinons de plus près les principes de Service Mesh.
Lorsque nous avons abordé les microservices, nous n’avons couvert que les directives théoriques sur la décomposition et l’intégration, sans toucher à l’implémentation spécifique. Si nous passons à l’implémentation, l’industrie possède en réalité de nombreux frameworks de microservices, mais la plupart sont limités à des SDK de langages spécifiques, en particulier les frameworks Java de microservices.
Le framework de microservices sous forme de SDK a généralement un fort accent sur l’implémentation de la communication réseau entre les microservices, comme la répétition des requêtes de service échouées, l’équilibrage de charge entre plusieurs instances de service et la limitation du trafic en cas de volume élevé de requêtes de service. Ces logiques nécessitent souvent l’attention des développeurs de microservices et doivent être implémentées à plusieurs reprises dans chaque langage SDK. Alors, est-il possible d’extraire la logique de communication réseau des microservices du SDK, rendant nos microservices plus légers et même éliminant le besoin de se soucier de la communication réseau ?
La réponse est Service Mesh.
Si nous déployons des applications décomposées dans les Pods du cluster K8s, le processus est comme indiqué dans le diagramme ci-dessous, où l’application MyApp appellera directement le microservice utilisateur et le microservice de tâches à faire au sein du cluster via HTTP.
Mais qu’en est-il des problèmes de sécurité découlant de l’accès HTTP direct ? Si quelqu’un démarre un conteneur BusyBox dans notre cluster, ne pourrait-il pas attaquer directement notre microservice utilisateur et notre microservice de tâches à faire ? De plus, lorsque nous avons plusieurs instances du microservice utilisateur, comment répartissons-nous le trafic ?
Traditionnellement, nous utiliserions un SDK d’architecture de microservices, qui contient beaucoup de cette logique et de nombreuses stratégies que nous devons décider quand activer lors de l’appel du SDK. Notre code deviendrait également fortement couplé au SDK d’architecture de microservices.
Service Mesh adopte une approche différente en extrayant la logique de communication réseau des microservices et en gérant le trafic réseau de manière non intrusive, nous permettant de ne plus nous soucier du lourd SDK de microservices. Voyons comment Service Mesh résout ce problème.
Service Mesh peut être divisé en un plan de données et un plan de contrôle. Le plan de données est responsable de la gestion de la communication réseau, tandis que le plan de contrôle contrôle et surveille l’état de la communication réseau. Service Mesh intercepte tout le trafic réseau en injectant un Sidecar.
Dans le plan de données, nos applications et microservices semblent communiquer directement avec le Sidecar, mais en réalité, le Sidecar peut y parvenir grâce au détournement de trafic. Par conséquent, nos applications et microservices ne sont généralement pas conscients de cela et n’ont besoin d’aucune modification, ils utilisent simplement des requêtes HTTP pour transmettre des données.
Le plan de contrôle est plus complexe et constitue le cœur du fonctionnement de Service Mesh. Le pilot est le moteur de tout le plan de contrôle, responsable de la découverte de services, de la gestion du trafic et de la mise à l’échelle. Citadel est la forteresse gardienne du plan de contrôle, responsable des certificats de sécurité et de l’authentification. Mixer est l’officier de communication, distribuant les politiques du plan de contrôle et collectant l’état de fonctionnement de chaque service.
Maintenant, vous devriez avoir une compréhension claire de ce qu’est Service Mesh, comment il extrait la logique de communication réseau des microservices du SDK, et pourquoi nous disons que Service Mesh est le fondement de la communication réseau pour Serverless.
La relation entre Serverless et les moteurs de conteneurs
La valeur fondamentale de Serverless réside dans le fait de ne pas avoir à gérer les serveurs, permettant de se concentrer sur la logique métier. La technologie des conteneurs fournit l’infrastructure puissante et les capacités de planification flexibles nécessaires à Serverless, en particulier lorsqu’elle est combinée à des outils d’orchestration comme Kubernetes.
Les conteneurs offrent des avantages tels que l’emballage léger, l’isolation des ressources et un démarrage rapide. Les conteneurs empaquettent les applications et leurs dépendances, garantissant la cohérence de l’environnement d’exécution, ce qui facilite le déploiement rapide et le démarrage des instances d’application sur une plateforme Serverless. De plus, les conteneurs fournissent des environnements d’exécution isolés, garantissant que différentes applications n’interfèrent pas entre elles, améliorant ainsi la stabilité globale de la plateforme. En outre, le démarrage des conteneurs est plus rapide que celui des machines virtuelles, répondant aux exigences élevées des applications Serverless en matière de mise à l’échelle élastique.
En tant que cœur de la planification Serverless, Kubernetes possède des fonctions telles que le déploiement automatisé, la mise à l’échelle élastique et la découverte de services. Il peut déployer automatiquement des applications conteneurisées en fonction de règles prédéfinies, sans intervention manuelle, ajuster le nombre d’instances d’application en fonction de la charge en temps réel, garantissant les performances tout en optimisant l’utilisation des ressources, et fournir des mécanismes de découverte de services pour faciliter la communication entre les composants de la plateforme Serverless.
Pour construire une plateforme Serverless basée sur des conteneurs, il faut d’abord empaqueter les applications et leurs dépendances dans des images de conteneurs, en veillant à ce que les applications puissent être rapidement déployées et exécutées sur la plateforme. Ensuite, choisissez une plateforme cloud appropriée ou configurez un cluster Kubernetes auto-hébergé comme infrastructure de la plateforme Serverless. Ensuite, développez les composants de la plateforme Serverless, y compris une passerelle API pour recevoir et router les requêtes externes, un environnement d’exécution de fonctions pour charger et exécuter le code des fonctions et gérer les cycles de vie des fonctions, et des déclencheurs d’événements qui écoutent diverses sources d’événements et convertissent les événements en appels de fonctions. Enfin, utilisez Deployment de Kubernetes pour gérer le déploiement et la mise à jour des instances d’application, Service pour la découverte de services et l’équilibrage de charge, et HPA pour réaliser une mise à l’échelle élastique automatique.
Une plateforme Serverless basée sur des conteneurs offre une grande flexibilité, une forte personnalisation et un bon rapport coût-efficacité. Les développeurs peuvent librement choisir la technologie de conteneurs sous-jacente et la plateforme Kubernetes, personnaliser les fonctions et les caractéristiques de la plateforme Serverless selon leurs besoins, et utiliser les capacités de planification des ressources de Kubernetes pour optimiser l’utilisation des ressources et réduire les coûts.
La combinaison de la technologie des conteneurs et de Kubernetes fournit des outils et des méthodes puissants pour construire des plateformes Serverless efficaces, flexibles et évolutives, permettant aux développeurs de construire facilement leurs propres plateformes Serverless, de se concentrer sur le développement de la logique métier et d’améliorer l’efficacité du développement.
Novita AI Serverless
Chez Novita AI, nous avons développé notre propre moteur de conteneurs, Nexus. Grâce aux capacités de calcul distribué et de planification des ressources de Nexus, Novita AI a construit un service Serverless destiné à la prochaine génération d’IA générative. Les utilisateurs n’ont qu’à se concentrer sur l’innovation métier sans se soucier des ressources de calcul sous-jacentes. Les réservations sont désormais ouvertes ; rejoignez la liste d’attente pour être parmi les premiers à découvrir Novita AI Serverless.
Novita AI est la plateforme cloud tout-en-un qui donne vie à vos ambitions en IA. APIs intégrées, serverless, instances GPU — les outils rentables dont vous avez besoin. Éliminez l’infrastructure, commencez gratuitement, et faites de votre vision IA une réalité.
Lectures recommandées
Mise à l’échelle à la demande : Comment Serverless gère les pics de trafic avec aisance
Dévoiler la révolution : Explorer le monde du calcul Serverless
