Meilleures pratiques en matière d’IA/ML dans Kubernetes : l’essentiel

L’exécution de charges de travail d’IA/ML à grande échelle sur Kubernetes peut donner l’impression de naviguer dans un labyrinthe d’allocations de ressources, d’obstacles à la sécurité et de demandes de surveillance, surtout si vous n’avez pas de plan solide en place. Bien sûr, il est passionnant de voir des tâches de réseau neuronal comme la reconnaissance d’images ou la prédiction de l’attrition, mais il y a toujours le souci de pousser votre cluster à ses limites.

Le MLOps est un point d’ancrage convivial ici, qui comble le fossé entre les scientifiques des données, les personnes DevOps et les équipes de sécurité sous la forme d’un ensemble d’idées et d’outils qui vous aident à suivre la création, les tests et la publication des modèles. Il encourage une collaboration étroite, de sorte qu’un scientifique des données d’une équipe et un gourou de Kubernetes d’une autre peuvent mettre à jour un modèle en toute confiance sans se marcher sur les pieds'orteils. Lorsque le MLOps rencontre l’orchestration de conteneurs, vous disposez d’un moyen plus prévisible de contrôler les pipelines d’IA.

L’objectif de cet article est de partager les meilleures pratiques pour l’exécution de tâches d’IA complexes sur Kubernetes. Nous'Nous parlerons de la mise à l’échelle, de la planification, de la sécurité, de la gestion des ressources et d’autres éléments importants pour les ingénieurs de plateforme chevronnés et les personnes qui se lancent dans l’apprentissage automatique dans Kubernetes. En parcourant chaque section, vous'vous trouverez des conseils pratiques pour protéger votre cluster Risques de sécurité liés à l’IA, contrôlez vos coûts et donnez à vos modèles la puissance de calcul dont ils ont besoin.

Pratiques de codage sécurisé Kubernetes [Aide-mémoire]

Cet aide-mémoire de 10 pages fournit des conseils avancés et exploitables aux développeurs d’infrastructures et de plateformes pour protéger les applications conteneurisées.

Télécharger le PDF

Gestion des ressources

Avant de lancer des conteneurs à des fins d’entraînement ou d’inférence, il est important de s’assurer que les ressources du cluster correspondent à l’intensité de vos charges de travail. Après tout, ignorer les demandes du GPU ou sauter le dimensionnement approprié du CPU entraîne des performances lentes, des destructions aléatoires de mémoire insuffisante et des équipes déçues.

Allocation de GPU et de matériel spécialisé

Les GPU, TPU et autres accélérateurs sont comme les voitures de sport d’un cluster's. Ils vous permettent d’entraîner des modèles massifs ou de gérer un débit énorme pendant l’inférence. La mise à disposition de ces ressources matérielles à l’intérieur des pods s’appuie sur des plug-ins d’appareil fournis par Kubernetes. Par exemple, en ajoutant le plugin officiel de l’appareil NVIDIA, vous pouvez demander des tranches de GPU par pod.

Un conseil important ? La définition des demandes de ressources appropriées permet de s’assurer que le planificateur détecte le bon nœud avec le bon GPU. Si vous ignorez ces définitions de ressources, votre charge de travail peut atterrir sur un nœud sans l’accélérateur, ce qui entraîne des échecs de tâche. Il est également utile d’étiqueter les nœuds GPU avec quelque chose comme nvidia.com/gpu=true pour les cibler facilement via nodeSelector ou nodeAffinity.

L’extrait de code ci-dessous montre une spécification de pod de base qui demande un GPU à NVIDIA :

apiVersion : v1
type : Pod
métadonnées:
  Nom : gpu-training-pod
Spec:
  Conteneurs:
  - Nom : gpu-training-container
    Image : nvcr.io/nvidia/tensorflow:22.01-tf2-py3
    ressources:
      Limites:
        nvidia.com/gpu : 1
  nodeSelector :
    nvidia.com/gpu : "vrai"

