Depuis le 13 octobre, il ne reste plus grand-chose de Microsoft 365 chez Vecteur IT : mes mails, mes fichiers et ceux d’un de mes clients tournent sur des logiciels libres que j’héberge, sur mes clusters Kubernetes.

Je fais un rapide REX, parce que la migration s’est faite d’une façon un peu particulière : du début à la fin avec de l’IA agentique comme copilote (non pas Copilot). Environ 120 Go de mails et 560 Go de fichiers en trois semaines, sans perte de données.

Migration de WordPress vers Hugo sur Kubernetes

Entre 470 millions et 590 millions de sites WordPress sont déployés dans le monde. Si l’on migrait tous ces sites vers Hugo les gains serait les suivants:

1. Gain en Cycles CPU et RAM Infrastructure : La migration permettrait de supprimer la nécessité de millions d’instances de bases de données et de serveurs d’application. Un seul serveur standard pourrait héberger 10 à 50 fois plus de sites Hugo qu’il ne le fait pour WordPress, réduisant drastiquement le parc de serveurs physiques nécessaires.

2. Mémoire vive : En économisant une moyenne basse de 256 Mo de RAM par site WordPress et 256 Mo de RAM par base MySQL, le gain global se chiffrerait en pétaoctets de RAM libérés à l’échelle des centres de données mondiaux.

3. Réduction énergétique et CO2 Consommation par visite : Un site WordPress génère en moyenne 0,5 g de CO2 par vue de page. Un site statique optimisé descend souvent sous les 0,1 g.

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.

Après avoir sauvegardé un déploiement, il est maintenant temps de passer à la restauration.

Les déploiements correctement sauvegardés apparaissent  en vert dans la section compliant sur le portail Kasten:

En cliquant sur compliant on arrive sur le détail des applis sauvegardées. Sur chaque appli on verra le nombre de point de restauration s’afficher:

Dans mon cas 2 points car je n’ai eu qu’une exécution qui a fait un backup local et un export:

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)