Guides Essentiels
Voir tous les articles de ce guide
Actualites
Cet article fait partie de notre guide: Kubernetes, la nouvelle infrastructure d’une IT en mode hybride

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

Ce support des containers Windows par l’orchestrateur open source est désormais stable, mais comporte encore quelques limites. Cet article fait le point.

Beth Pariseau
par
Publié le: 27 mars 2019

Cela est certainement la fonctionnalité la plus importante de cette version 1.14 de Kubernetes : le support des containers Windows. Si aujourd’hui cette fonction, initialement prévue pour la version 1.13, débarque dans une version stable, il reste encore du travail pour parvenir à une parité fonctionnelle avec Linux. Là où est finalement né cet orchestrateur devenu aujourd’hui la référence.

Toutefois, pour les responsables en charge des développements de Kubernetes, les plus aguerris aux Windows Server Containers ont de quoi satisfaire leurs ambitions en production. Même si pour l’heure, ce support des containers Windows ne s’étend qu'aux nœuds workers.
Les nœuds leaders ou maîtres de Kubernetes doivent quant à eux toujours fonctionner sur Linux.

Kubernetes 1.14 ne prend également en charge que les hôtes et containers Windows qui s'exécutent sur Windows Server 2019 – et seulement. En clair, ces fonctionnalités ne seront pas utilisées en production par les DSI qui généralement n’ont pas la dernière version installée de l’OS. Autre limite : l’OS hôte doit faire correspondre le système d'exploitation des containers avec les nœuds Windows, ce qui signifie qu’on ne pourra pas encore utiliser cela pour gérer le legacy.

Conséquence : avec la gestion des privilèges système de Windows, les containers privilégiés ne sont pas pris en charge sur les hôtes Windows. Certaines fonctions d'auto-remédiation de Kubernetes, telles que le détecteur d’incidents au niveau du noeud et la suppression de processus, ne sont pas disponibles pour Windows. De même, les nœuds Windows ne supportent pas les systèmes de fichiers en lecture seule.

Pour l'heure, héberger Kubernetes sur Microsoft Azure est le seul moyen sûr pour les entreprises ayant Windows de containeriser leurs applications, et le support de Kubernetes pour Windows n'est pas suffisant pour changer cela, affirment certains experts IT.

« Cela en limite l'adoption dans certains environnements comme les départements de taille réduite par exemple, qui ont tendance à être 100 % Windows », souligne Chris Riley, directeur DevOps chez CPrime , une société de conseil en développement Agile. « Il n'y a pas de marché énorme pour des configurations masters Linux / workers Windows, donc c'est la première étape du déploiement. »

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.

Pour approfondir sur Open Source