Dimensionnement du processeur et de la mémoire

Tous les pipelines de données ou tâches d’entraînement de modèles n’ont pas besoin d’un GPU. De nombreuses tâches s’exécutent parfaitement sur les processeurs si vous les dimensionnez correctement. En définissant des requêtes et des limites, le planificateur Kubernetes sait combien de pods peuvent tenir sur un nœud. Sans ces paramètres, vous risquez une mauvaise planification ou des pods en concurrence pour les mêmes cœurs de processeur. Pour faire passer la planification au niveau supérieur, ajoutez Mise à l’échelle automatique du cluster pour absorber les pics soudains de trafic ou de formation des emplois.

N’oubliez pas de surveiller attentivement les mesures d’utilisation réelles, à l’aide d’un système de surveillance comme Prometheus. Si les pods atteignent constamment 90 % du processeur, ajustez légèrement les demandes. D’un autre côté, si les pods restent autour de 20 % d’utilisation du processeur, vous pouvez réduire leurs demandes.

Vous trouverez ci-dessous un exemple de déploiement qui définit les demandes et les limites de processeur et de mémoire :

apiVersion : apps/v1
type : Déploiement
métadonnées:
  Nom : ml-inference-deployment
Spec:
  répliques : 2
  modèle:
    Spec:
      Conteneurs:
      - Nom : ml-inference-container
        image : votre-registre/ml-inference :latest
        ressources:
          Requêtes:
            CPU: "500 m"
            mémoire: "512mi"
          Limites:
            CPU: "1000m"
            mémoire: "1024mi"

Mise à l’échelle de vos charges de travail IA/ML

Une fois que vous avez'J’ai défini comment demander et allouer des ressources, il est temps d’évoluer. Dans certains scénarios, vous mettrez à l’échelle les pods d’inférence horizontalement pour gérer les demandes entrantes pointues. Dans d’autres, vous planifierez des tâches d’entraînement volumineuses qui peuvent nécessiter des types de nœuds spécialisés.

Mise à l’échelle horizontale et verticale

La mise à l’échelle horizontale est ce dont vous avez besoin pour gérer des charges utilisateur imprévisibles, en particulier pour les points de terminaison d’inférence. Il est recommandé de configurer Les HPA pour surveiller l’utilisation du CPU ou du GPU, puis faire tourner de nouveaux pods lorsque les choses se réchauffent. Néanmoins, la mise à l’échelle verticale peut être une meilleure réponse si votre conteneur a besoin de plus de mémoire ou de cœurs de processeur sur un seul nœud. L’autoscaler de pod vertical (VPA) peut vous aider à ajuster les demandes de charges de travail stables au fil du temps.

Ici's un extrait d’un HPA faisant référence à un déploiement en fonction de l’utilisation du processeur :

apiVersion : mise à l’échelle automatique/v2
type : HorizontalPodAutoscaler
métadonnées:
  Nom : Inference-HPA
Spec:
  scaleTargetRef :
    apiVersion : apps/v1
    type : Déploiement
    Nom : inference-deployment
  minRépliques : 2
  maxRépliques : 15
  métrique:
  - type : Ressource
    ressource:
      Nom : CPU
      cible:
        type : Utilisation
        moyenneUtilisation : 75

Traitements par lots et ordonnancement

La formation à grande échelle est souvent préférable en tant que processus par lots. Pour simplifier votre pipeline, utilisez les Jobs Kubernetes pour les expériences ponctuelles et les CronJobs pour les tâches planifiées telles que le réentraînement nocturne. En adoptant cette approche, chaque exécution de tâche réussie signifie que le modèle ou l’artefact peut être automatiquement stocké quelque part pour une utilisation ultérieure.

Un traitement par lots bien structuré garantit que les tâches d’entraînement de longue durée ne surchargent pas vos nœuds de cluster. Pour ce faire, vous pouvez demander des ressources GPU ou CPU de la même manière que n’importe quel autre pod, en vous assurant de les gérer efficacement.

