L’ARM a toujours eu une place particulière chez Scaleway. C’est grâce à cette architecture qu’ont été lancées les toutes premières Instances en 2014, les C1, que nous avions construites sur du matériel conçu en interne et fabriqué en France. À l’époque, nous étions les premiers au monde à lancer des instances sur une architecture de processeur ARM, et c’est d’ailleurs ainsi que Scaleway est née.
Techcrunch avait rédigé quelques articles à ce sujet: Online Labs designed its own ARM servers to take on AWS, qui revient sur notre toute première offre ARM, ainsi que Scaleway thinks the future of cloud hosting is ARM-based servers, qui vous explique pourquoi nous pensons que l’ARM a de l’avenir.
L'écosystème a depuis mûri et une nouvelle gamme a vu le jour grâce au processeur Altra Max d'Ampere Computing. Ce processeur change la vision de petit SoC (System on a Chip) pour téléphone et la fait évoluer vers des usages Datacenter avec une forte puissance de calcul.
Le mois dernier, nous avions annoncé le retour de l’ARM dans notre catalogue: les Instances AMP2, sorties sous forme d’essai public. Elle vous offre des performances élevées tout en préservant une consommation d'énergie relativement faible.
Les Instances AMP2 sont dès aujourd’hui compatibles avec Kosmos, notre offre Kubernetes de contrôleur dédié, qui permet de gérer des nœuds où qu’ils soient hébergés. Du point de vue de Kubernetes, l’architecture ARM64 est supportée depuis toujours, et beaucoup d’images docker parmi les plus populaires sont disponibles sur cette architecture. Nous pouvons donc simplement intégrer des nœuds ARM64 sur un cluster Kubernetes.
Nous allons maintenant nous concentrer sur le déploiement de Kosmos. En créant un node pool externe sur un cluster Kosmos, et en appliquant le script d’installation (avec quelques modifications mineures pour télécharger les paquets ARM64 au lieu de packet AMD64), de nouveaux noeuds AMP2 pourront être ajoutés au cluster. Après plusieurs minutes d’installation, je les ai vues se connecter au control-plane, et doucement tirer les différentes images OCI nécessaires à son fonctionnement. Il se trouve que toutes les images utilisées ont été build nativement et disponibles via le support multi-architecture.
Vous trouverez plus d'informations ainsi qu’un tutoriel pour créer votre cluster Kubernetes multi-cloud sur notre plateforme de documentation. Lors de l'ajout d'un nouveau node, il vous faudra remplacer amd64 par arm64 dans les commande d'installation comme ceci:
wget https://scwcontainermulticloud.s3.fr-par.scw.cloud/node-agent_linux_arm64 && chmod +x node-agent_linux_arm64
sudo ./node-agent_linux_arm64 -loglevel 0 -no-controller
Après de nombreux tests, mon déploiement fonctionne parfaitement, le load-balancer forward bien le trafic sur mes nodes ARM sans difficultés. La fonctionnalité d'auto-scaling des noeuds ne sont bien sûr pas fonctionnelles pour ce type de node pool vu que leur installation est manuelle, j’ai donc gardé quelques node en AMD64. J’ai donc un cluster Kubernetes multi-architecture qui tourne parfaitement.
Dans cet article, nous allons distinguer les différentes méthodes d'autoscaling fournies par Kubernetes et comprendre les différences entre l'horizontal pod autoscaler et le vertical pod autoscaler.
Vous pouvez désormais profiter de notre control plane managé et haute disponibilité pour créer vos clusters de conteneurs. Découvrez Kubernetes Kapsule dans cet article