Container Service for Kubernetes:Best practices for deploying AI inference services in Knative

Accélération du déploiement des modèles

Pour garantir que les services d'inférence IA déployés dans Knative Serving puissent être rapidement mis à l'échelle selon les besoins, évitez d'emballer les modèles d'IA dans des images de conteneurs. Lorsque les modèles d'IA sont inclus dans les images de conteneurs, celles-ci deviennent extrêmement volumineuses, ce qui ralentit le déploiement des conteneurs. De plus, les versions des modèles d'IA sont liées aux versions des images de conteneurs, ce qui complexifie la gestion des versions.

Pour éviter ces problèmes, nous vous recommandons de télécharger toutes les données relatives à votre modèle d'IA vers un système de stockage externe, tel que Object Storage Service (OSS) ou File Storage NAS (NAS), puis de créer une revendication de volume persistant (PVC) pour monter ce système de stockage sur les pods du service Knative. Vous pouvez également utiliser Fluid, un moteur d'orchestration et d'accélération de jeux de données distribués, pour accélérer le chargement des modèles d'IA. Cette approche permet de charger des grands modèles de langage en quelques secondes. Pour plus d'informations, consultez Accélérer l'accès aux fichiers OSS avec JindoFS et Utiliser EFC pour accélérer l'accès aux systèmes de fichiers NAS.

Prérequis

• Knative est déployé dans votre cluster. Pour plus d'informations, consultez Déployer et gérer les composants Knative.

• Le composant ack-fluid est installé. Pour plus d'informations, consultez Déployer la suite AI cloud-native.

• Un bucket OSS a été créé. Pour plus d'informations, consultez Créer des buckets.

Étape 1 : Définir un Dataset

Si votre modèle d'IA est stocké dans OSS, créez une ressource personnalisée (CR) Dataset pour déclarer le jeu de données du modèle dans OSS et utilisez JindoRuntime pour exécuter les tâches de mise en cache.

apiVersion: v1
kind: Secret
metadata:
  name: access-key
stringData:
  fs.oss.accessKeyId: your_ak_id   # Replace with the AccessKey ID used to access OSS. 
  fs.oss.accessKeySecret: your_ak_skrt   # Replace with the AccessKey secret used to access OSS. 
---
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: oss-data
spec:
  mounts:
  - mountPoint: "oss://{Bucket}/{path-to-model}" # Replace with the OSS bucket and OSS path where the model is stored. 
    name: xxx
    path: "{path-to-model}" # Replace with the path of the model to be loaded. 
    options:
      fs.oss.endpoint: "oss-cn-beijing.aliyuncs.com"  # Replace with the endpoint of the OSS bucket. 
    encryptOptions:
      - name: fs.oss.accessKeyId
        valueFrom:
          secretKeyRef:
            name: access-key
            key: fs.oss.accessKeyId
      - name: fs.oss.accessKeySecret
        valueFrom:
          secretKeyRef:
            name: access-key
            key: fs.oss.accessKeySecret
  accessModes:
    - ReadOnlyMany
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: oss-data
spec:
  replicas: 2
  tieredstore:
    levels:
      - mediumtype: SSD
        volumeType: emptyDir
        path: /mnt/ssd0/cache
        quota: 100Gi
        high: "0.95"
        low: "0.7"
  fuse:
    properties:
      fs.jindofsx.data.cache.enable: "true"
    args:
      - -okernel_cache
      - -oro
      - -oattr_timeout=7200
      - -oentry_timeout=7200
      - -ometrics_port=9089
    cleanPolicy: OnDemand

Étape 2 : Monter un PVC pour accélérer l'accès à OSS

Après avoir déclaré une CR Dataset et une CR JindoRuntime, le système crée automatiquement un PVC portant le même nom que le Dataset et monte ce PVC sur le service Knative pour accélérer l'accès à OSS.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: sd-backend
spec:
  template:
    spec:
      containers:
        - image: <YOUR-IMAGE>   # Replace <YOUR-IMAGE> with the name of the image. 
          name: image-name
          ports:
            - containerPort: xxx
              protocol: TCP
          volumeMounts:
            - mountPath: /data/models  # The path of the model to be loaded. Replace with the value of moutPath. 
              name: data-volume
      volumes:
        - name: data-volume
          persistentVolumeClaim:
            claimName: oss-data   # Mount a PVC with the same name as the Dataset.

Étape 3 : Déployer le modèle en quelques secondes grâce aux caches d'images

