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.

   ...

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)

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…