Mise en oeuvre d’un cluster Kubernetes dans une instance AMD EPYC de Scaleway via Rancher et Multipass : introduction au No-Ops avec DevSpace …

Image for post
Image for post

Scaleway propose une nouvelle gamme d’instances entièrement basée sur AMD EPYC allant de 4 à 48 cœurs, de 16 à 256 Go de mémoire, de 150 à 600 Go de stockage (SSD) et de 0,4 à 2 Gb/s de bande passante. Le tout, pour un tarif variant de 39 à 569 euros par mois, pouvant être facturé à l’heure. De fait, après avoir été un des premiers à miser sur des solutions ARM « BareMetal », Scaleway migre une bonne partie de son offre d’hébergement sur des serveurs EPYC d’AMD, au détriment d’Intel :

Image for post
Image for post
Image for post
Image for post

Je commence par créer une instance x86 dans Outscale qui hébergera le serveur Rancher 2.2.0 RC4 :

Image for post
Image for post
Image for post
Image for post

J’installe un client ZeroTier pour initier une liaison VPN qui servira à la jonction entre différentes instances. Le serveur Rancher est accessible via une adresse IP fournie via ZeroTier :

Image for post
Image for post
Image for post
Image for post

Je lance alors une instance GP1-XS à 4 coeurs, un stockage SSD de 150 Go et 16 Go de RAM dans Scaleway mettant en oeuvre ces processeurs AMD EPYC :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

avec les extensions de virtualisation actives :

Image for post
Image for post

Propriétés spécifiques à cette génération de processeur AMD:

Image for post
Image for post

Et j’y installe Multipass que l’on a vu dans un précédent article :

sudo snap install multipass --beta --classic
Image for post
Image for post

Avec multipass je lance 3 machines virtuelles dans cette instance de Scaleway :

Image for post
Image for post

Ces VMs sont reliées au réseau VPN via ZeroTier :

Image for post
Image for post

Je retourne sur la console du serveur Rancher pour initier la création d’un cluster Kubernetes avec ces VMs imbriquées nouvellement créées :

Image for post
Image for post

Création du noeud maître du cluster Kubernetes :

Image for post
Image for post
Image for post
Image for post

et des deux autres noeuds du cluster :

Image for post
Image for post
Image for post
Image for post

Le cluster Kubernetes est actif :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

J’ajoute l’ensemble des cataloguesde Charts fournis avec Helm :

Image for post
Image for post
Image for post
Image for post

et que l’on peut retrouver avec Bitnami via le Hub de KubeApps : https://hub.kubeapps.com/

Image for post
Image for post

J’active le monitoring au sein du Cluster Kubernetes via le portail du serveur Rancher avec Prometheus et Grafana :

Image for post
Image for post
Image for post
Image for post

Le dashboard Grafana devient accessible avec la visualisation d’un ensemble de métriques :

Image for post
Image for post
Image for post
Image for post

Il ne me reste plus qu’à effectuer le test No-Ops avec DevSpace. Pour rappel, NoOps (No Operations) — l’absence de personnel d’exploitation — est un concept selon lequel un environnement informatique a atteint un niveau d’automatisation et de virtualisation suffisant, par rapport à son infrastructure sous-jacente, pour que plus aucune équipe interne ne soit nécessaire à l’administration de l’infrastructure logicielle :

Image for post
Image for post

Le concept NoOps se distingue de celui de DevOps. En effet, dans ce dernier, la frontière entre les équipes de développement et d’exploitation devient floue, les membres de chaque équipe pouvant endosser certaines responsabilités de l’autre. Mais aucune des deux ne disparait. DevSpace permet de conteneuriser rapidement des applications existantes et d’utiliser les ressources comme les fichiers Dockerfile dans son projet. Le processus d’initialisation crée et vérifie tout ce qui a été créé. L’interface CLI de DevSpace est un outil open-source en ligne de commande qui permet de créer des espaces DevSpace et de les connecter à son de travail local :

Image for post
Image for post
Image for post
Image for post

Sous linux cela passe avec ces lignes de commande :

curl -s -L "https://github.com/devspace-cloud/devspace/releases/latest" | sed -nE 's!.*"([^"]*devspace-linux-amd64)".*!https://github.com\1!p' | xargs -n 1 curl -L -o devspace && chmod +x devspace;
sudo mv devspace /usr/local/bin;
Image for post
Image for post

Je récupère via Git les sources du dernier démonstrateur FranceConnect Particulier. DevSpace utilise Docker pour construire des images de containers, vous avez donc besoin de Docker localement pour initier DevSpace :

Image for post
Image for post

La construction de l’image Docker étant réalisée localement il n’y a plus qu’à la pousser ici vers le Docker Hub puis à la déployer dans un Pod au sein du cluster Kubernetes :

Image for post
Image for post
Image for post
Image for post

L’image apparaît au sein du Docker Hub avec ce tag :

Image for post
Image for post

et dans le portail du serveur Rancher avec ces deux Pods :

Image for post
Image for post

Sur la base de l’Ingress Controller fourni par défaut avec Nginx dans le cluster Kubernetes, je lance un accès sur la base d’un domaine Wildcard via xip.io

Image for post
Image for post
Image for post
Image for post

Le démonstrateur FCP est accessible :

Image for post
Image for post

En complément je peux initier un processus GitOps via Weave Cloud qui permet également de superviser le cluster Kubernetes :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Je lie mon projet dans Weave Cloud avec le dépôt Github et celui sur Docker Hub :

Image for post
Image for post

Une modification du Dockerfile dans Github entraîne la recréation d’une nouvelle image Docker du démonstrateur FCP ainsi que son redéploiement dans le cluster Kubernetes :

Image for post
Image for post

Je passe ici à la version 11 de l’image Alpine de Node.js :

Image for post
Image for post
Image for post
Image for post

Je réaccède au portail FCP mis à jour dans le cluster Rancher :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

et les notifications sont faites dans un canal Slack préconfiguré :

Image for post
Image for post

L’informatique sans serveur est le rêve d’un développeur non seulement parce qu’il n’a plus besoin de s’inquiéter de l’endroit où le code va être exécuté, mais aussi parce qu’il n’a pas besoin d’un accès direct au système d’exploitation pour gérer ce code. Le résultat : Les développeurs peuvent se concentrer uniquement sur le codage, ce qu’ils font le mieux. Les deux principaux moteurs de l’approche NoOps selon une définition officielle, sont l’accroissement de l’automatisation IT et le Cloud computing. En poussant le concept à l’extrême, une organisation NoOps n’aurait aucun employé chargé de l’exploitation ; toutefois, divers autres systèmes méritent également le label « NoOps ». Par exemple, certains fournisseurs de solutions PaaS (Platform-as-a-Service) qualifient leurs offres de plateformes NoOps.

Image for post
Image for post
Deloitte Analysis

Quand à l’usage des processeurs AMD EPYC, il s’agit d’une offre qui occupe désormais le gros du terrain du catalogue de Scaleway, une claque pour Intel qui se retrouve marginalisé dans les solutions d’entrée de gamme, jusqu’à 8 cœurs, aux côtés d’ARM. Un tel choix est une première pour un service d’infrastructures Cloud.

Image for post
Image for post

A suivre ! …

Quelques liens à ce sujet :

Above the clouds, the sky is always blue ...

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store