Installation et configuration avancée de K3s avec Cilium

Dans cet article, nous allons explorer en détail l’installation et la configuration de K3s, une distribution légère de Kubernetes, en utilisant Cilium comme solution de mise en réseau (CNI). Cette configuration avancée nous permettra de remplacer certains composants par défaut de K3s par des alternatives plus performantes.

Pourquoi choisir Cilium ?

Par défaut, K3s est livré avec le CNI Flannel, un ingress basé sur Traefik, un load balancer basé sur Klipper, et le kube-proxy natif. Cependant, nous allons opter pour Cilium comme CNI, car il offre des fonctionnalités avancées, notamment un ingress et un load balancer intégrés, éliminant ainsi le besoin de composants supplémentaires comme MetalLB.

Dans le billet précédent j’ai installé KASTEN K10. Maintenant il est temps l’utiliser et de planifier des sauvegardes.

Dans K10 les stratégies de sauvegardes sont appelées Policies. Pour créer une nouvelle stratégie de sauvegarde il faut aller dans la partie Policie à partir du portail d’accueil:

On va créer une policy journalière afin d’effectuer un sauvegarde par jour:

On va donc indiquer un nom (daily dans mon cas), une action (snapshot pour sauvegarder) une fréquence(journalière)

Apres l’installation du nouveau cluster vient le moment de la migration.

Pour réaliser cette opération il existe un outil indispensable à toute installation de cluster kubernetes: Kasten

Il permet de réaliser les sauvegardes non seulement des stockages persistants, mais de tout votre déploiement.

Il permet aussi d’exporter les sauvegardes réalisées vers le clous (aws, azure…) ou sur un stockage générique S3 (MinIO ou autre)

Et lors des restaurations, il permet de restaurer en modifiant par exemple le storage-class, se qui permet par exemple d’importer une sauvegarde qui n’aurait pas les memes classes de stockage qu’a la source: donc, no problemo pour sauvegarder un cluster OnPrem, et le restaurer dans le cloud ou vice-versa…

L’histoire

Depuis fin 2020, la chose était connue, le support de Docker au sein de kubernetes allait être abandonné. Cet abandon sera réellement  effectif dans la version 1.24. La version RKE1 quant à elle s’appui sur docker et surement n’évoluera pas. Mais Rancher a une autre version : RKE2.

Cette nouvelle distribution de Kubernetes s’appuie sur ContainerD. Exit docker et dockershim. Donc pas de problème d’évolution future sur cette version. En revanche, il n’existe aucune possibilité a l’heure actuelle de faire une migration dite in-place.

Et oui , rien à voir avec Microsoft, mais j’ai décidé de faire un rapide REX sur ces solutions là, que j’utilise depuis un bout de temps pour héberger différentes applications et sites web.

Quand j’ai commencé mon activité d’indépendant il y a maintenant 13 ans, j’ai auto-hébergé, sites web et applications, sur l’OS que je connaissait bien: Windows.

Mais voila, après avoirs fait le tour de la question je me suis lassé et pleins de nouvelles solutions apparaissaient, notamment les containers Docker apparaissaient.