Serverless : Installation de Knative Serving sur un cluster Kubernetes via Gloo, Rancher, Kontena Pharos et des instances Azure basse priorité. Mise en oeuvre rapide du Chaos Engineering via Gremlin …
Knative Serving s’appuie sur Kubernetes et ici Gloo pour déployer et servir des applications et fonctions sans serveur. Le service est facile à mettre en place et s’adapte à des scénarios avancés. Knative Serving fournit des primitives middleware qui activent un déploiement rapide de containers serverless, un scaling up et down à zero de manière automatique ou des instantanés ponctuels du code et des configurations déployés …
Pour arriver à cette architecture, je commence par lancer des instances basse priorité sur des groupes identiques (VMSS Low Priority) dans Azure que l’on pourrait comparer aux instances préemptibles dans Google Cloud (avec une durée de vie limitée et un prix très réduit jusqu’à 80%) :
Je peux partir du template JSON acoompagné du fichier de paramètre :
Je lance le déploiement qui se termine en quelques minutes :
Je récupère Pharos qui va me permettre d’initier la création d’un cluster Kubernetes rapidement dans ces instances Azure basse priorité :
Je récupère donc le binaire sur le site de Kontena Pharos :
et je créé un fichier de configuration cluster.yml :
Et je lance la création du cluster Kubernetes :
Le cluster est disponible avec les adresses IP publiques :
Je raccorde ce cluster Kubernetes à une instance où tourne Rancher Server dans Outscale :
Et j’importe ce cluster Kubernetes :
Je peux activer le monitoring offert dans ce cluster via Grafana et Prometheus :
Je peux initier Knative Serving dans ce cluster Kubernetes via Gloo :
Gloo est un Ingress Controller natif dans Kubernetes, et un API Gateway de nouvelle génération. Gloo prend en charge des applications legacy, des microservices et le serverless. Il possède des capacités de découverte et une intégration étroite avec les principaux projets open-source. Gloo est spécialement conçu pour prendre en charge les applications hybrides, dans lesquelles de multiples technologies, architectures, protocoles et clouds peuvent coexister …
Je récupère le binaire Glooctl pour linux depuis Github :
ou via une ligne de commande :
et je lance l’installation de Knative Serving :
J’arrive donc à cette configuration :
Je peux lancer le test du fameux Helloworld en Go via la création d’un fichier helloworld.go :
accompagné de son Dockerfile :
et d’un template YAML pour le déploiement d’un service Helloworld dans ce cluster via Knative Serving :
Et je lance sur l’instance Master du cluster Kubernetes la construction de l’image Helloworld :
Je lance le déploiement dans le cluster :
kubectl apply --filename service.yamlet je peux invoquer ce service Helloworld :
Dans le tableau de bord du serveur Rancher je peux voir le POD et les namespaces impliqués dans ce service Helloworld :
Il ne me reste plus qu’à initier un test rapide de « Chaos Engineering ». Cette approche consiste à générer des pannes volontairement dans l’architecture de production afin d’observer les conséquences de cette défaillance, in-situ. L’objectif de cette démarche est de prendre des mesures qui permettront de contrer l’éventuel effet papillon. Cet effet qui peut se manifester de manière imprévue sur la plateforme de production et qui n’a pu être détecté en pré-production.
Pour cela je m’appuie sur la plateforme SaaS Gremlin :
Je commance par installer les agents Gremlin dans le cluster Kubernetes :
Je vois apparaître les hôtes du cluster Kubernetes dans le dashboard Gremlin ainsi que les containers :
et je peux créer une attaque sur le CPU de certains PODs :
Lancement du test qui se termine avec un rapport d’exécution :
et qui se visualise dans Grafana sur des pics de charge CPU sur certains PODs et sur les hôtes du cluster :
Pour conclure, on a vu que Knative (projet initié par IBM et Google en juillet 2018) fournit un ensemble de composants middleware nécessaires à la création d’applications modernes basées sur des conteneurs et axées sur la source, qui peuvent s’exécuter dans n’importe quel environnement : sur site, dans le cloud et même dans un centre de données tiers. Les composants Knative s’appuient sur Kubernetes et codifient les bonnes pratiques partagées par des frameworks réels basés sur Kubernetes. Les développeurs peuvent ainsi se concentrer sur l’écriture du code plutôt que de gérer les aspects fastidieux de la création, du déploiement et de la gestion d’une application. En conjonction de Knative Serving, on retrouve Knative Build (qui utilise les primitives Kubernetes existantes pour vous fournir la possibilité d’exécuter des constructions de conteneurs sur cluster à partir des sources) ou Knative Eventing (système conçu pour répondre à un besoin commun de développement en mode Cloud Native et qui fournit des primitives composables pour créer des sources d’événements à liaison tardive et des consommateurs d’événements) …
A suivre !
Quelques liens à ce sujet :