Vous trouverez ci-dessous un CronJob qui lance une course d’entraînement nocturne :

apiVersion : batch/v1
type : CronJob
métadonnées:
  Nom : nightly-model-training
Spec:
  horaire: "0 2 * * *"
  jobTemplate :
    Spec:
      modèle:
        Spec:
          Conteneurs:
          - nom : training-container
            image : votre-registre/image-de-formation :latest
            ressources:
              Limites:
                nvidia.com/gpu : 1
            commande : ["python", "train.py"]
          restartPolicy : Jamais

Stratégies multi-clusters et hybrides

Il est parfois nécessaire de répartir les charges de travail sur plusieurs Clusters Kubernetes, surtout si vous souhaitez une redondance ou pour exécuter certaines tâches sur site et d’autres dans le cloud. Cela peut permettre d’économiser de l’argent et de réduire les risques. Des outils tels que Anthos Offrez une console de gestion qui montre comment les tâches sont distribuées. S’il y a'un problème dans un environnement, vous pouvez basculer vers un autre, ce qui vous donne la tranquillité d’esprit lorsque vous'Jongler avec les tâches d’inférence critiques destinées à l’utilisateur.

Figure 1 : Vue d’ensemble multi-cluster d’Anthos (Source : Google Cloud)

Stockage et gestion des données

Une fois que vos tâches peuvent évoluer efficacement, les données occupent le devant de la scène. Où sont-ils stockés ? À quelle vitesse pouvez-vous le lire ? Comment le prouvez-vous ? Ces questions se posent souvent lorsqu’il s’agit de grands ensembles de données d’entraînement, et elles sont cruciales pour éviter que la récupération des données ne devienne un goulot d’étranglement.

Classes de stockage hautes performances

StockageLes classes basées sur des disques SSD sont idéales pour l’entraînement de charges de travail avec de grandes exigences en lecture/écriture. Pour en tirer le meilleur parti, définissez un PersistentVolumeClaim (PVC) qui fait référence à la StorageClass appropriée et aux dispositions de cluster appropriées pour le stockage de sauvegarde. Veillez également à surveiller les IOPS (opérations d’entrée/sortie par seconde) en lecture/écriture pour confirmer que vos volumes de stockage peuvent gérer le débit requis.

Ci-dessous, un PVC qui demande une classe de stockage haute performance :

piVersion : v1
type : PersistentVolumeClaim
métadonnées:
  Nom : FAST-PVC
Spec:
  accessModes :
    - LireÉcrireUne fois
  storageClassName : high-perf-ssd
  ressources:
    Requêtes:
      stockage : 100Gi

Localité des données et mise en cache

Dans la formation distribuée, la localité des données est importante. Lorsque les travailleurs récupèrent des données à partir de volumes distants, la latence du réseau peut entraîner des ralentissements. La solution ? Placez les couches de mise en cache devant le stockage distant ou choisissez des volumes SSD locaux au nœud. Une autre stratégie consiste à exécuter un conteneur sidecar de mise en cache dans le même pod, qui gère les lectures et les écritures de données, améliorant ainsi les performances dans des flux de travail spécifiques.

L’extrait de code ci-dessous montre un conteneur sidecar qui fournit une mise en cache pour les données d’entraînement :

apiVersion : apps/v1
type : Déploiement
métadonnées:
  Nom : training-deployment
Spec:
  répliques : 2
  sélecteur:
    matchLabels :
      App : Appli de formation
  modèle:
    métadonnées:
      Étiquettes:
        App : Appli de formation
    Spec:
      Conteneurs:
      - nom : caching-sidecar
        image : votre-registre/caching-sidecar :latest
        volumeSupports :
          - nom : cache-volume
            mountPath : /cache
      - nom : training-container
        image : votre-registre/image-de-formation :latest
        volumeSupports :
          - nom : cache-volume
            mountPath : /dataset
      Volumes:
        - nom : cache-volume
          emptyDir : {}

