Questions fréquentes relatives à l'utilisation de Knative dans un cluster ACK (Container Service for Kubernetes).
Quelles sont les différences entre Alibaba Cloud Knative et la version open source de Knative ?
Alibaba Cloud Knative enrichit le projet open source selon six axes : l'exploitation et la maintenance, la simplicité d'utilisation, l'élasticité, les passerelles, les capacités événementielles ainsi que la surveillance et les alertes. Consultez la rubrique Comparaison entre Alibaba Cloud Knative et Knative open source pour une analyse détaillée.
Quelle passerelle choisir lors de l'installation de Knative ?
Alibaba Cloud Knative prend en charge trois types de passerelles :
| Passerelle | Meilleure utilisation |
|---|---|
| Application Load Balancer (ALB) | Équilibrage de charge au niveau applicatif avec gestion avancée du trafic |
| ASM (Alibaba Cloud Service Mesh) | Politiques de trafic granulaires ou observabilité inter-services, basé sur Istio |
| Kourier | Routage de base sans exigences spécifiques concernant ALB ou ASM |
En l'absence d'exigences particulières, optez pour Kourier. Pour plus de détails sur la configuration, reportez-vous à la section Choisir une passerelle pour Knative.
Quelles autorisations sont nécessaires pour utiliser Knative avec un utilisateur ou un rôle RAM ?
L'utilisateur ou le rôle Resource Access Management (RAM) doit disposer d'un accès à tous les namespaces du cluster.
Connectez-vous à la console Container Service. Dans le volet de navigation de gauche, cliquez sur Authorizations.
Sélectionnez l'onglet RAM Users. À côté de l'utilisateur RAM cible, cliquez sur Manage Permissions.
Dans la zone Add Permissions, sélectionnez le cluster, définissez le namespace sur tous les namespaces et finalisez l'autorisation.
Combien de temps faut-il pour qu'un pod Knative soit réduit à zéro instance ?
Trois paramètres régissent le délai de réduction à zéro :
| Paramètre | Fonction |
|---|---|
stable-window |
Fenêtre d'observation précédant le début de la mise à l'échelle. L'autoscaler surveille les métriques durant cette période sans agir. |
scale-to-zero-grace-period |
Délai d'attente avant la réduction à zéro. Pendant cette période, le système conserve le dernier pod même en l'absence de nouvelles requêtes, afin de gérer les pics de trafic soudains. |
scale-to-zero-pod-retention-period |
Durée de conservation du dernier pod avant la mise à l'échelle à zéro. Cela permet une réponse rapide aux pics de trafic sans avoir à démarrer un nouveau pod depuis zéro. |
Les trois conditions suivantes doivent être réunies pour qu'un pod soit réduit à zéro :
Aucune requête n'est reçue durant la fenêtre
stable-window.La période
scale-to-zero-pod-retention-perioda expiré.Le temps nécessaire au service SKS (Serverless Kubernetes Service) pour basculer en mode proxy dépasse la valeur
scale-to-zero-grace-period.
La durée maximale de conservation d'un pod est calculée comme suit : stable-window + max(scale-to-zero-grace-period, scale-to-zero-pod-retention-period). Pour imposer une durée minimale de conservation spécifique, configurez le paramètre scale-to-zero-pod-retention-period.
Comment utiliser les ressources GPU dans Knative ?
Dans la spécification du service Knative, ajoutez l'annotation k8s.aliyun.com/eci-use-specs sous spec.template.metadata.annotations pour indiquer le type d'instance GPU. Déclarez ensuite la limite de ressource GPU à l'aide de nvidia.com/gpu sous spec.containers.resources.limits.
Un exemple est disponible dans la section Utiliser des GPU.
Comment utiliser les GPU partagés dans Knative ?
Activez la planification des GPU partagés pour les nœuds. Reportez-vous à la rubrique Exécuter un exemple de planification de GPU partagé.
Dans votre service Knative, configurez la limite de mémoire GPU en utilisant
aliyun.com/gpu-memsousspec.containers.resources.limits.
Pour plus de détails, consultez la section Activer la planification des GPU partagés.
Comment réduire la latence de démarrage à froid lors de la mise à l'échelle à zéro ?
En l'absence de requêtes, Knative réduit le nombre d'instances à zéro pour limiter les coûts. Lorsqu'une nouvelle requête arrive, la séquence de démarrage implique l'allocation des ressources IaaS, la planification du conteneur, le téléchargement des couches d'image et le démarrage de l'application ; chaque étape ajoute de la latence.
Deux approches permettent de réduire cette latence :
Instances réservées (recommandé pour les charges de travail sensibles à la latence)
Réservez une instance à performance éclatée peu coûteuse qui reste active pendant que vos instances principales sont à zéro. Dès l'arrivée de la première requête, l'instance réservée la traite immédiatement et déclenche la mise à l'échelle horizontale d'instances aux spécifications complètes. Une fois ces instances prêtes, le trafic leur est transféré et l'instance réservée est arrêtée. Cette méthode offre un compromis entre économies de coûts et rapidité de réponse initiale.
Consultez la rubrique Configurer des instances réservées.
Cache d'image ECI (réduction du temps de tirage d'image)
Créez préalablement des instantanés de cache pour les images de votre application. ECI (Elastic Container Instance) utilise ces instantanés lors de la création des pods, ce qui permet d'ignorer ou de raccourcir l'étape de téléchargement des couches d'image. Cela réduit le temps de création des instances, que vous utilisiez ou non des instances réservées.
Reportez-vous à la section Utiliser l'accélération d'image.
Le composant Activator d'ACK Knative est-il facturé ?
Oui. L'Activator s'exécute sous forme de pod dans le plan de données et consomme des ressources d'instance, lesquelles sont facturées en conséquence.
Comment configurer le port d'écoute des services Knative ?
Le port sur lequel votre application écoute doit correspondre au champ containerPort dans la définition du service Knative. La valeur par défaut est 8080. Pour utiliser un autre port, consultez la section Configurer un port d'écoute personnalisé.