Introduction

Quand on commence à étudier Kubernetes (k8s), on a besoin d’un environnement où tester ce qu’on apprend. Les environnements possibles sont nombreux : Minikube, Kubernetes (k8s) officiel, k0s, k3s, etc. Cela ne s’arrête plus !

Entre les difficultés à installer l’environnement et celles à appliquer ce qu’on apprend, on ne s’en sort plus. Cela devient vite compliqué au point de vouloir tout arrêter ; c’était mon cas.

Avant de décrocher complètement, j’ai fait une pause, pris du recul et étudié la question. Je vous relate ici le résultat de cette petite aventure dans le monde de Kubernetes et des outils envisagés pour créer un labo de développement d’applications tournant sous Kubernetes.

Dans un premier temps nous poserons le problème, après quoi nous étudierons quelques solutions pour finalement détailler le produit de cette pérégrination.

Quelques tubes à essais avec une pipette vus de près

Photo trouvée sur publicdomainpictures.net sous Licence CC0 Public Domain.

Le contexte

Venant du monde de Docker et Docker Compose, il me semblait aller de soi d’étudier ensuite le monde de Kubernetes - qui utilise la conteneurisation. Seulement je ne pensais pas que l’installation même de Kubernetes était un cap à franchir.

Au début on découvre Minikube. Du moins c’est un outil très souvent conseillé. Pratique sur une machine bureautique pour triturer rapidement quelques fichiers Kubernetes (des fichiers au format YAML). Il est bien documenté et possède plusieurs plugins pour faciliter l’étude du Kubernetes en place ; par exemple un plugin Dashboard permet de visualiser les métriques du serveur et les objets instanciés. J’ai la sensation que cet outil reste « trop spécifique ». Il ne représente pas totalement un « vrai » Kubernetes. Ça peut parfois causer des torts au moment de déployer sur un autre serveur Kubernetes. L’outil est également lourd et relativement lent pour instancier un nouvel environnement.

Pourquoi ne pas tester un Kubernetes connu pour sa légèreté ? Par exemple k3s. D’autant qu’il s’installe rapidement à l’aide de k3sup (qui fonctionne à merveille). Sur le papier c’est une bonne idée : léger, facile à installer. En revanche il ne permet pas d’instancier un nouvel environnement ; il faut donc jouer avec les namespaces Kubernetes. Rebelote : ce n’est pas un outil adapté à l’apprentissage de Kubernetes. Au départ on fait forcément des erreurs dues à l’incompréhension ou l’ignorance ; ce qui peut rendre l’environnement rapidement inutilisable.

Après ces deux premières tentatives, je sais désormais ce que je veux :

  • possibilité de créer un environnement « propre »,
  • encore mieux s’il peut créer plusieurs environnements,
  • si possible léger (petit) - ce qui exclue les machines virtuelles,
  • facile à installer,
  • et rapide.

Nous avons nos critères, il ne reste plus qu’à chercher le(s) outil(s) permettant de créer rapidement un environnement de développement autour de Kubernetes.

Solutions étudiées

À la recherche des mots clés « lightweight » (similaire au mot léger) et « kubernetes » dans un moteur de recherche, on trouve plusieurs outils comme :

k3s a déjà été cité dans cet article. Il ne me convient pas pour un environnement de développement/d’étude concernant k8s. Il est sûrement très redoutable à l’installation rapide sur une quantité importante de machines à l’aide de k3sup. Mais ce n’est pas le sujet de cet article.

La liste mentionne également MicroK8S, le petit rejeton de la famille Ubuntu, qui semble être une alternative à Minikube avec des plugins (Dashboard, DNS, registry, istio, etc.). Je pense qu’il est effectivement intéressant pour un usage complet entre des développeurs, une intégration continue (CI) / déploiement continue (CD) et plusieurs environnements allant jusqu’à des environnements dit « de production ». Je sens cependant que la similitude avec Minikube ne puisse me convenir. Je le laisse de côté pour l’instant.

k0s, quant à lui, semble être la solution idéale pour une installation sur une machine physique. À usage privé. Bien qu’il semble léger, facile à installer et utiliser, je comprends rapidement qu’il est fait pour avoir une installation unique sur une machine physique précise. Il ne répond pas à mon critère de création multiple d’environnements.

Et un de plus en moins !

Il reste le dernier de cette liste : kind. A priori il semble léger, prévu pour un usage spécifique au développement ou de l’intégration continue (CI) et utilise Docker pour créer un cluster complet à chaque fois. Waouh, rien que ça ! Sur le papier, cet outil est très prometteur car il répond aux critères précédemment listés :

À l’usage, kind (qui veut dire Kubernetes IN Docker) semble facile à prendre en main :

# Créer un cluster nommé olivier
kind create cluster --name olivier
# Supprime le cluster nommé olivier
kind delete cluster --name olivier

Une fois le cluster créé, il s’agit simplement de jouer avec la commande kubectl habituelle pour contacter le cluster. Et la commande étant à taper, je peux tout à fait scripter la création du cluster et sa destruction.

Il serait plus pratique de l’utiliser avec d’autres outils pour en faciliter l’usage. J’ai donc cherché au fur et à mesure de nouveaux outils dont voici la liste :

  • kubectx va permettre de commuter d’un contexte Kubernetes à un autre. Autrement dit passer d’un cluster à un autre facilement,
  • kubeconform pour valider nos fichiers YAML,
  • kube-linter pour pousser à l’usage des bonnes pratiques en matière de rédaction de fichiers YAML,
  • skaffold pour surveiller la moindre modification (équivalent d’un « watcher ») sur nos fichiers YAML et les déployer directement sur le cluster,
  • et make (avec un fichier Makefile) pour mélanger tout ça.

