Lors de l’événement KubeCon/CloudNativeCon qui se déroule en ce moment à Copenhague (2-5 mai), Google a annoncé le passage en open source de son outil GVisor pour accroître la sécurité des containers orchestrés par Kubernetes. De son côté CoreOS, fraichement racheté par Red Hat, a poussé auprès de la communauté le SDK Operator permettant de gérer plus efficacement les applicatives natives pour l’orchestrateur de containers.
Brandon Philips, CTO de CoreOS, a annoncé la mise en open source du SDK du framework Operator. (crédit : D.F.)
En direct de Copenhague. Kubernetes, tout comme n’importe quelle technologie, ne pourra pas voir son adoption s’étendre au plus grand nombre sans que la problématique de sécurité soit bien adressée. Bien conscients de cet enjeu, les promoteurs de l’orchestrateur de containers le plus répandu dans le monde (54% de projets initiés d’après la dernière étude menée par la Cloud Native Computing Foundation) l’ont martelé au 2e jour de la conférence KubeCon/CloudNativeCon qui se joue en ce moment dans la capitale danoise.
En plus des dernières briques de sécurité de Kubernetes en version stable (Network Policy 1.7, extension réseau améliorant la sécurité des pods, RBAC 1.8 pour contrôler les accès utilisateur et application aux ressources ou encore PodSecurityPolicy 1.8 pour définir un set de conditions pour permettre à un pod de tourner dans un cluster), la responsable produit groupe Kubernetes et chargée du Kubernetes Engine chez Google, Aparna Sinha, a annoncé la mise en open source de GVisor. Cet outil apporte l’isolation entre des conteneurs pour permettre aux entreprises de sécuriser leurs différents workloads tournant dedans.
Tous les appels système Linux pas encore supportés par GVisor
« GVisor peut être considéré comme un système d’exploitation extrêmement paravirtualisé avec une empreinte de ressources flexible et un coût fixe inférieur à celui d’une machine virtuelle complète. Cependant, cette flexibilité se fait au prix de frais généraux d’appels par système plus élevés et de compatibilité des applications », a précisé Google dans un communiqué. GVisor s’intègre avec Docker et Kubernetes mais s’il ne supporte pas tous les appels système Linux, il devrait fonctionner avec les applications écrites notamment pour Node.js, Java 8, MySQL, Jenkins, Apache, Redis et MongoDB.
Outre la sécurité, des évolutions au niveau des applications ont également été annoncées. A commencer par Cronjobs beta et Spark 1.8 pour planifier des jobs et assurer l’intégration native du moteur big data avec Kubernetes. Avec GPU 1.9, Kubernetes ajoute aussi support pour les circuits graphiques pour accélérer les workloads d’apprentissage machine. « Cela permet d’apporter de l’autoscale GPU pour les workloads d’apprentissage machine », a expliqué Aparna Sinha. « On peut parler aux apps directement en utilisant la nouvelle API Spark et un job applicatif tournant en mode cluster utilisant big query ».
Du « KubyOnRails » pour faciliter le développement d’apps Kubernetes
Google n’est pas le seul à pousser en open source ses outils Kubernetes. C’est également le cas de CoreOS, racheté en janvier par Red Hat, qui a annoncé la disponibilité auprès de la communauté du SDK de son framework Operator. Développé depuis 2016, Operator fournit des outils de développement et de runtime Kubernetes pour aider les développeurs à construire et gérer des applications cloud native.
« Ce que l’on voulait faire c’est apporter aux développeurs une sorte de KubyOnRails pour faciliter le cycle de vie du développement d’applications Kubernetes », a annoncé avec malice Brandon Philips, CTO de CoreOS. Operator Lifecycle Management assure ainsi la supervision, les mises à jour et la gestion du cycle de vie des applications et services associés tournant sur un cluster Kubernetes. Dans les prochains mois, une brique de reporting, Operator Metering, est également attendue.