Outre la taille du modèle d'IA, vous devez prendre en compte l'impact de la taille de l'image de conteneur sur le service Knative. Les images de conteneur utilisées pour exécuter des modèles d'IA incluent généralement des dépendances telles que CUDA et pytorch-gpu, ce qui augmente leur volume. Lorsque vous déployez des services d'inférence IA Knative dans des pods sur des instances de conteneur élastiques, nous vous recommandons d'utiliser des caches d'images pour accélérer le téléchargement des images. Les caches des images utilisées pour déployer des pods sur des instances de conteneur élastiques sont créés à l'avance, permettant au système de télécharger les images en quelques secondes. Pour plus d'informations, consultez Utiliser ImageCache pour accélérer la création de pods ECI.

apiVersion: eci.alibabacloud.com/v1
kind: ImageCache
metadata:
  name: imagecache-ai-model
  annotations:
    k8s.aliyun.com/eci-image-cache: "true" # Enable the reuse of image caches. 
spec:
  images:
  - <YOUR-IMAGE>
  imageCacheSize:
    25 # The size of each image cache. Unit: GiB. 
  retentionDays:
    7 # The retention period of image caches.

Arrêt gracieux des pods

Pour garantir que les requêtes en cours ne soient pas interrompues, les pods doivent être arrêtés d'une manière spécifique après réception du signal SIGTERM.

• Si une application utilise la sonde HTTP, les pods de l'application passent à l'état Not Ready après avoir reçu le signal SIGTERM, empêchant ainsi le transfert de nouvelles requêtes vers ces pods.

• Pendant le processus d'arrêt des pods, Knative queue-proxy peut continuer à transférer des requêtes vers les pods. Nous vous recommandons de définir le paramètre timeoutSeconds à 1,2 fois la durée maximale de délai d'attente afin de garantir que toutes les requêtes soient traitées avant l'arrêt des pods. Par exemple, si la durée maximale de délai d'attente des requêtes est de 10 secondes, définissez le paramètre timeoutSeconds à 12 secondes.

  apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: helloworld-go
    namespace: default
  spec:
    template:
      spec:
        timeoutSeconds: 12

Configurer les paramètres de concurrence

La configuration des paramètres de concurrence améliore considérablement les performances et la rapidité de réponse des services Knative. Des réglages de concurrence appropriés permettent à votre application de gérer plus efficacement un grand nombre de requêtes simultanées, améliorant ainsi la qualité du service et l'expérience utilisateur.

• Limite de concurrence stricte : il s'agit d'une limite supérieure imposée. Lorsque le niveau de concurrence atteint cette limite, les requêtes excédentaires sont mises en cache. Elles restent en attente jusqu'à ce que des ressources suffisantes soient disponibles.

• Limite de concurrence souple : il ne s'agit pas d'une contrainte stricte. En cas de pic de requêtes, le niveau de concurrence peut dépasser cette limite souple.

• Objectif d'utilisation : par rapport à target, l'annotation autoscaling.knative.dev/target-utilization-percentage offre un moyen plus direct de spécifier le niveau de concurrence. Vous pouvez définir cette annotation à une valeur proche de 100 % pour traiter efficacement les requêtes concurrentes.

Pour plus d'informations, consultez Configurer la limite de concurrence souple.

Mise à l'échelle automatique

Avant de configurer la mise à l'échelle automatique, définissez vos objectifs, tels que la réduction de la latence, la minimisation des coûts et la gestion des pics de trafic. Estimez ensuite le temps nécessaire au lancement des pods dans les scénarios souhaités. Par exemple, il existe une différence de temps entre le lancement d'un seul pod et le lancement simultané de plusieurs pods. Ces métriques servent de base à la mise à l'échelle automatique.

Pour plus d'informations sur les paramètres, consultez Activer la mise à l'échelle automatique pour absorber les fluctuations de trafic.

Modes de mise à l'échelle

La mise à l'échelle automatique fonctionne selon deux modes : le mode stable et le mode panique. Chaque mode s'exécute dans une fenêtre temporelle. Le mode stable convient aux opérations régulières. Par défaut, la fenêtre de panique est plus courte ; le mode panique est donc adapté à la création rapide de pods pour gérer les pics de trafic.

Fenêtre stable

Pour garantir une mise à l'échelle des pods conforme aux attentes, la fenêtre stable doit être supérieure au temps moyen de lancement des pods. Nous vous recommandons de définir la fenêtre stable au double du temps moyen.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/window: "40s"

Fenêtre de panique

La fenêtre de panique est définie comme un pourcentage de la fenêtre stable. Elle gère généralement les pics de trafic inattendus.

