Dans un contexte Kubernetes, la mutualisation fait référence au partage d’un grand cluster entre plusieurs équipes, applications ou utilisateurs, principalement dans des environnements inférieurs tels que le développement et les tests, principalement pour réduire les coûts et les frais généraux liés à la gestion de nombreux clusters. La mutualisation devient une exigence essentielle pour les équipes de plateforme qui déploient l’infrastructure Kubernetes.
Atteindre la multilocation à l’aide des espaces de noms Kubernetes
De loin, l’approche la plus populaire pour réaliser la multilocation consiste à utiliser les espaces de noms Kubernetes. Les espaces de noms Kubernetes offrent un moyen simple de diviser un ensemble de ressources, telles que des pods, des services et des déploiements, qui ne sont accessibles que dans cet espace de noms.
Les équipes de plate-forme gèrent et exploitent généralement les clusters et disposent d’autorisations complètes au niveau du cluster. Ils réalisent la multilocation en créant un ou plusieurs espaces de noms spécifiques à chaque équipe/application/utilisateur et en restreignant l’accès à ces espaces de noms pour les utilisateurs finaux qui sont des développeurs, des ingénieurs DevOps et des propriétaires d’applications. Les utilisateurs finaux ne peuvent effectuer que des opérations spécifiques aux espaces de noms dont ils sont propriétaires. Cela fonctionne bien pour la grande majorité des cas d’utilisation multi-locataires ; cependant, il existe un cas d’utilisation d’angle où le framework vcluster peut être utile.
Multi-Tenancy à l’aide du framework Open Source Vcluster
Restreindre l’accès des utilisateurs finaux uniquement aux espaces de noms ne fonctionne pas dans certains cas particuliers où les utilisateurs finaux ont besoin d’accéder à des objets de portée de cluster tels que les CRD, les contrôleurs d’entrée, les serveurs d’API de cluster, etc., pour leur travail de développement quotidien. En règle générale, un accès au niveau du cluster est nécessaire pour les utilisateurs finaux qui sont impliqués dans le développement de ressources personnalisées et de contrôleurs personnalisés pour étendre l’API Kubernetes, les contrôleurs d’admission pour implémenter des webhooks de mutation et de validation, et d’autres services qui peuvent nécessiter une configuration Kubernetes personnalisée. Virtual Cluster (Vcluster) est un framework open-source qui vise à résoudre ce problème. Vcluster est essentiellement un cluster virtuel qui peut être créé dans un cluster physique.
Vcluster installe un cluster K3s par défaut (k0s, k8s et EKS en option) dans un espace de noms du cluster hôte pour chaque instance de vcluster et installe les composants principaux de Kubernetes tels que le serveur d’API, le gestionnaire de contrôleur, le backend de stockage et éventuellement un planificateur. Les utilisateurs finaux interagissent avec le serveur d’API de cluster virtuel et obtiennent un accès complet au cluster virtuel, tout en maintenant l’isolation et la sécurité des ressources car ils sont limités aux espaces de noms hôtes et n’ont pas accès au serveur d’API de cluster hôte. Les équipes de plate-forme créent un espace de noms dans le cluster hôte, configurent les quotas de ressources et les politiques pour l’espace de noms hôte, créent une instance vcluster et transmettent le cluster virtuel aux utilisateurs finaux.
Questions clés à répondre avant de déployer des Vclusters
Bien que le déploiement de vcluster pour un petit groupe d’utilisateurs finaux soit assez simple, les équipes de plate-forme doivent se poser les questions suivantes et mettre en œuvre des solutions supplémentaires autour de vcluster pour répondre aux exigences d’automatisation, de sécurité, de gouvernance et de conformité de leur organisation avant de procéder à des déploiements vcluster à grande échelle :
Comment créer des espaces de noms au niveau de l’hôte et des quotas de ressources pour chaque espace de noms et les mapper avec des utilisateurs/équipes internes ?
- Les équipes de plate-forme ont toujours besoin d’une solution pour la multilocation au niveau de l’espace de noms, car les espaces de noms d’hôte doivent d’abord être créés pour déployer des instances vcluster.
Comment automatisez-vous la gestion du cycle de vie de vcluster pour une utilisation à grande échelle ?
- Les équipes de plate-forme doivent résoudre des problèmes tels que la création/la modification/la suppression d’instances vcluster, l’exposition du serveur d’API vcluster aux utilisateurs finaux (à l’aide d’ingress ou équilibreur de charges), distribuer en toute sécurité les fichiers vcluster Kubeconfig aux utilisateurs finaux et mettre à niveau les instances vcluster (K3) pour les mises à jour logicielles et les vulnérabilités de sécurité.
Comment vous assurez-vous que seuls les services approuvés et mandatés à l’échelle du cluster s’exécutent dans chaque vcluster ? Les déployez-vous dans chaque vcluster ? Comment garantir qu’il n’y a pas de dérive ?
- Ces services incluent généralement les plugins de sécurité, la journalisation, la surveillance, le service mesh, les contrôleurs d’entrée, les plugins de stockage, etc.
Comment créez-vous des politiques de réseau au niveau de l’espace de noms pour les espaces de noms hôtes ?
- Ce niveau d’isolation du réseau est toujours nécessaire car le cluster physique peut être partagé entre plusieurs BU et équipes d’application, ce qui nécessite une isolation du réseau entre les espaces de noms hôtes.
Comment appliquez-vous les politiques de sécurité telles que l’OPA dans chaque vcluster ? Déployez-vous ces politiques dans chaque vcluster ?
- La plupart des équipes de plate-forme standardisent un ensemble de politiques de sécurité basées sur les recommandations de leurs équipes de sécurité et les déploient dans chaque cluster pour maintenir la sécurité même dans des environnements inférieurs.
Comment récupérez-vous les journaux d’audit Kubectl pour chaque vcluster ?
- Pour certaines organisations, l’audit Kubectl est une exigence clé, même dans des environnements inférieurs.
Comment gérez-vous la répartition des coûts ?
- Étant donné que les ressources sont partagées par différentes équipes de développement, elles peuvent appartenir à différents centres de coûts et les équipes de plate-forme doivent mettre en œuvre les politiques de refacturation appropriées pour la répartition des coûts.
Comment faire fonctionner d’autres outils de développement comme ArgoCD avec vcluster ?
- Les outils GitOps comme ArgoCD nécessitent un accès au cluster pour le déploiement d’applications, de sorte que chaque instance vcluster doit être configurée dans ArgoCD pour que les utilisateurs finaux puissent tirer parti du déploiement ArgoCD GitOps. Cela peut s’appliquer à d’autres outils courants tels que les outils d’observabilité, de journalisation et de surveillance.
Quel type de ressources supplémentaires et de frais généraux opérationnels encourez-vous avec chaque instance de vcluster ?
- Chaque vcluster est essentiellement un cluster K3s/K8s avec tous les add-ons, tels que vos plugins de sécurité, plugins de journalisation, plugins de surveillance, contrôleurs d’entrée, etc. Ces ressources Kubernetes par vcluster et les add-ons peuvent potentiellement entraîner des frais généraux importants lorsque vous déployer plus d’instances vcluster. De même, étant donné que chaque vcluster est essentiellement un cluster Kubernetes, les équipes de plate-forme peuvent encourir des frais supplémentaires pour gérer ces clusters pour les mises à jour de version de Kubernetes, la gestion des correctifs et la gestion des modules complémentaires.
Le vcluster correspond-il à votre environnement de production réel ?
- Pour certaines organisations, il est important que l’environnement de développement corresponde étroitement à l’environnement de production. Vcluster prend en charge d’autres distributions telles que K8 et EKS, mais les équipes de plate-forme doivent vérifier si cela équivaut à exécuter un cluster autonome pour les cas d’utilisation qui nécessitent des environnements proches de la production. Par exemple, EKS prend en charge de nombreuses fonctionnalités avancées, notamment des CNI tiers, diverses classes de stockage, la mise à l’échelle automatique, IRSA et des modules complémentaires, qui peuvent ne pas être disponibles dans les clusters EKS virtuels.
Conclusion
Pour la plupart des équipes de plate-forme, la mutualisation basée sur des espaces de noms avec une automatisation supplémentaire autour de la gestion du cycle de vie des espaces de noms, de la sécurité et du contrôle des coûts résout leurs cas d’utilisation de mutualisation. Vcluster comble une lacune spécifique dans la multilocation de l’espace de noms Kubernetes, dans laquelle les utilisateurs finaux qui ne disposent pas de privilèges au niveau du cluster peuvent désormais accéder aux objets de l’étendue du cluster au sein de leur cluster virtuel. Les équipes de plate-forme doivent valider en interne s’il existe une telle exigence pour leurs utilisateurs finaux, effectuer une analyse coûts-avantages approfondie en tenant compte de leurs exigences en matière de sécurité, de conformité et de gouvernance, et mettre en œuvre une automatisation supplémentaire pour s’assurer qu’elle est prête pour l’entreprise avant le déploiement.