Mon idée est d’utiliser un fichier Makefile pour fournir plusieurs commandes permettant de créer le cluster, le détruire, vérifier les fichiers YAML ou encore lancer un déploiement automatique s’il y a des changements dans les fichiers en cours de développement.

J’imagine quelque chose comme :

  • make cluster pour créer un cluster,
  • make dev pour lancer skaffold et écouter le moindre changement sur le dossier de développement de l’application,
  • make kubeconform pour vérifier les fichiers une fois écrits,
  • make lint pour vérifier les bonnes pratiques avec kube-linter,
  • et make clean pour détruire le cluster.

Tentons l’aventure et voyons le résultat !

Ce que j’ai finalement produit

En bref

Le fichier Makefile :

CLUSTER_NAME := k8s-dev-example
KUBECTL := kubectl
SKAFFOLD := skaffold
KIND := kind
KUBECONFORM := kubeconform
KUSTOMIZE := kustomize

NAMESPACES := dev

.PHONY: help
help:
	@echo "Commandes disponibles :"
	@echo "  make cluster       - Crée un cluster Kind"
	@echo "  make namespaces    - Crée les namespaces Kubernetes (dev/staging/prod)"
	@echo "  make dev           - Lance Skaffold pour l'env dev"
	@echo "  make kubeconform   - Lance kubeconform sur l'env de DEV"
	@echo "  make clean         - Supprime le cluster Kind"

cluster:
	$(KIND) create cluster --name $(CLUSTER_NAME) ||:

namespaces:
	@for ns in $(NAMESPACES); do \
		$(KUBECTL) get ns $$ns >/dev/null 2>&1 || $(KUBECTL) create ns $$ns; \
	done

dev: cluster namespaces
	$(SKAFFOLD) dev

kubeconform: kubeconform-dev

kubeconform-dev:
	$(KUSTOMIZE) build overlays/dev | $(KUBECONFORM) -strict -summary -ignore-missing-schemas

clean:
	$(KIND) delete cluster --name $(CLUSTER_NAME)

Ce fichier Makefile est disponible sur le dépôt Gitlab d’ODTRE.

Il va utiliser deux dossiers principaux :

  • base qui contient les fichiers YAML de l’application qu’on souhaite implémenter sur Kubernetes,
  • overlays/dev qui contient un fichier kustomization.yaml pour surcharger le dossier base.

Et 2 fichiers de configuration :

  • kube-linter.yaml avec votre configuration de l’outil,
  • skaffold.yaml avec le contenu suivant :
apiVersion: skaffold/v4beta13
kind: Config
metadata:
  name: k8s-demo-app
manifests:
  kustomize:
    paths:
      - ./overlays/dev
# Exemple de redirection de port sur le service nommé dev-nginx (car l'overlay ajoute dev- devant tout)
portForward:
  - resourceType: service
    resourceName: dev-nginx
    namespace: dev
    port: 80
    localPort: 4000

Cela permet de surveiller le dossier ./overlays/dev avec kustomize pour interpréter les fichiers. Et il va ouvrir le port 4000 sur la machine locale pour rediriger sur le port 80 du service Nginx d’exemple (fourni dans le dépôt Gitlab mentionné précédemment).

À l’usage

Tout n’est pas parfait. Cependant ce fichier Makefile permet de lancer quelques commandes make utiles :

# Lance l'environnement de DEV. Si le cluster n'existe pas : il le créé. Sinon il ignore.
make dev
# Vérifie la conformité des fichiers YAML en utilisant le dossier overlays/dev
make kubeconform
# Détruit le cluster de DEV
make clean
# Pousse à l'usage des bonnes pratiques sur les fichiers contenus dans le dossier ./base
kube-linter lint --config kube-linter.yaml ./base

Pour toute aide supplémentaire, faites : make help.

Ainsi il devient facile de travailler sur un nouvel environnement :

  • je copie les fichiers disponible sur un dépôt template sur Gitlab,
  • j’ouvre le fichier Makefile en écriture,
  • j’édite la ligne suivante pour adapter le nom du cluster de travail :
CLUSTER_NAME := k8s-dev-example

Et le tour est joué !

Je suis assez satisfait de cet environnement. Il répond aux critères édictés plusieurs fois dans cet article. Et je me sens plus à l’aise de pouvoir modifier comme bon me semble cet environnement de développement/travail.

Les outils utilisés me font penser à une boîte à outil de base pour le travail sur Kubernetes. Même sans utiliser le fichier Makefile je suis amené à pratiquer les outils comme kubeconform, kubectl, kube-linter et kustomize.

C’est donc une très bonne chose d’avoir regroupé ces outils autour de Makefile et de les utiliser régulièrement sur mes projets Kubernetes.

Conclusion

Nous avons posé le contexte d’une recherche d’outil simple, rapide et léger pour créer de nombreux environnements Kubernetes afin de travailler sur ces environnements dans le cadre d’un développement de fichiers YAML.

Après quelques essais sur Minikube et k3s, mes recherches se sont portées sur l’utilisation de kind. Puis j’ai utilisé make pour le manipuler et regrouper aussi les différents outils utiles.

La boîte à outil se compose de :

  • kind,
  • skaffold,
  • kubectl,
  • kubeconform,
  • kube-linter,
  • et make.

J’aborde désormais de manière plus sereine le développement d’une application qui sera hébergée par un Kubernetes. J’ai un template à ma disposition pour ces fichiers. Template que je peux faire évoluer au gré des obstacles rencontrés. Il utilise tous les outils que j’ai appréciés. J’en suis pleinement satisfait 😎 .

Et vous, quel environnement Kubernetes utilisez-vous pour vos développements de fichiers YAML ?

Liens utiles