Et si on utilisait Kubernetes pour le développement local ?

Kubernetes sur ma machine de dev :

Aujourd’hui, on peu tester / utiliser Kubernetes sur sa machine avec minikube (essentiellement VirtualBox) ou si on est sous ubuntu : LXD, conjure-up.

Les autres méthodes, sont peu documentées ou très spécifiques.

Qu’est ce qu’on peut faire avec ça

C’est génial pour faire ses premiers pas dans cet environnement complexe, écrire ses premiers services, contrôleurs, pods, etc.

A grand renfort de kubectl on apprends dans un environnement simplifié (un seul hôte) à déployer son application, convertir son docker-compose en yaml, gérer ses données.

On finir par découvrir helm qui nous simplifie bien la vie en nous fournissant des recettes prêtes à l’emploi.

On se dit que Kubernetes, c’est vraiment génial, ça va nous permettre de nous intégrer à Gitlab CI pour faire de l’Auto Deploy Auto DevOps.

Et si on s’en servait comme environnement de dev ?

J’entends par là développer mes applicatifs (js, python, and co), pas mes yaml k8s, ni développer kubernetes lui-même.

Et là c’est le drame, on retrouve tous les problèmes de développement via docker mais avec une couche de complexité en plus.

Soit on bourrine en construisant des images docker à chaque commit (irréaliste), qu’on doit ensuite pousser vers le worker (ou via un repository / hub) : ce qu’on trouve dans 95% des articles sur docker. C’est lourd, lent, consommateur de ressources et donc pas éco-responsable.

Soit, on opte pour des solution avec des point de montage réseau. (docker –volume ou –mount). Et on a en plus la complexité k8s : le worker de minikube c’est une vm, le worker de Juju c’est un conteneur lxc. En aucun cas on est sur notre machine de dev directement.

On configure alors le partage de fichiers au niveau de la vm, le partage réseau ou on va coder directement sur l’hôte (ssh+vim).

Et à ce moment là, on a l’impression de coder sur un serveur de prod ou d’intégration. Et c’est normal, c’est ce qu’on est entrain de faire.

On a réussi à monter une usine à gaz qui nous rajoute pleins plus de problèmes que ça n’en résout. Par contre, on a maintenant une très belle stack !

Conclusion

Kubernetes c’est bien, c’est l’avenir. Mais l’avenir c’est demain; et aujourd’hui c’est adapté aux boites ont une équipe dédiée. Même si c’est plutôt bien documenté, c’est encore immature, les messages d’erreurs sont parfois génériques donc difficile à comprendre.

Donc k8s, sur le poste du developpeur: c’est non; trop de complexité par rapport au gains. Sur le poste du sysadmin, pour coder l’infrastructure: oui Héberger son propre cluster : non, trop complexe pour commencer, on internalisera quand ça sera plus mature et qu’on sera mieux l’utiliser.

Pour fin 17 et 2018, je vais basculer une partie non-critique de mes environnements de tests et d’intégration continue par contre, je ne vais pas administrer mon infra et confier cette gestion à un AWS, GAE ou autre.

–

PS: les perfs de minikube sont pour le moment pas au top, c’est donc un peu lent, juju c’est bien sympa jusqu’au moment où ça ne marche plus. Il faut donc investiguer du coté d’appArmor, de MaaS, d’LXC, de snap et de conjure-up. C’est passionnant certes, mais chronophage.