Ejecutar cargas de trabajo de IA/ML a gran escala en Kubernetes puede parecer navegar por un laberinto de asignaciones de recursos, obstáculos de seguridad y demandas de monitoreo, especialmente si no tiene un plan sólido. Claro, es emocionante ver tareas de redes neuronales como el reconocimiento de imágenes o la predicción de abandono, pero siempre existe la preocupación de llevar su clúster a sus límites.
MLOps es un ancla amigable aquí, cerrando la brecha entre los científicos de datos, la gente de DevOps y los equipos de seguridad como un conjunto de ideas y herramientas que lo ayudan a realizar un seguimiento de la creación, prueba y lanzamiento de modelos. Fomenta una estrecha colaboración, por lo que un científico de datos en un equipo y un gurú de Kubernetes en otro pueden actualizar con confianza un modelo sin pisarse unos a otros's dedos de los pies. Cuando MLOps se encuentra con la orquestación de contenedores, obtiene una forma más predecible de controlar las canalizaciones de IA.
Nuestro objetivo con este artículo es compartir las mejores prácticas para ejecutar tareas complejas de IA en Kubernetes. Nosotros'hablará sobre escalado, programación, seguridad, administración de recursos y otros elementos que son importantes para los ingenieros de plataformas experimentados y las personas que recién ingresan al aprendizaje automático en Kubernetes. Al caminar por cada sección,'recogerá consejos prácticos para proteger su clúster de Riesgos de seguridad de la IA, mantenga sus costos bajo control y brinde a sus modelos la potencia informática que anhelan.
Prácticas de codificación segura de Kubernetes [hoja de trucos]
Esta hoja de referencia rápida de 10 páginas proporciona una guía avanzada y práctica para que los desarrolladores de infraestructura y plataformas protejan las aplicaciones en contenedores.
Descargar PDF
Gestión de recursos
Antes de poner en marcha contenedores para el entrenamiento o la inferencia, es importante asegurarse de que los recursos del clúster coincidan con la intensidad de las cargas de trabajo. Después de todo, ignorar las demandas de la GPU u omitir el tamaño adecuado de la CPU conduce a un rendimiento lento, muertes aleatorias por falta de memoria y equipos decepcionados.
Asignación de GPU y hardware especializado
Las GPU, TPU y otros aceleradores son como los autos deportivos en un clúster'. Le permiten entrenar modelos masivos o manejar un gran rendimiento durante la inferencia. Hacer que estos recursos de hardware estén disponibles dentro de los pods se basa en los complementos de dispositivo proporcionados por Kubernetes. Por ejemplo, agregando el complemento oficial del dispositivo NVIDIA, puede solicitar segmentos de GPU por pod.
¿Un consejo importante? La configuración de las solicitudes de recursos adecuadas garantiza que el programador detecte el nodo correcto con la GPU correcta. Si omite esas definiciones de recursos, la carga de trabajo podría aterrizar en un nodo sin el acelerador, lo que provocaría errores en el trabajo. También es útil etiquetar los nodos de GPU con algo como nvidia.com/gpu=true para dirigirse a ellos a través de nodeSelector o nodeAffinity fácilmente.
El siguiente fragmento de código muestra una especificación básica de pod que solicita una GPU de NVIDIA:
apiVersion: v1
tipo: Vaina
metadatos:
Nombre: gpu-training-pod
Especificaciones:
recipientes:
- nombre: gpu-training-container
Imagen: nvcr.io/nvidia/tensorflow:22.01-tf2-py3
Recursos:
Límites:
nvidia.com/gpu: 1
nodeSelector:
nvidia.com/gpu: "verdadero"Dimensionamiento de CPU y memoria
No todos los trabajos de entrenamiento de modelos o canalizaciones de datos necesitan una GPU. Muchas tareas se ejecutan perfectamente bien en las CPU si las dimensiona correctamente. Al establecer solicitudes y límites, el programador de Kubernetes sabe cuántos pods caben en un nodo. Sin estos parámetros, corre el riesgo de una mala programación o de que los pods compitan por los mismos núcleos de CPU. Para llevar la programación al siguiente nivel, agregue Escalado automático de clústeres para absorber picos repentinos en el tráfico o trabajos de capacitación.
Recuerde observar cuidadosamente las métricas de uso reales, utilizando un sistema de monitoreo como Prometheus. Si los pods alcanzan constantemente el 90 % de la CPU, ajuste ligeramente las solicitudes. Por otro lado, si los pods se mantienen alrededor del 20% de uso de la CPU, puede reducir sus solicitudes.
A continuación se muestra un ejemplo de implementación que define las solicitudes y los límites de CPU y memoria:
apiVersion: apps/v1
tipo: Implementación
metadatos:
Nombre: ML-inference-deployment
Especificaciones:
Réplicas: 2
plantilla:
Especificaciones:
recipientes:
- nombre: ml-inference-container
Imagen: your-registry/ml-inference:latest
Recursos:
Solicitudes:
CPU: "500 metros"
memoria: "512 millones"
Límites:
CPU: "1000 metros"
memoria: "1024Mi"Escalado de las cargas de trabajo de IA/ML
Una vez que'Una vez precisado cómo solicitar y asignar recursos, es hora de escalar. En algunos escenarios, escalará los pods de inferencia horizontalmente para controlar las solicitudes entrantes con picos. En otros, programará grandes trabajos de entrenamiento que podrían necesitar tipos de nodos especializados.
Escalado horizontal y vertical
El escalado horizontal es lo que necesita para lidiar con cargas de usuarios impredecibles, especialmente para los puntos de conexión de inferencia. Es una buena práctica configurar HPA para ver el uso de la CPU o la GPU, y luego poner en marcha nuevos pods cuando las cosas se calientan. Aún así, el escalado vertical puede ser una mejor respuesta si su contenedor necesita más memoria o núcleos de CPU en un solo nodo. El escalador automático vertical de pods (VPA) puede ayudarlo a ajustar las solicitudes de cargas de trabajo estables a lo largo del tiempo.
Aquí's un fragmento de un HPA que hace referencia a una implementación por uso de CPU:
apiVersion: escalado automático/v2
tipo: HorizontalPodAutoscaler
metadatos:
Nombre: Inference-HPA
Especificaciones:
scaleTargetRef:
apiVersion: apps/v1
tipo: Implementación
nombre: inferencia-implementación
minRéplicas: 2
Réplicas máximas: 15
Métricas:
- type: Recurso
recurso:
Nombre: CPU
blanco:
tipo: Utilización
Utilización promedio: 75Trabajos por lotes y programación
La capacitación a gran escala suele ser mejor como un proceso por lotes. Para simplificar la canalización, use Kubernetes Jobs para experimentos únicos y CronJobs para tareas programadas, como el reentrenamiento nocturno. Al adoptar este enfoque, cada ejecución de trabajo exitosa significa que el modelo o artefacto se puede almacenar automáticamente en algún lugar para su uso posterior.
Un trabajo por lotes bien estructurado garantiza que las tareas de entrenamiento de larga duración no sobrecarguen los nodos del clúster. Para lograr esto, puede solicitar recursos de GPU o CPU de la misma manera que cualquier otro pod, asegurándose de administrarlos de manera efectiva.
A continuación se muestra un CronJob que inicia una ejecución de entrenamiento nocturna:
apiVersion: batch/v1
tipo: CronJob
metadatos:
nombre: entrenamiento-de-modelo-nocturno
Especificaciones:
horario: "0 2 * * *"
jobTemplate:
Especificaciones:
plantilla:
Especificaciones:
recipientes:
- nombre: contenedor de entrenamiento
Imagen: su-registro/imagen-de-entrenamiento:último
Recursos:
Límites:
nvidia.com/gpu: 1
comando: ["pitón", "train.py"]
restartPolicy: NuncaEstrategias multiclúster e híbridas
A veces es necesario distribuir las cargas de trabajo entre varios Clústeres de Kubernetes, especialmente si desea redundancia o ejecutar algunos trabajos en las instalaciones y otros en la nube. Esto puede ahorrar dinero y reducir el riesgo. Herramientas como Anthos Ofrecer una consola de administración que muestre cómo se distribuyen los trabajos. Si hay'es un problema en un entorno, puede pasar por error a otro, lo que le da tranquilidad cuando're haciendo malabarismos con tareas críticas de inferencia orientadas al usuario.
Almacenamiento y gestión de datos
Una vez que sus trabajos pueden escalar de manera eficiente, los datos ocupan un lugar central. ¿Dónde se almacena? ¿Qué tan rápido puedes leerlo? ¿Cómo lo respaldas? Estas preguntas surgen mucho cuando se trata de grandes conjuntos de datos de entrenamiento y son cruciales para evitar que la recuperación de datos se convierta en un cuello de botella.
Clases de almacenamiento de alto rendimiento
Las StorageClasses respaldadas por SSD son ideales para entrenar cargas de trabajo con grandes demandas de lectura/escritura. Para aprovecharlos al máximo, defina un PersistentVolumeClaim (PVC) que haga referencia a la clase de almacenamiento correcta y a las disposiciones del clúster adecuadas para el almacenamiento de respaldo. Además, asegúrese de supervisar las IOPS de lectura/escritura (operaciones de entrada/salida por segundo) para confirmar que los volúmenes de almacenamiento pueden controlar el rendimiento necesario.
A continuación se muestra un PVC que solicita una clase de almacenamiento de alto rendimiento:
piVersión: v1
kind: PersistenteVolumeClaim
metadatos:
Nombre: Fast-PVC
Especificaciones:
Modos de acceso:
- ReadWriteOnce
storageClassName: ssd de alto rendimiento
Recursos:
Solicitudes:
almacenamiento: 100GiLocalidad de datos y almacenamiento en caché
En el entrenamiento distribuido, la localidad de los datos es importante. Cuando los trabajadores obtienen datos de volúmenes remotos, la latencia de la red puede causar ralentizaciones. ¿La solución? Coloque capas de almacenamiento en caché delante del almacenamiento remoto o seleccione volúmenes SSD locales de nodo. Otra estrategia es ejecutar un contenedor sidecar de almacenamiento en caché en el mismo pod, que controla las lecturas y escrituras de datos, lo que mejora el rendimiento en flujos de trabajo específicos.
En el siguiente fragmento de código se muestra un contenedor sidecar que proporciona almacenamiento en caché para los datos de entrenamiento:
apiVersion: apps/v1
tipo: Implementación
metadatos:
Nombre: Formación-Despliegue
Especificaciones:
Réplicas: 2
selector:
matchLabels:
aplicación: aplicación de entrenamiento
plantilla:
metadatos:
Etiquetas:
aplicación: aplicación de entrenamiento
Especificaciones:
recipientes:
- nombre: caching-sidecar
Imagen: your-registry/caching-sidecar:latest
volumeMounts:
- nombre: volumen de caché
mountPath: /caché
- nombre: contenedor de entrenamiento
Imagen: su-registro/imagen-de-entrenamiento:último
volumeMounts:
- nombre: volumen de caché
mountPath: /conjunto de datos
Volúmenes:
- nombre: volumen de caché
emptyDir: {}Copia de seguridad y control de versiones
El seguimiento de las versiones del modelo es estándar por una buena razón: si los nuevos modelos fallan en producción (¡oye, sucede!), Necesitarás reversiones frecuentes. Además de almacenar artefactos del modelo en el almacenamiento de objetos, también es importante ejecutar copias de seguridad programadas. Incluso si'Con respecto al uso de un servicio en la nube que proporciona copias de seguridad automáticas, las copias de seguridad adicionales son el camino a seguir para evitar problemas en el futuro.
A continuación se muestra un Flujo de trabajo de Argo que carga artefactos de modelo en un bucket remoto en S3:
apiVersion: argoproj.io/v1alpha1
kind: Flujo de trabajo
metadatos:
generateName: copia de seguridad del modelo-
Especificaciones:
Punto de entrada: modelo de copia de seguridad
Plantillas:
- nombre: modelo de copia de seguridad
contenedor:
Imagen: your-registry/backup-tool:latest
comando: ["modelo de copia de seguridad"]
args: ["--model-path=/modelos", "--destination=s3://ml-backups"]Consideraciones de seguridad
Nosotros'Todos han visto los titulares sobre el secuestro de clústeres o la filtración de datos, como el de mayo de 2024 incidente de acceso no autorizado en Hugging Face donde los atacantes se dirigieron a su plataforma de alojamiento de modelos de IA. Estas infracciones resaltan por qué Seguridad de Kubernetes y Seguridad de IA se han convertido en una gran prioridad. Cuando se combinan cargas de trabajo en contenedores con canalizaciones de ML avanzadas, los vectores de amenazas se multiplican rápidamente. Dejar'de algunas formas de mantener estos riesgos bajo control.
25 agentes de IA. 257 ataques reales. ¿Quién gana?
Desde el descubrimiento zero-day hasta la escalada de privilegios en la nube, probamos 25 combinaciones agente-modelo en 257 desafíos reales de seguridad ofensiva. Los resultados pueden sorprenderte 👀
Aspectos básicos de la seguridad de Kubernetes
Para reforzar la seguridad, siga estas prácticas recomendadas:
Analizar imágenes de contenedores para detectar vulnerabilidades antes de la implementación.
Aplicar el control de acceso basado en roles (RBAC) para restringir quién puede implementar, modificar o eliminar cargas de trabajo.
Aplicar estándares de seguridad de pods (PSS) para evitar configuraciones incorrectas que podrían exponer los clústeres a amenazas.
Limitar el acceso a Registros de contenedor y monitorear cambios no autorizados.
Etiquetar imágenes con referencias estables para garantizar que solo se utilicen versiones verificadas en producción.
Aquí'es un fragmento de RBAC que concede privilegios mínimos a un espacio de nombres:
kind: Rol
apiVersion: rbac.authorization.k8s.io/v1
metadatos:
Espacio de nombres: ml-project
nombre: ml-project-role
reglas:
- apiGroups: ["", "Aplicaciones"]
Recursos: ["Vainas", "Implementaciones"]
verbos: ["Obtener", "lista", "crear", "actualizar", "borrar"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadatos:
nombre: ml-project-rolebinding
Espacio de nombres: ml-project
Temas:
- kind: Usuario
nombre: ml-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Rol
nombre: ml-project-role
apiGroup: rbac.authorization.k8s.ioProtección de la integridad del modelo
A medida que los modelos de IA se vuelven más poderosos y se implementan ampliamente, también se convierten en objetivos de ataques adversarios, envenenamiento de datos y deriva de distribución. Los atacantes pueden manipular los datos de entrenamiento para socavar el rendimiento del modelo o explotar las debilidades en la lógica del modelo.
Para mitigar estas amenazas, supervise los datos entrantes en busca de anomalías, use herramientas de detección de desviaciones para detectar cuándo comienza a disminuir el rendimiento real de su modelo y entrene (o vuelva a entrenar) solo en conjuntos de datos examinados. Mantener esta vigilancia ayuda a garantizar que su modelo se mantenga preciso y resistente frente a las amenazas en evolución.
A continuación se muestra un fragmento de Python de muestra que muestra cómo puede usar la biblioteca Alibi Detect para detectar desviaciones de datos:
desde alibi_detect.cd importar KSDrift
importar numpy como np
# Datos de referencia (por ejemplo, datos de entrenamiento de referencia)
X_ref = np.random.rand(1000, 10)
# Nuevos datos entrantes (por ejemplo, muestras de tráfico en vivo)
X = np.random.rand(1000, 10) # Reemplazar con datos de producción reales
# Inicializar el detector de deriva
cd = KSDrift(X_ref, p_val=0.05)
# Ejecutar comprobación de deriva
preds = cd.predict(X)
si preds['data_drift']:
print("¡Se detectó una deriva de datos! Valor P:", preds['p_val'])
# Opcionalmente, desencadene una canalización o alerta de reentrenamiento
más:
print("No se detectó ninguna desviación de datos. Valor P:", preds['p_val'])Firma de imágenes
Una vez que haya tomado medidas para preservar la integridad del modelo, la siguiente capa de defensa es confirmar la autenticidad de un modelo mediante la firma de imágenes de contenedor que contienen los artefactos del modelo. Herramientas como Cosign Facilite la adición de firmas digitales, mientras que el cifrado en reposo y una cadena de custodia para los datos de entrenamiento ayudan a proteger aún más su ecosistema, especialmente en industrias reguladas.
Puede firmar la imagen de contenedor con un simple comando Cosign:
$ cosign sign --key cosign.key tu-registro/tu-imagen:etiquetaAdemás de eso, agregue pasos de escaneo de código automatizados en las canalizaciones de CI. Esto ayuda a detectar posibles vulnerabilidades en las dependencias antes de que lleguen a producción. A continuación se muestra un fragmento de código que integra Trivy, un escáner de seguridad de código abierto, en una canalización de GitHub Actions:
nombre: code-scanning-workflow
Encendido: [empujar, pull_request]
Trabajos:
escanear:
se ejecuta en: ubuntu-latest
Pasos:
- Usos: Acciones/checkout@v2
- nombre: Escanear con Trivy
Usos: AquaSecurity/Trivy-action@master
con:
referencia de imagen: "su-registro/su-imagen:último"
formato: "mesa"Aislamiento de red y confianza cero
La protección de las cargas de trabajo de IA comienza con un fuerte aislamiento de la red. Un enfoque eficaz es definir Directivas de red que restringen qué pods y espacios de nombres pueden comunicarse entre sí. Más allá de eso,'para evitar ejecutar cargas de trabajo de IA/ML junto con otras aplicaciones en el mismo clúster. Al segmentar las cargas de trabajo en función del propósito, como separar los servicios de inferencia de las aplicaciones web generales, minimiza el riesgo de movimiento lateral en caso de infracción.
Este enfoque se alinea con los principios de confianza cero, donde cada parte del tráfico de red se trata con cautela, incluso si's interno al clúster. Combinadas con una sólida gestión de acceso a la identidad, estas barreras de seguridad ayudan a prevenir fugas accidentales de datos e intentos de infiltración.
Aquí'es una NetworkPolicy que limita el tráfico solo al espacio de nombres de inferencia:
apiVersion: networking.k8s.io/v1
tipo: Política de red
metadatos:
nombre: allow-namespace-traffic
Espacio de nombres: inferencia
Especificaciones:
podSelector: {}
ingreso:
-De:
- namespaceSelector:
matchLabels:
Propósito: inferenciaVisibilidad de extremo a extremo: desde el código hasta el tiempo de ejecución
Las cargas de trabajo de IA/ML presentan desafíos complejos de seguridad y cumplimiento que abarcan todo el ciclo de vida, desde el desarrollo del código hasta la ejecución en tiempo de ejecución. Sin una visibilidad completa, las configuraciones incorrectas, las vulnerabilidades y la deriva pueden infiltrarse en sus clústeres de Kubernetes, lo que aumenta el riesgo de infracciones.
Para abordar esto, los equipos necesitan una estrategia de seguridad que cubra todas las etapas de la canalización de IA: escaneo de configuraciones de infraestructura como código (IaC), protección de imágenes de contenedores, Aplicación de protecciones en tiempo de ejecucióny Monitoreo continuo para anomalías. Al integrar los controles de seguridad en toda la canalización, se asegura de que las cargas de trabajo de IA sigan siendo resistentes y compatibles.
Wiz ofrece una plataforma que le permite realizar un seguimiento de las vulnerabilidades, los problemas de cumplimiento y la postura de seguridad en todo su clúster en tiempo real. Aproveche el panel de control de Wiz para detectar problemas de imágenes de contenedores, configuraciones incorrectas e incluso Secretos Al acecho en el código:
Observabilidad: Monitoreo, registro y rastreo
Al ajustar el clúster para cargas de trabajo de aprendizaje automático, su objetivo es obtener una visión clara de lo que's. Eso significa recopilar métricas de pods, almacenar registros en una ubicación centralizada y realizar un seguimiento de las solicitudes en los microservicios. La observabilidad exhaustiva hace que la resolución de problemas sea una obviedad cuando algo falla.
Métricas y alertas
Prometheus generalmente se encuentra en el corazón de su pila de monitoreo, lo que lo ayuda a realizar un seguimiento de las métricas clave de rendimiento. Para garantizar operaciones fluidas de IA/ML, utilice una combinación de herramientas:
Prometeo recopila métricas de uso de CPU, memoria y GPU de los servicios de inferencia de modelos.
Grafana Proporciona paneles en tiempo real para visualizar el rendimiento del clúster y detectar anomalías.
Reglas de alerta activan automáticamente notificaciones (por ejemplo, alertas de Slack) cuando el uso de recursos supera los umbrales definidos.
A continuación se muestra una PrometheusRule que alerta sobre el uso elevado de la GPU:
A continuación se muestra una PrometheusRule que alerta sobre el uso elevado de la GPU:
apiVersion: monitoring.coreos.com/v1
tipo: Regla de Prometeo
metadatos:
nombre: reglas de uso de GPU
Espacio de nombres: Monitoreo
Especificaciones:
grupos:
- nombre: gpu-alerts
reglas:
- alerta: HighGPUUsage
expr: nvidia_gpu_utilization > 90
para: 5m
Etiquetas:
Gravedad: Advertencia
Anotaciones:
resumen: "Se detectó un alto uso de GPU"Seguimiento distribuido e información sobre el rendimiento
OpenTelemetry es una excelente opción para el seguimiento distribuido, especialmente si la canalización de IA incluye varios microservicios. Cada servicio emite intervalos de seguimiento, lo que le ayuda a identificar dónde puede existir un cuello de botella. Este enfoque no tiene precio cuando se depuran solicitudes lentas o anomalías de rendimiento aleatorias en los flujos de procesamiento de datos.
Así es como OpenTelemetry Collector y Jaeger trabajan juntos para proporcionar información de rendimiento y seguimiento de extremo a extremo para cargas de trabajo de IA/ML:
Correlación de seguridad y rendimiento con Wiz
A veces, una caída de rendimiento está vinculada a un evento relacionado con la seguridad. Wiz lo ayuda a ver esa correlación al combinar los hallazgos de seguridad con los datos de rendimiento. Tal vez un proceso sospechoso esté acaparando los recursos de la GPU o una vulnerabilidad conocida esté provocando la inestabilidad del clúster. Cuando vea estos patrones, Wiz le pedirá una solución inmediata.
🚨Informe de Investigación en Seguridad Kubernetes 2025
Nuevos conocimientos de 200.000+ cuentas en la nube revelan los últimos riesgos, tendencias de ataques y brechas de seguridad en los entornos Kubernetes.
Descargar PDF
CI/CD para flujos de trabajo de IA/ML
Todos sabemos que el envío de un modelo entrenado implica algo más que copiar un archivo. Desea automatizar completamente la compilación, prueba e implementación de artefactos de ML. Aquí es donde las canalizaciones de CI/CD son útiles. Puede encadenar tareas que ejecutan pruebas, escanean imágenes, las insertan en un registro y, a continuación, implementan nuevas versiones en producción.
Automatización de la gestión del ciclo de vida de los modelos
Herramientas como Tekton o Flujos de trabajo de Argo le permiten definir canalizaciones para todo el ciclo de vida del modelo, desde la preparación de datos hasta el entrenamiento y la implementación. Cada etapa se activa automáticamente cada vez que confirma un cambio, lo que mantiene la coherencia del proceso. También puede agregar comprobaciones de validación para asegurarse de que un modelo cumpla con los umbrales de precisión predefinidos antes de etiquetarlo para producción. Esto ayuda a evitar que se implementen modelos de bajo rendimiento y afecten a la experiencia del usuario.
A continuación se muestra un Tekton PipelineRun que inicia la construcción y el despliegue de modelos:
apiVersion: tekton.dev/v1beta1
tipo: PipelineRun
metadatos:
nombre: ml-pipeline-run
Especificaciones:
pipelineRef:
nombre: ml-build-deploy-pipeline
Espacios de trabajo:
- nombre: datos compartidos
volumeClaimTemplate:
Especificaciones:
modos de acceso: ["ReadWriteOnce"]
Recursos:
Solicitudes:
almacenamiento: 5Gi
parámetros:
- nombre: nombre-modelo
valor: "my-ml-model"Artefactos inmutables y GitOps
Es útil etiquetar imágenes con hashes de confirmación para saber exactamente qué versión del código o modelo're corriendo. GitOps amplía esa práctica al permitirle almacenar manifiestos de Kubernetes en un repositorio de Git. Cualquier cambio en esos manifiestos se aplica automáticamente al clúster de forma controlada. Este método le ayuda a realizar un seguimiento preciso de cuándo y por qué se producen los cambios.
Aquí's an Solicitud de CD de Argo hacer referencia al repositorio de Git para administrar configuraciones de implementación:
apiVersion: argoproj.io/v1alpha1
tipo: Aplicación
metadatos:
nombre: ml-inference-app
Especificaciones:
destino:
Espacio de nombres: ML-inference
servidor: https://kubernetes.default.svc
fuente:
repoURL: 'https://github.com/your-org/ml-deploy-configs.git'
targetRevision: main
ruta: manifiestos / inferencia
proyecto: predeterminado
syncPolicy:
automatizado:
Prune: Verdadero
autocuración: verdaderoOptimización del rendimiento
Los modelos tienen que responder rápidamente y no desperdiciar costosas horas de GPU o CPU. Afortunadamente, los ajustes menores en los parámetros de HPA o las reglas de equilibrio de carga pueden reducir valiosos milisegundos y reducir los costos por un margen sólido.
Equilibrio de carga
El equilibrio de carga con recursos de entrada ayuda a enrutar el tráfico al servicio de inferencia correcto. Para separar diferentes versiones de un modelo, tiene la opción de utilizar el enrutamiento basado en rutas.
A continuación se muestra una entrada con enrutamiento basado en rutas a varios servicios de inferencia:
apiVersion: networking.k8s.io/v1
tipo: Entrada
metadatos:
nombre: inferencia-entrada
Especificaciones:
reglas:
- Anfitrión: ml.example.com
HTTP:
Caminos:
- ruta: /v1/
pathType: Prefijo
Backend:
servicio:
nombre: modelo de inferencia-v1
puerto:
Número: 8081
- ruta: /v2/
pathType: Prefijo
Backend:
servicio:
nombre: inference-model-v2
puerto:
Número: 8081Perfilado y optimización de costes
A todo el mundo le gusta ver cómo sus nodos de GPU, nodos de CPU y uso de memoria se alinean con el gasto. Pero ajustar manualmente los recursos puede llevar mucho tiempo y ser ineficiente. Ahí es donde herramientas como Karpenter y Piloto automático Puede escalar automáticamente los nodos del clúster para que coincidan con las demandas de recursos, lo que le ahorra el aprovisionamiento manual de nodos. Para entrenar cargas de trabajo que no necesitan computación persistente, aprovechar Instancias de spot puede reducir drásticamente los costos, solo asegúrese de que su canalización pueda manejar posibles interrupciones.
A continuación se muestra un ejemplo de la configuración de Karpenter para hacer coincidir los tipos de instancia con las cargas de trabajo:
apiVersion: karpenter.sh/v1alpha5
tipo: Aprovisionador
metadatos:
nombre: predeterminado
Especificaciones:
Requisitos:
-llave: "node.kubernetes.io/instance-type"
operador: En
valores: ["m5.grande", "m5.xlarge"]
proveedor:
subnetSelector:
karpenter.sh/discovery: "mi-clúster"
securityGroupSelector:
karpenter.sh/discovery: "mi-clúster"¿Otra forma de ahorrar a lo grande? Utilice una herramienta como Wiz para ver si hay factores de costo relacionados con recursos mal configurados o patrones de uso inusuales. Wiz también lo ayuda a fortalecer los nodos durante la creación para asegurarse de que no solo se escalen automáticamente, sino que también sean seguros.
Conclusión
Nosotros'He hablado sobre varias estrategias para flujos de trabajo de aprendizaje automático en Kubernetes. Desde la gestión de recursos hasta las mejores prácticas de seguridad de IA y la conexión de tuberías de Tekton,'He visto cómo cada pieza puede contribuir a una plataforma estable. La idea principal es vigilar los riesgos de seguridad de la IA, vigilar los sobrecostos y crear una canalización en la que la gente confíe.
Cuando implementa estas prácticas recomendadas, minimiza las interrupciones del clúster y ayuda a los científicos de datos a impulsar las actualizaciones con confianza. Nosotros'Estoy emocionado de ver cómo encajan estas sugerencias en su trabajo. Nosotros'Me encantaría recibir noticias sobre lo que creas, las lecciones que descubres y cómo sigues mejorando tu aprendizaje automático en los flujos de trabajo de Kubernetes.
Este viaje puede parecer complicado, pero con las herramientas adecuadas, como Wiz', los paneles y las funciones de cumplimiento en tiempo real, puede crear un entorno más seguro para el entrenamiento y la inferencia. Si usted'Si busca refinar y escalar sus proyectos de IA/ML mientras se mantiene seguro, pruebe Wiz para obtener una visión amplia de las vulnerabilidades de los contenedores, la configuración del clúster y los puntos de referencia de cumplimiento. Con Wiz, puede mantener sus clústeres saludables, rentables y a salvo de intrusiones.
Proteja su nube desde el código hasta la producción
Descubre por qué las empresas de más rápido crecimiento eligen Wiz para proteger contenedores, Kubernetes y entornos en la nube desde el tiempo de construcción hasta el tiempo real.