Sauvegarde et gestion des versions

Le suivi des versions des modèles est standard pour une bonne raison : si les nouveaux modèles échouent en production (hé, ça arrive !), vous aurez besoin de retours en arrière fréquents. Outre le stockage des artefacts de modèle dans le stockage d’objets, il est également important d’exécuter des sauvegardes planifiées. Même si vous'En ce qui concerne l’utilisation d’un service cloud qui fournit des sauvegardes automatiques, des sauvegardes supplémentaires sont la voie à suivre pour éviter les problèmes sur toute la ligne.

Vous trouverez ci-dessous un Flux de travail Argo qui charge les artefacts de modèle dans un compartiment distant dans S3 :

apiVersion : argoproj.io/v1alpha1
type : Flux de travail
métadonnées:
  generateName : model-backup-
Spec:
  point d’entrée : modèle-de-sauvegarde
  Modèles:
  - nom : Backup-model
    conteneur:
      image : votre-registre/outil de sauvegarde :latest
      commande : ["modèle-de-sauvegarde"]
      args : ["--model-path=/models", "--destination=s3 ://ml-backups"]

Considérations relatives à la sécurité

Nous'ont tous vu les gros titres sur le piratage de clusters ou l’exfiltration de données, comme le Incident d’accès non autorisé à Hugging Face où les attaquants ont ciblé leur plateforme d’hébergement de modèle d’IA. Ces violations mettent en évidence pourquoi Sécurité Kubernetes et Sécurité de l’IA sont devenus une énorme priorité. Lorsque vous combinez des charges de travail conteneurisées avec des pipelines de ML avancés, les vecteurs de menaces se multiplient rapidement. Laisser'quelques façons de contrôler ces risques.

25 agents IA. 257 attaques réelles. Qui gagne ?

De la découverte zero-day à l’escalade des privilèges cloud, nous avons testé 25 combinaisons agent-modèle sur 257 défis réels de sécurité offensive. Les résultats pourraient vous 👀 surprendre

Principes fondamentaux de la sécurité Kubernetes

Pour renforcer la sécurité, suivez ces bonnes pratiques :

Analyser les images de conteneur pour détecter les vulnérabilités avant le déploiement.
Appliquer le contrôle d’accès basé sur les rôles (RBAC) pour limiter les personnes autorisées à déployer, modifier ou supprimer des charges de travail.
Appliquer les normes de sécurité des pods (PSS) pour éviter les erreurs de configuration qui pourraient exposer les clusters à des menaces.
Limiter l’accès à registres de conteneurs et surveiller les modifications non autorisées.
Baliser les images avec des références stables pour s’assurer que seules des versions vérifiées sont utilisées en production.

Ici's un extrait de code RBAC qui accorde des privilèges minimaux à un espace de noms :

type : Rôle
apiVersion : rbac.authorization.k8s.io/v1
métadonnées:
  Espace de noms : ml-project
  Nom : ml-project-role
règlement:
- apiGroups : ["", "Apps"]
  Ressources : ["Gousses", "Déploiements"]
  verbes : ["Avoir", "liste", "créer", "mettre à jour", "supprimer"]
---
type : RoleBinding
apiVersion : rbac.authorization.k8s.io/v1
métadonnées:
  Nom : ml-project-rolebinding
  Espace de noms : ml-project
Sujets:
- kind : Utilisateur
  Nom : ml-user
  apiGroup : rbac.authorization.k8s.io
roleRef :
  type : Rôle
  Nom : ml-project-role
  apiGroup : rbac.authorization.k8s.io

Protection de l’intégrité du modèle

À mesure que les modèles d’IA deviennent plus puissants et plus largement déployés, ils deviennent également la cible d’attaques adverses, d’empoisonnement des données et de dérives de distribution. Les attaquants peuvent manipuler les données d’entraînement pour nuire aux performances du modèle ou exploiter les faiblesses de la logique du modèle.

