Knative : De quoi s'agit-il et pourquoi devriez-vous vous en soucier?

Donner un sens à la plate-forme native Kubernetes pour les développeurs

Ce tutoriel va vous apprendre Knative, un outil pratique pour les développeurs en environnement Kubernetes.

Un espace de discussion est disponible sur le forum pour recevoir vos avis. Commentez Donner une note  l'article (5)

Article lu   fois.

L'auteur

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Introduction

On a beaucoup parlé ces derniers temps des serveurs sans serveur, Kubernetes et Knative. Commençons donc par expliquer comment Knative s’intègre dans cet écosystème et ce qui le rend unique. Knative est idéal pour les développeurs d'applications qui utilisent déjà Kubernetes, en leur fournissant des outils leur permettant de se concentrer moins sur l'infrastructure et la plomberie et davantage sur le code qu'ils écrivent.

Cette mission n’est pas très différente des autres plates-formes sans serveur, mais là où la plupart des plates-formes ont une approche descendante consistant à fournir une nouvelle interface centrée sur le code, Knative se concentre sur la construction de ces outils et services de manière à rehausser l’expérience Kubernetes existante.

Cela fournit à une classe de développeurs en croissance constante (utilisateurs de Kubernetes) des avantages immédiats et facilite le développement sans serveur. À cette fin, Knative est construit avec les mêmes modèles (contrôleurs), API (kube-api) et infrastructure (ressources kubernetes) que Kubernetes lui-même. Knative fournit également une fonctionnalité évolutive à zéro, qui permet une utilisation à coût zéro pour les applications inactives et des déploiements Bleu / Vert pour tester de nouvelles versions de vos applications sans serveur.

II. Les composants Knative

Knative comprend trois composants principaux :

  • Serving fournit une fonctionnalité de calcul basée sur une requête évolutive. Il s’agit essentiellement d’ un ensemble de sous-composants d'exécution et de dimensionnement d'une plate-forme sans serveur ;
  • Build fournit une fonctionnalité expressive d’exécution complète qui est utile pour créer des flux de travail CI / CD. Serving utilise Build pour transformer un référentiel source en une image de conteneur contenant votre application ;
  • Eventing fournit des mécanismes d'abonnement et de livraison abstraits qui permettent de créer des applications sans serveur, couplées de manière lâche et basées sur des événements.

Il est important de noter que Knative vise à ce que ses composants (et beaucoup d'autres sous-composants) soient couplés de manière lâche. Cela signifie que les fournisseurs de services et les utilisateurs devraient pouvoir mélanger, faire correspondre et remplacer ces composants comme bon leur semble. Par exemple, bien que Serving puisse utiliser Build pour transformer votre référentiel source en une application sans serveur, un utilisateur averti peut également implémenter sa propre machine Build, qui utilise une autre plate-forme de construction mais utilise toujours la distribution Knative.

III. Description du composant Serving

Dans cet article, nous allons nous concentrer sur le composant Serving car il s’agit d’un point de départ naturel pour la plongée dans Knative. Un utilisateur du service de Knative doit connaître quatre ressources principales: Revision, Configuration, Route et Service.

Image non disponible

Source:  https://github.com/knative/docs/tree/master/serving

Revision  : ceci représente une instance unique de votre application. Cette instance contient une image et un ensemble d'options de configuration spécifiques (options telles que des variables d'environnement) sous une forme immuable. Elle est responsable de la gestion des ressources pour les réaliser, y compris le déploiement de Kubernetes qui exécute votre application.

Configuration  : il s'agit de l'interface permettant de créer des révisions. La gestion du cycle de vie des applications s'effectue donc principalement via cette ressource. Pensez à cela comme à votre script de déploiement : une configuration est responsable de la définition de l'image de l'application et de sa configuration, cette configuration est similaire à une révision, sauf que ces valeurs sont mutables. Cela permet de mettre à jour une variable d'environnement ou une balise d'image dans une configuration afin de déployer une nouvelle version. Chaque fois que ces valeurs sont modifiées, une nouvelle instance de l'application (révision) est créée. Par conséquent, il y a toujours au moins une révision pour une configuration donnée.

Route  : le trafic dirigé vers une révision spécifique se produit via cette ressource. Lorsque vous utilisez un service pour un déploiement simple, vous n'avez pas souvent besoin de connaître cette ressource, car elle fonctionne dans un mode par défaut en envoyant tout le trafic à la dernière révision (la plus récente). Les utilisateurs peuvent également utiliser cette ressource pour spécifier des fractionnements de trafic en pourcentage (par exemple, les déploiements a / b où 10% du trafic passe à la révision 2 et 90% à la révision 1). Ce sujet n'est pas traité dans cet article, mais vous pouvez trouver une démonstration de cette fonctionnalité ici : https://github.com/knative/docs/tree/master/serving/samples/traffic-splitting .

