Le serverless ne signifie pas « sans serveur » : il signifie que l'infrastructure d'exécution est largement abstraite pour le développeur. Dans les offres managées (AWS Lambda, Google Cloud Run functions), cela s'accompagne souvent d'une facturation à l'usage réel. Dans des plateformes open source comme Knative sur Kubernetes, l'intérêt principal est le déploiement simplifié, le scaling automatique et le scale-to-zero, mais vous continuez à payer votre cluster. Ce guide explique les concepts fondamentaux du serverless, le modèle FaaS, l'architecture event-driven et Knative, la solution serverless open source pour Kubernetes.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »Le serverless fait partie des concepts cloud native utiles à connaître pour la KCNA, en particulier dans le domaine Architecture. Ce guide reste conceptuel, aucune installation n'est nécessaire : la leçon pratique qui le suit, Knative Serving : scale-to-zero mesuré, déploie un service Knative et mesure son scale-to-zero.
- Ce que signifie serverless et ce que ce n'est pas
- La distinction entre BaaS (Backend as a Service) et FaaS (Function as a Service)
- Le fonctionnement du scale-to-zero et ses implications
- Le modèle event-driven au cœur du serverless
- Knative : le serverless cloud native sur Kubernetes
- Les limites du serverless et quand préférer d'autres approches
De quoi parle-t-on exactement ?
Section intitulée « De quoi parle-t-on exactement ? »Le terme « serverless » prête à confusion. Évidemment, des serveurs existent quelque part, mais le développeur ne les voit pas, ne les provisionne pas et ne les gère pas. Le contrat est simple : vous fournissez du code, la plateforme s'occupe du reste.
Ce modèle existe sous deux formes :
| Modèle | Définition | Exemple |
|---|---|---|
| BaaS (Backend as a Service) | Des services managés qui remplacent des composants côté serveur (base de données, authentification, stockage) | Firebase, Auth0, Amazon DynamoDB |
| FaaS (Function as a Service) | Vous déployez des fonctions individuelles qui s'exécutent en réponse à des événements | AWS Lambda, Google Cloud Run functions, Knative Functions |
Dans le contexte de la KCNA et du cloud native, c'est le modèle FaaS qui est le plus pertinent.
Function as a Service (FaaS) : le cœur du serverless
Section intitulée « Function as a Service (FaaS) : le cœur du serverless »Le modèle FaaS repose sur une idée simple : du point de vue du développeur, l'unité logique de déploiement devient la fonction. En dessous, la plateforme peut tout à fait utiliser des conteneurs pour l'exécuter, mais le développeur n'a pas à s'en soucier.
Comment ça fonctionne
Section intitulée « Comment ça fonctionne »Les six étapes ci-dessous décrivent le cycle de vie d'une invocation, de l'écriture du code à la destruction de l'instance. Le point à retenir est l'étape 6 : sans événement, rien ne tourne. C'est ce qui sépare le FaaS d'un serveur classique qui attend en permanence, et ce qui rend le scale-to-zero possible.
- Vous écrivez une fonction, un morceau de code qui prend un événement en entrée, le traite et retourne un résultat
- Vous la déployez sur la plateforme FaaS, sans vous soucier de l'infrastructure
- Un événement arrive (requête HTTP, message dans une file, changement de fichier...)
- La plateforme provisionne automatiquement une instance pour exécuter votre fonction
- La fonction s'exécute, renvoie le résultat et l'instance peut être réutilisée ou détruite
- Sans événement, aucune instance ne tourne, c'est le scale-to-zero
Caractéristiques du FaaS
Section intitulée « Caractéristiques du FaaS »Ces cinq propriétés ne sont pas indépendantes, elles découlent les unes des autres. Parce qu'une fonction est stateless, la plateforme peut la rendre éphémère ; parce qu'elle est éphémère, elle peut passer de zéro à des milliers d'instances sans état à migrer. La première ligne, stateless, est donc la contrainte fondatrice : c'est elle qui interdit de stocker une session en mémoire locale et impose de déporter tout état vers un service externe.
| Caractéristique | Description |
|---|---|
| Stateless | Chaque invocation est indépendante, pas d'état partagé entre deux exécutions (principe stateless and share-nothing des 12-factor apps) |
| Éphémère | Les instances de fonction ont une durée de vie courte (secondes à minutes) |
| Event-driven | L'exécution est déclenchée par un événement, pas par un processus qui tourne en permanence |
| Scaling automatique | De zéro à des milliers d'instances, géré par la plateforme |
| Facturation à l'usage | Dans les offres managées, vous payez le temps d'exécution réel, avec Knative auto-hébergé, l'économie vient du scale-to-zero sur les ressources du cluster |
Scale-to-zero : l'innovation clé
Section intitulée « Scale-to-zero : l'innovation clé »Le scale-to-zero est la caractéristique qui distingue fondamentalement le serverless du déploiement conteneur classique.
Dans un déploiement Kubernetes classique, un Deployment maintient un nombre minimum de pods en permanence, même si aucune requête n'arrive. Avec le scale-to-zero, quand aucune requête n'est reçue pendant un temps configurable, la plateforme détruit toutes les instances. Le nombre de pods tombe littéralement à zéro.
Quand une nouvelle requête arrive, la plateforme crée une instance, l'initialise et route la requête vers elle. Ce processus d'initialisation s'appelle le cold start (démarrage à froid).
| Aspect | Déploiement classique | Serverless (scale-to-zero) |
|---|---|---|
| Pods au repos | Nombre minimum configuré (1+) | 0, aucun pod |
| Coût au repos | Ressources consommées en permanence | Offre managée : aucun coût de calcul. Knative auto-hébergé : le cluster reste payé, seules ses ressources se libèrent |
| Temps de réponse | Immédiat (pods déjà prêts) | Cold start possible (de quelques centaines de ms à plusieurs secondes) |
| Scaling | HPA réagit aux métriques, avec délai | Scaling rapide déclenché par requête |
La colonne de gauche correspond au HorizontalPodAutoscaler (HPA) de
Kubernetes, dont le minimum est resté à une réplique pendant des années :
jusqu'à Kubernetes 1.36, descendre à zéro demandait d'activer la porte de
fonctionnalité HPAScaleToZero, alors en alpha et désactivée par défaut.
Depuis Kubernetes 1.37, cette fonction est en bêta et activée par
défaut : un HPA peut déclarer minReplicas: 0, mais seulement avec une
métrique d'objet ou externe (par exemple la longueur d'une file), jamais
avec le CPU ou la mémoire, qui n'existent plus sans Pod.
Reste un second obstacle : un Service Kubernetes ne met pas les requêtes en attente tant qu'aucun Pod n'est prêt. Pour du HTTP, il faut une couche de mise en tampon à part, ce que fait l'Activator de Knative, présenté plus bas. Si le HPA, le VPA et le Cluster Autoscaler ne vous sont pas familiers, le guide autoscaling dans Kubernetes les présente avant d'aller plus loin.
Architecture event-driven
Section intitulée « Architecture event-driven »Le serverless est intrinsèquement lié à l'architecture event-driven (pilotée par les événements). Au lieu d'un serveur qui attend en permanence des requêtes, des événements déclenchent l'exécution du code.
Les types d'événements
Section intitulée « Les types d'événements »Un événement peut venir de sources très variées, et c'est cette diversité qui fait la souplesse du modèle. Le tableau les classe des plus courantes aux plus spécifiques au cloud native. Retenez surtout que la requête HTTP n'est qu'un cas parmi d'autres : un message de file d'attente ou un changement dans un bucket de stockage déclenche une fonction exactement de la même façon, sans qu'un utilisateur soit devant son écran.
| Source d'événement | Exemples concrets |
|---|---|
| Requête HTTP | Un utilisateur envoie un formulaire |
| Message queue | Un message arrive dans Kafka, RabbitMQ ou SQS |
| Changement de données | Un objet est ajouté dans un bucket S3, une ligne modifiée dans une base |
| Timer / cron | Une tâche planifiée (nettoyage quotidien, rapport hebdomadaire) |
| Événement Kubernetes | Un pod est créé, un ConfigMap modifié |
Le standard CloudEvents
Section intitulée « Le standard CloudEvents »Pour éviter que chaque fournisseur définisse son propre format d'événement, la CNCF a créé la spécification CloudEvents, un format standard pour décrire les événements de façon interopérable. CloudEvents est un projet CNCF graduated.
La spécification CloudEvents impose quatre attributs obligatoires :
- id : identifiant de l'événement, unique pour une même source
- source : d'où vient l'événement (ex:
/myapp/orders) - specversion : version de la spécification utilisée (ex:
1.0) - type : quel type d'événement (ex:
order.created)
Le contenu de l'événement (data) et l'horodatage (time) sont optionnels.
Ce standard permet de connecter des sources d'événements et des consommateurs de façon indépendante du fournisseur cloud.
Knative : le serverless cloud native
Section intitulée « Knative : le serverless cloud native »Knative est une plateforme open source graduated par la CNCF qui apporte les capacités serverless à Kubernetes, notamment le scale-to-zero, le routage HTTP et l'event-driven. Créé par Google en 2018, accepté en incubation en 2022 puis promu graduated en septembre 2025, Knative permet de déployer et scaler automatiquement des workloads serverless sur n'importe quel cluster Kubernetes, sans lock-in vers un fournisseur cloud.
Knative se compose de trois composants principaux :
Knative Serving
Section intitulée « Knative Serving »Knative Serving gère le cycle de vie complet des workloads HTTP : déploiement, scaling automatique (y compris scale-to-zero), routage et traffic splitting.
Les concepts clés de Serving :
| Concept | Rôle |
|---|---|
| Service | Ressource principale, gère automatiquement les Routes, Configurations et Révisions |
| Révision | Snapshot immutable du code + configuration à un instant T. Chaque mise à jour crée une nouvelle Révision |
| Route | Mappe un endpoint réseau vers une ou plusieurs Révisions (traffic splitting) |
| Configuration | Maintient l'état désiré du déploiement |
Concrètement, quand vous déployez un Knative Service :
- La plateforme crée une Révision (version immutable)
- Si aucun trafic n'arrive, le nombre de pods tombe à zéro
- À la première requête, l'Activator intercepte la requête, demande au scaler de créer des pods
- Le pod démarre, le queue-proxy (sidecar léger) gère la concurrence et collecte les métriques
- Si le trafic augmente, le scaler crée des pods supplémentaires automatiquement
Le schéma suivant déroule ces étapes pour la première requête, celle qui subit le cold start : l'Activator retient la requête pendant que l'autoscaler crée le Pod, puis la transmet quand il est prêt.
Knative Eventing
Section intitulée « Knative Eventing »Knative Eventing fournit l'infrastructure pour l'architecture event-driven. Il gère le routage d'événements entre producteurs et consommateurs en utilisant le standard CloudEvents.
Les concepts clés d'Eventing :
| Concept | Rôle |
|---|---|
| Source | Produit des événements depuis un système externe (Kafka, API Kubernetes, timer...) |
| Broker | Réceptionne les événements et les route vers les consommateurs intéressés |
| Trigger | Filtre les événements par attributs CloudEvents et les délivre au bon consommateur |
| Sink | Consommateur qui reçoit et traite les événements |
Knative Functions
Section intitulée « Knative Functions »Knative Functions ajoute une expérience développeur plus simple pour exposer des fonctions sur Knative, en générant automatiquement les artefacts nécessaires (image conteneur, manifeste Kubernetes) à partir du code source, sans écrire de Dockerfile.
Knative ou une offre managée ?
Section intitulée « Knative ou une offre managée ? »AWS Lambda, Google Cloud Run functions (ex-Cloud Functions) et Azure Functions sont des offres propriétaires : vous êtes lié à un fournisseur, mais aucun cluster n'est à exploiter. Knative est open source et tourne sur n'importe quel cluster Kubernetes : vous gardez la portabilité, en échange de la gestion de ce cluster. Le choix déplace donc la charge d'exploitation sans la supprimer.
Serverless vs conteneurs : quand choisir quoi
Section intitulée « Serverless vs conteneurs : quand choisir quoi »Cette section compare le serverless et les conteneurs sur Kubernetes. Pour le choix du serverless chez un fournisseur cloud, avec le cycle de vie d'une invocation et les cinq pièges (démarrage à froid, verrouillage, débogage, durée maximale, coût à l'échelle), voir Serverless et FaaS : ce qui se cache derrière « sans serveur ».
Le serverless n'est pas un remplacement des conteneurs, c'est une abstraction au-dessus. En fait, Knative déploie vos fonctions sous forme de conteneurs dans Kubernetes. La question est le niveau d'abstraction souhaité.
| Critère | Conteneurs (Deployment K8s) | Serverless (FaaS / Knative) |
|---|---|---|
| Unité de déploiement | Image conteneur + manifeste | Fonction ou service HTTP |
| Scaling | Manuel ou HPA (minimum 1 pod par défaut) | Automatique, incluant scale-to-zero |
| Coût au repos | Pods consomment des ressources | Offre managée : zéro coût de calcul sans requête. Knative : le cluster reste facturé |
| Cold start | Aucun (pods déjà prêts) | Possible (de quelques centaines de ms à plusieurs secondes) |
| Workloads adaptés | Services longue durée, trafic constant | Tâches événementielles, trafic variable ou intermittent |
| Contrôle | Total (réseau, stockage, runtime) | Réduit (abstraction de l'infrastructure) |
| Complexité opérationnelle | Moyenne (vous gérez les Deployments) | Supérieure au début (Knative à installer), puis inférieure au quotidien |
Cas d'usage idéaux pour le serverless
Section intitulée « Cas d'usage idéaux pour le serverless »Le dénominateur commun de cette liste est le trafic intermittent ou imprévisible. Dès que la charge varie fortement ou tombe à zéro à certaines heures, le scale-to-zero paie : vous ne réservez pas de ressources pour un pic qui n'arrive pas la nuit. Repérez dans votre propre système les traitements déclenchés par un événement ponctuel, ce sont les meilleurs candidats.
- APIs avec trafic variable : un service qui reçoit beaucoup de requêtes le jour et aucune la nuit
- Traitement événementiel : un pipeline qui réagit à l'upload d'un fichier, un message Kafka, un webhook
- Tâches planifiées : nettoyage de données, génération de rapports, envoi d'e-mails
- Prototypage rapide : déployer un service sans se préoccuper de l'infrastructure
- Environnements de développement : scale-to-zero pour économiser les ressources
Cas où le serverless n'est pas adapté
Section intitulée « Cas où le serverless n'est pas adapté »À l'inverse, ces situations annulent le bénéfice du serverless ou se heurtent à ses limites techniques. Deux motifs reviennent : la durée (une fonction est plafonnée en temps d'exécution) et l'état (une fonction éphémère ne conserve rien entre deux appels). Si votre charge tourne en permanence, le scale-to-zero ne se déclenche jamais et vous payez la complexité sans la contrepartie.
- Processus long : la durée d'une invocation est plafonnée (15 minutes au maximum pour AWS Lambda en configuration standard) ; avec Knative, c'est le délai de requête de la Révision (
timeoutSeconds, 300 secondes par défaut, plafonné à 600 secondes par défaut) - Workloads avec état : bases de données, caches persistants, systèmes de fichiers
- Trafic constant et prévisible : le scale-to-zero n'apporte rien si les pods tournent en permanence
- Latence ultra-faible requise : le cold start est un risque pour les applications temps réel
- Applications avec beaucoup de connexions persistantes : WebSockets, gRPC streaming
À retenir
Section intitulée « À retenir »- Serverless signifie que l'infrastructure est abstraite, le développeur ne gère ni serveurs ni scaling
- Le modèle FaaS (Function as a Service) exécute du code à la demande, en réponse à des événements
- Le scale-to-zero distingue le serverless du déploiement classique : zéro pod quand il n'y a pas de trafic, mais attention au cold start
- L'architecture event-driven est au cœur du serverless : les événements (HTTP, messages, cron) déclenchent l'exécution
- CloudEvents (CNCF graduated) standardise le format des événements pour l'interopérabilité
- Knative (CNCF graduated) apporte le serverless à Kubernetes : Serving (scale-to-zero), Eventing (routage événementiel), Functions (expérience simplifiée)
- Le serverless est idéal pour les workloads événementiels et intermittents ; pour les services à trafic constant ou les processus longs, les conteneurs classiques restent plus adaptés
Contrôle de connaissances
Validez vos connaissances avec ce quiz interactif
Informations
- Le chronomètre démarre au clic sur Démarrer
- Questions à choix multiples, vrai/faux et réponses courtes
- Vous pouvez naviguer entre les questions
- Les résultats détaillés sont affichés à la fin
Lance le quiz et démarre le chronomètre
Vérification
(0/0)Score par domaine
Un domaine regroupe plusieurs guides et reçoit plusieurs questions : son score est plus fiable qu'un score par thème, qui porte souvent sur une seule question.
Bilan
Points forts
Aucun sujet réussi à 80 % sur au moins deux questions pour l’instant.
Points faibles
Aucun sujet sous le seuil de réussite.
À faire ensuite
Des indices pour retenter votre chance ?
Continuer le cours : Knative Serving : scale-to-zero mesuré
Nouveau quiz complet avec des questions aléatoires
Retravailler uniquement les questions ratées
Retour à la liste des certifications