• Si la fenêtre stable est de 30 secondes et la fenêtre de panique de 10 %, le système décide d'activer le mode panique en fonction des statistiques collectées sur 3 secondes. Si les pods nécessitent 30 secondes pour être lancés, le système peut continuer à déployer des pods alors que les nouveaux pods sont encore en cours de lancement. Cela entraîne la création d'un nombre excessif de pods.

• Ne modifiez pas la fenêtre de panique avant d'avoir ajusté les autres paramètres et confirmé que les activités de mise à l'échelle se déroulent comme prévu, surtout si la fenêtre de panique est égale ou inférieure au temps de lancement des pods. Si la fenêtre stable est le double du temps moyen de lancement des pods, définissez la fenêtre de panique à 50 % comme limite entre les modes stable et panique.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/panic-window-percentage: "20.0"

Le seuil du mode panique définit le ratio entre le trafic entrant et la capacité du service. Ajustez ce seuil en fonction de la valeur de pointe du trafic et de la latence tolérable. La valeur initiale est de 200 % ou plus jusqu'au démarrage du mode stable. Vous pouvez modifier ce seuil après une période d'exécution de votre application.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/panic-threshold-percentage: "150.0"

Taux de mise à l'échelle

Vous pouvez ajuster les taux de montée et de descente en charge pour mieux contrôler la mise à l'échelle des pods. Les taux par défaut répondent aux exigences de la plupart des scénarios. Avant de modifier ces taux, observez l'état actuel, testez les nouveaux taux dans un environnement de préproduction et évaluez leur impact. En cas de problème de mise à l'échelle, vérifiez les paramètres pertinents, tels que la fenêtre stable et la fenêtre de panique.

Taux de montée en charge

Ne modifiez le taux de montée en charge que si nécessaire pour résoudre certains problèmes. Par exemple, ajustez-le si le temps de lancement des pods est long en raison de l'attente de ressources pour les nouveaux pods. Si les activités de mise à l'échelle sont fréquemment déclenchées, vous devrez peut-être également modifier d'autres paramètres, tels que la fenêtre stable ou la fenêtre de panique.

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  max-scale-up-rate: "500.0"

Taux de descente en charge

Définissez le taux de descente en charge au temps moyen de lancement des pods ou à une valeur supérieure. Le taux par défaut convient à la plupart des scénarios. Toutefois, pour réduire les coûts, vous pouvez augmenter ce taux afin de supprimer rapidement les pods lorsque le volume de trafic diminue.

Le taux de descente en charge est un ratio. Par exemple, N/2 signifie que le nombre de pods est réduit de moitié à la fin du cycle de mise à l'échelle actuel. Pour les services exécutant peu de pods, réduisez le taux de descente en charge afin de maintenir un certain nombre de pods. Cela améliore la stabilité du système et évite les mises à l'échelle fréquentes.

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  max-scale-down-rate: "4.0"

Délai de descente en charge

Définissez un délai de descente en charge pour empêcher l'autoscaler de créer fréquemment des pods lors de la réception de nouvelles requêtes. Cela aide à résoudre le problème de latence de réponse des pods aux requêtes.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/scale-down-delay: "2m" // Scale-down activities are performed with a delay of two minutes.

Limites de mise à l'échelle

Les limites de mise à l'échelle dépendent de l'ampleur de l'activité commerciale et de la disponibilité des ressources.

Limite inférieure

autoscaling.knative.dev/min-scale contrôle le nombre minimal de réplicas pour chaque révision. Knative maintient le nombre de réplicas supérieur ou égal à cette limite inférieure. Pour les services rarement consultés mais devant rester constamment disponibles, définissez la limite inférieure à 1 pour garantir au moins un réplica. Pour les services susceptibles de connaître des pics de trafic, définissez la limite inférieure à une valeur supérieure à 1. Si vous souhaitez que les réplicas descendent à zéro en l'absence de requête, définissez la limite inférieure à 0.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/min-scale: "0"

Limite supérieure

La valeur de autoscaling.knative.dev/max-scale ne doit pas dépasser la quantité de ressources disponibles. La limite supérieure plafonne le coût maximal des ressources.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/max-scale: "3"

Mise à l'échelle initiale

Définissez la mise à l'échelle initiale à 1,2 fois le nombre actuel de pods afin que le trafic puisse être distribué aux nouvelles versions.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/initial-scale: "3"

Partage de GPU

Grâce à la fonctionnalité de partage de GPU de Container Service for Kubernetes (ACK), les services Knative peuvent exploiter pleinement la capacité d'isolation de la mémoire GPU de cGPU pour améliorer l'utilisation des ressources GPU.

