Le déploiement de charges de travail serverless sur Kubernetes nécessite généralement de gérer séparément les objets Deployment, Service et Ingress, puis de les interconnecter à chaque mise à jour. Le service Knative regroupe ces éléments dans une seule ressource qui gère automatiquement le déploiement, le routage du trafic, la mise à l'échelle automatique basée sur les requêtes et la gestion multi-versions.
Concepts clés
Un service Knative gère automatiquement quatre sous-ressources :
| Ressource | Rôle |
|---|---|
| Configuration | Contient la spécification de la charge de travail : image de conteneur, variables d'environnement et limites de ressources. Chaque modification déclenche la création d'une nouvelle Revision. |
| Revision | Instantané immuable d'une Configuration à un instant donné. Chaque mise à jour génère une nouvelle Revision, conservant ainsi un historique des versions pour permettre les retours en arrière ou la répartition du trafic. |
| Route | Achemine le trafic entrant vers une ou plusieurs Revisions selon des pourcentages configurables. |
| Tag | Libellé nommé associé à une Revision spécifique. L'attribution d'un tag pousse Knative à générer une URL d'accès indépendante pour cette Revision, utile pour valider des versions canary sans exposer la Revision au trafic actif. |
Fonctionnement
Mise à l'échelle automatique basée sur les requêtes
Les métriques CPU et mémoire accusent souvent un décalage par rapport à la charge utilisateur réelle. Knative met à l'échelle le service en fonction de la simultanéité et du nombre de requêtes par seconde (RPS), qui reflètent directement son débit.
Knative Serving injecte un conteneur queue-proxy dans chaque pod. Ce dernier collecte les métriques de simultanéité et de RPS ; l'autoscaler les lit périodiquement et ajuste en conséquence le nombre de pods du Deployment.
Flux des requêtes :
Une requête arrive au HTTP Router, qui la transmet au Serverless Service (SKS) de Knative. SKS est l'abstraction par Knative des ressources Kubernetes Service et achemine les requêtes vers différents endpoints backend.
-
SKS sélectionne un mode de routage selon le nombre de pods actifs :
Mode Serve : Des pods actifs existent. Les requêtes leur sont directement transmises.
Mode Proxy : Le nombre de pods a été réduit à zéro. Les requêtes sont acheminées vers l'activator, qui les reçoit et les met en tampon.
L'activator reçoit les requêtes, enregistre les métriques de simultanéité et les signale à l'autoscaler.
L'autoscaler compare les métriques aux seuils prédéfinis. En cas de besoin de mise à l'échelle horizontale, il envoie une requête à l'API server.
L'API server met à jour le Deployment et crée de nouveaux pods.
Dès que l'activator détecte que les nouveaux pods sont prêts, il leur transmet les requêtes mises en tampon.
Pour plus de détails sur la configuration, consultez la rubrique Activer la mise à l'échelle automatique pour absorber les fluctuations de trafic.
Mise à l'échelle automatique jusqu'à zéro
Lorsqu'un service ne reçoit aucun trafic, Knative réduit automatiquement le nombre de pods à zéro, libérant ainsi les ressources. À l'arrivée de la requête suivante, l'autoscaler provisionne à nouveau des pods et l'activator maintient la requête en attente jusqu'à ce qu'un pod soit prêt.
Transitions de mode :
De Serve à Proxy : Lorsque le taux de requêtes tombe à zéro, l'autoscaler bascule en mode Proxy et réduit le nombre de pods à zéro.
De Proxy à Serve : Lorsqu'une nouvelle requête arrive, l'autoscaler effectue une mise à l'échelle horizontale. Une fois les pods prêts, le mode repasse en Serve et l'activator transmet la requête.
Pour plus de détails sur la configuration, consultez la rubrique Activer la mise à l'échelle automatique pour absorber les fluctuations de trafic.
Gestion multi-versions et déploiements canary
Chaque mise à jour de la Configuration produit une Revision unique et immuable. Les Routes répartissent le trafic entre les Revisions selon des pourcentages configurables, offrant ainsi des capacités de retour en arrière et de déploiement canary sans redéploiement.
Exemple : Créez la Revision V1, puis mettez à jour la Configuration pour générer la Revision V2. Configurez une Route qui dirige 70 % du trafic vers V1 et 30 % vers V2. Déplacez progressivement le pourcentage jusqu'à ce que V2 traite 100 % du trafic.
Exemples YAML
Les exemples suivants couvrent les configurations courantes du service Knative.
Service de base
Un service Knative minimal avec un seul conteneur :
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: helloworld-go
spec:
template:
spec:
containers:
- image: registry-vpc.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
env:
- name: TARGET
value: "Knative"Répartition du trafic (déploiement canary)
Acheminez 70 % du trafic vers une Revision stable et 30 % vers une nouvelle :
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: helloworld-go
spec:
template:
spec:
containers:
- image: registry-vpc.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
traffic:
- revisionName: helloworld-go-v1
percent: 70
- revisionName: helloworld-go-v2
percent: 30Validation canary avec un tag
Déployez une nouvelle Revision à des fins de test sans lui acheminer de trafic actif. Le tag staging génère un endpoint indépendant que vous pouvez utiliser pour la validation :
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: helloworld-go
spec:
template:
spec:
containers:
- image: registry-vpc.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
traffic:
- revisionName: helloworld-go-v1
percent: 100
- revisionName: helloworld-go-v2
percent: 0
tag: stagingLa définition de percent: 0 avec un tag exclut la Revision du trafic actif, tandis que Knative génère une URL dédiée pour cette Revision, permettant de la tester directement.
Pour connaître les procédures de déploiement canary, consultez la rubrique Effectuer un déploiement canary basé sur la répartition du trafic.