Kubernetes 1.14 : au-delà de Linux, bienvenue aux containers Windows

Les limites de Kubernetes pour Windows laissent Docker dans le pétrin

Docker Enterprise 18.09, sorti en novembre 2018, supporte lui-aussi Kubernetes pour Windows, et Docker entend combler certaines lacunes de Kubernetes pour Windows dans la prochaine version de Docker Enterprise, prévue pour avril 2019. Le support d'Active Directory via les Group Managed Service Accounts, qui sont sortis en alpha dans la version 1.14, est par exemple prévu.

Chez certains, cela fait naître l'espoir qu'un éloignement de Docker Swarm pour les hôtes Windows sera bientôt viable. « Nous continuons à faire des tests sur la stabilité de Swam, mais nous pensons que Kubernetes sera beaucoup mieux », commente à son tour Richard Fong, directeur de l'ingénierie logicielle chez Mitchell International, une compagnie d'assurance automobile. « Nous voulons aussi nous en tenir à une plateforme d'orchestration de conteneurs au lieu d’en supporter deux. »

L'année dernière, l'entreprise a connu une panne de deux heures due à un master Swarm défaillant. Un algorithme de quorum a élu un nouveau nœud maître et a déplacé les workloads des containers Linux vers EC2. L'entreprise a toujours des applications Windows. Pour le responsable, ce support interchangeable entre Swarm et Kubernetes dans Docker Enterprise facilitera la transition vers Kubernetes lorsque le moment viendra.

« Nous avons de nombreux clients qui utilisent Docker Enterprise avec Windows et Swarm et qui n'ont pas rencontré ce problème. Nous nous réjouissons également du support étendu de Kubernetes car nos clients Docker Enterprise ont le choix d'utiliser l'un ou l'autre orchestrateur », déclare quant à lui un porte-parole de Docker.

Une 1.14 plus sécurisée

La sécurité des containers reste une préoccupation majeure si on veut placer Kubernetes en production. Le marché a connu une crise lorsque les chercheurs ont révélé une vulnérabilité qui a affecté tous les runtimes des containers. Avec cette faille, un attaquant pourrait exécuter du code au niveau racine sur l'hôte du container et potentiellement contrôler le reste de l'infrastructure. Les risques étaient certes limités pour les entreprises avec de bonnes mesures de sécurité, mais  le rapport d'un fournisseur de sécurité IT a montré que cette vulnérabilité compromettait tout de même des centaines d'hôtes Docker.

Kubernetes 1.14 supprime justement la découverte des API  qui, par défaut, permettent un accès non authentifié. Cela limite la capacité des attaquants à exploiter la vulnérabilité.

Mais les mises à jour de l'API n'éliminent pas complètement la vulnérabilité. Il est toujours nécessaire de sécuriser correctement les environnements Kubernetes. Cependant, tout ce qui peut être fait en amont pour renforcer la sécurité par défaut est important, de l'avis de Chris Riley.

« La simplicité du déploiement en matière de sécurité et celle côté réseau auront plus d'importance que toute autre caractéristique - plus la communauté peut se concentrer là-dessus, mieux c'est », rappelle-t-il. « C'est particulièrement vrai dans les cas où l'hôte peut commencer à causer des dommages importants à l'infrastructure. »

Le stockage persistant pour les applications stateful

Le support des volumes de stockage persistants en local est l’autre ajout clé de cette version 1.14.

« Nous avons de plus en plus besoin de serveurs bare-metal, et nous ré-utilisons le matériel que nous avons déjà », témoigne Matthew Esser, en charge de l'infrastructure de containers chez Viasat Inc, une société de télécommunications par satellite. L'entreprise orchestre ses serveurs virtuels avec OpenStack, qui nécessite un matériel identique entre les hôtes, mais le matériel ré-utilisé ne peut fonctionner que s'il est utilisé sans hyperviseur.

Ces volumes de stockage persistants en local seront également clés pour Kubernetes pour des cas d’usage liés à l’Edge Computing où les systèmes de stockage externes sont peu pratiques, souligne encore Chris Riley.