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.
Mon infrastructure actuelle RKE1 étant sous forme de VM, il était temps de se poser la question de l’intérêt de la virtualisation dans ce type d’infra. J’en suis venu au point de me débarrasser de l’infrastructure Hyper-V pour monter un infrastructure 100% physique, 100% pure :).
L’infrastructure matérielle
Dans un datacenter, l’une des problématiques est l’encombrement. Pour cette nouvelle infrastructure il faudrait quelle soit contenue. L’objectif était de réaliser 2 clusters indépendants avec chacun 6 noeuds.
Apres quelques recherche la solution fut de me tourner vers un ensemble de serveurs compacts, et l’aide d’un ancien collègue, François Jeanmougin Senior Achitect chez Supermicro, nous avons opté pour le chassis 3U SYS-530MT-H12TRF .
Ce châssis rack 3U proposé intègre 12 lames/serveurs peuplés d’un mono processeur Xeon E-2378 8C/16T , de 16Go de ram et de 4 SSD Entreprise de 250 Go.
Il répond donc parfaitement a mon critère principal: le faible encombrement et la haute densité de serveurs.
L’infrastructure logicielle
L’installation RKE2 peut être faite comme RKE1 a l’aide de Rancher. Dans Rancher lors de la création du cluster placer le curseur sur RKE2 et créer le Custom Cluster
Pour l’occasion de ce déploiement, j’utiliserai comme cni cilium plutôt que Calico. Cilium permet de se passer d’iptable et d’utiliser ebpf a la place qui est plus performant. Il dispose en plus d’interface afin de visualiser le trafic réseau. Il y a aussi un super outil qui permet de générer les network policy ici
Ensuite il sera nécéssaire de retoucher le déploiement afin de configurer Cilium pour ne pas utiliser kube-proxy entre les noeuds mais utiliser le routage direct, et activer hubble, l’interface de visualisation du trafic réseau:
Une fois déployé on peut constater que le container runtime est bien containerD:
Il ne reste plus qu’a installer cert-manager pour la génération des certificats ssl pour les déploiements, Portworx pour le stockage persistant, et Kasten pour effectuer les sauvegarde et migrations.
Kasten est vraiment un super outil pour permettre d’effectuer une migration simple et rapide entre le cluster RKE1 et le nouveau cluster RKE2.
J’en profite pour vous partager l’outils de gestion de K8s que j’affectionne particulièrement: Lens
Un super outil qui a notamment l’avantage de pouvoir proxyfier le service d’un pod localement d’un simple clic:
Très pratique si l’on a pas publié via Ingress un service 🙂
Donc prochaine étape et prochain billet: Installation, configuration et migration à l’aide de Kasten !!!