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

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.

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.

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.

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.

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:

$ 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:

$ 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 champDOMAIN:

$ 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 :

$ 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▲

$ 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

IV-B. Configuration▲

$ 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

IV-C. Révision▲

$ 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

$ kubectl get revision

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

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

Hello World: Go Sample v2!

IV-D. Route▲

$ 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

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 .

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.