Pour atténuer ces menaces, surveillez les données entrantes à la recherche d’anomalies, utilisez des outils de détection de dérive pour repérer le moment où les performances réelles de votre modèle commencent à baisser, et entraînez-vous (ou réentraînez-vous) uniquement sur des ensembles de données vérifiés. Le maintien de cette vigilance permet de s’assurer que votre modèle reste précis et résilient face à l’évolution des menaces.

Vous trouverez ci-dessous un exemple d’extrait de code Python montrant comment vous pouvez utiliser la bibliothèque Alibi Detect pour détecter la dérive des données :

à partir de alibi_detect.cd importer KSDrift
Importer numpy en tant que NP

# Données de référence (par exemple, données d’entraînement de base)
X_ref = np.random.rand(1000, 10)

# Nouvelles données entrantes (par exemple, échantillons de trafic en direct)
X = np.random.rand(1000, 10) # Remplacer par les données de production réelles

# Initialiser le détecteur de dérive
cd = KSDrift(X_ref, p_val=0,05)

# Exécuter la vérification de la dérive
preds = cd.predict(X)

si les preds['data_drift']:
    imprimer("Dérive de données détectée ! Valeur P :", préds['p_val'])
    # Éventuellement, déclenchez un pipeline de réentraînement ou une alerte
autre:
    imprimer("Aucune dérive de données n’a été détectée. Valeur P :", préds['p_val'])

Signature d’images

Une fois que vous avez pris des mesures pour préserver l’intégrité du modèle, la couche de défense suivante consiste à confirmer l’authenticité d’un modèle en signant des images de conteneur qui contiennent vos artefacts de modèle. Des outils tels que Cosigner Simplifiez l’ajout de signatures numériques, tandis que le chiffrement au repos et une chaîne de traçabilité pour les données d’entraînement contribuent à protéger davantage votre écosystème, en particulier dans les secteurs réglementés.

Vous pouvez signer votre image de conteneur à l’aide d’une simple commande Cosign :

$ cosign sign --key cosign.key votre-registre/votre-image :tag

En plus de cela, ajoutez des étapes d’analyse de code automatisées dans les pipelines CI. Cela permet d’identifier les vulnérabilités potentielles dans les dépendances avant qu’elles n’atteignent la production. Vous trouverez ci-dessous un extrait de code qui intègre Trivy, un scanner de sécurité open source, dans un pipeline GitHub Actions :

Nom : code-scanning-workflow
sur : [pousser, pull_request]
Emplois:
  numériser:
    Fonctionne sur : ubuntu-latest
    escalier:
    - Utilisations : Actions/checkout@v2
    - nom : Scanner avec Trivy
      Utilisations : Aquasécurité/Trivy-action@master
      avec:
        image-ref : "votre-registre/votre-image :latest"
        format: "table"

Isolation du réseau et Zero Trust

La sécurisation des charges de travail d’IA commence par une isolation solide du réseau. Une approche efficace consiste à définir Stratégies réseau qui limitent les pods et les espaces de noms peuvent communiquer entre eux. Au-delà de cela, il'pour éviter d’exécuter des charges de travail d’IA/ML en même temps que d’autres applications dans le même cluster. En segmentant les charges de travail en fonction de leur objectif, par exemple en séparant les services d’inférence des applications Web générales, vous minimisez le risque de mouvement latéral en cas de violation.

Cette approche s’aligne sur les principes Zero Trust, selon lesquels chaque élément du trafic réseau est traité avec prudence, même s’il'internes au cluster. Associés à une solide gestion de l’accès aux identités, ces garde-fous permettent d’éviter les fuites de données accidentelles et les tentatives d’infiltration.

Ici's une NetworkPolicy qui limite le trafic à l’espace de noms d’inférence uniquement :

apiVersion : networking.k8s.io/v1
type : NetworkPolicy
métadonnées:
  name : allow-namespace-traffic
  espace de noms : inférence
Spec:
  podSelector : {}
  entrée:
  -De:
    - namespaceSelector :
        matchLabels :
          Objectif : inférence

