Dev, boulot, kubernetes 

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.

Dev, boulot, kubernetes 

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.

Dev, boulot, kubernetes 

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é.

Dev, boulot, kubernetes 

Ç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.

Dev, boulot, kubernetes 

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.

Dev, boulot, kubernetes 

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.

Dev, boulot, kubernetes 

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...

Dev, boulot, kubernetes 

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.

Dev, boulot, kubernetes 

À 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é).

Dev, boulot, kubernetes 

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)

Dev, boulot, kubernetes 

Voilà mes conclusions pour le moment, ça va sûrement bouger encore.

Follow

Dev, boulot, kubernetes 

Ah oui et du coup ben, faut aimer ou a minima supporter Docker, sinon c'est un peu chaud ;)

Dev, boulot, kubernetes 

J'ai presque terminé la mise en place d'un env de staging complet, identique à la prod. Seule exception : les mails partent sur mailhog pour pouvoir débugger facilement github.com/mailhog/MailHog au lieu d'être envoyés pour de vrai.

C'est cool, tout tourne sous Docker et peut être distribué / répliqué maintenant (on avait encore des scripts custom lancés via cron, j'ai du les porter sur une task queue distribuée).

Dev, boulot, kubernetes 

il me reste encore deux trois petites choses à régler, notamment faire une copie régulière de la base de prod sur l'env de staging pour avoir des données à jour.

Et évidemment, il faut que je fasse tester l'env de staging à mon collègue pour qu'on valide ensemble que tout est bon.

Et à partir de là, je devrais pouvoir déployer très simplement le cluster de prod \o/

Dev, boulot, kubernetes 

après il restera la migration de notre VM actuelle vers la nouvelle prod sur Kubernetes, ça va être fun pour minimiser le downtime mais bon, ça fait partie du jeu aussi 😛

Sign in to participate in the conversation
Eldritch Café

Une instance se voulant accueillante pour les personnes queers, féministes et anarchistes ainsi que pour leurs sympathisant·e·s. Nous sommes principalement francophones, mais vous êtes les bienvenu·e·s quelle que soit votre langue.

A welcoming instance for queer, feminist and anarchist people as well as their sympathizers. We are mainly French-speaking people, but you are welcome whatever your language might be.