GP - Fotolia
Roadmap : Kubernetes met l’accent sur la sécurité des conteneurs et sur la simplicité d'exploitation
La version 1.6 de l’outil d’orchestration de conteneurs libre Kubernetes apporte plusieurs améliorations en matière de sécurité afin de rivaliser avec Docher Swarm. À plus long terme, Kubernetes prévoit aussi de simplifier la configuration et les mises à jour de l'outil en production.
La version 1.6 de Kubernetes, qui fera ses débuts le 22 mars, apporte le support par défaut de la gestion des accès à base de rôles (RBAC ou Role Based Access Control) pour la gestion des infrastructures conteneurisées. Cet ajout répond non seulement aux préoccupations de sécurité, qui bloquent aujourd’hui le déploiement à grande échelle des conteneurs dans certains environnements de production d’entreprises, mais permet aussi à Kubernetes de faire jeu égal en la matière avec Docker Swarm, la technologie d’orchestration développée par Docker (Docker Swarm supporte la gestion des rôles et l’intégration avec les annuaires LDAP et AD).
« C’est certainement une version plus sûre », explique Joe Beda, le CTO d’Heptio et créateur de Kubernetes. Heptio est une start-up fondée par plusieurs anciens de Google, dont l’objectif est d’accélérer l’adoption de Kubernetes en entreprise. « Nous avons verrouillé tous les systèmes non sécurisés sur l’ensemble de la plate-forme, de telle sorte que, même si vous avez accès au nœud maître, vous devez avoir les bonnes autorisations et les clés adéquates pour pouvoir exécuter et modifier des choses ».
Jusqu’alors, la gestion des contrôles d’accès à base de rôles était mise en œuvre de manière inégale dans les différents modules qui composent Kubernetes, de sorte qu’une meilleure intégration est une bonne nouvelle pour les clients. « La gestion par rôle n’était pas particulièrement simple ou bien documentée auparavant, mais la version 1.6 l’active par défaut, ce qui est un énorme avantage », indique Rob Scott, le vice-président de l’architecture logicielle chez Spire Labs.
Les utilisateurs de Kubernetes cherchent à simplifier leur exploitation
Les utilisateurs de Kubernetes ont des retours d’expériences très variés sur l’installation et les mises à niveau de Kubernetes dans les environnements de cloud public.
En fait, il y a presque autant de façons de créer des clusters Kubernetes qu’il y a de déploiements dans le monde. Les acteurs de l’écosystème OpenStack, tels que Mirantis, apportent leurs méthodes d’installation au projet, et il en va de même pour des PaaS comme OpenShift de Red Hat. Platform9 propose sa plate-forme SaaS de configuration pour simplifier le déploiement d’environnements Kubernetes en mode managé. D’autres utilisateurs choisissent d’y aller seuls avec des outils open source, tels que Kubernetes Operations (kops), des outils de gestion de configuration, comme Ansible ou des outils de provisioning d’infrastructures, comme Terraform de HashiCorp.
Kops confère un avantage dans les environnements Amazon Web Services (AWS), explique Scott. Kops rend plus simple et plus abordable la configuration d’architectures Kubernetes à haute disponibilité s’appuyant sur plusieurs zones de disponibilité Amazon. Cela a protégé Spire de la récente défaillance d’Amazon S3, qui a affecté une grande partie du Web.
Mais, il ya un prix à payer pour ces bénéfices. Selon Scott, les mises à jour de Kubernetes avec kops peuvent être un défi, et passer outre ces mises à niveau peut exposer à des failles de sécurité.
« Une de nos frustrations avec Kubernetes — et je ne pense pas que nous soyons un cas particulier — est qu’il peut être difficile à mettre à jour », a déclaré Scott. « Il y a plusieurs personnes qui essaient de s’attaquer à ce problème [dans la feuille de route de Kubernetes], mais, pour l’instant, c’est encore un point douloureux. »
Par exemple, l’équipe informatique de Spire consacre beaucoup de temps à surveiller les vulnérabilités et les expositions courantes et à s’assurer que les systèmes Kubernetes sont bien à jour avec l’ensemble des correctifs. Une version récente de kops permet des mises à niveau automatisées des images serveur, même si cela ne protège pas de toutes les vulnérabilités, explique toutefois Scott.
« La dernière fois que nous avons fait une montée de version, nous avons simplement instancié de nouveaux clusters — nous n’avons même pas essayé de mettre à jour nos clusters en place », a-t-il dit. « Cela s’est en fait déroulé de façon relativement indolore, mais il faut tout de même provisioner la nouvelle infrastructure, et cela a pris quelques jours. Si c’est l’une des meilleures façons de mettre à jour votre système, ce n’est pas génial. »
La feuille de route Kubernetes s’attaque aux problèmes de configuration et cherche à simplifier les mises à niveau des clusters
Une solution pour les problèmes de mise à niveau fait l’objet de discussion entre les développeurs Kubernetes. Il s’agit de l’utilitaire baptisé kubeadm, qui a été créé sous les auspices d’un groupe d’intérêt spécial Kubernetes, appelé sig-cluster-lifecycle. Pour faire court, kubeadm à l’ambition d’apporter les bénéfices de kops à un éventail plus large d’environnements Kubernetes en dehors d’Amazon AWS.
« Parce que kops part de l’hypothèse qu’il fonctionne dans AWS, il y a certaines dépendances qui le rendent plus facile à lancer et à opérer [dans AWS] », indique Joe Beda. Kops assume qu’il a accès à un référentiel de fichiers de configuration sur S3, par exemple. Kubeadm vise à rendre l’expérience de configuration kops portable entre les grands clouds et datacenters « on-premises », et ce en éliminant les dépendances à des services AWS spécifiques.
Un article de janvier sur le blog de Kubernetes décrivait les objectifs de kubeadm pour la version1.6 de Kubernetes 1.6, y compris un nouveau processus de configuration modulaire plus facile à gérer et plus transparent pour l’utilisateur — une fonctionnalité que les utilisateurs estiment cruellement nécessaire.
« Le danger avec des outils comme celui-ci est que quand ils cassent, ils sont une sorte de boîte noire. S’il y a un échec et que vous ne savez pas ce qu’ils font, vous n’avez vraiment aucun moyen de retomber sur vos pieds », note toutefois Cole Calistra, le CTO de Kairos AR, une société qui conçoit des solutions de reconnaissance faciale et des algorithmes d’analyse pour les développeurs. Calistra a fait le choix d’utiliser Ansible et Terraform pour installer et configurer ses hôtes Kubernetes.
Selon Joe Beda, de nombreux objectifs définis pour kubeadm décrits dans le billet de blog restent néanmoins sur la feuille de route de Kubernetes. La possibilité d’invoquer les différentes phases de kubeadm séparément, par exemple, est en version alpha actuellement. « La gestion des mises à niveau est encore plus manuelle que ce que nous voudrions qu’elle soit », indique Beda.
Un autre point à l’ordre du jour des futures versions est la possibilité pour kubeadm d’effectuer des montées de version non disruptives en une simple opération. Jusqu’à présent, Heptio, Weaveworks et Apprenda ont été les principaux contributeurs à kubeadm.
À plus long terme, la feuille de route de Kubernetes, prévoit aussi un support plus modulaire pour les infrastructures de fournisseur de nuage public. Actuellement, ce support doit être intégré dans le dépôt de code maître de Kubernetes, ce qui crée un processus excessivement complexe et long pour supporter de nouveaux nuages. Le support de plug-ins modulaires pour chaque cloud est prévu pour la version 1.9, mais l’inclusion dépendra des discussions en cours dans la communauté open source, a indiqué Beda.
« Les délais dans les projets open source sont une chose difficile », explique-t-il. « Nous allons voir qui va réellement rouler ses manches et délivrer du code. »
