L'esecuzione di carichi di lavoro AI/ML su larga scala su Kubernetes può sembrare come navigare in un labirinto di allocazioni di risorse, ostacoli alla sicurezza e richieste di monitoraggio, soprattutto se non si dispone di un piano solido. Certo, è emozionante vedere attività di rete neurale come il riconoscimento delle immagini o la previsione dell'abbandono, ma c'è sempre la preoccupazione di spingere il cluster al limite.
MLOps è un'ancora amichevole in questo caso, che colma il divario tra data scientist, DevOps e team di sicurezza come un set di idee e strumenti che ti aiutano a tenere traccia della creazione, del test e del rilascio del modello. Incoraggia una stretta collaborazione, in modo che un data scientist in un team e un guru di Kubernetes in un altro possano aggiornare con sicurezza un modello senza calpestarsi a vicenda's dita dei piedi. Quando MLOps incontra l'orchestrazione dei contenitori, si ottiene un modo più prevedibile di controllare le pipeline di intelligenza artificiale.
Il nostro obiettivo con questo articolo è condividere le best practice per l'esecuzione di attività di intelligenza artificiale complesse su Kubernetes. Noi'parleremo di scalabilità, pianificazione, sicurezza, gestione delle risorse e altri elementi che contano per gli ingegneri di piattaforma esperti e per le persone che stanno appena entrando nell'apprendimento automatico in Kubernetes. Camminando attraverso ogni sezione, si'raccoglieremo consigli pratici per proteggere il tuo cluster da Rischi per la sicurezza dell'IA, tieni sotto controllo i costi e offri ai tuoi modelli la potenza di calcolo che desiderano.
Pratiche di codifica sicura di Kubernetes [Cheat Sheet]
Questo cheat sheet di 10 pagine fornisce una guida avanzata e pratica per gli sviluppatori di infrastrutture e piattaforme per salvaguardare le applicazioni containerizzate.
Scaricare PDF
Gestione delle risorse
Prima di avviare i contenitori per il training o l'inferenza, è importante assicurarsi che le risorse del cluster corrispondano all'intensità dei carichi di lavoro. Dopotutto, ignorare le richieste della GPU o saltare il corretto dimensionamento della CPU porta a prestazioni lente, uccisioni casuali di memoria esaurita e team delusi.
Allocazione di GPU e hardware specializzato
GPU, TPU e altri acceleratori sono come le auto sportive in un cluster's garage. Consentono di addestrare modelli di grandi dimensioni o gestire un throughput elevato durante l'inferenza. Rendere disponibili queste risorse hardware all'interno dei pod si basa sui plug-in del dispositivo forniti da Kubernetes. Ad esempio, aggiungendo il plug-in ufficiale del dispositivo NVIDIA, è possibile richiedere sezioni GPU per pod.
Un consiglio importante? L'impostazione di richieste di risorse corrette garantisce che l'utilità di pianificazione individui il nodo giusto con la GPU corretta. Se si ignorano queste definizioni di risorse, il carico di lavoro potrebbe finire in un nodo senza l'acceleratore, causando errori di processo. È anche utile etichettare i nodi GPU con qualcosa come nvidia.com/gpu=true per indirizzarli facilmente tramite nodeSelector o nodeAffinity.
Il frammento di codice seguente mostra una specifica pod di base che richiede una GPU da NVIDIA:
apiVersion: v1
tipo: Pod
Metadati:
Nome: GPU-Training-pod
Spec:
contenitori:
- Nome: gpu-training-container
Immagine: nvcr.io/nvidia/tensorflow:22.01-tf2-py3
risorse:
Limiti:
nvidia.com/gpu: 1
nodeSelector:
nvidia.com/gpu: "vero"Dimensionamento della CPU e della memoria
Non tutti i processi di training di pipeline di dati o modelli necessitano di una GPU. Molte attività vengono eseguite perfettamente sulle CPU se vengono dimensionate correttamente. Impostando richieste e limiti, l'utilità di pianificazione di Kubernetes sa quanti pod possono essere inseriti in un nodo. Senza questi parametri, si rischia una pianificazione scadente o pod in competizione per gli stessi core della CPU. Per portare la programmazione a un livello superiore, aggiungi Scalabilità automatica del cluster per assorbire picchi improvvisi di traffico o lavori di formazione.
Ricordati di osservare attentamente le metriche di utilizzo effettive, utilizzando un sistema di monitoraggio come Prometheus. Se i pod raggiungono costantemente il 90% della CPU, regolare leggermente le richieste. D'altra parte, se i pod rimangono intorno al 20% di utilizzo della CPU, puoi ridurre le loro richieste.
Di seguito è riportato un esempio di distribuzione che definisce le richieste e i limiti di CPU e memoria:
apiVersion: apps/v1
tipo: Distribuzione
Metadati:
Nome: ml-inference-deployment
Spec:
Repliche: 2
sagoma:
Spec:
contenitori:
- nome: ml-recipient-inference-container
Immagine: Your-Registry/ML-inference:Latest
risorse:
Richieste:
CPU: "500 metri"
memoria: "512Mi"
Limiti:
CPU: "1000 metri"
memoria: "1024Mi"Ridimensionamento dei carichi di lavoro AI/ML
Una volta che tu'Dopo aver individuato come richiedere e allocare le risorse, è il momento di scalare. In alcuni scenari, i pod di inferenza verranno ridimensionati orizzontalmente per gestire le richieste in ingresso con picco. In altri, si pianificheranno processi di training di grandi dimensioni che potrebbero richiedere tipi di nodo specializzati.
Ridimensionamento orizzontale e verticale
Il ridimensionamento orizzontale è ciò di cui hai bisogno per gestire carichi utente imprevedibili, in particolare per gli endpoint di inferenza. È consigliabile configurare HPA per monitorare l'utilizzo della CPU o della GPU, quindi avvia nuovi pod quando le cose si surriscaldano. Tuttavia, il ridimensionamento verticale può essere una risposta migliore se il tuo container ha bisogno di più memoria o core CPU su un singolo nodo. Il Vertical Pod Autoscaler (VPA) può aiutarti a modificare le richieste di carichi di lavoro stabili nel tempo.
Qui's un frammento di un HPA che fa riferimento a una distribuzione in base all'utilizzo della CPU:
apiVersion: ridimensionamento automatico/v2
tipo: HorizontalPodAutoscaler
Metadati:
Nome: Inferenza-HPA
Spec:
scaleTargetRef:
apiVersion: apps/v1
tipo: Distribuzione
Nome: Inferenza-Distribuzione
MinReplicas: 2
Numero massimo di repliche: 15
Metriche:
- tipo: Risorsa
risorsa:
Nome: CPU
bersaglio:
tipologia: Utilizzo
average Utilization: 75Processi batch e programmazione
La formazione su larga scala è spesso migliore come processo batch. Per semplificare la pipeline, usa Kubernetes Jobs per esperimenti una tantum e CronJobs per attività pianificate come la riqualificazione notturna. Adottando questo approccio, ogni esecuzione riuscita del processo significa che il modello o l'artefatto può essere archiviato automaticamente in una posizione per un ulteriore utilizzo.
Un processo batch ben strutturato garantisce che le attività di training a esecuzione prolungata non sovraccarichino i nodi del cluster. Per raggiungere questo obiettivo, è possibile richiedere le risorse GPU o CPU allo stesso modo di qualsiasi altro pod, assicurandosi di gestirle in modo efficace.
Di seguito è riportato un CronJob che avvia una corsa di allenamento notturna:
apiVersion: batch/v1
tipo: CronJob
Metadati:
Nome: Nightly-model-training
Spec:
Programma: "0 2 * * *"
jobTemplate:
Spec:
sagoma:
Spec:
contenitori:
- Nome: Training-container
Immagine: il-tuo-registro/formazione-immagine:Ultimo
risorse:
Limiti:
nvidia.com/gpu: 1
comando: ["pitone", "train.py"]
restartPolicy: MaiStrategie multi-cluster e ibride
A volte è necessario distribuire i carichi di lavoro su più Cluster Kubernetes, soprattutto se si desidera la ridondanza o l'esecuzione di alcuni processi on-premise e altri nel cloud. Questo può far risparmiare denaro e ridurre i rischi. Strumenti come Anthos Offri una console di gestione che mostra come vengono distribuiti i lavori. Se vi sono'è un problema in un ambiente, puoi passare a un altro, dandoti tranquillità quando'destreggiarsi tra le attività critiche di inferenza rivolte all'utente.
Archiviazione e gestione dei dati
Una volta che i processi possono essere scalati in modo efficiente, i dati sono al centro dell'attenzione. Dove viene conservato? Quanto velocemente riesci a leggerlo? Come si esegue il backup? Queste domande si pongono spesso quando si ha a che fare con set di dati di addestramento di grandi dimensioni e sono fondamentali per evitare che il recupero dei dati diventi un collo di bottiglia.
Classi di archiviazione ad alte prestazioni
Le classi di archiviazione supportate da SSD sono ideali per l'addestramento di carichi di lavoro con elevate esigenze di lettura/scrittura. Per sfruttarli al meglio, definire un PersistentVolumeClaim (PVC) che faccia riferimento alla StorageClass corretta e ai provisioning del cluster adatti per il backup dell'archiviazione. Assicurarsi inoltre di monitorare le operazioni di I/O al secondo (operazioni di input/output al secondo) in lettura/scrittura per verificare che i volumi di archiviazione siano in grado di gestire la velocità effettiva richiesta.
Di seguito è riportato un PVC che richiede una classe di archiviazione ad alte prestazioni:
piVersion: v1
tipo: PersistentVolumeClaim
Metadati:
Nome: Fast-PVC
Spec:
accessModes:
- ReadWriteOnce
storageClassName: ssd ad alte prestazioni
risorse:
Richieste:
stoccaggio: 100GiLocalizzazione dei dati e memorizzazione nella cache
Nell'addestramento distribuito, la localizzazione dei dati è importante. Quando i lavoratori acquisiscono dati da volumi remoti, la latenza di rete può causare rallentamenti. La soluzione? Posiziona i livelli di memorizzazione nella cache davanti all'archiviazione remota o seleziona i volumi SSD locali del nodo. Un'altra strategia consiste nell'eseguire un contenitore sidecar di memorizzazione nella cache nello stesso pod, che gestisce le letture e le scritture dei dati, migliorando le prestazioni in flussi di lavoro specifici.
Il frammento di codice seguente mostra un contenitore sidecar che fornisce la memorizzazione nella cache per i dati di training:
apiVersion: apps/v1
tipo: Distribuzione
Metadati:
Nome: Training-Deployment
Spec:
Repliche: 2
selettore:
matchLabels:
App: Training-App
sagoma:
Metadati:
Etichette:
App: Training-App
Spec:
contenitori:
- Nome: Caching-sidecar
Immagine: your-registry/caching-sidecar:latest
volumeMounts:
- nome: volume-cache
mountPath: /cache
- Nome: Training-container
Immagine: il-tuo-registro/formazione-immagine:Ultimo
volumeMounts:
- nome: volume-cache
mountPath: /dataset
Volumi:
- nome: volume-cache
emptyDir: {}Backup e controllo delle versioni
Il monitoraggio delle versioni dei modelli è standard per una buona ragione: se i nuovi modelli non riescono a entrare in produzione (ehi, succede!), avrai bisogno di rollback frequenti. Oltre a memorizzare gli artefatti del modello nello storage a oggetti, è anche importante eseguire backup pianificati. Anche se tu'Per quanto riguarda l'utilizzo di un servizio cloud che fornisce backup automatici, i backup aggiuntivi sono la strada da percorrere per prevenire problemi su tutta la linea.
Di seguito è riportato un Flusso di lavoro Argo che carica gli artefatti del modello in un bucket remoto in S3:
apiVersion: argoproj.io/v1alpha1
tipo: Flusso di lavoro
Metadati:
generateName: modello-backup-
Spec:
Punto di ingresso: modello di backup
Modelli:
- Nome: modello di backup
contenitore:
Immagine: Il-tuo-registro/Strumento-di-backup:Ultimo
comando: ["modello-di-backup"]
argomenti: ["--percorso-modello=/modelli", "--destination=s3://ml-backups"]Considerazioni sulla sicurezza
Noi'Tutti hanno visto i titoli dei giornali sui cluster dirottati o esfiltrati di dati, come il maggio 2024 incidente di accesso non autorizzato a Hugging Face dove gli aggressori hanno preso di mira la loro piattaforma di hosting di modelli AI. Queste violazioni evidenziano il motivo per cui Sicurezza Kubernetes e Sicurezza dell'intelligenza artificiale sono diventati una priorità enorme. Quando si combinano carichi di lavoro containerizzati con pipeline ML avanzate, i vettori delle minacce si moltiplicano rapidamente. Lasciare's illustra alcuni modi per tenere sotto controllo questi rischi.
25 agenti IA. 257 attacchi reali. Chi vince?
Dalla zero-day discovery all'escalation dei privilegi cloud, abbiamo testato 25 combinazioni agente-modello su 257 sfide reali di sicurezza offensiva. I risultati potrebbero sorprenderti 👀
Nozioni di base sulla sicurezza di Kubernetes
Per rafforzare la sicurezza, attenersi alle seguenti procedure consigliate:
Scansione delle immagini dei contenitori per rilevare le vulnerabilità prima della distribuzione.
Applicare il controllo degli accessi in base al ruolo per limitare gli utenti che possono distribuire, modificare o eliminare i carichi di lavoro.
Applicare gli standard di sicurezza dei pod (PSS) per evitare configurazioni errate che potrebbero esporre i cluster alle minacce.
Limitare l'accesso a Registri contenitori e monitorare la presenza di modifiche non autorizzate.
Contrassegna le immagini con riferimenti stabili Per garantire che nell'ambiente di produzione vengano utilizzate solo le versioni verificate.
Qui's un frammento di controllo degli accessi in base al ruolo che concede privilegi minimi a uno spazio dei nomi:
tipologia: Ruolo
apiVersion: rbac.authorization.k8s.io/v1
Metadati:
Spazio dei nomi: ML-Project
nome: ml-progetto-ruolo
norme:
- apiGroups: ["", "Applicazioni"]
Risorse: ["Baccelli", "Distribuzioni"]
verbi: ["Ottieni", "lista", "creare", "aggiornare", "cancellare"]
---
tipo: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
Metadati:
Nome: ml-project-rolebinding
Spazio dei nomi: ML-Project
Soggetti:
- tipo: Utente
Nome: ML-User
apiGroup: rbac.authorization.k8s.io
roleRef:
tipologia: Ruolo
nome: ml-progetto-ruolo
apiGroup: rbac.authorization.k8s.ioProtezione dell'integrità del modello
Man mano che i modelli di intelligenza artificiale diventano più potenti e ampiamente distribuiti, diventano anche bersagli di attacchi avversari, avvelenamento dei dati e deriva della distribuzione. Gli aggressori possono manipolare i dati di addestramento per compromettere le prestazioni del modello o sfruttare i punti deboli della logica del modello.
Per mitigare queste minacce, monitora i dati in entrata per rilevare eventuali anomalie, utilizza strumenti di rilevamento delle deviazioni per individuare quando le prestazioni reali del tuo modello iniziano a diminuire e addestra (o ripeti il training) solo su set di dati controllati. Mantenere questa vigilanza aiuta a garantire che il modello rimanga accurato e resiliente di fronte alle minacce in evoluzione.
Di seguito è riportato un esempio di frammento Python che mostra come utilizzare la libreria Alibi Detect per rilevare la deriva dei dati:
da alibi_detect.cd importare KSDrift
Importa numpy come NP
# Dati di riferimento (ad es. dati di allenamento di base)
X_ref = np.random.rand(1000, 10)
# Nuovi dati in entrata (ad es. campioni di traffico in tempo reale)
X = np.random.rand(1000, 10) # Sostituisci con i dati di produzione effettivi
# Inizializza il rilevatore di deriva
cd = KSDrift(X_ref, p_val=0,05)
# Esegui il controllo della deriva
preds = cd.predict(X)
if preds['data_drift']:
print("Rilevata una deriva dei dati! Valore P:", preds['p_val'])
# Facoltativamente, attivare una pipeline di ripetizione del training o un avviso
altro:
print("Non è stata rilevata alcuna deriva dei dati. Valore P:", preds['p_val'])Firma dell'immagine
Dopo aver adottato le misure per preservare l'integrità del modello, il livello successivo di difesa consiste nel confermare l'autenticità di un modello firmando le immagini del contenitore che contengono gli artefatti del modello. Strumenti come Cofirma L'aggiunta di firme digitali è semplificata, mentre la crittografia dei dati inattivi e una catena di custodia per i dati di addestramento contribuiscono a salvaguardare ulteriormente l'ecosistema, soprattutto nei settori regolamentati.
È possibile firmare l'immagine del contenitore con un semplice comando Cosign:
$ cosign sign --key cosign.key tuo-registro/la-tua-immagine:tagInoltre, aggiungi i passaggi di scansione automatica del codice nelle pipeline CI. In questo modo è possibile rilevare potenziali vulnerabilità nelle dipendenze prima che raggiungano la produzione. Di seguito è riportato un frammento di codice che integra Trivy, uno scanner di sicurezza open source, in una pipeline GitHub Actions:
Nome: flusso di lavoro di scansione del codice
su: [premere, pull_request]
Lavori:
scannerizzare:
Gira su: ubuntu-latest
Passi:
- Usi: azioni/checkout@v2
- nome: Scansione con Trivy
Applicazioni: Aquasecurity/trivy-action@master
con:
riferimento immagine: "il-tuo-registro/la-tua-immagine:più recente"
formato: "tavolo"Isolamento della rete e zero trust
La protezione dei carichi di lavoro di intelligenza artificiale inizia con un forte isolamento della rete. Un approccio efficace consiste nel definire Criteri di rete che limitano quali pod e spazi dei nomi possono comunicare tra loro. Oltre a ciò,'per evitare di eseguire carichi di lavoro AI/ML insieme ad altre applicazioni nello stesso cluster. Segmentando i carichi di lavoro in base allo scopo, ad esempio separando i servizi di inferenza dalle applicazioni Web generiche, è possibile ridurre al minimo il rischio di movimenti laterali in caso di violazione.
Questo approccio è in linea con i principi zero-trust, in cui ogni parte del traffico di rete viene trattata con cautela, anche se's interno al cluster. In combinazione con una solida gestione dell'accesso alle identità, questi guardrail aiutano a prevenire perdite accidentali di dati e tentativi di infiltrazione.
Qui'è una NetworkPolicy che limita il traffico solo allo spazio dei nomi di inferenza:
apiVersion: networking.k8s.io/v1
tipo: Politica di rete
Metadati:
nome: consenti-spazio-dei nomi traffico
Spazio dei nomi: inferenza
Spec:
podSelector: {}
Ingresso:
-Da:
- namespaceSelector:
matchLabels:
Scopo: inferenzaVisibilità end-to-end: dal codice al runtime
I carichi di lavoro AI/ML introducono complesse sfide di sicurezza e conformità che coprono l'intero ciclo di vita, dallo sviluppo del codice all'esecuzione del runtime. Senza una visibilità completa, configurazioni errate, vulnerabilità e deviazioni possono insinuarsi nei cluster Kubernetes, aumentando il rischio di violazioni.
Per affrontare questo problema, i team hanno bisogno di una strategia di sicurezza che copra ogni fase della pipeline di intelligenza artificiale: scansione delle configurazioni IaC (Infrastructure-as-Code), protezione delle immagini dei container, Applicazione delle protezioni di runtimee monitoraggio continuo per anomalie. Integrando i controlli di sicurezza in tutta la pipeline, si garantisce che i carichi di lavoro di intelligenza artificiale rimangano resilienti e conformi.
Wiz offre una piattaforma che ti consente di tenere traccia delle vulnerabilità, dei problemi di conformità e della posizione di sicurezza in tutto il tuo cluster in tempo reale. Sfrutta la dashboard di Wiz per individuare problemi di immagine del container, configurazioni errate e persino segreti in agguato nel codice:
Osservabilità: monitoraggio, registrazione e tracciamento
Quando si ottimizza il cluster per i carichi di lavoro di Machine Learning, si mira a ottenere una visione cristallina di ciò che's sta accadendo. Ciò significa raccogliere metriche dai pod, archiviare i log in una posizione centralizzata e tenere traccia delle richieste tra i microservizi. L'osservabilità approfondita rende la risoluzione dei problemi un gioco da ragazzi quando qualcosa non si accende.
Metriche e avvisi
Prometheus di solito si trova al centro del tuo stack di monitoraggio, aiutandoti a tenere traccia delle metriche chiave delle prestazioni. Per garantire operazioni AI/ML fluide, utilizza una combinazione di strumenti:
Prometeo raccoglie le metriche di utilizzo di CPU, memoria e GPU dai servizi di inferenza del modello.
Grafana Fornisce dashboard in tempo reale per visualizzare le prestazioni del cluster e rilevare le anomalie.
Regole di avviso attivano automaticamente le notifiche (ad esempio, gli avvisi Slack) quando l'utilizzo delle risorse supera le soglie definite.
Di seguito è riportata una PrometheusRule che avvisa in caso di utilizzo elevato della GPU:
Di seguito è riportata una PrometheusRule che avvisa in caso di utilizzo elevato della GPU:
apiVersion: monitoring.coreos.com/v1
tipo: PrometheusRule
Metadati:
nome: gpu-regole-di-utilizzo
Spazio dei nomi: monitoraggio
Spec:
Gruppi:
- Nome: GPU-Alerts
norme:
- avviso: HighGPUUsage
Espressione: nvidia_gpu_utilization > 90
per: 5m
Etichette:
Gravità: Avviso
Annotazioni:
sommario: "Rilevato elevato utilizzo della GPU"Traccia distribuita e informazioni dettagliate sulle prestazioni
OpenTelemetry è un'ottima scelta per la traccia distribuita, soprattutto se la pipeline di intelligenza artificiale include più microservizi. Ogni servizio genera intervalli di traccia, consentendo di individuare la posizione in cui potrebbe esistere un collo di bottiglia. Questo approccio è inestimabile quando si esegue il debug di richieste lente o anomalie casuali delle prestazioni nei flussi di elaborazione dei dati.
Ecco come OpenTelemetry Collector e Jaeger collaborano per fornire analisi end-to-end e informazioni dettagliate sulle prestazioni per i carichi di lavoro AI/ML:
Correlazione di sicurezza e prestazioni con Wiz
A volte, un calo delle prestazioni è legato a un evento correlato alla sicurezza. Wiz ti aiuta a vedere questa correlazione combinando i risultati di sicurezza con i dati sulle prestazioni. Forse un processo sospetto sta monopolizzando le risorse della GPU o una vulnerabilità nota sta causando l'instabilità del cluster. Quando vedi questi modelli, Wiz richiede una correzione immediata.
🚨Rapporto di ricerca sulla sicurezza Kubernetes 2025
Nuove informazioni da 200.000+ account cloud rivelano i rischi più recenti, le tendenze degli attacchi e le lacune di sicurezza negli ambienti Kubernetes.
Scaricare PDF
CI/CD per flussi di lavoro AI/ML
Sappiamo tutti che la spedizione di un modello addestrato comporta molto di più della semplice copia di un file. Si desidera automatizzare completamente la creazione, il test e la distribuzione di artefatti ML. È qui che le pipeline CI/CD tornano utili. È possibile concatenare attività che eseguono test, analizzano le immagini, ne eseguono il push in un Registro di sistema e quindi implementano le nuove versioni nell'ambiente di produzione.
Automazione della gestione del ciclo di vita del modello
Strumenti come Tekton o Flussi di lavoro Argo Consente di definire le pipeline per l'intero ciclo di vita del modello, dalla preparazione dei dati all'addestramento fino alla distribuzione. Ogni fase viene attivata automaticamente ogni volta che si esegue il commit di una modifica, mantenendo il processo coerente. È inoltre possibile aggiungere controlli di convalida per assicurarsi che un modello soddisfi le soglie di precisione predefinite prima di etichettarlo per la produzione. In questo modo si evita che vengano distribuiti modelli con prestazioni insufficienti e che influiscano sull'esperienza utente.
Di seguito è riportato un Tekton PipelineRun Questo dà il via alla creazione e alla distribuzione del modello:
apiVersion: tekton.dev/v1beta1
tipo: PipelineRun
Metadati:
Nome: ml-pipeline-run
Spec:
pipelineRef:
Nome: ml-build-deploy-pipeline
Spazi di lavoro:
- Nome: Shared-Data
volumeClaimTemplate:
Spec:
accessModes: ["ReadWriteOnce"]
risorse:
Richieste:
conservazione: 5Gi
parametri:
- nome: nome-modello
valore: "modello-mio-ml"Artefatti immutabili e GitOps
È utile etichettare le immagini con hash di commit in modo da sapere esattamente quale versione del codice o del modello si desidera're in esecuzione. GitOps estende questa pratica consentendo di archiviare i manifesti Kubernetes in un repository Git. Tutte le modifiche apportate a tali manifesti vengono applicate automaticamente al cluster in modo controllato. Questo metodo consente di tenere traccia con precisione di quando e perché si verificano le modifiche.
Qui's an Applicazione Argo CD facendo riferimento al repository Git per la gestione delle configurazioni di distribuzione:
apiVersion: argoproj.io/v1alpha1
tipologia: Applicazione
Metadati:
nome: ml-inference-app
Spec:
destinazione:
Spazio dei nomi: ML-inference
server: https://kubernetes.default.svc
fonte:
repoURL: 'https://github.com/your-org/ml-deploy-configs.git'
targetRevision: main
Percorso: manifesti/inferenza
progetto: predefinito
syncPolicy:
automatizzato:
prugna: vero
selfHeal: veroOttimizzazione delle prestazioni
I modelli devono rispondere rapidamente e non sprecare costose ore di GPU o CPU. Fortunatamente, piccole modifiche ai parametri HPA o alle regole di bilanciamento del carico possono ridurre i millisecondi preziosi e i costi con un solido margine.
Bilanciamento del carico
Il bilanciamento del carico con le risorse in ingresso consente di instradare il traffico verso il servizio di inferenza corretto. Per separare le diverse versioni di un modello, è possibile utilizzare l'instradamento basato sul percorso.
Di seguito è riportato un Ingress con routing basato sul percorso a più servizi di inferenza:
apiVersion: networking.k8s.io/v1
tipo: Ingresso
Metadati:
Nome: inferenza-ingresso
Spec:
norme:
- Ospite: ml.example.com
http:
Percorsi:
- percorso: /v1/
pathType: Prefisso
Parte posteriore:
servizio:
Nome: Inference-model-v1
porto:
Numero: 8081
- Percorso: /v2/
pathType: Prefisso
Parte posteriore:
servizio:
Nome: Inference-model-v2
porto:
Numero: 8081Profilazione e ottimizzazione dei costi
A tutti piace osservare come i nodi GPU, i nodi CPU e l'utilizzo della memoria si allineano con la spesa. Tuttavia, la regolazione manuale delle risorse può richiedere molto tempo ed essere inefficiente. È qui che strumenti come Karpenter e Autopilota È possibile ridimensionare automaticamente i nodi del cluster in base alle esigenze delle risorse, evitando il provisioning manuale dei nodi. Per i carichi di lavoro di training che non richiedono calcolo persistente, sfruttando Istanze Spot può ridurre drasticamente i costi, ma assicurati che la tua pipeline sia in grado di gestire potenziali interruzioni.
Di seguito è riportato un esempio di configurazione di Karpenter per la corrispondenza dei tipi di istanza ai carichi di lavoro:
apiVersion: karpenter.sh/v1alpha5
tipo: Provisioner
Metadati:
Nome: predefinito
Spec:
fabbisogno:
-chiave: "node.kubernetes.io/instance-type"
operatore: In
valori: ["m5.large", "m5.xlarge"]
provider:
subnetSelector:
karpenter.sh/discovery: "mio-cluster"
securityGroupSelector:
karpenter.sh/discovery: "mio-cluster"Un altro modo per risparmiare alla grande? Utilizza uno strumento come Wiz per vedere se ci sono fattori di costo correlati a risorse configurate in modo errato o modelli di utilizzo insoliti. Wiz ti aiuta anche a rafforzare i nodi durante la creazione per assicurarti che non solo vengano ridimensionati automaticamente, ma anche sicuri.
Conclusione
Noi'ho parlato di varie strategie per i flussi di lavoro di apprendimento automatico su Kubernetes. Dalla gestione delle risorse alle best practice di sicurezza dell'intelligenza artificiale fino al collegamento delle pipeline Tekton,'Ho visto come ogni pezzo può contribuire a una piattaforma stabile. L'idea principale è quella di tenere d'occhio i rischi per la sicurezza dell'intelligenza artificiale, osservare i superamenti dei costi e costruire una pipeline di cui le persone si fidino.
Quando si implementano queste procedure consigliate, si riducono al minimo le interruzioni del cluster e si aiuta i data scientist a eseguire il push degli aggiornamenti in modo sicuro. Noi'Non vedo l'ora di vedere come questi suggerimenti si inseriscono nel tuo lavoro. Noi'Mi piacerebbe ricevere una risposta su ciò che crei, sulle lezioni che scopri e su come continui a migliorare il tuo apprendimento automatico nei flussi di lavoro Kubernetes.
Questo viaggio potrebbe sembrare complicato, ma con gli strumenti giusti, come Wiz', i dashboard e le funzionalità di conformità in tempo reale: è possibile creare un ambiente più sicuro per l'addestramento e l'inferenza. Se tu'Stai cercando di perfezionare e scalare i tuoi progetti AI/ML mantenendo la sicurezza, dai una possibilità a Wiz per una visione completa delle vulnerabilità dei container, delle impostazioni del cluster e dei benchmark di conformità. Con Wiz, puoi mantenere i tuoi cluster sani, convenienti e al sicuro dalle intrusioni.
Proteggi il tuo cloud dal codice alla produzione
Scopri perché le aziende in più rapida crescita scelgono Wiz per proteggere container, Kubernetes e ambienti cloud dalla fase di creazione a quella in tempo reale.
