Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Ces derniers mois, j’ai beaucoup joué avec le couple Windows Server + Linux afin de voir jusqu’où un développeur pouvait aller en 2020. Je n’ai pas été dessus. On est bien loin de ce que l’on pouvait faire en 1998 (date de mes premiers pas avec Linux).

Aujourd’hui, je vous propose un petit retour de ce qu’il est possible de faire avec Kubernetes (v1.18.2) pour faire persister des conteneurs sur Windows Server.

Mon Lab de tests Hyper-V est constitué de deux hôtes et des VM suivantes :

• 2 Master Kubernetes (Kubic, 2 CPU et 3Gb de RAM chacun)
• 2 Nodes Kubernetes (Kubic, 4 CPU et 8Gb de RAM chacun)
• 2 Load balancer (OpenSuse, 2 CPU et 1Gb de RAM chacun)
• 1 Serveur de fichier Windows (Windows 2019, 2 CPU et 2Gb de RAM), NFS et SMB sur NTFS et ReFS.
• 1 Serveur de fichier Linux (OpenSuse, 2 CPU et 2Gb de RAM) NFS sur BTRFS.

Toutes les applications, et OS sont utilisés dans leurs dernières versions (patch compris).

Le serveur de fichier Linux a été monté pour confirmer les tests effectués avec le serveur Windows. Les VM Linux font partie du même domaine Active Directory que le serveur de fichier Windows.

Est-ce que cela fonctionne ?

Allons directement au but. Oui, on peut utiliser Windows Server comme serveur de fichier pour la persistance de volumes avec Kubernetes. On peut le faire en utilisant SMB ou NFS. Les deux fonctionnent très bien.

Je n’ai pas trouvé de cas où le serveur Windows dégradait les performances par rapport au serveur Linux. Bien évidemment, je n’ai pas joué avec des outils de tests théoriques. Je voulais voir le comportement du cluster sur des cas de la vie courante. J’ai joué avec des sites web (codes .net core personnels) et des applications courantes sur Kubernetes (NextCloud, Nginx, MySQL, Mariadb, PostgreSQL, PiHole, Harbor…). Je les ai utilisés et j’ai effectué quelques tests de montée en charge avec Visual Studio.

Le ressenti était bon et les tests de montée en charge ne m’ont pas permis de faire de différences entre Windows Server et Linux.

Petite exception : j’ai trouvé SMB pouvait être plus performant avec un conteneur NextCloud. (Constaté lors de la première utilisation, au moment où NextCloud doit créer beaucoup de petits fichiers). Avec NFS sur Windows Server, NextCloud est d’une lenteur sans nom.

Cela fonctionne pour toutes les applications ?

Non, malheureusement. Il y a des applications qui refuseront de fonctionner du premier coup. Il y a aussi des applications qui ne fonctionneront jamais.

Ces problèmes ne sont pas liés à Windows Server, NFS, SMB, ReFS ou NTFS. Ce sont juste des applications qui veulent appliquer des droits sur les volumes (changement de propriétaire, changement de droits de lecture et d'écriture…). Ces applications voudraient retirer tous droits au serveur qui partage les volumes… "No comments !?"

Ces applications fonctionnent à l’ancienne. À mon sens, ces applications ont raté le coche de la modernisation et raté leur conteneurisation.

Dites à votre administrateur système que votre application va prendre les pleins pouvoirs sur son serveur de fichier. Il va faire des bonds.

Particularité du NFS sous Windows Server

Pour ne pas avoir de problèmes, il faut configurer Windows Server pour autoriser les clients NFS à changer le propriétaire de la racine (avez-vous vraiment envie de faire cela ?).

Avec un serveur NFS Linux, il faut faire la même chose. Il n’y a donc aucune différence entre les deux OS.

Cependant, certaines applications comme PostgreSQL ne fonctionneront toujours pas avec les volumes exposés via NFS et Windows Server (PostgreSQL semble ne pas aimer les systèmes de fichiers de Microsoft, même quand ils sont montés via NFS).

Particularité du SMB sous Windows Server

Microsoft a bien travaillé son driver FlexVolume pour SMB, il permet de contourner une partie du problème :

• Il retourne des réponses positives aux commandes chown.
• Il peut spécifier un id d’utilisateur et un id de groupe propriétaire du volume
• Il peut retourner de fausses informations sur les droits de lecture, écriture et exécution.

Pour chaque application, il faut donc jouer les spéléologues dans les conteneurs pour connaitre la configuration qui fonctionne bien. On est très loin des concepts de modernisation et d’abstraction promis par la mise en conteneur.

À mon sens, le jeu n’en vaut pas la chandelle. Il est plus simple d’utiliser un serveur NFS Linux. Les responsables de votre infrastructure ne seront pas très joyeux de constater les actions entreprises par ces conteneurs. Mais la mise en œuvre sera moins compliquée.

Quand doit-on utiliser Windows Server ?

Pour persister des conteneurs dont vous maitrisez le code :

• Si vous avez un environnement qui comprend déjà des serveurs de fichier Windows, autant les utiliser.
• Si vous avez des serveurs NFS sous Linux, inutiles d’installer un Windows Server, vous n’avez rien à y gagner.

Pour persister des conteneurs dont vous ne maitrisez pas le code :

• Utilisez un serveur Linux, car certains développeurs ne semblent pas avoir modernisé leurs applications et gèrent leurs images comme des serveurs classiques (à grand renfort de bash, chown, chmod).

Conclusion

Un développeur peut faire de très belles choses avec Windows Server, Linux et Kubernetes.

En ce qui concerne l’interopérabilité, j’en suis arrivé à une conclusion mi-figue, mi-raisin :

• Microsoft a démontré un très bon niveau d’ouverture qui lui permet d’offrir des solutions vraiment interopérables (le niveau de tuning du service NFS est surprenant).
• Côté Linux, il y a des applications qui manquent d’ouverture et de modernité (changement de droits sur les volumes, obligation de réduire le niveau de sécurité des serveurs NFS, manque de documentation des applications conteneurisées concernant ces besoins). J’espère que cela va changer, car cela ajoute une charge de travail supplémentaire.

Avec un serveur NFS Linux, certaines applications (ex : Harbor, Redis, Trivy), ont besoin que l’on joue du chown pour affecter manuellement les id d’utilisateur et de groupe qui sont utilisés dans les containers.