Visibilité de bout en bout : du code à l’exécution

Les charges de travail d’IA/ML posent des défis complexes en matière de sécurité et de conformité qui couvrent l’ensemble du cycle de vie, du développement du code à l’exécution du runtime. Sans une visibilité complète, des erreurs de configuration, des vulnérabilités et des dérives peuvent se glisser dans vos clusters Kubernetes, augmentant ainsi le risque de violations.

Pour y remédier, les équipes ont besoin d’une stratégie de sécurité qui couvre toutes les étapes du pipeline d’IA : analyse des configurations d’infrastructure en tant que code (IaC), sécurisation des images de conteneurs, Application des protections d’exécutionet surveillance continue pour les anomalies. En intégrant des contrôles de sécurité dans l’ensemble du pipeline, vous vous assurez que les charges de travail d’IA restent résilientes et conformes.

Wiz propose une plateforme qui vous permet de suivre en temps réel les vulnérabilités, les problèmes de conformité et la posture de sécurité de votre cluster. Profitez du tableau de bord Wiz pour repérer les problèmes d’image de conteneur, les erreurs de configuration et même Secrets Caché dans le code :

Figure 2 : Présentation du tableau de bord de conformité Wiz

Observabilité : surveillance, journalisation et traçage

Lorsque vous ajustez votre cluster pour les charges de travail de machine learning, vous visez une vue claire de ce que'. Cela signifie collecter des métriques à partir de pods, stocker les journaux dans un emplacement centralisé et suivre les demandes sur les microservices. Grâce à une observabilité approfondie, le dépannage est une évidence en cas d’erreur.

Métriques et alertes

Prometheus se trouve généralement au cœur de votre pile de surveillance, vous aidant à suivre les indicateurs de performance clés. Pour garantir des opérations IA/ML fluides, utilisez une combinaison d’outils :

Prométhée collecte les métriques d’utilisation du CPU, de la mémoire et du GPU à partir des services d’inférence de modèle.
Grafana Fournit des tableaux de bord en temps réel pour visualiser les performances du cluster et détecter les anomalies.
Règles d’alerte déclenchent automatiquement des notifications (par exemple, des alertes Slack) lorsque l’utilisation des ressources dépasse les seuils définis.

Vous trouverez ci-dessous une règle Prometheus qui alerte en cas d’utilisation élevée du GPU :

apiVersion : monitoring.coreos.com/v1
genre : PrometheusRule
métadonnées:
  Nom : gpu-usage-rules
  espace de noms :surveillance
Spec:
  groupe:
  - Nom : GPU-Alerts
    règlement:
    - alert : HighGPUUsage
      expr : nvidia_gpu_utilization > 90
      Pour : 5m
      Étiquettes:
        Sévérité : Avertissement
      Annotations:
        résumé: "Utilisation élevée du GPU détectée"

Traçage distribué et informations sur les performances

OpenTelemetry est un excellent choix pour le traçage distribué, en particulier si votre pipeline d’IA comprend plusieurs microservices. Chaque service émet des plages de traces, ce qui vous permet de localiser un goulot d’étranglement. Cette approche n’a pas de prix lorsqu’il s’agit de déboguer des requêtes lentes ou des anomalies de performances aléatoires dans les flux de traitement de données.

Voici comment OpenTelemetry Collector et Jaeger travaillent ensemble pour fournir des informations de suivi et de performances de bout en bout pour les charges de travail d’IA/ML :

Figure 3 : OpenTelemetry et Jaeger (Source : Red Hat)

Corréler sécurité et performance avec Wiz

Parfois, une baisse de performance est liée à un événement lié à la sécurité. Wiz vous aide à voir cette corrélation en mélangeant les résultats de sécurité avec les données de performance. Il se peut qu’un processus suspect monopolise les ressources GPU ou qu’une vulnérabilité connue entraîne une instabilité du cluster. Lorsque vous voyez ces modèles, Wiz vous demande une correction immédiate.

