Kubernetes et Helm c'est quand même très cool. Par contre, la prise en main et la compréhension des concepts est hardcore.

Ça doit faire deux ans que j'ai essayé d'y toucher à plusieurs reprises (en déployant un cluster localement, etc.) sans grand succès.

Et là après 10 jours intensifs dessus, à lire des donnes de docs, je commence tout juste à l'avoir bien en main, à faire des déploiements complètement automatisés connectés à la CI, etc.

Pourquoi c'est pratique/utile.

Déjà, il y a une abstraction totale de la machine sur laquelle tourne un process. On réfléchit beaucoup plus en termes de ressources, de contraintes, de volumes de données, d'applications, et de comment elles communiquent entre elles.

Du coup, en terme d'adminsys, c'est beaucoup plus simple de rajouter/enlever des noeuds dans un cluster k8s pour s'adapter à la charge de travail que de le faire à la mano avec les outils habituels.

Ensuite, c'est orienté production et réplication des applications/données.

L'idée, c'est que chaque application soit répliquée sur au moins 2/3 noeuds et que même si un noeud ou un applicatif crashe, le traffic soit redirigé automatiquement sur les autres.

C'est rendu possible par le système de healtcheck: k8s monitore en permanence les applicatifs pour s'assurer qu'ils sont en bonne santé.

Ça rend aussi possible des mises en prod progessives sans downtime :

1. je mets à jour 1/3 des applicatifs, je regarde s'ils sont en bonne santé avant de les exposer sur le réseau
2. je mets à jour le second tiers
3. etc.

Après ça c'est des trucs qu'on peut faire aussi sans k8s. La boite ou j'étais avant le gérait avec Ansible et ça marchait. Mais les playbooks étaient d'une complexité monstre, et hyper spécifiques à notre applicatif.

Maintenant, pour les aspects moins reluisants, tu sens que l'écosystème kubernetes est avant tout une aubaine pour les hébergeurs, à commencer par Google.

Comme la maintenance d'un cluster est complexe, il y a des cluster gérés en SaaS par différentes boites. En soi ce n'est pas gênant, on toujours gérer le cluster à la main si on veut, tout le code est open source.

Par contre il y a un risque de se faire enfermer sans s'en rendre compte. Je développe.

En soi, une configuration k8s est générique et peut théoriquement fonctionner d'un hébergeur à l'autre, et c'est à peu près le cas pour des applicatifs stateless qui n'ont pas besoin de persister des données.

Mais dès que tu commence à utiliser les services que l'hébergeur vend en parallèle, comme les volumes de données dynamiques et répliqués, ou le load balancing, la situation change...

Mais bon, il y a toujours la possibilité de garder une ou des machines hors kubernetes pour les données, et gérer cette partie là soi même.

C'est ce que j'ai fait dans le cas présent. Je me vois pas mettre ma BDD de prod dans une image Docker qui va tourner sur une machine où j'ai pas d'accès root et où je peux pas tweaker le système.

À part ce risque là qui est quand même important, et la complexité générale du machin, des concepts, etc, je pense que c'est quand même un outil intéressant et qui répond à un besoin réel (déployer des applicatifs simplement, de manière secure, sans downtime et en haute disponibilité).

L'écosystème est plutôt bien fait, il y a beaucoup de doc. On peut gérer et monitorer son cluster en ligne de commande, avec un dashboard ou même avec des outils tiers (Gitlab, dans mon cas, gère les déploiements via la CI/CD, et m'affiche même des stats sur l'utilisation CPU/mémoire au sein du cluster)