Kubernetes : cinq solutions "légères" pour le développement local
Publié par Clément Bohic le - mis à jour à
Pour déployer Kubernetes en local, qu'existe-t-il au-delà de la référence Minikube ? Le point sur cinq solutions « légères » alternatives.
« Quel(s) environnement(s) Kubernetes ciblez-vous lors du développement en local ? » Canonical a sondé sa communauté à ce propos *.
Il y en a qui n'utilisent pas de conteneurs à cette phase (5,9%). D'autres si, mais sans exploiter Kubernetes (11,3%), lui préférant par exemple Docker Compose. Ils sont plus nombreux à s'appuyer sur les Kubernetes managés des CSP (22,3%) et sur des déploiements internes (23,8%).
Certains ont opté pour des versions « light » de l'orchestrateur. Parmi elles, Minikube est la distribution la plus populaire (32,3%). Suivent Docker Kubernetes (31,7%), MicroK8s (made in Canonical ; 25,6%), k3s (origine Rancher ; 20,7%) et kind (17%).
k0s : Mirantis à la baguette
Parmi les solutions non citées figure k0s. Sous licence Apache, le projet émane de Mirantis. L'entreprise américaine en a fait le socle d'une de ses offres commerciales. En l'occurrence, une option « clusters managés » pour Lens, un IDE Kubernetes. Celui-ci est gratuit en version desktop. Et payant en version cloud.
Particularité de k0s : il est livré en un seul binaire. Pas de dépendances, donc, hormis à quelques composants kernel. Pour le moment, il est considéré comme stable sur Linux (x86-64, ARM64, ARMv7). La prise en charge de Windows (édition Server 2019) reste expérimentale.
La dernière version mineure (1.23.1, du 27 décembre 2021) a notamment apporté un mode IPv6-only et la possibilité d'étiqueter les noeuds contrôleurs. La gestion des versions est alignée sur celle de Kubernetes. La politique de support aussi : un an pour chaque mineure.
Par défaut, k0s utilise le runtime containerd. Et Kube-router pour le réseau. Pour le plan de contrôle, c'est etcd sur les clusters multinoeuds et du SQLite interne sur les mononoeuds. Avec les possibilité de s'appuyer sur du MySQL ou du PostgreSQL externe, via Kine (« Kine is not etcd »). Pas de prise en charge native des CSP. Il faut soit installer leurs contrôleurs, soit passer par un provider intégré capable d'assigner aux noeuds de travail des IP statiques externes, grâce aux annotations Kubernetes.
Au sein des clusters, k0s gère la haute disponibilité (avec k0sctl), les GPU, les fournisseurs OpenID ou encore CoreDNS. Configuration minimale exigée pour les noeuds de contrôle : 1 vCPU + 1 Go de RAM (recommandé : 2 vCPU et 2 Go). Pour les noeuds de travail, c'est 1 vCPU + 0,5 Go de RAM (recommandé : 2 vCPU et 1 Go). Il est possible de créer un cluster dans Docker. Tous les noeuds s'exécutent alors au sein d'un même conteneur.
Typhoon : DigitalOcean en soutien
Autre Kubernetes « léger » open source (licence MIT) : Typhoon. Son principal sponsor : DigitalOcean. La structure qui le porte (Poseidon Labs) gère aussi les projets Matchbox (provisionnement PXE de clusters sur matériel nu) et Fleetlock (gestionnaire de redémarrage de clusters sur Fedora CoreOS).
La numérotation est elle aussi alignée sur celle de Kubernetes. La dernière version mineure (1.23.1, publiée le 31 décembre 2021), a marqué le passage de docker à containerd dans les images pour Flatcar Linux. Celles destinées à l'installation sur AWS et bare metal sont stables. Celles pour Google Cloud et DigitalOcean sont en bêta. Celle pour Azure, en alpha.
Typhoon couvre une deuxième plate-forme : Fedora CoreOS. On en est aux mêmes statuts de maturité, sauf pour Google Cloud (stable).
Toutes ces images n'ont qu'une version AMD64. À l'exception de celle pour Fedora CoreOS sur AWS. Elle gère les pools hybrides. Mais ne peut pas exploiter certaines composantes, à l'image de Calico pour le réseau.
Dénominateur commun à toutes les images : un module Terraform. C'est avec lui qu'on définit les clusters. Avec quelques options spécifiques à Google Cloud, dont la prise en charge des instances préemptives. Ces dernières représentent la capacité excédentaire de GCP. Elles ont une durée de vie maximale de 24 heures et Google peut les stopper à tout moment. En contrepartie, il les vend 60 à 91 % moins cher que les instances « classiques ».
Les configurations minimales requises sont les mêmes sur l'un et l'autre OS.
- Matériel nu : 2 Go de RAM et 30 Go de disque pour un noeud de contrôleur
- AWS : instance t2.small (noeuds de contrôle et de travail)
- Google Cloud : instance n1-standard-1 (pour les deux types de noeuds)
- DigitalOcean : droplets s-2vcpu-2gb (contrôleurs) et s-1vcpu-2gb (workers)
- Azure : instances Standard_B2s (contrôleur) et Standard_DS1_v2 (workers)
kind : Kubernetes dans Docker
Sous licence Apache, le projet kind (« Kubernetes in Docker ») est un peu différent. Il déploie les noeuds sous forme de conteneurs - chaque cluster étant identifié par une étiquette Docker. Son usage est donc plutôt orienté sur le test que le développement.
Le coeur fonctionnel est codé en Go. L'installation de base se fonde sur une image minimale d'Ubuntu. Elle contient les outils statiques nécessaires à Kubernetes, ajoute un point d'entrée sur chaque noeud pour réaliser des actions avant l'amorçage et paramètre un service systemd pour gérer la journalisation. Il en existe des variantes « étendues », contenant des tarballs (archives d'images) que le cluster chargera avant d'exécuter kubeadm.
L'installation est nettement plus lourde qu'avec les options sus-évoquées. Sur Mac comme sur Windows, il faut au minimum 6 Go de RAM (8 recommandés) pour la VM Docker. Il n'existe pas encore d'images Arm. Ce qui, entre autres, explique le statut de « work in progress » du projet (cf. roadmap).
Parmi les autres limites, kind ne gère pas les applications à état. Il ne fonctionne par ailleurs pas dans la sandbox Linux de Chrome OS et ne prend pas en charge les conteneurs Windows. Depuis peu, il permet d'utiliser, côté hôte, docker et podman en rootless. L'implémentation réseau par défaut repose sur un module propre au projet (kindnetd). Associable à MetalLB pour la répartition de charge, il supporte l'IPv6, y compris en mode dual-stack.
Minikube et MicroK8s : les premiers choix
Pas encore d'IPv6 sur Minikube, le « Kubernetes light officiel ». Sa première release remonte à 2016. Il couvre aujourd'hui Windows, Mac et Linux, sur x86-64. Son principe : exécuter des clusters à noeud unique dans une VM. Ses exigences : au minimum 2 CPU, 2 Go de RAM et 20 Go de disque. On peut aussi l'utiliser en remplacement de Docker Desktop, sans lancer Kubernetes.
Comme k0s, MicroK8s (AMD64, ARM64) peut faire l'objet d'un support commercial - 10 ans de maintenance - par son éditeur. Au-delà du développement local, il cible l'IoT et les environnements minimaux d'intégration continue. Canonical le distribue sous forme de Snap (et d'exécutable sur Windows) qui exécute nativement l'orchestrateur (sans VM).
De base, MicroK8s inclut le serveur d'API, le planificateur, le kubelet, l'interface CNI et kube-proxy. On peut l'étendre avec une trentaine d'add-on dont Istio, Kubeflow, OpenFaaS, Prometheus et l'opérateur NVIDIA. Configuration minimale recommandée : 4 Go de RAM et 20 Go de disque sur Linux avec l'installation par défaut (40 Go de disque sur Windows et Mac). Autre possibilité : installer MicroK8s dans un conteneur LXD. Comme Minikube, on est sur du déploiement de clusters à un seul noeud. Mais il est possible d'en ajouter et d'activer la haute disponibilité - avec DQlite en datastore.
* Enquête portant sur1150 répondants
Illustration principale © LuckyStep - Adobe Stock