@al @arthurlutz

LXC, avec les outils kernels mis à disposition par Google n'a pas perçu le concept de conteneur, c'est tout ce que je lui reproche.
J'ai commencé par utiliser de l'openVZ, et j'étais donc sensible au concept de pseudo VM légère, j'ai manipuler runc et je testerai gVisor aussi. Du coup, je garde le terme de myope, mais tant mieux si le produit vit encore.

https://trends.google.fr/trends/explore?date=today%205-y&q=lxc,%2Fm%2F0wkcjgj,%2Fg%2F11b7lxp79d

@athoune @arthurlutz A mon avis, tu confonds container et micro container.
Et bon, se référer aux trends pour choisir sa techno, c'est se baser sur la Hype pour choisir sa plateforme :)
En se basant sur ce genre d'approches, il y a quelques années qui aurait prévu la suprématie de *NIX et la mort de Microsoft ?
Et aujourd'hui, la mort programmée de Docker ?

@al @arthurlutz les bons termes sont fat container (l'approche LXC) et les container (tout court, pas micro). Pour proposer une techno, il faut des utilisateurs, avec une masse critique. Les machins exotiques sont là pour explorer, il faut ensuite de la masse pour que ce soit adopté. Miser sur un truc de niche est risqué, tu peux le faire pour flatter et recruter une élite, mais avec le danger de ne plus trouver personne derrière. Tu peux aussi faire le pari du early adopter.

@al @arthurlutz Pour moi, MS n'a jamais été hégémonique coté serveur internet. Java et même PHP l'ont été bien plus.

Sinon, là, ton Docker, pas la peine de faire une fixette dessus. Il a emplit son rôle de pédagogie, avec une belle intégration sur les OS de devs (Win/Mac/Linux), l'étape suivante, qui est douloureuse pour lui, ce sont des specs : https://www.cncf.io/ et le pognon de l'hébergement. Docker ne devenant qu'une (belle) implémentation.

@al @arthurlutz Le terme de "mort programmé de Docker" est vain. Un peu comme emacs vs vim, perl vs python et autres dichotomies artificielles.
La différence est une richesse, et ce qui est intéressant, c'est d'en extraire des normes et des protocoles, surtout pas des implémentations. Les ctrl-machins d'emacs sont dans le bash ou la barre d'adresse de FF. Les raccourcis vim sont dans atom, sublimtext et code. Les PCRE sont partout. Cgroup et namespace sont maintenant dans tous les Linux.

@athoune @arthurlutz
Héhé, ça va dépasser la discussion Mastodon là :D
Docker, joli, non, vraiment. Leur implémentation du concept de manifeste pour une VM est acceptable. Le réseau et le FS, le repo d'images sans contrôle, bwerk. La clusterisation vient comme une pensée tardive. Ne parlons meme pas de la prod si les gens ne savent pas régler leurs cgroups et font du stateful / Write.
Après c'est pas CNF, c'est Open Container Initiative qui me semble de nature à les remplacer.

@al @arthurlutz Il ne faut JAMAIS utiliser le terme VM quand on parle de conteneur. Même pour gVisor.

Docker swarm n'a jamais convaincu quiconque, et Docker est en train de basculer sur k8s.

CNF est plus large et propose un ensemble cohérent des services pour accompagner/coordonner les conteneurs, de l'OCI, qui lui est bas niveau.

Docker, avec Compose permet de définir un besoin, mais ne l'implémente pas directement.

La registry a des controles.

@athoune
Un fat container, si tu veux, ça remplit exactement le même role qu'une VM.
Je découvre le "User Space Kernel" de gVisor 😀 Curieux de voir quand les premières failles de sécu vont arriver 😽 mais intéressant.
Après tu râles sur le piège de k8s et de l'enfermement dans les silos d'hébergement : LXC -membre de l'OCI- est une bonne solution pour les besoins simples.
En revanche, la promesse de l'élasticité reste un sport de haut niveau...

@al c'est le contraire, en fait, l'objectif de gVisor est de limiter la surface d'attaque (les appels systèmes) par rapport à namespace + seccomp/apparmor/selinux. Ce qui amuse Google, c'est de combiner du gvisor et du namespace, dans un même cluster.

L'objectif des conteneurs, ce n'est pas forcément l'élasticité, mais la densité.

@athoune Oui pour gvisor j'ai bien compris et ça pourrait justement résoudre les soucis d'hébergement du type : présenter à un client des nodes Kubernetes lui permettant de gérer sa propre flotte, avec l'agrément du container comme host et la sécurité du KVM/Kernel séparé.

Élasticité : Augmenter dynamiquement le nombre de nodes selon une métrique arbitraire (load des workers/nombre de paniers/...) est quand même une des promesses intéressantes de k8s et autres orchestrateurs d'infra.

@al en l'état, il ne me semble pas sage de mutualiser un k8s entre différents clients. Par contre, c'est légitime pour différents projets d'un même client.

Le premier objectif est de densifier, et de dépasser les 15% de CPU, avant de rêver à des fluctuations énormes.

@athoune Pas mutualiser du k8s, bien sûr.
Avoir des gvisor + leurs containers sous xrunc individuels, sur un même node physique.
Genre faire le vase d'expansion pour des infras qui ont ponctuellement besoin de nodes en plus et dont le cluster 100% autonome est déjà plein.