DEV Community

Karim
Karim

Posted on • Originally published at deep75.Medium on

Amazon EKS Distro dans un clone privé d’AWS avec Eucalyptus et Equinix Metal …

Depuis plus d’une décennie, Eucalyptus a permis de créer un environnement de cloud hybride ou privé compatible AWS en émulant les principales API AWS sur sa propre infrastructure. La plate-forme est passée sous le contrôle de HP en 2014, mais en 2017 (à la suite de la suppression par HP de ses activités de services aux entreprises), AppScale a commencé à offrir des services d’assistance aux entreprises liés à Eucalyptus, qui elle-même est une plate-forme entièrement “Open Source”.

L’écosystème de l’eucalyptus a été relativement calme depuis lors, sans aucune annonce majeure. Mais la plate-forme reste bien vivante. Il continue de fournir un moyen parfaitement viable de créer un cloud compatible AWS dans un centre de données privé ou d’intégrer une infrastructure privée avec des centres de données AWS publics sans s’appuyer sur un cadre propriétaire comme AWS Outposts.

Four Major Open Source Hybrid Cloud Platforms

Je vais donc tester l’installation d’Eucalyptus dans un serveur Bare Metal d’Equinix Metal dans la region de Francfort :

En prenant le mode Spot :

Je pars dans ce serveur Bare Metal avec une distribution CentOS 7 64 Bits :

J’utilise le mode FastStart pour exécuter Eucalyptus sur ce serveur unique :


bash <(curl -Ls https://get.eucalyptus.cloud)
Enter fullscreen mode Exit fullscreen mode

Au préalable j’ai relié un segment d’adresses IPV4 publique à ce serveur dans la console d’Equinix Metal :

Le script d’installation d’Eucalyptus va lancer en arrière fond une série de playbooks Ansible :

L’installation se termine en 20/30 minutes environ …

Je configure la clé publique d’accès aux instances, les identifiants de la console Eucalyptus et les règles par défaut du groupe de sécurité …

Je récupère une image Cloud d’Ubuntu 20.04 LTS avec ce script Python :

python <(curl -Ls https://eucalyptus.cloud/images)
Enter fullscreen mode Exit fullscreen mode

Je peux alors me connecter à la console d’Eucalyptus :

Je dispose donc de mon image Ubuntu 20.04 LTS :

AWS CLI est utilisable immédiatement avec l’installation d’Eucalyptus :

Lancement de trois instances Ubuntu 20.04 LTS

qui vont lancer un cluster Amazon EKS Distro avec l’aide de Snap :

sudo snap install eks --classic --edge
Enter fullscreen mode Exit fullscreen mode

Pour rappel, Amazon EKS Distro est une distribution Kubernetes utilisée par Amazon EKS pour aider à créer des clusters fiables et sûrs. Vous pouvez déployer EKS Distro partout où vos applications doivent être exécutées.

Vous pouvez déployer des clusters et laisser AWS se charger de tester et de suivre les mises à jour, les dépendances et les correctifs de Kubernetes. Chaque EKS Distro vérifie la compatibilité des nouvelles versions de Kubernetes. Le code source, les outils open source et les paramètres sont fournis pour des constructions reproductibles. EKS Distro fournira un support étendu pour Kubernetes, avec des compilations de versions précédentes mises à jour avec les derniers correctifs de sécurité. EKS Distro est disponible en open source sur GitHub.

Ici c’est l’implémentation par Canonical et basée sur MicroK8s qui est utilisée …

Les instances sont en exécution avec Amazon EKS Distro …

Je crée les tokens pour former mon cluster Kubernetes avec ces trois noeuds :

Install Amazon EKS Distro anywhere | Ubuntu

Je peux alors joindre les deux noeuds avec ces tokens :

Le cluster Kubernetes est alors actif avec ces trois instances :

Avec le segment d’adresses IPV4 fournies dans Equinix Metal, je procède à l’installation de MetalLB :

MetalLB, bare metal load-balancer for Kubernetes

avec cette configuration en DHCP :

Je peux procéder encore une fois au déploiement du sempiternel démonstrateur FC avec ce fichier YAML :

Le démonstrateur FC devient accessible :

Pour plus de visibilté au sein de ce cluster, je peux installer la console OKD disponible sous la forme d’images Docker dans Quay.io :

Quay

comme on avait pu le voir dans un précédent article. En effet, la console Web OKD est une interface utilisateur accessible depuis un navigateur Web. Les développeurs peuvent utiliser la console Web pour visualiser, parcourir et gérer le contenu des Namespaces. Il est également plus aisé et plus convivial d’utiliser la forme d’une application Web que le client Kubectl. Il s’intègre à d’autres services tels que la surveillance, la rétrofacturation et l’Operator Lifecycle Manager ou OLM :

Medium

Lorsque la console Web est accessible à partir d’un navigateur, elle charge d’abord toutes les ressources statiques requises. Effectue ensuite des requêtes auprès de l’API Kubernetes en utilisant les valeurs définies en tant que variables d’environnement dans l’hôte sur lequel la console est exécutée.

J’utilise ce fichier YAML pour le déploiement de la console OKD : l’idée d’exécuter la console Web comme un autre pod. L’idée est de tirer parti de la version conteneurisée disponible en tant que console d’origine dans le référentiel d’images du conteneur OpenShift et de l’exécuter dans un cluster Kubernetes en tant qu’application régulière, ici comme un pod …

Exposition de la console OKD avec Cloudflared dans cet exemple :

Releases · cloudflare/cloudflared

La console OKD est disponible avec des informations complémentaires à celle du dashboard Kubernetes :

et sur les déploiements en particulier :

Le tout avec ces ressources consommées disponibles dans ce serveur Bare Metal …

Si vous créez un cloud hybride aujourd’hui, il est plus probable qu’improbable que vous utilisiez une plate-forme propriétaire, comme Azure Arc ou AWS Outposts. L’écosystème de cloud hybride moderne est dominé par des offres comme celles-ci. Pourtant, les solutions de cloud hybride open source se maintiennent discrètement, offrant une alternative aux organisations qui hésitent à s’engager sur une plate-forme propriétaire pour la mise en place et la gestion d’un cloud hybride.

L’open source reste bien vivant dans le monde du cloud hybride, même si les solutions open source dans cet espace n’ont pas fait la une des journaux ces dernières années que les alternatives propriétaires. Les frameworks hybrides à source fermée sont sans doute plus faciles à utiliser et offrent de meilleures intégrations prêtes à l’emploi (au moins avec les environnements que leurs fournisseurs choisissent de prendre en charge), mais si vous voulez des coûts inférieurs, moins de risque de verrouillage et plus flexibilité, une plate-forme cloud hybride open source pourrait mieux répondre à vos besoins …

À suivre !

Top comments (0)