Tous les produits
Search

Ce produit

    Container Service for Kubernetes:Knative FAQ

    Centre de documentation

    Container Service for Kubernetes:Knative FAQ

    Dernière mise à jour :Sep 20, 2026

    Cette rubrique répond aux questions fréquemment posées (FAQ) sur l'utilisation de Knative dans les clusters Container Service for Kubernetes (ACK).

    Sommaire

    Différences entre Alibaba Cloud Knative et Knative open source

    Alibaba Cloud Knative est compatible avec Knative open source et offre des fonctionnalités améliorées pour l'exploitation et la maintenance, la facilité d'utilisation, l'élasticité, les passerelles, l'architecture événementielle ainsi que la surveillance et les alertes. Pour plus d'informations, reportez-vous à la rubrique Comparaison entre Alibaba Cloud Knative et Knative open source.

    Choix d'un Ingress pour Knative

    Alibaba Cloud Knative prend en charge trois types d'Ingress : Application Load Balancer (ALB), Alibaba Cloud Service Mesh (ASM) et Kourier. ALB se concentre sur les scénarios d'équilibrage de charge au niveau applicatif. ASM fournit les capacités de maillage de services (Istio). Choisissez Kourier si vous avez uniquement besoin des fonctionnalités Ingress de base. Pour plus d'informations, consultez la rubrique Choisir un Ingress pour Knative.

    Autorisations requises pour les utilisateurs et rôles RAM

    Vous devez disposer des autorisations d'accès à tous les namespaces du cluster. Accordez les autorisations requises comme suit.

    1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Authorizations.

    2. Cliquez sur l'onglet RAM Users. Dans la liste des utilisateurs RAM, repérez l'utilisateur cible et cliquez sur Modify Permissions dans la colonne Actions.

    3. Dans la section Add Permissions, sélectionnez le cluster cible, choisissez Tous les namespaces pour Namespace, puis finalisez l'autorisation.

    Durée de réduction à zéro des pods

    Le temps nécessaire pour qu'un pod soit réduit à zéro dépend des trois paramètres suivants :

    • stable-window : fenêtre temporelle pendant laquelle le système observe et évalue les métriques avant d'effectuer une mise à l'échelle vers le bas. Le système n'entreprend aucune action immédiate durant cette période.

    • scale-to-zero-grace-period : période de grâce précédant la réduction à zéro. Pendant cet intervalle, le système n'arrête ni ne supprime immédiatement le dernier pod, même en l'absence de nouvelles requêtes. Cela permet de gérer les pics de trafic soudains.

    • scale-to-zero-pod-retention-period : durée de conservation du dernier pod avant sa réduction à zéro. Cette configuration permet au système de réagir rapidement aux pics de trafic imprévus sans subir de démarrage à froid.

    Un pod est réduit à zéro uniquement si les trois conditions suivantes sont réunies :

    1. Aucune requête n'est reçue pendant la durée définie par stable-window.

    2. La période de conservation spécifiée par scale-to-zero-pod-retention-period est écoulée.

    3. Le temps passé par le service Serverless Kubernetes (ASK) en mode proxy dépasse la durée indiquée par scale-to-zero-grace-period ; le pod commence alors sa mise à l'échelle vers le bas.

    Un pod est conservé pour une durée maximale égale au résultat de la formule suivante : stable-window + Max("scale-to-zero-grace-period", "scale-to-zero-pod-retention-period"). Pour imposer une durée de conservation spécifique pour le dernier pod, utilisez le paramètre scale-to-zero-pod-retention-period.

    Utilisation des 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 afin de spécifier le type d'instance GPU. Déclarez ensuite la limite de ressource GPU en utilisant nvidia.com/gpu sous spec.containers.resources.limits.

    Pour plus d'informations, consultez la rubrique Utiliser les ressources GPU.

    Mise en œuvre du partage de GPU dans Knative

    Reportez-vous à l'exemple Exécuter un exemple de planification avec partage de GPU pour activer la planification avec partage de GPU sur les nœuds. Ensuite, dans le service Knative, configurez les limites de ressources à l'aide du champ aliyun.com/gpu-mem. Pour plus d'informations, consultez la rubrique Activer la planification avec partage de GPU.

    Réduction de la latence de démarrage à froid

    Par défaut, Knative open source réduit à zéro le nombre d'instances d'application en l'absence de requêtes entrantes. Cette approche permet de diminuer le coût lié à l'exécution d'instances inactives. Lorsqu'une nouvelle requête arrive, une nouvelle instance est attribuée à l'application. Ce processus implique l'allocation et la planification des ressources IaaS, le téléchargement de l'image de l'application ainsi que son démarrage, ce qui engendre une latence importante appelée démarrage à froid.

    Si votre activité est sensible à la latence de démarrage à froid, vous pouvez opter pour l'une des deux solutions suivantes :

    • Configurer une instance réservée : maintenez en fonctionnement une instance à performances éclatées peu coûteuse et de faible spécification afin d'équilibrer coûts et latence de démarrage à froid. À l'arrivée de la première requête, l'instance réservée la traite tandis qu'une instance aux spécifications par défaut est mise à l'échelle. Une fois l'instance par défaut prête, toutes les nouvelles requêtes lui sont acheminées. L'instance réservée est automatiquement libérée après avoir traité ses requêtes. Pour plus d'informations, consultez la rubrique Configurer une instance réservée.

    • Utiliser la fonctionnalité de cache d'images d'Elastic Container Instance (ECI) : créez préalablement un instantané de cache pour l'image, puis générez des instances ECI (pods) à partir de cet instantané afin d'éviter ou de réduire le téléchargement des couches d'image. Cela accélère la création des instances. Pour plus d'informations, consultez la rubrique Utiliser l'accélération d'image pour accélérer la création d'instances.

    Facturation du composant Activator

    Oui. Le composant Activator est un composant du plan de données qui s'exécute sous forme de pods et consomme vos ressources d'instance.

    Configuration du port d'écoute

    Le port d'écoute de votre application doit correspondre au paramètre containerPort du service Knative, défini par défaut sur 8080. Pour configurer un port d'écoute personnalisé, consultez la rubrique Configurer un port d'écoute personnalisé.