( Knative ) Service  : à ne pas confondre avec la ressource de service Kubernetes, ce service Knative est la ressource de niveau le plus élevé reliant une application complète sans serveur. Pour une utilisation simple (comme notre exemple hello-world ci-dessous), il s'agit de la seule ressource avec laquelle les utilisateurs doivent interagir pour déployer leur application. Lorsqu'un service est créé, une route et une configuration sont également créées, lesquelles sont expliquées plus en détail ci-dessous.

IV. Exemple d’application « Bonjour le monde ! »

Nous supposerons que vous avez une installation Knative fonctionnelle et un accès kubectl au cluster Knative. (Voir https://github.com/knative/docs/blob/master/install/README.md pour plus d'informations sur l'installation de Knative.)

Définissons le service Knative suivant en utilisant kubectl en écrivant le contenu suivant dans un fichier (service.yaml) et en exécutant:

 
Sélectionnez
$ kubectl -f service.yaml

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  runLatest:
    configuration:
      revisionTemplate:
        spec:
          container:
            image: <helloworld-go docker image>
            env:
            - name: TARGET
              value: "Go Sample v1"

C'est tout ce dont nous avons besoin pour créer une instance de l'application helloworld-go basée sur des requêtes.

Recherchez l'adresse IP où vous pouvez accéder à votre application en copiant le champ IP EXTERNE à partir de la commande suivante:

 
Sélectionnez
$ kubectl get svc knative-ingressgateway --namespace istio-system

NAME                     TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                                      AGE
knative-ingressgateway   LoadBalancer   10.23.247.74   35.203.155.229   80:32380/TCP,443:32390/TCP,32400:32400/TCP   2d

Recherchez ensuite le domaine de votre application à l'aide de la commande suivante, en copiant le champ DOMAIN:

 
Sélectionnez
$ kubectl get ksvc helloworld-go

NAME            DOMAIN                              LATESTCREATED         LATEST READY           READY     REASON
helloworld-go   helloworld-go.default.example.com   helloworld-go-00001   helloworld-go-00001   True

Vous pouvez ensuite faire une demande à votre application en utilisant la commande suivante :

 
Sélectionnez
$ curl -H "Host: {DOMAIN}" http://{IP_ADDRESS}

Hello World: Go Sample v1!

Félicitations, vous venez de déployer avec succès votre première application sans serveur Knative !

IV-A. Service

Voyons maintenant les ressources qui composent notre application. Commençons par examiner le service que nous avons défini avec :

 
Sélectionnez
$ kubectl get ksvc helloworld-go

NAME            DOMAIN                              LATESTCREATED         LATESTREADY           READY     REASON
helloworld-go   helloworld-go.default.example.com   helloworld-go-00001   helloworld-go-00001   True

Cela montre le domain à notre application et les dernières révisions créées et prêtes de notre application. Comme il s'agit de la ressource exacte où nous l'avons définie à l'origine, il n'y a pas grand-chose d'autre à voir ici ; alors plongeons dans certaines des autres ressources que Knative a créées pour nous.

IV-B. Configuration

Lorsque nous avons défini notre service Knative, une configuration a été automatiquement créée pour notre application. Nous pouvons voir cette configuration en utilisant la commande suivante :

 
Sélectionnez
$ kubectl get configuration helloworld-go -o yaml

apiVersion: serving.knative.dev/v1alpha1
kind: Configuration
metadata:
  name: helloworld-go
  namespace: default
  <other_metadata>
spec:
  generation: 1
  revisionTemplate:
    metadata:
      annotations:
        sidecar.istio.io/inject: "false"
      creationTimestamp: null
    spec:
      container:
        env:
        - name: TARGET
          value: Go Sample v1
        image: <image_url>/helloworld-go
        name: ""
        resources: {}
      containerConcurrency: 1
      timeoutSeconds: 1m0s
status:
  conditions:
  <conditions>
  latestCreatedRevisionName: helloworld-go-00001
  latestReadyRevisionName: helloworld-go-00001
  observedGeneration: 1

Une partie de la sortie a été supprimée pour faciliter cette lecture. Comme vous pouvez le constater, en fonction de la commande que nous avons émise, le nom de cette configuration (helloworld-go) correspond au nom du service que nous avons défini. C'est toujours le cas lors de la définition d'un service. Le composant le plus intéressant est la section spec.revisionTemplate.

IV-C. Révision

Examinons la révision créée à partir de notre configuration en exécutant la commande suivante :

 
Sélectionnez
$ kubectl get revision helloworld-go-00001 -o yaml

apiVersion: serving.knative.dev/v1alpha1
kind: Revision
metadata:
  name: helloworld-go-00001
  namespace: default
  <metadata>
spec:
  container:
    env:
    - name: TARGET
      value: Go Sample v1
    image: <image_url>
    name: ""
    resources: {}
  containerConcurrency: 1
  generation: 1
  timeoutSeconds: 1m0s
status:
  conditions:
  <conditions>
  serviceName: helloworld-go-00001-service

Comme pour notre configuration, nous avons supprimé une partie de la sortie de révision pour faciliter la lecture. Comme mentionné précédemment, chaque fois que notre configuration est modifiée, une nouvelle révision est créée. Une révision initiale est également créée pour toute configuration. S'agissant de la première révision, le numéro de révision est 00001. Notez également que les spécifications de révision correspondent à notre revisionTemplate de la configuration ci-dessus.

Essayons maintenant de changer notre configuration (via notre service) et observons la création d’une nouvelle révision. Nous pouvons le faire en modifiant la valeur de la ligne :
« Go Sample v1 » dans notre fichier service.yaml: valeur: «  ».

Nous pouvons ensuite mettre à jour le service en utilisant : kubectl apply -f service.yaml

Jetons un coup d’œil à nos révisions actuelles en utilisant la commande suivante :

 
Sélectionnez
$ kubectl get revision

NAME                  SERVICE NAME                  READY     REASON
helloworld-go-00001   helloworld-go-00001-service   True
helloworld-go-00002   helloworld-go-00002-service   True

Comme vous pouvez le constater, une nouvelle révision (helloworld-go-00002) a été créée pour nous. Nous pouvons également voir que la réponse de notre application a changé en ré-exécutant la commande curl :

 
Sélectionnez
$ curl -H "Host: {DOMAIN}" http://{IP_ADDRESS}

Hello World: Go Sample v2!

IV-D. Route

Voyons maintenant la route que Knative a créée pour notre service, en lançant la commande suivante :

 
Sélectionnez
$ kubectl get route helloworld-go -oyaml

apiVersion: serving.knative.dev/v1alpha1
kind: Route
metadata:
  name: helloworld-go
  namespace: default
  <other metadata>
spec:
  generation: 1
  traffic:
  - configurationName: helloworld-go
    percent: 100
status:
  address:
    hostname: helloworld-go.default.svc.cluster.local
  <conditions>
  domain: helloworld-go.default.example.com
  domainInternal: helloworld-go.default.svc.cluster.local
  traffic:
  - percent: 100
    revisionName: helloworld-go-00002

Comme vous pouvez le constater, la section de spécification de cette ressource est relativement légère par rapport à nos autres ressources, car elle ne se compose que d’une section de génération et de trafic. La section trafic est ce qui permet à un utilisateur de spécifier une configuration (comme celle que nous avons ici), qui dirigera toujours le trafic vers la révision prête la plus récente ou vers une révision spécifique. Lorsque vous ciblez une révision spécifique, notez que vous pouvez préciser une liste de révisions, chacune avec son propre pourcentage cible, ce qui permet ensuite à l'utilisateur de déployer les modifications progressivement, en n'envoyant initialement qu'un faible pourcentage du trafic vers une nouvelle révision.

V. Conclusion

Dans cet article, vous avez découvert comment déployer une application helloworld simple sans serveur , qui évolue entièrement en fonction de la charge de la demande. Vous avez également découvert les composants qui composent le projet Knative’s Serving et comment inspecter les blocs de construction de base avec kubectl. Cet article ne concerne que la surface de Knative et je vous encourage à rechercher plus d'informations disponibles dans le référentiel de documents de Knative : https://github.com/knative/docs . Si vous souhaitez mettre à profit vos nouvelles compétences Knative, découvrez comment automatiser l’installation de Knative sur le cloud .

VI. Remerciements Developpez.com

Developpez.com remercie IBM pour l’autorisation de publication de ce tutoriel. Des remerciements également à Guillaume SIGUI pour la mise au gabarit et Bruno Barthel pour la relecture orthographique.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2019 Gregory Haynes. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.