La conteneurisation des flux de travail de développement, de test et de production révolutionne la gestion informatique à tous les niveaux, qu'il s'agisse d'applications et de services destinés aux clients ou d'applications internes. Les organisations gagnent en efficacité en matière de développement et de délai de déploiement grâce à l'utilisation d'architectures basées sur des microservices construites sur des conteneurs et à l'exploitation de frameworks d'orchestration de conteneurs tels que Kubernetes.
La transition de l'informatique classique vers les approches basées sur les conteneurs résulte souvent d'initiatives menées par des équipes ou des départements DevOps qui créent un environnement prototype ensuite reproduit par d'autres équipes. Si ces équipes agissent ainsi pour gagner en efficacité et en flexibilité, il en résulte fréquemment des silos de clusters DevOps, et par conséquent soit de mauvaises performances (ressources insuffisantes), soit une sous-utilisation des ressources (ressources sous-utilisées en dehors des heures de pointe). Le plus souvent, les deux sont présents : pendant qu'une équipe est confrontée à un déséquilibre entre l'offre et la demande de ressources, d'autres équipes peuvent disposer de nombreuses ressources inutilisées. Pire encore, les équipes surdimensionnent souvent leurs ressources, ce qui engendre des coûts considérables. Les normes du secteur en matière d'utilisation des clusters se situent généralement autour de 20 %.
Consolider les clusters (ou les comptes cloud, d'ailleurs) de plusieurs en moins, idéalement en un seul, et partager les ressources entre les équipes et les cas d'utilisation est la recette pour augmenter les performances et la production tout en réduisant les coûts. La consolidation et le partage vous permettent vraiment de faire plus avec moins - si vous pouvez partager efficacement, automatiquement et équitablement.
Les frameworks d'orchestration de conteneurs actuels, tels que Kubernetes , Docker Swarm ou Mesos, ne permettent pas de réaliser cela nativement. Kubernetes et Swarm proposent des schémas de distribution de charge simplistes, comme « spread » (round-robin), « pack » ou « random », et nécessitent une segmentation manuelle des ressources du cluster via des concepts tels que les espaces de noms ou les étiquettes. Dans Mesos, différents types de charges de travail (par exemple, Spark, Hadoop ou les services Marathon) disposent de leur propre planificateur, qui peut proposer ou non des politiques de partage de ressources (avec sa propre logique et configuration). Cependant, les charges de travail se disputent l'accès aux ressources, sans système de politiques global permettant d'identifier les charges de travail les plus importantes pour l'entreprise et de répondre à leurs besoins sans surcharger les ressources.
Pour les cas d'utilisation de partage de ressources non triviaux, chacun de ces systèmes nécessitera de nombreuses interventions manuelles et nécessitera toujours un surapprovisionnement ou souffrira d'impacts sur les performances causés par des conflits de ressources.
Ce qui est vraiment nécessaire pour pouvoir partager un pool de ressources entre les organisations et les types arbitraires de charges de travail (conteneurisées mais également non conteneurisées) est un système de politique avancé qui comprend les caractéristiques de la charge de travail et les priorités de l'entreprise afin qu'il puisse automatiser la prise de décision sur l'allocation des ressources et réaffecter les ressources à la demande lorsque les conditions aux limites ou les demandes changent.
Navops Command est actuellement un exemple unique de ce type de fonctionnalité. Il enrichit Kubernetes en y ajoutant des politiques sophistiquées, dynamiques et pilotées par la demande, automatisant ainsi la priorisation des charges de travail et la consommation des ressources à tout moment. Comparé aux autres frameworks d'orchestration de conteneurs, Kubernetes offre l'ensemble de fonctionnalités de production le plus complet pour gérer les charges de travail de manière fiable (contrôleurs automatisés pour les réplicas, les tâches, les déploiements, l'admission des charges de travail, etc.). Avec Navops Command sur Kubernetes, vous pouvez exécuter des builds logiciels, des tests automatisés et des déploiements en production de plusieurs applications et environnements de service sur un même cluster ou pool cloud. Les tâches DevOps et les services de production peuvent provenir de différentes équipes et avoir une importance variable au cours de la journée. Navops Command garantit qu'aucune charge de travail n'interfère avec les autres, tout en assurant leur bon fonctionnement.
Image 1 : Politique de commande Navops "Partages proportionnels" automatisant le partage des ressources entre les groupes, les projets et les individus
Avec Navops Command, il est possible d'atteindre des taux d'utilisation des clusters de 80 % et même plus. Il offre ses avantages même au sein d'une seule équipe lorsque vous exécutez diverses tâches telles que la construction, les tests et les opérations, et il offre encore plus d'avantages lorsque vous partagez entre les équipes.
Navops Command illustre les prérequis pour exécuter efficacement des applications basées sur des microservices, ainsi que d'autres charges de travail conteneurisées, dans un environnement partagé (sur site ou dans le cloud). Actuellement disponible pour toute distribution Kubernetes, il peut être facilement évalué comme décrit ici.
A propos de l'auteure
Fritz Ferstl est actuellement CTO et Business Development EMEA chez Univa Corporation.
Fritz Ferstl apporte à Univa 20 ans d'expérience en informatique en grille et en nuage et, en tant que directeur de la technologie, il contribuera à définir une vision technique tout en dirigeant des alliances stratégiques. Fritz, longtemps considéré comme le père du logiciel Grid Engine et de ses précurseurs Codine et GRD, a dirigé l'activité logicielle Grid Engine au sein de Sun Microsystems et d'Oracle au cours des 10 dernières années, la faisant passer d'une technologie pionnière à la solution de gestion de charge de travail la plus largement déployée. dans certains des environnements de centres de données les plus difficiles de la planète. Sous la direction de Fritz, le logiciel Grid Engine était open source et a développé une communauté dynamique.
Amazon