Réinventer le Serverless avec Knative

Lors de la dernière Google Next, Google a annoncé un nouveau produit Open Source, Knative. Ce projet ambitionne de standardiser les déploiements serverless en utilisant Kubernetes comme moteur.
Ce qui était une version alpha complexe et peu stable devient au fil des mois un outil de plus en plus puissant et fiable.

Qu’est ce que Knative ?

Il serait faux de dire que Knative est un simple logiciel, car en fait Knative c’est aujourd’hui trois composants distincts partageant une base commune. Ces trois composants sont :

  • Serving : Service de conteneurs avec scaling de 0 à N
  • Eventing : Système de gestion et traitement des événements
  • Build : Système de build

Chacun d’entre eux est spécialisé dans son domaine et cherche à répondre à une seule problématique.

Dans la suite de cet article, nous ferons un focus sur le composant Serving. Ce choix n’est pas totalement le fruit du hasard, car depuis de nombreux mois, plusieurs solutions Open Source tentent de reproduire les offres “Functions” des grands fournisseurs de cloud. Qu’il s’agisse de Google Cloud Functions, AWS Lambda, ou Azure Functions, cette capacité à exécuter de simples morceaux de code a ouvert de nouvelles possibilités dans la construction d’architectures cloud native.

Quelques initiatives très suivies ont vu le jour, comme OpenFaaS, OpenWhisk, ou Fission. Knative Serving s’inscrit dans le même paysage et ouvre la voie vers une standardisation et réutilisabilité en se servant de conteneurs exécutés sur Kubernetes.

Installation du composant Knative Serving

A la racine de toute installation de Knative, il y a un cluster Kubernetes. Ce cluster peut être déployé n’importe où, de même que les workloads déployés sont totalement agnostiques du lieu d'exécution ou du fournisseur de cloud.

Pour cela, je vous propose de simplement installer un cluster Kubernetes sur Google Cloud, et pour aller encore plus vite, vous trouverez une recette Terraform prête à l’emploi sur mon lab Knative.

cd 00_knative_on_gcp
terraform init
terraform apply

Maintenant que nous avons un cluster Kubernetes fonctionnel, nous devons nous authentifier dessus, un script est à votre disposition dans le même répertoire pour simplifier l’accès et vous octroyer également des permissions cluster-admin :

bash configure_credentials.sh

Le cluster est prêt à accueillir Knative, vous noterez que nous avons activé le nouvel add-on Istio sur GKE. En effet, Knative s’appuie grandement sur Istio pour gérer sa partie réseau. Il aurait été possible de l’installer séparément mais autant profiter de l’installation via add-on sur GKE. Nous pouvons maintenant installer Knative et configurer Istio :

kubectl label namespace default istio-injection=enabled
kubectl apply -f https://github.com/knative/serving/releases/download/v0.3.0/serving.yaml

Plusieurs Custom Resources (CRD) sont créées et plusieurs deployments également pour offrir le service Knative. Après la fin du déploiement, un nouveau type de ressource est utilisable par la commande kubectl ksvc (Knative Service) :

kubectl get ksvc

Déploiement d’une application

Notre cluster étant actif, déployons un service dessus. Au sens Knative Serving pas besoin de séparer la notion de service et de deployment, seul un service est utilisé. En fait, cela est tout à fait logique car nous avons seulement besoin de déployer le point d’accès, ensuite le déploiement réel de la partie exécution sera fait à la demande :

kubectl apply -f helloworld.yaml
kubectl get ksvc
kubectl describe ksvc helloworld

Au bout de quelques minutes, le service sera prêt à accueillir des requêtes, pour cela forgeons une requête avec l’outil cURL.

KNATIVE_INGRESS=$(kubectl get service --namespace=istio-system istio-ingressgateway --output=jsonpath="{.status.loadBalancer.ingress[0].ip}")
KNATIVE_HELLO=$(kubectl get ksvc --namespace=serving helloworld --output jsonpath="{.status.domain}")

curl -H "Host: ${KNATIVE_HELLO}" http://${KNATIVE_INGRESS}

Pour aller plus loin

Pour achever cette rapide démonstration, on peut aller plus loin en configurant un domaine spécifique afin d’éviter d’avoir à forger une requête, ainsi nous pouvons exposer directement le service issu de Knative Serving

Configure custom domain

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-domain
  namespace: knative-serving
data:
  knative.wescale.fr: ""

D’autres configurations sont disponibles directement dans la documentation de Knative Serving.

Pour conclure Knative est en développement actif et évolue vite, n’hésitez pas à suivre et à y contribuer !

Bastien Cadiot

Spécialisé en OpenSource et GoogleDevExpert Cloud, Bastien est passionné par la conception de systèmes évolutifs. Il pense que chaque besoin est unique et cherche des solutions toujours adaptées.