Figure 4 : Graphique de sécurité Wiz pour l’analyse des causes profondes

🚨Rapport de recherche sur la sécurité Kubernetes 2025

De nouvelles analyses issues de 200 000+ comptes cloud révèlent les derniers risques, tendances d’attaque et lacunes de sécurité dans les environnements Kubernetes.

Télécharger le PDF

Flux de travail CI/CD pour l’IA/ML

Nous savons tous que la livraison d’un modèle entraîné implique plus qu’une simple copie d’un fichier. Vous souhaitez automatiser entièrement la création, le test et le déploiement d’artefacts de ML. C’est là que les pipelines CI/CD sont utiles. Vous pouvez enchaîner des tâches qui exécutent des tests, analysent des images, les envoient dans un registre, puis déploient de nouvelles versions en production.

Automatisation de la gestion du cycle de vie des modèles

Des outils tels que Tekton ou Flux de travail Argo Vous permet de définir des pipelines pour l’ensemble du cycle de vie du modèle, de la préparation des données à l’entraînement et au déploiement. Chaque étape est déclenchée automatiquement chaque fois que vous validez une modification, ce qui permet de maintenir la cohérence du processus. Vous pouvez également ajouter des vérifications de validation pour vous assurer qu’un modèle répond aux seuils de précision prédéfinis avant de l’étiqueter pour la production. Cela permet d’éviter que des modèles peu performants ne soient déployés et n’aient un impact sur l’expérience utilisateur.

Vous trouverez ci-dessous un Tekton PipelineRun qui donne le coup d’envoi de la construction et du déploiement du modèle :

apiVersion : tekton.dev/v1beta1
type : PipelineRun
métadonnées:
  Nom : ml-pipeline-run
Spec:
  pipelineRéf :
    Nom : ml-build-deploy-pipeline
  Espaces de travail :
  - Nom : Shared-Data
    volumeClaimTemplate :
      Spec:
        accessModes : ["LireÉcrireUne fois"]
        ressources:
          Requêtes:
            stockage : 5Gi
  Paramètres :
  - name : nom-modèle
    valeur: "mon-modèle-ml"

Artefacts immuables et GitOps

Il est pratique de marquer les images avec des hachages de commit afin de savoir exactement quelle version du code ou du modèle vous're-run. GitOps étend cette pratique en vous permettant de stocker les manifestes Kubernetes dans un dépôt Git. Toutes les modifications apportées à ces manifestes sont automatiquement appliquées au cluster de manière contrôlée. Cette méthode vous permet de savoir précisément quand et pourquoi les changements se produisent.

Ici's un Argo CD Application référencement du référentiel Git pour la gestion des configurations de déploiement :

apiVersion : argoproj.io/v1alpha1
type : Application
métadonnées:
  Nom : ml-inference-app
Spec:
  destination:
    Espace de noms : ml-inference
    Serveur : https://kubernetes.default.svc
  source:
    repoURL : 'https://github.com/your-org/ml-deploy-configs.git'
    targetRevision : principal
    chemin d’accès : manifestes/inférence
  projet : par défaut
  syncPolicy :
    automatisé:
      Pruneau : Vrai
      selfHeal : vrai

Optimisation des performances

Les modèles doivent réagir rapidement et ne pas gaspiller d’heures de GPU ou de CPU coûteuses. Heureusement, des modifications mineures des paramètres HPA ou des règles d’équilibrage de charge peuvent faire gagner de précieuses millisecondes et réduire les coûts de manière solide.

Équilibrage

L’équilibrage de charge avec les ressources d’entrée permet d’acheminer le trafic vers le service d’inférence approprié. Pour séparer les différentes versions d’un modèle, vous avez la possibilité d’utiliser le routage basé sur le chemin.

Vous trouverez ci-dessous une entrée avec routage basé sur le chemin vers plusieurs services d’inférence :

apiVersion : networking.k8s.io/v1
type : Entrée
métadonnées:
  Nom : inférence-entrée
