Je vais devoir me mettre à Kubernetes cette année normalement.
Même si c'est moi qui ai proposé cette solution, j'avoue, je ne suis pas serein

A voir si dans l'étude qu'on va faire cet été sur nos besoins et les solutions techniques, autre chose que K8s ressort.

Je m'y suis intéressé plusieurs fois, mais à chaque tentative, j'ai baissé les bras et j'ai laissé tomber C'est trop "complexe" et trop demandeur pour que je mette ça en place pour mon travail au quotidien. Je vais y passer des jours voire des semaines pour finalement ne pas m'en servir autant que je le voudrai (et "éduquer" mon équipe à en faire usage ne présente pas beaucoup d'interêt, car à peine auront-ils pris l'habitude de l'utiliser correctement qu'ils auront fini leur thèse et qu'il faudra recommencer tout le processus avec les nouveaux chercheurs ).

La feignantise du chercheur c'est quelque chose quand même !

L'article de billet je le trouve bof, c'est très argumentaire avec un homme de paille.

Aujourd'hui tu recrutes des devs ou des devops, et tu sais que si tu demandes à tes devs de faire du devops ça va être soit sous optimal, soit mal se passer, tout comme si t'essayes de faire dev à tes devops.
Maintenant pour pouvoir hoster une application ou un service quelconque sur kubernetes, il faut que les devs aient quelques bases: ça ne veut pas dire en faire des experts kube qui seront capables de le déployer et le maintenir.

Je déploie et maintiens des clusters kube pour ma boite, si vous avez des questions je peux essayer d'y répondre. Pour moi le principal problème avec kube c'est un mix de:
- ça abstrait beaucoup de choses et il faut avoir un modèle mental de ce qu'il se passe quand une requête HTTP arrive, vers quoi elle passe avant d'atteindre ton code.
- Pour la même raison d'abstractions, c'est difficile d'aller debug efficacement quand tu n'as que ponctuellement des soucis.
- il y a trop trop trop de buzz qui encouragent des déploiements ou des setup alambiqués. Dès que tu cherches un truc simple sur google t'as 40 articles de blog hello-world qui ressortent, et peut-être une dizaine qui font un peu ce que tu veux mais d'une façon différente les uns des autres ou qui t'ajoutent des dépendances dont tu n'as pas besoin que forcément si tu ne connais pas tu es perdu.

yaugLa feignantise du chercheur c'est quelque chose quand même !

Plutôt une histoire de priorisation aussi

SyssonL'article de billet je le trouve bof, c'est très argumentaire avec un homme de paille.

L'article n'est pas fou c'est sur, mais pointe un problème quand même je trouve.

SyssonJe déploie et maintiens des clusters kube pour ma boite, si vous avez des questions je peux essayer d'y répondre.

vu que je vais sans doute m'en manger si tu as des ressources à conseiller notamment sur les bonnes pratiques etc.

Le point d'entrée va vraiment dépendre du niveau auquel tu vas travailler, il va falloir que tu répondes à quelques questions pour cadrer ma réponse:

Si tu vas installer et maintenir des cluster, ça va beaucoup dépendre de l'environnement dans lequel tu es. Si c'est du cloud que ce soit aws, gcp, azure, oracle, etc ils viennent tous avec leurs panoplies de pré-choix pour le réseau et le stockage, il faut juste bien dimensionner les choses (notamment les plages d'ips pour les noeuds, services et pods). Si c'est du bare metal, ça sera encore une autre discussion.

Si tu vas packager une appli pour un/des kubernetes existant, ça va beaucoup dépendre de ce qui est en place pour gérer les déploiements: ça peut être du Helm, du Kustomize, des manifests dans du terraform, des manifests tout court, autre chose... Le tout potentiellement géré par une ci/cd (argocd est vachement répendu, mais ça peut être autre chose).