Pour partager les GPU dans Knative, il suffit de définir limits sur aliyun.com/gpu-mem pour le service Knative. Exemple :

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    spec:
      containerConcurrency: 1
      containers:
      - image: registry-vpc.cn-hangzhou.aliyuncs.com/demo-test/test:helloworld-go
        name: user-container
        ports:
        - containerPort: 6666
          name: http1
          protocol: TCP
        resources:
          limits:
            aliyun.com/gpu-mem: "3"

Sondes

Configurez des sondes de vivacité et de readiness pour surveiller l'état de santé et la disponibilité des services Knative. Contrairement à la politique de sondage Kubernetes, Knative sonde les services plus fréquemment afin de minimiser le temps de démarrage à froid des pods.

• Sondes de vivacité : utilisées pour surveiller l'état de santé des conteneurs. Si un conteneur est en état Failed ou si le service dans le conteneur ne parvient pas à démarrer, la sonde de vivacité redémarre le conteneur.

• Sondes de readiness : utilisées pour gérer efficacement la mise à l'échelle automatique des applications, garantissant que seuls les pods en état Ready reçoivent du trafic. Cela améliore la stabilité et la rapidité de réponse du service.

  • Une sonde TCP n'ouvre le port d'écoute qu'une fois tous les composants chargés et les conteneurs prêts.

  • Une sonde HTTP ne marque un service comme prêt que lorsque l'endpoint du service est prêt à traiter les requêtes.

  • Définissez periodSeconds (intervalle de sondage) sur une petite valeur. Dans la plupart des cas, spécifiez un intervalle de sondage inférieur à la valeur par défaut de 10 secondes.

Pour plus d'informations sur le sondage de port et les bonnes pratiques, consultez Configurer le sondage de port dans Knative.

Descente à zéro

Knative peut réduire à zéro le nombre de pods d'un service lorsque celui-ci est inactif.

Si vous devez gérer plusieurs modèles, nous vous recommandons de créer un service Knative pour chaque modèle afin de simplifier la logique métier de chaque service.

• La fonctionnalité de descente à zéro de Knative empêche les modèles inactifs d'engendrer des coûts de ressources.

• Lorsqu'un client accède à un modèle pour la première fois, Knative commence la montée en charge depuis zéro.

Pour plus d'informations sur la descente à zéro et les bonnes pratiques, consultez Configurer des instances réservées pour les services Knative afin de réduire la latence de démarrage à froid.

Versions Canary

Knative garantit la continuité des activités lors des déploiements de nouvelles versions. Lorsque vous mettez à jour le code ou modifiez un service, Knative continue d'exécuter l'ancienne version jusqu'à ce que la nouvelle version soit prête.

Vous pouvez spécifier le pourcentage de trafic distribué à la nouvelle version. Ce pourcentage est un paramètre clé qui détermine le moment où Knative bascule le trafic de l'ancienne vers la nouvelle version. Vous pouvez définir ce pourcentage dans une plage de 10 % à 100 %. Lorsque vous n'avez plus besoin de l'ancienne version, définissez le pourcentage à 100 %. L'ancienne version est immédiatement retirée dès que la nouvelle version est prête.

Vous devez limiter la vitesse de descente en charge de l'ancienne version lors des opérations par lots avec un nombre limité de pods. Par exemple, si un service exécute 500 pods et que seulement 300 pods supplémentaires sont disponibles, définir un pourcentage de trafic trop élevé peut rendre certaines fonctionnalités du service indisponibles.

Pour plus d'informations sur les versions canary et les bonnes pratiques, consultez Version canary par répartition du trafic.

Colocalisation des instances ECS et des instances de conteneur élastiques

Vous pouvez configurer des ResourcePolicies pour utiliser des instances Elastic Compute Service (ECS) pendant les heures creuses et des instances de conteneur élastiques pendant les heures de pointe.

• Lors du processus de montée en charge, les pods Knative sont de préférence planifiés sur des instances ECS. Lorsque le nombre de pods dépasse la limite supérieure prédéfinie ou que les instances ECS sont en rupture de stock, les nouveaux pods sont planifiés sur des instances de conteneur élastiques.

• Lors du processus de descente en charge, les pods sur les instances de conteneur élastiques sont de préférence supprimés en premier.

Pour plus d'informations sur la colocalisation et les bonnes pratiques, consultez Colocaliser des instances ECS et des instances de conteneur élastiques dans Knative.