Spec:
  règlement:
  - Animateur : ml.example.com
    http :
      Chemins:
      - chemin : /v1/
        pathType : Préfixe
        Arrière-plan :
          service:
            Nom : inference-model-v1
            port:
              Numéro : 8081
      - chemin : /v2/
        pathType : Préfixe
        Arrière-plan :
          service:
            Nom : inference-model-v2
            port:
              Numéro : 8081

Profilage et optimisation des coûts

Tout le monde aime regarder comment ses nœuds GPU, ses nœuds CPU et son utilisation de la mémoire s’alignent sur les dépenses. Mais l’ajustement manuel des ressources peut prendre du temps et être inefficace. C’est là que des outils comme Karpenter et Pilote automatique Peut automatiquement mettre à l’échelle les nœuds de cluster pour répondre aux demandes de ressources, ce qui vous évite d’avoir à provisionner manuellement les nœuds. Pour les charges de travail d’entraînement qui n’ont pas besoin de calcul persistant, en tirant parti de Spot Instances peut réduire considérablement les coûts, il suffit de s’assurer que votre pipeline peut gérer les interruptions potentielles.

Vous trouverez ci-dessous un exemple de configuration Karpenter pour faire correspondre les types d’instance aux charges de travail :

apiVersion : karpenter.sh/v1alpha5
type : Provisionneur
métadonnées:
  Nom : par défaut
Spec:
  Exigences:
    -clé: "node.kubernetes.io/instance-type"
      operator : Dans
      valeurs : ["m5.grand", "m5.xlarge"]
  fournisseur:
    subnetSelector :
      karpenter.sh/discovery : "mon-cluster"
    securityGroupSelector :
      karpenter.sh/discovery : "mon-cluster"

Une autre façon d’économiser gros ? Utilisez un outil comme Wiz pour voir s’il existe des facteurs de coût liés à des ressources mal configurées ou à des modèles d’utilisation inhabituels. Wiz vous aide également à renforcer les nœuds lors de la création pour vous assurer qu’ils sont non seulement automatiquement mis à l’échelle, mais aussi sécurisés.

Figure 5 : Règles de coût du cloud Wiz

Conclusion

Nous'J’ai discuté de diverses stratégies pour les flux de travail d’apprentissage automatique sur Kubernetes. De la gestion des ressources aux meilleures pratiques de sécurité de l’IA en passant par le raccordement des pipelines Tekton, nous'J’ai vu comment chaque pièce peut contribuer à une plate-forme stable. L’idée principale est de garder un œil sur les risques de sécurité de l’IA, de surveiller les dépassements de coûts et de créer un pipeline auquel les gens font confiance.

Lorsque vous mettez en œuvre ces bonnes pratiques, vous minimisez les interruptions de cluster et aidez les data scientists à pousser les mises à jour en toute confiance. Nous'J’ai hâte de voir comment ces suggestions s’intègrent dans votre travail. Nous'J’aimerais avoir des nouvelles de ce que vous créez, des leçons que vous découvrez et de la façon dont vous continuez à améliorer votre apprentissage automatique dans les flux de travail Kubernetes.

Ce voyage peut sembler compliqué, mais avec les bons outils, comme Wiz'd’analyse en temps réel, de tableaux de bord et de fonctions de conformité, vous pouvez créer un environnement plus sûr pour la formation et l’inférence. Si vous'Si vous cherchez à affiner et à faire évoluer vos projets d’IA/ML tout en restant en sécurité, donnez à Wiz une chance d’obtenir une vue d’ensemble des vulnérabilités des conteneurs, des paramètres de cluster et des benchmarks de conformité. Avec Wiz, vous pouvez garder vos clusters sains, rentables et à l’abri des intrusions.

Sécurisez votre cloud, du code à la production

Découvrez pourquoi les entreprises à la croissance la plus rapide choisissent Wiz pour sécuriser les conteneurs, Kubernetes et les environnements cloud, du temps de construction au temps réel.