¶ Clusters Kubernetes virtuels
¶ Introduction
Essayez vcluster, une implémentation open source qui s’attaque à certains aspects des modèles d’isolation typiques basés sur les espaces de noms et les clusters.
Si vous parlez à des personnes qui utilisent Kubernetes en production, l’une des plaintes que vous entendez souvent est la difficulté du multi tenant. Les organisations utilisent deux modèles principaux pour partager des clusters Kubernetes avec plusieurs tenants, mais les deux présentent des problèmes. Ces modèles sont les suivants :
- L’espace de noms
- Les clusters
Le premier modèle de multilocation commun est basé sur l’isolation des espaces de noms, où les clients (une équipe développant un microservice, par exemple) sont limités à l’utilisation d’un ou plusieurs espaces de noms dans le cluster. Bien que ce modèle puisse fonctionner pour certaines équipes, il présente des défauts. Tout d’abord, le fait de limiter l’accès des membres de l’équipe aux ressources des espaces de noms signifie qu’ils ne peuvent pas administrer les objets globaux du cluster, tels que les définitions de ressources personnalisées (CRD). C’est un gros problème pour les équipes qui travaillent avec des CRD dans le cadre de leurs applications ou dans une dépendance (par exemple, en construisant au-dessus de Kubeflow ou Argo Pipelines).
Deuxièmement, un problème de maintenance à long terme beaucoup plus important est la nécessité d’ajouter constamment des exceptions aux règles d’isolation des espaces de noms. Par exemple, lorsqu’ils utilisent des stratégies de réseau pour verrouiller des espaces de noms individuels, les administrateurs se rendent probablement compte que certaines équipes ont finalement besoin d’exécuter plusieurs microservices qui communiquent entre eux. Les administrateurs de clusters doivent en quelque sorte ajouter des exceptions pour ces cas, les suivre et gérer tous ces cas particuliers. Bien entendu, la complexité s’accroît au fur et à mesure que le temps passe et que de plus en plus d’équipes se mettent à utiliser Kubernetes.
L’autre modèle standard avec des clusters multiples, qui utilise l’isolation au niveau du cluster, est encore plus problématique. Dans ce scénario, chaque équipe obtient son propre cluster, voire plusieurs (dev, test, UAT, staging, etc.). Le problème immédiat de l’utilisation de l’isolation des clusters est de se retrouver avec de nombreux clusters à gérer, ce qui peut être un énorme casse-tête. Et tous ces clusters ont besoin de ressources de cloud computing coûteuses, même si personne ne les utilise activement, par exemple la nuit ou le week-end. Comme le souligne Holly Cummins dans son discours d’ouverture de la KubeCon 2021, cette explosion de clusters a un impact dangereux sur l’environnement.
Jusqu’à récemment, les administrateurs de clusters devaient choisir entre ces deux modèles insatisfaisants, en choisissant celui qui correspondait le mieux à leur cas d’utilisation et à leur budget. Cependant, il existe un concept relativement nouveau dans Kubernetes, appelé clusters virtuels, qui correspond mieux à de nombreux cas d’utilisation.
¶ Comparaison
¶ Architecture
¶ Que sont les clusters virtuels ?
Un cluster virtuel est un cluster Kubernetes partagé qui apparaît au locataire comme un cluster dédié. En 2020, notre équipe de Loft Labs a publié vcluster, une implémentation open source des clusters Kubernetes virtuels.
Avec vcluster, les ingénieurs peuvent provisionner des clusters virtuels au-dessus des clusters Kubernetes partagés. Ces clusters virtuels fonctionnent dans les espaces de noms habituels du cluster sous-jacent. Ainsi, un administrateur peut créer des clusters virtuels et les distribuer aux locataires ou, si une organisation utilise déjà la multilocation basée sur l’espace de noms, mais que les utilisateurs sont limités à un seul espace de noms, les utilisateurs locataires peuvent créer eux-mêmes ces clusters virtuels dans leur espace de noms.
Cela combine le meilleur des deux approches de multi tenant décrites ci-dessus : Les locataires sont limités à un seul espace de noms sans qu’aucune exception ne soit nécessaire car ils ont un contrôle total à l’intérieur du cluster virtuel mais un accès très restreint à l’extérieur du cluster virtuel.
Comme un administrateur de cluster, l’utilisateur a un contrôle total à l’intérieur d’un cluster virtuel. Cela lui permet de faire n’importe quoi à l’intérieur du cluster virtuel sans avoir d’impact sur les autres locataires du cluster hôte partagé sous-jacent. En coulisse, vcluster accomplit cette tâche en exécutant un serveur API Kubernetes et d’autres composants dans un pod au sein de l’espace de noms sur le cluster hôte. L’utilisateur envoie des requêtes au serveur API du cluster virtuel dans son espace de noms au lieu du serveur API du cluster sous-jacent. L’état du cluster virtuel est également entièrement séparé du cluster sous-jacent. Les ressources telles que les déploiements ou les intrusions créées à l’intérieur du cluster virtuel n’existent que dans le magasin de données du cluster virtuel et ne sont pas persistées dans l’etcd du cluster sous-jacent.
Cette architecture offre des avantages considérables par rapport aux modèles d’isolation des espaces de noms et des clusters :
- Puisque l’utilisateur est un administrateur de son cluster virtuel, il peut gérer des objets à l’échelle du cluster comme les CRD, ce qui permet de surmonter la grande limitation de l’isolation de l’espace de noms.
- Comme les utilisateurs communiquent avec leurs propres serveurs API, leur trafic est plus isolé que dans un cluster partagé normal. Cela permet également la fédération, ce qui peut faciliter la mise à l’échelle des demandes d’API dans les clusters à fort trafic.
- Les clusters virtuels sont très rapides à provisionner et à démanteler, de sorte que les utilisateurs peuvent bénéficier d’environnements véritablement éphémères et en redémarrer plusieurs si nécessaire.
¶ Comment utiliser les clusters virtuels
Il existe de nombreux cas d’utilisation des clusters virtuels, mais en voici quelques-uns que nous avons vu la plupart des utilisateurs de vcluster adopter.
¶ Environnements de développement
Le provisionnement et la gestion des environnements de développement est actuellement le cas d’utilisation le plus populaire de vcluster. Les développeurs qui écrivent des services qui s’exécutent dans des clusters Kubernetes ont besoin d’un endroit pour exécuter leurs applications pendant leur développement. Bien qu’il soit possible d’utiliser des outils tels que Docker Compose pour orchestrer des conteneurs pour les environnements de développement, les développeurs qui codent contre des clusters Kubernetes auront une expérience beaucoup plus proche de la façon dont leurs services fonctionnent en production.
Une autre option pour le développement local consiste à utiliser un outil comme Minikube ou Docker Desktop pour provisionner les clusters Kubernetes, mais cela présente certains inconvénients. Les développeurs doivent posséder et maintenir cette pile de clusters locaux, ce qui représente un fardeau et une perte de temps considérable. En outre, ces clusters locaux peuvent nécessiter une grande puissance de calcul, ce qui est difficile sur les machines de développement locales. Nous savons tous à quel point les ordinateurs portables peuvent devenir chauds pendant le développement, et ce n’est peut-être pas une bonne idée d’ajouter Kubernetes au mélange.
L’exécution de clusters virtuels en tant qu’environnements de développement dans un cluster de développement partagé répond à ces préoccupations. En outre, comme mentionné ci-dessus, les vclusters sont rapides à provisionner et à supprimer. Les administrateurs peuvent supprimer un vcluster en supprimant l’espace de nom de l’hôte sous-jacent à l’aide d’une seule commande kubetctl, ou en exécutant la commande vcluster delete fournie avec l’outil d’interface de ligne de commande. La rapidité de l’infrastructure et des outils dans les flux de travail de développement est essentielle car l’amélioration des temps de cycle pour les développeurs peut augmenter leur productivité et leur bonheur.
¶ Pipelines CI/CD
L’intégration continue/développement continu (CI/CD) est un autre cas d’utilisation important des clusters virtuels. En général, les pipelines fournissent des systèmes sous test (SUT) pour exécuter des suites de tests. Souvent, les équipes souhaitent qu’il s’agisse de systèmes récents, sans accumulation de données susceptibles de perturber les tests. Les équipes qui exécutent de longs pipelines avec de nombreux tests peuvent être amenées à provisionner et à détruire les SUT plusieurs fois au cours d’un test. Si vous avez passé beaucoup de temps à provisionner des clusters, vous avez probablement remarqué que le démarrage d’un cluster Kubernetes est souvent une opération qui prend du temps. Même dans les clouds publics les plus sophistiqués, cela peut prendre plus de 20 minutes.
Les clusters virtuels sont rapides et faciles à provisionner avec vcluster. Lorsque vous exécutez la commande vcluster create pour provisionner un nouveau cluster virtuel, tout ce qui est impliqué en coulisses est l’exécution d’un diagramme Helm et l’installation de quelques pods. C’est une opération qui ne prend généralement que quelques secondes. Toute personne qui exécute de longues suites de tests sait que le moindre temps gagné sur le processus peut faire une énorme différence dans la rapidité avec laquelle l’équipe d’assurance qualité et les ingénieurs reçoivent un retour d’information.
En outre, les organisations pourraient utiliser la vitesse de vcluster pour améliorer tout autre processus où beaucoup de clusters sont provisionnés, comme la création d’environnements pour les ateliers ou la formation des clients.
Test de différentes versions de Kubernetes
Comme mentionné précédemment, vcluster exécute un serveur d’API Kubernetes dans l’espace de noms d’hôte sous-jacent. Il utilise le serveur API K3s (Lightweight Kubernetes) par défaut, mais vous pouvez également utiliser k0s, Amazon Elastic Kubernetes Service ou le serveur API Kubernetes amont normal. Lorsque vous provisionnez un vcluster, vous pouvez spécifier la version de Kubernetes avec laquelle l’exécuter, ce qui ouvre de nombreuses possibilités. Vous pouvez :
- Exécuter une version plus récente de Kubernetes dans le cluster virtuel pour avoir un aperçu du comportement d’une application face au serveur API plus récent.
- Exécuter plusieurs clusters virtuels avec différentes versions de Kubernetes pour tester un opérateur dans un ensemble de distros et de versions de Kubernetes différentes pendant le développement ou pendant les tests de bout en bout.
¶ En savoir plus
Il n’existe peut-être pas de solution parfaite pour la multilocation Kubernetes, mais les clusters virtuels répondent à de nombreux problèmes liés aux modèles de location actuels. La vitesse et la facilité d’utilisation de vcluster en font un excellent candidat pour de nombreux scénarios où vous préféreriez utiliser un cluster partagé mais où vous souhaitez également donner aux utilisateurs la flexibilité d’administrer leurs clusters. Il existe de nombreux cas d’utilisation de vcluster au-delà de ceux décrits dans cet article.
Pour en savoir plus, rendez-vous sur vcluster.com, ou si vous souhaitez vous plonger directement dans le code, téléchargez-le depuis le repo GitHub. L’équipe de Loft Labs assure la maintenance de vcluster, et nous aimons recevoir des idées à son sujet. Nous avons ajouté de nombreuses fonctionnalités en fonction des commentaires des utilisateurs. N’hésitez pas à ouvrir des problèmes ou des RP. Si vous souhaitez d’abord discuter avec nous de vos idées ou si vous avez des questions tout en explorant vcluster, nous avons également un canal vcluster sur Slack.