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.
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:
$ 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▲
Voyons maintenant les ressources qui composent notre application. Commençons par examiner le service que nous avons défini avec :
$
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 :
$ 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 :
$ 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 revisionTemplatede 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 :
$
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 :
$
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 :
$ 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.