Comme dit précédemment, j'ai cassé l'écran de mon Latitude E5540 de 2013. J'ai commandé une dalle de rechange mais elle tarde à arriver et on ne peut jamais être certain de la qualité du produit étant donné qu'il ne s'agit pas d'une pièce officielle. Par exemple ma dernière dalle avait des angles d'affichage immondes. Je me suis donc posé la question de simplement acheter un nouveau PC portable, et c'est ce que j'ai fait.
Mes critères étaient les suivants :
Choisir un modèle dans une gamme professionnelle, j'ai plus confiance au niveau durabilité même si le prix peut être multiplié par deux.
Pas de GPU, ni AMD ni Nvidia. Je ne veux pas avoir à gérer Optimus et compagnie, ou avoir à traiter avec des drivers propriétaires sous Linux. De plus je ne compte pas jouer.
Écran 15,6 pouces minimum avec un grand angle d'affichage, si possible en technologie IPS.
Clavier rétro éclairé + pavé numérique.
Processeur 4c/8t, mémoire >= 8 GB, SSD >= 256 GB.
Des clic touchpad souples (oui c'est con mais je déteste les "clic clic" ou "tic tic" à répétition).
Une batterie de bonne capacité (assez difficile à estimer mais bon).
Une connectique standard car beaucoup de modèles n'ont pas de RJ45. J'en ai besoin.
Budget max €1000.
Après avoir tenu un comparatif de plusieurs modèles incluant Dell, HP et Lenovo (les Thinkpad), je suis finalement parti un Dell Latitude 5500 BTX pour ~€1000, je reste donc fidèle à la marque.
Le bazar
S'il y a une chose dont il faut parler, c'est du bazar absolu que sont les catalogues des constructeurs. Difficile de s'y retrouver quand la même machine existe en plusieurs versions et que les différences se situent dans les détails techniques. Dell fait fort avec parfois une dizaine de variantes du même modèle qui ont les mêmes caractéristiques mais pas les mêmes options. C'est le bordel absolu.
L'autre point qui m'a particulièrement agacé chez Dell est l'impossibilité d'obtenir des photo contractuelles des machines. Sur leur site il n'y a que des illustrations utilisées pour toute la gamme, et elles ne sont pas d'une grande utilité. Idem dans les manuels téléchargeables. Heureusement on peut en trouver chez les revendeurs (la photo que j'ai mis vient de LDLC) ou sur Youtube lorsque des tests ou des unboxing sont disponibles. J'avais besoin des photo pour voir à quoi ressemble le touchpad, et ce fut difficile à trouver.
La machine
Caractéristiques techniques:
Intel Core i5-8365U (4c/8t, de 1,6 à 4,1 GHz).
iGP Intel UHD 620.
8 GB DDR4.
SSD NVMe 256 GB.
15,6" 1920x1080 "grand angle", mat.
Clavier rétro éclairé.
Batterie 4 cellules, 68 Wh.
Oui, du Core i5. À une époque j'aurais exigé du Core i7 mais depuis qu'AMD écrase tout avec ses Ryzen, Intel a rendu ses i5 plus intéressants. On a bien 4 cœurs avec hyperthreading (donc 8 threads) mais avec des fréquences légèrement inférieures au Core i7 et un cache L3 moins important (6 MB au lieu de 8 MB). Cependant je suis prêt à sacrifier 10% de performances si ça me permet d'économiser €150, dans tous les cas le CPU est overkill pour mes besoins (loisirs et développement avec des langages qui n'ont pas besoin de compilation).
Sans aller jusqu'à dire que c'était un critère de sélection, j'aime le look sobre de la machine. Pas d’aluminium brossé, pas de sacrifice du port RJ45, pas d'excentricités. Le seul point notable est l'absence de lecteur DVD, mais on est en 2020 et personnellement je n'en ai pas besoin.
J'ai fait ma commande le Jeudi soir, la machine a été expédié le Lundi, et je l'ai reçue le Mercredi, livrée par UPS.
Le chargement se fait via le port USB-C, ce que j'ai trouvé surprenant au début, mais pourquoi pas. Si cela permet d'aller vers une unification des chargeurs alors c'est une bonne chose. Autre surprise: les boutons Function (par exemple pour augmenter le son ou la luminosité) sont par défaut prioritaires sur les touches F1-F12. Autrement dit, si on appuie sur F2, on baisse le son. Si on veut vraiment "F2", alors il faut faire FN+F2. Ce comportement est modifiable avec Fn + ESC, heureusement. Le rétro éclairage du clavier peut être désactivé ou diminué.
L'écran est plutôt bon et les angles sont corrects, bien moins fatigant pour les yeux que mon ancienne machine. Je ne saurais dire s'il s'agit d'une dalle IPS, l'information n'était pas donnée. Le son n'est pas trop mauvais, ce n'est pas de la "haute qualité" comme affiché sur le site de Dell, ça reste un PC portable.
Dans l'ensemble la machine est satisfaisante, très légère, très sobre, bien construite, mis à part l'autonomie batterie qui n'a rien d'exceptionnel et dont je vais reparler un peu plus loin.
Debian
Pas de Bios sur cette machine, uniquement UEFI (avec ou sans secure boot). Heureusement cela ne pose pas de problèmes à Debian qui s'installe sans broncher, avec le réseau en RJ45 car la carte Wifi a besoin d'un firmware propriétaire non inclus (on l'ajoute plus tard avec le paquet firmware-iwlwifi des dépôts non-free).
Je note avec amusement que l'installeur de Debian propose par défaut MATE alors que j'ai toujours pensé que c'était GNOME 3. Tant mieux. Par contre mauvaise surprise, le compositeur par défaut fourni avec MATE est désormais Compiz, et ça c'est pas cool. Déjà parce que j'ai passé l'âge des effets graphiques inutiles, mais aussi et surtout parce qu'il me provoque des bugs (freezes de plusieurs secondes) ou des désagréments, par exemple je ne peux plus agripper le bord d'une fenêtre en faisant ALT + clic droit. En installant le paquet mate-tweak
j'ai pu remettre le compositeur par défaut, Marco, beaucoup plus fiable.
Pour faire fonctionner le Wifi, j'ai du ajouter les dépôts non-free et installer le paquet firmware-iwlwifi. Et c'est tout, le reste fonctionne out-the-box, même pas besoin du kernel des backports même si la machine est récente. L'autonomie batterie pourrait peut-être être améliorée avec un noyau plus à jour mais je n'ai pas encore essayé.
La batterie, parlons-en. Après 2 heures d'utilisation je tombe à 60%, ce qui donne (avec une règle de trois) une autonomie théorique de 5 heures. J'ai connu l'époque pas si lointaine où les PC portables avaient une autonomie standard de 1h30, et les plus économiques tiraient jusqu'à 3 heures. Donc en soit, c'est 5 heures c'est bien. Néanmoins mon E5540 avait une batterie 9 cellules qui tenait bien plus longtemps alors qu'elle va sur ses 7 ans. Je ne peux m'empêcher d'être un peu déçu surtout qu'il n'y a pas de GPU à alimenter. Mais ce n'est pas si grave.
Au niveau des performances, rien à redire. Le SSD en NVMe fait le boulot et les chargements sont instantanés. Mes petites machines virtuelles exploitent bien les 8 cœurs du CPU et ça dépote. Côté accélération graphique, je n'ai lancé que Stellarium pour l'instant et il cape à 60 fps donc tout va bien. Cet ordinateur offre un support exemplaire de Linux.
En résumé
Points positifs:
Les performances, le Core-i5 fait le taf et le SSD en NVMe est au top.
Le look sobre, le poids limité, la connectique.
Les angles de vue convenables pour l'écran.
Le son convenable pour un notebook.
Fonctionne parfaitement sous Linux Debian.
Points négatifs:
Autonomie batterie correcte (5 heures en théorie) mais moins bien que mon E5540.
Pas de touches multimédia (play/stop, previous, next).
Il faut démonter pour enlever la batterie.
Le prix ? Un peu cher mais c'est une gamme pro (intervention sur site en cas de problèmes). Et puis il faut relativiser, c'est moins de 50% du prix d'un Mac book pro.
J'attends quelques semaines avant d'apposer mon tampon "Utux approves" mais pour l'instant c'est bien parti.
EDIT: Je rencontre un bug étrange. Lors du démarrage, si la batterie est faible, le chargement se fige sur l'initramfs, juste après le grub. Pour pouvoir démarrer il faut soit ajouter acpi=off, soit brancher le chargeur. Peut-être qu'une mise à jour du bios réglera ce souci.
EDIT2: La mise à jour du firmware UEFI a bien résolu le problème de démarrage sur batterie.
EDIT3: Correction du nom, c'est bien le Latitude 5500 et pas E5500 (qui se réfère à une ancienne gamme).
Encore une fois, j'ai cassé l'écran de mon DELL Latitude E5540, ma machine principale pour internet, les loisirs, et le codage perso. En attendant de recevoir une dalle de rechange, j'improvise. J'utilise beaucoup mon rig de gaming avec une machine virtuelle Linux, mais je perds l'aspect mobilité. J'ai donc fouillé dans mes placards et trouvé un vieil Acer Aspire 3023 WLMI, une machine de 2005 équipée d'un AMD Sempron monocoeur, 512 MB de RAM, une ATI X700, et un HDD de 100 GB. Il est prévu pour fonctionner sous Windows XP.
Oui, c'est bien une de ces horreurs bas de gamme qui ont pullulé à une époque où Acer s'est rendu compte qu'il suffisait de vendre des machines à bas prix peu importe la qualité afin d'inonder le marché, c'est ce que toutes les marques font aujourd'hui d'ailleurs. Dans mon esprit la gamme Aspire c'est avant tout des charnières qui finissent par lâcher, ce qui est le cas pour le 3023 WLMI en ma possession. De plus les processeurs Sempron n'était pas réputés pour leur vélocité, ils servaient principalement de réponse aux Celeron de Intel, c'est à dire pour meubler l'entrée de gamme au prix le plus bas possible quitte à plomber la machine avec des performances misérables même pour l'époque.
Pour la petite histoire, mon tout premier notebook était un Acer Aspire 5022 WLMI avec un AMD Turion ML-30 à 1,6 GHz , 1GB de RAM, une carte graphique ATI X700. Pendant un certain temps il fut ma machine de gaming principale, c'est fou, je pouvais jouer à Half Life 2 en graphismes Max en 1280x800, bien avant que le moteur Source ne soit mis à jour bien entendu. La machine chauffait tellement que je ne pouvait pas poser mes poignets à nu dessus et la ventilation faisait le bruit d'une turbine. Et bien entendu, les charnières ont fini par lâcher. Concernant Linux, c'était à l'époque des pilotes ATI misérables, les fameux fglrx instables au possible, les choses ont bien changé aujourd'hui. Pour le wifi il fallait utiliser ndiswrapper + un driver à compiler pour faire fonctionner le petit bouton on/off (acerhk ou aceracpi).
Pour en revenir au Acer Aspire 3023 WLMI sorti de mon placard, j'ai installé Debian Buster. C'est long, très long, la faute au disque dur mécanique qui a du mal à suivre. Il faut également veiller à utiliser une version i386 car le processeur ne supporte pas le 64-bit. Pour l'environnement de bureau j'ai sélectionné Mate, et oui à l'époque on pouvait utiliser GNOME2 sur ce type de machine donc pourquoi pas. Et il faut reconnaître que tout fonctionne out-the-box, surtout l'accélération graphique et le WiFi, c'est gros progrès par rapport à l'époque. Par contre ça rame... ça rame beaucoup. Rien qu'installer un paquet prend énormément de temps, et Firefox est à peine utilisable sans faire planter la machine. La lenteur générale est due aux faibles performances du disque mécanique et les blocages sont liés à la mémoire insuffisante. Pour lancer Firefox et aller sur le web de nos jours il faut au minimum 1,5 GB de RAM. Inutile de dire qu'avec 512 MB ça swap direct, et sur un disque mécanique arthritique, c'est la mort. Vous allez sûrement me dire en commentaires que j'aurais du utiliser Xfce ou LXDE, des environnements plus légers. Cela ne change rien. Peu importe l'environnement, à partir du moment où on ouvre un navigateur web, la mémoire explose. Ce type de machine est simplement obsolète pour le Web aujourd'hui.
Pour le défi, j'ai commandé un kit 2x1 GB de DDR sur eBay. On va voir si avec 2GB de RAM la machine est utilisable pour quelque chose. Je doute cependant que Firefox soit capable de lire une vidéo Youtube. A bientôt pour de nouvelles aventures.
Le stage a commencé début Mars. J'avais prévu une première semaine légère consacrée à la familiarisation avec l'environnement et les outils. J'ai passé un peu de temps à expliquer le principe de fonctionnement d'Azure avec par exemple la hiérarchisation des ressources (Tenants, Subscriptions, Resource groups...) puis lui ai confié des "travaux pratiques" à réaliser en sandbox dans le seul but de lui faire mettre les mains dans le cambouis. Il s'agissait par exemple d'installer un Wordpress 100% PaaS à l'aide des App Services et Azure Databases for MySQL. Ensuite, la même chose avec AWS.
J'ai été surpris par la rapidité avec laquelle il a accompli ces exercices. Le bougre est plutôt bon techniquement et autonome, au point que j'ai pu lui confier plus tôt que prévu des "vraies" tâches reliées à des projets de l'entreprise. J'avais notamment mis de côté un projet d'externalisation des logs du Cloud vers une stack Elastic, et c'était parfait car il y avait suffisamment de matière pour l'occuper alors que je devais partir en congés.
Mon retour de congés a eu lieu la semaine 12, c'est à dire au moment où le confinement a été annoncé. Je me souviens du Lundi où l'ambiance était apocalyptique, les rumeurs circulaient dans l'entreprise et dans certaines équipes les gens avaient déjà été renvoyés chez eux. Et la nouvelle est tombée l'après-midi, notre manager nous a réunit pour nous annoncer 45 jours de télétravail. Le stage a alors pris une tournure inattendue car tout allait devoir être fait 100% en remote. Heureusement l'entreprise était déjà habituée au télétravail et tous les outils étaient déjà là.
Le travail à distance n'a pas changé grand chose au stage, nous communiquons principalement par Mattermost et faisons des conférences vocales via Teams. Ce qui semble moins évident en revanche c'est l'intégration dans l'équipe. Dans le bureau tout se passait bien et mon stagiaire participait aux batailles de Nerf avec les collègues. Mais dans Mattermost et Teams il est plus discret, ce qui est dommage.
L'épisode 4 parlera du sujet de stage qui a débuté en retard.
J'ai bien aimé Doom 2016, un jeu bien bourrin offrant des mécaniques proches de celles des fps à l'ancienne, servi avec une ost Metal presque parfaite. Aujourd'hui nous sommes en 2020 et sa suite Doom Eternal est sortie. Le titre est bien trouvé, Doom est en effet éternel et tout comme Star Wars il transcende les générations.
L'éditeur Bethesda a orienté la communication du jeu sur le personnage principal: le Doom guy (appelé ici Doom Slayer) qui est totalement bourrin et qui met les pieds où il veut, surtout dans la gueule des démons. Aussi fort que Chuck Norris, il compte bien sauver le monde à lui tout seul en exterminant tout l'enfer sur son chemin. Le message est clair, pas question de réfléchir ou de faire dans la subtilité, on va user d'un arsenal démesuré pour poutrer les méchants. Il faut ajouter à cela l'OST monumentale de Mick Gordon qui revient pour nous prouver que Doom est la symbiose du jeu vidéo et du Metal. On espère donc que le jeu est à la hauteur des promesses de la communication de Bestheda.
J'ai donc acheté Doom Eternal et fait exploser ma fibre optique pour le télécharger. Comme vous pouvez le voir, l'internet français n'est pas si saturé que cela, à moins que les FAI fassent de la QoS pour nous permettre de télécharger Doom à pleine vitesse, ce qui serait vraiment royal :
La technique
S'il y a un point sur lequel Doom Eternal fait un sans-faute, c'est la technique. Les graphismes sont très réussis et le jeu est extrêmement fluide sur à peu près toutes les configurations. Par exemple ma GTX 1070 qui date de 2017 le supporte en 2560x1440 Ultra sans broncher. Le jeu est une vitrine technologique pour l'api Vulkan et frappe un grand coup. Si on ajoute à cela les temps de chargement qui se comptent en secondes, on a probablement affaire à l'un des jeux AAA les mieux optimisés de tous les temps. C'est dit.
Le gameplay
Doom Eternal mérite clairement son succès. Les développeurs du jeu se sont vraiment demandé comment améliorer les mécaniques de fps à l'ancienne sans en renier les fondements. Et pour cela ils ont rendu le jeu beaucoup plus nerveux (encore) et ajouté de nombreux moyens d'éliminer les ceux qui se dressent sur notre chemin. D'une part les ennemis et leurs projectiles sont plus rapides, ce qui fait que vous allez subir beaucoup de dégâts même en strafant, et d'autre part les item à ramasser sont beaucoup plus rares. Pour survivre il faut donc aller tuer les monstres au corps à corps, ce qui génère des bonus. Je n'en suis qu'à 2h de jeu mais il y a déjà :
Les glorykill qui donnent des points de vie.
La tronçonneuse qui donne des munitions.
Le lance-flammes qui donne de l'armure.
Cette incitation à aller au corps à corps est à double tranchant, elle rend indéniablement le jeu plus violent et plus technique, mais elle peut être frustrante parce qu'on ne peut plus se contenter de tirer en continu avec le Gatling Gun sans se poser de question, les munitions sont trop rares. J'ai eu beaucoup de mal à m'y faire.
Ces ajouts de mécaniques de gameplay peuvent aussi être déroutants au début du jeu car il y a beaucoup beaucoup de choses et elles arrivent trop vite. En 2h de jeu j'ai déjà : les glorykill, tronçonneuse, lance-flammes, tirs secondaires, améliorations d'armes, améliorations d'armure praetor, les cellules sentinelle, la frappe sanglante, le dash, le ralenti, les portes du Slayer... j'ai souvent eu envie de crier stop !!!
Un autre ajout important est l'agilité de votre personnage. Il est maintenant possible d'escalader les murs et d'utiliser des barres d'acrobate et les dashs pour aller plus loin. Le jeu tire pleinement parti des 3 dimensions, peut-être parfois à l'extrême avec des phases de plateforme/puzzle qui cassent le rythme et peuvent être frustrantes.
En parlant de casser le rythme, le jeu dispose maintenant d'un hub, c'est à dire que le Doom Slayer a une base qu'il rejoint entre chaque mission, et qui permet de visualiser les secrets collectés, s’entraîner, débloquer des améliorations, lancer les missions. Je ne suis pas du tout fan du hub, je ne comprends pas pourquoi le jeu n'enchaîne tout simplement pas les niveaux comme dans Doom 2016.
Pour en finir avec les points négatifs, Doom Eternal a beaucoup trop de phases qui ne servent à rien d'autre qu'expliquer l'histoire du jeu. Et il y a à mon sens beaucoup trop d'histoire...
Conclusion
Doom Eternal est un excellent jeu qui a su se renouveler et faire évoluer les mécaniques de gameplay du fps à l'ancienne sans les dénaturer. Et pourtant, il est indéniablement entaché de nombreuses lourdeurs qui pourront rebuter certains joueurs et le rendre aussi frustrant que bon. Si vous hésitez, attendez que le prix baisse.
Avec un peu plus de munitions, un système de sauvegarde rapide et en l'absence du hub, j'aurais encore plus apprécié le jeu. En attendant, il est toujours possible de jouer aux Doom originaux grâce à Doomsday ou GZDoom, ou encore d'aller à la concurrence avec eDuke32. Je lâche quand même mon Seal of Approval à Doom Eternal.
Attention, cet article va exploser le compteur de buzzwords.
J'utilise Docker en standalone depuis bientôt 3 ans, d'ailleurs mon blog tourne dessus à l'aide de deux images : PluXml et OpenSMTPD - pour le formulaire de contact - que j'ai moi-même réalisé. Sans dire que je maîtrise Docker, j'ai un niveau bien avancé. A côté de cela je travaille régulièrement avec OpenShift (la distribution Kubernetes commerciale de Red Hat) et même si je suis bien moins à l'aise qu'avec Docker, j'ai tout de même pas mal de connaissances.
Docker seul est un peu limité, on ne peut pas faire de clustering, ce qui est bien dommage car les containers et les micro-services s'y prêtent fortement. Il existe heureusement Swarm qui étend Docker au support d'une infrastructure à plusieurs nœuds.
D'un autre côté, le monde entier a les yeux rivés sur Kubernetes, le grand concurrent à Docker conçu dès le départ pour les clusters et la haute disponibilité. Ce dernier est très puissant mais aussi beaucoup plus complexe que Docker Swarm (surtout les RBAC dont je ne parlerai pas). Il faut aussi comprendre qu'on ne télécharge pas Kubernetes, on télécharge une distribution Kubernetes, et il en existe plusieurs. Dans le test de performances plus bas dans cet article je vais utiliser k3s, fourni par Rancher et grandement allégé et simplifié.
Alors, faut-il utiliser Swarm ou Kubernetes ?
Architecture
Docker Swarm
Le cluster se compose de nodes manager et workers. Les premiers sont chargés de piloter le cluster, les second exécutent les containers. Les commandes doivent être exécutées sur un des managers. Un système d'encapsulation UDP est en place entre les nodes, il permet aux réseaux des containers de se propager.
Dans Swarm on déclare des services, soit en cli soit en yaml (docker-compose). Le scheduler va ensuite provisionner les containers nécessaires au service sur un ou plusieurs workers, selon le nombre de replica demandé. Exemple :
$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
sb40x4z1zqkb httpd replicated 1/1 httpd:latest
owq6yurtagjg traefik replicated 1/1 traefik:2.1 *:80->80/tcp, *:443->443/tcp
On peut augmenter ou diminuer manuellement le nombre de replicas, il y a un load balancer interne qui va répartir le trafic de manière transparente. Un système d'affinités permet de lier les containers à une node en particulier, très pratique. Les services peuvent être mis à jour en rolling update, c'est à dire qu'on ne restart pas tous les containers d'un coup mais les uns après les autres, ce qui permet de ne pas interrompre le service. Un rollback est possible.
Et... c'est à peu près tout. Simple et efficace, mais aussi un peu limité il faut l'avouer. Swarm est un bon choix pour un usage personnel de part sa simplcité. Par contre on va voir que pour les cas d'usage avancés, Kubernetes est plus adapté.
Kubernetes
Accrochez-vous. Commençons avec l'architecture Infra.
Le cluster est composé de nodes Control Plane (les masters ou managers) ainsi que des workers. Les Control Planes pilotent le cluster et l'API Kubernetes, à l'aide d'un système de configuration centralisé, qui est souvent basé sur etcd (selon les distributions) mais pas toujours. Par exemple, k3s utilise sqlite. Les workers ont un agent (kubelet) qui reçoit les instructions du scheduler. Là encore une encapsulation UDP est prévue entre les nodes pour permettre la propagation des réseaux des containers.
Attaquons maintenant le fonctionnement des ressources. Dans le cluster Kubernetes, tout est objet, tout est yaml ou json. C'est avec ça que l'on contrôle comment nos containers sont déployés et fonctionnent. Les types (kind) d'objets les plus courants sont :
Pod : Un espace logique qui exécute un ou plusieurs containers.
Service : Sert à exposer un ou plusieurs ports pour un pod, attaché à une IP privée ou publique.
DeploymentConfig : Défini ce qu'on déploie. Typiquement l'image à utiliser, le nombre de replica, les services à exposer, les volumes...
ReplicaSet : un contrôleur qui va vérifier que le nombre de pods en place correspond au nombre de replicas attendu. Scaling automatique possible.
PV, PVC : système d'attribution (automatique ou pas) de volumes persistants.
ConfigMap : objet permettant de stocker de la configuration, qui peut être ensuite lue et utilisée par les containers.
Namespace : Séparation logique des ressources, seules les ressources affectées au namespace en cours sont visibles.
Exemple d'utilisation :
$ kubectl -n web get all
NAME READY STATUS RESTARTS AGE
pod/svclb-httpd-rw7k5 1/1 Running 0 5s
pod/httpd-8647457dd7-s2j4d 1/1 Running 0 5s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/httpd LoadBalancer 10.43.80.117 10.19.2.73 80:30148/TCP 5s
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/svclb-httpd 1 1 1 1 1 5s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/httpd 1/1 1 1 5s
NAME DESIRED CURRENT READY AGE
replicaset.apps/httpd-8647457dd7 1 1 1 5s
Par souci de simplification je ne parle pas du système de RBAC qui permet une granularité dans la gestion des droits, au prix d'une complexité (très) importante.
Kubernetes n'est pas aussi simple que Swarm mais il permet de faire beaucoup plus de choses. En fait on peut presque dire qu'on peut tout faire avec. Les namespaces sont une fonctionalité très pratique, tout comme le scaling auto et la possibilité d'éditer les objets avec la commande edit. En environnement pro, où vous allez gérer plusieurs clients, beaucoup d'applications et de fortes charges, Kubernetes est quasiment indispensable.
Fonctionnalités
Swarm
Kubernetes
Configuration yaml ou json
Oui
Oui
Commandes Docker
Oui
Non
CLI distant
Oui
Oui
Network inter-containers & DNS
Oui
Oui
Replicas
Oui
Oui
Scaling manuel
Oui
Oui
Auto-scaling
Non
Oui
Health probes
Non
Oui
Modification d'objets en ligne
Non
Oui
RBAC
Oui (EE)
Oui
Namespaces
Non
Oui
Volumes self-service
Non
Oui
Kubernetes est indéniablement plus complet, mais à quel point ces fonctionnalités sont-elles indispensables, surtout pour un usage en perso ? Et bien il y a à mon sens deux points que je trouve excellents dans Kubernetes et qui me manquent dans Swarm:
La modification d'objets en ligne. J'entends par là que la commande kubectl edit type/object permet de faire une modification à la volée, par exemple changer un port ou une version d'image dans un DeploymentConfig. Cela n'est à ma connaissance pas possible dans Docker, sauf avec docker-compose (stack dans le cas de Swarm) à condition d'avoir encore les fichiers yaml et que ceux-ci soient à jour.
Les namespaces. Pour éviter de mélanger plusieurs ressources de projets qui n'ont rien à voir, Kubernetes propose un système de namespaces. Par exemple je peux créer un namespace utux dans lequel je vais déployer mes images PluXml et OpenSMTPD, ce qui permet de s'y retrouver mais aussi de tout supprimer plus facilement si besoin. Les namespaces sont aussi très utiles lorsque vous partagez ou louez votre Cluster Kubernetes, chaque utilisateur a ainsi son espace dans lequel il ne voit que ses ressources.
Cependant Docker et Docker Swarm sont beaucoup plus simples et n'utilisent que des composant upstream.
Consommation de ressources
Tests effectués sur des instances DEV-1S de chez Scaleway (2 vcpu, 2GiB RAM, no swap). Le système d'Exploitation est Debian 10 Buster x86_64.
Système seul: RAM 70.9M/1.94G
Swarm seul: RAM 155M/1.94G
Swarm + Traefik + PluXml (apache): 209M/1.94G
k3s seul: RAM 619M/1.94G
k3s + Traefik + PluXml (apache): 678M/1.94G
Si vous comptez monter un cluster de Raspberry Pi avec 1GB de mémoire, vous pouvez oublier k3s/Kubernetes qui en consomme déjà presque 75% à vide. Si vous avez les moyens de payer des serveurs de calcul un peu plus costauds, avec 16 ou 32GB de mémoire, la différence sera alors négligeable.
Les pré requis pour certaines distributions comme OpenShift sont beaucoup plus importants: 4 vcpus et 16GiB de ram pour chaque master (x3), 2 vpus et 8GiB de ram pour les workers (à multiplier par 4 si vous montez l'infra de logging ElasticSearch). C'est la raison pour laquelle je ne l'ai pas utilisé dans ce comparatif, il est hors compétition.
Exemple
Docker Swarm
Exemple simple avec la création d'un container apache vide :
$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
8pxc580r3yh6 test_web replicated 1/1 httpd:latest *:8080->80/tcp
$ curl http://127.0.0.1:8080
<html><body><h1>It works!</h1></body></html>
Kubernetes
Reprenons notre container apache vide :
apiVersion: v1
kind: Service
metadata:
name: web
labels:
app: web
spec:
ports:
- port: 80
selector:
app: web
tier: frontend
type: LoadBalancer
---
apiVersion: apps/v1 #
kind: Deployment
metadata:
name: web
labels:
app: web
spec:
selector:
matchLabels:
app: web
tier: frontend
strategy:
type: Recreate
template:
metadata:
labels:
app: web
tier: frontend
spec:
containers:
- image: httpd:latest
name: web
ports:
- containerPort: 80
name: web
Chargons ces objets :
$ kubectl create namespace test
$ kubectl -n test create -f web.yaml
Vérifions :
# kubectl -n test get all
NAME READY STATUS RESTARTS AGE
pod/svclb-web-jqs6j 0/1 Pending 0 7m17s
pod/web-774f857549-dstkz 1/1 Running 0 7m17s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/web LoadBalancer 10.43.109.52 80:30452/TCP 7m17s
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/svclb-web 1 1 0 1 0 7m17s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/web 1/1 1 1 7m17s
NAME DESIRED CURRENT READY AGE
replicaset.apps/web-774f857549 1 1 1 7m17s
$ curl http://10.43.109.52
<html><body><h1>It works!</h1></body></html>
Conclusion
Kubernetes est plus complet que Swarm mais aussi plus compliqué. Il n'est pas toujours facile de choisir entre les deux, mais je vous donne les conseils suivants :
Pour un usage personnel, Docker standalone ou Docker Swarm sera votre choix par défaut, même si rien ne vous empêche d'essayer Kubernetes :)
Si vous êtes pragmatique ou que vous souhaitez travailler sur les containers, alors ce sera Kubernetes. C'est l'outil en vogue plébiscité par tout le monde et c'est ce que vous devez avoir sur votre CV.
Pour un usage en entreprise, Kubernetes sera incontournable car il y a de nombreuses offres dans le Cloud et On-Premise. Aks ou OpenShift sur Azure, Eks chez Aws, pour ne citer que les plus connus. Tout l'écosystème des containers est focalisé sur Kubernetes et les namespaces vous serons indispensables dans un contexte multi-client.
Pour finir, un court retour d'expérience sur l'utilisation de Kubernetes en entreprise. Tout d'abord, soyez conscient que votre cluster, vos clients et vos utilisateurs vous poseront de nombreux défis. Ne pensez pas que Kubernetes va résoudre magiquement tous vos problèmes et que vos admins vont se tourner les pouces, bien au contraire. Dans le cas d'une plateforme On-Premise, prévoyez 2 admins à temps plein au minimum. Ensuite, vous devez disposer de compétences dans quasiment tous les domaines : réseau, stockage, système, middlewares et surtout avoir une bonne maitrîse de la Elastic Stack (ELK ou EFK) puisque vous aurez à gérer les logs de vos nodes et containers.
Avec cet article j'espère avoir bien présenté les différences entre Docker Swarm et Kubernetes et fourni quelques pistes à ceux qui hésitent :)
