Kubernetes pour faciliter votre stratégie multi-cloud. Exemple avec un déploiement Druid

Kubernetes pour faciliter votre stratégie multi-cloud. Exemple avec un déploiement Druid

“Pour valoriser ses données, tous les chemins de l’innovation mènent au cloud” pourrait-on avancer, chaque jour un peu plus?
Sur ce sujet, le choix était jusqu’à présent cornélien : Innover (embrasser un écosystème foisonnant de technologies) ou Préserver son indépendance (Rester chez soi ou sur des offres cloud contraignantes)!
Face aux objections de gouvernance, sensibilité, indépendance, le manque de réversibilité des approches cloud ont longtemps pesé dans les reports de décisions stratégiques. Les choses sont en train de s’infléchir nettement :

Dans l’exemple illustré à travers cet article, nous traitons du portage d’AWS vers OVH, acteur Français que nous avons choisi pour ses travaux et investissements en cours. Les articles qui suivront démontreront cette portabilité sur tous les acteurs cloud significatifs.

 1  Propos Liminaire

• Pourquoi un déploiement de Apache Druid est un bon candidat ?

Nous avions mentionné à l’occasion d’un précédent article (http://www.novagen.tech/apache-druid-on-kubernetes-novagen/) les avantages de kubernetes(parfois raccourci en K8S) du point de vue élasticité(accompagner à la hausse et à la baisse les charges de travail) et résilience(capacité à redémarrer tout ou partie d’un service défectueux sans perte).
Il faut désormais placer au même niveau sa ‘portabilité’, pour caractériser le fait que Kubernetes est en passe de devenir un dénominateur commun de toutes les offres cloud, voire un standard ou même une norme, en témoigne le portefeuille de technologies de quelques acteurs incontournables :

1. Nous avons voulu véfifier que la promesse de transposition d’une solution Cloud définie vers une solution cloud concurrente ETAIT TENUE.
2. Nous avons également voulu vérifier l’EFFORT nécessaire, associé à cette promesse.

• Nous avons choisi de mettre en évidence AWS et OVH : Pourquoi ?

1. Parce que nous avons validé au préalable le portage de cette architecture entre AWS (notre point de départ) et Google Compute Engine (maître ès Kubernetes).
2. Parce que nous voulions tester un challenger (OVH) qui mise sur les standards et l’open source (OpenStack, Kubernetes) pour renforcer son attractivité.
3. Parce que nous voulions évaluer et mesurer les possibilités offertes et les éventuelles difficultés.rencontrées lors de la portabilité d’un cloud AWS vers un cloud Européen.

 2  Déploiement de notre solution sur Kubernetes

 1  Création de l’environnement Kubernetes

Objectif : créer le socle élastique, résilient, sécurisé …. de notre architecture.

• Chez AWS – EKS

La création et le déploiement sont entièrement pilotés par des scripts Terraform :

• Chez OVH – MKS

Le déploiement est largement automatisé mais requiert à ce jour un peu plus d’intervention humaine ou codée spécifiquement en dehors de Terraform : en particulier lors du lancement du cluster kubernetes et la récupération du fichier de configuration.

De AWS à OVHCloud : nous avons à cette occasion procédé à de légères retouches des fichier de déploiement kubernetes et de la configuration de Druid. celles-ci ont concerné :

• [K8S] Suppression des références à la gestion d’identité AWS IAM,
• [K8S] Simplification de la topologie réseau (Gateways, Subnet ),
• [Druid]Transposition des services AWS vers les services OVH (types de serveurs, S3 ⇔ Object Storage)
• [Druid] Paramétrage des credentials (Object Storage – S3)

 2  Déploiement des images

Objectif : déployer les différents services de notre architecture au travers de la création d’instances. Deux étapes sont nécessaires :

 a)  Construction (Build) et Publication des images docker

 b)  Affectation de nos images aux nodes de notre cluster kubernetes

In fine, nous voulons créer la répartition de services suivante :

Pour réaliser cette répartition, nous procédons au déploiement de Druid dans le service managé Kubernetes de OVHCloud selon cet enchaînement :

Pour réaliser le déploiement des images Docker, nous procédons avec kubectl :
“Kubectl est un outil en ligne de commande servant à contrôler des clusters Kubernetes”.
Voici, par exemple, la suite d’instructions qui exécutent les scripts d’affectations pour nos différents services Druid :

Pour superviser le déploiement et le fonctionnement de notre cluster, la commande suivante permet d’accéder à la console Web (aussi bien avec AWS que dans OVH Cloud) :

On y supervise toutes les ressources et il est possible d’effectuer des manipulations par interface graphique plutôt que par ligne de commande.

 3  Druid est lancé et opérationnel sur AWS et OVHCloud

Nous pouvons charger les données :

• depuis S3 pour AWS

• Grâce à la compatibilité OpenStack Swift avec S3, on procède EXACTEMENT DE LA MÊME MANIÈRE avec notre déploiement OVH.

Les données sont ensuite ingérées et analysables selon les mêmes mécanismes Druid.

Notre source de données est ensuite bien prise en compte et requêtable selon les dimensions que nous avons configurées .

Complétons ce déploiement Druid/K8S avec une solution de monitoring avancée.

Fort de notre investissement dans Kubernetes, nous l’avons également appliqué au monitoring des services :

• Captation des métriques : santé de nos services Druid,
• Mesures des temps de réponses Druid: pouvoir analyser les points performants et ceux en souffrance.

Nous avons donc créé des services embarquant les technologies TIG = Telegraf + InfluxDB + Grafana. Et nous avons ouvert les ports pour pouvoir accéder aux écrans de monitoring depuis notre poste de travail

 3  BILAN

Notre investissement initial sur Kubernetes pour faire de notre déploiement Druid sur AWS un processus fluide, automatique, reproductible, paramétrable s’est révélé un atout pour notre portage vers OVHCloud.
En moins de 2 jours , nous avons reconstitué notre architecture Druid et nous l’avons rendue opérationnelle avec de simples modifications de scripts.
L’offre AWS garde à ce jour quelques avantages pour l’automatisation complète du déploiement via Terraform.
Cette opération menée entre AWS et OVH peut être répétée désormais, quelles que soient les sources cloud de départ et d’arrivée (ou presque). Kubernetes en est une des clés.

1. La nécessaire portabilité des solutions cloud sera bientôt une réalité, au rythme où les améliorations sont apportées à l’écosystème.
2. Les stratégies multi-cloud ou encore cloud hybride seront alors beaucoup plus faciles à réaliser et permettront de choisir son empreinte chez les fournisseurs cloud, pour des raison de stratégie financière ou de souveraineté.
3. Sur ce point, il est indispensable qu’existent des acteurs cloud Européens et Français puissants, qui offrent des technologies et des niveaux de service en ligne avec les standards du marché.

Sur la base des principes exposés ici, Kubernetes confirme son intérêt majeur pour nos clients dont les patrimoines applicatifs sont complexes, nécessitent de la scalabilité, de l’élasticité, et de la réversibilité.