Diseño de LLM en OpenShift: solución de los SCC y la identidad híbrida

Los arquitectos empresariales conocen la realidad de la implementación en Red Hat OpenShift: no se limita a aplicar los manifiestos estándar con kubectl. Ya sea que ejecutes de forma local, en IBM Cloud Satellite, o mediante Azure Red Hat OpenShift (ARO), las primitivas de seguridad, específicamente las restricciones del contexto de seguridad (SCC), superarán de inmediato las implementaciones estándar de Kubernetes en sentido ascendente.

TrueFoundry funciona como una superposición de orquestación. Separamos la experiencia de los desarrolladores de la complejidad de la infraestructura, lo que le permite implementar LLM sin dejar de respetar los estrictos límites del ecosistema de Red Hat. En esta publicación se detalla cómo nos integramos con las redes de OpenShift, IBM Cloud IAM, y watsonx.ai.

El modelo de implementación: arquitectura de plano dividido

Usamos una arquitectura de plano dividido para cumplir con los requisitos de residencia de datos. Usted controla estrictamente la Plano de cálculo; gestionamos los metadatos en el Plano de control.

1. Plano de control (SaaS o VPC): Gestiona la gestión de identidades, los catálogos de modelos y la programación de trabajos.
2. Plano de cálculo (su clúster): El agente TrueFoundry se ejecuta directamente en su Plataforma de contenedores Red Hat OpenShift.

El agente inicia una conexión WebSocket solo saliente al plano de control. No se abren los puertos de firewall entrantes. Esto satisface los requisitos de aislamiento o de alta seguridad comunes en los sectores financiero y sanitario.

Figura 1: TrueFoundry opera dentro del plano de computación local, respetando el perímetro seguro.

Seguridad: automatización de SCC y RBAC

El punto de fricción en OpenShift es la aplicación de Restricciones del contexto de seguridad (SCC). A diferencia de los Kubernetes anteriores, OpenShift evita que los pods se ejecuten como root o accedan a las rutas del host de forma predeterminada.

Manejo de Restricted-v2

Diseñamos el agente TrueFoundry para que funcione dentro del SCC de versión 2 restringida.

• Inyección de UID: No codificamos los seudónimos. El agente detecta el rango de UID anotado del espacio de nombres e inyecta dinámicamente el ID de RunAsUser correcto en la especificación del pod de inferencia durante el tiempo de ejecución.
• Abstracción de volúmenes: Evitamos los requisitos de HostPath al utilizar reclamaciones de volumen persistentes (PVC) respaldadas por Almacenamiento en bloque en la nube de IBM o vSphere CSI para configuraciones locales.

Federación de identidades: IBM Cloud IAM

Las credenciales codificadas en secreto representan un riesgo para la seguridad. Para los despliegues en IBM Cloud, implementamos la federación de identidades mediante Perfiles confiables de IBM Cloud.

Esto permite que sus cargas de trabajo de OpenShift asuman una identidad dinámica. El pod intercambia su token de cuenta de servicio localizado por un token de IBM Cloud IAM, lo que otorga acceso temporal a Almacenamiento de objetos en la nube (COS) de IBM o IBM Key Protect.

Figura 2: Flujo de autenticación que utiliza perfiles de confianza para eliminar las credenciales estáticas de larga duración.

Redes: integración con OpenShift Routes

Los recursos estándar de Kubernetes Ingress a menudo requieren traducción en los entornos de Red Hat. TrueFoundry se integra directamente con Controlador de ingreso OpenShift (HAProxy).

• Entrada: Cuando implementa un modelo, suministramos una ruta de OpenShift automáticamente y gestionamos la terminación de SSL en el borde.
• Salida con brecha de aire: Para entornos desconectados, admitimos la obtención de imágenes internas Red Hat Quay registros. Puede almacenar previamente en caché los pesos de los modelos en un almacén interno compatible con S3 para eliminar las dependencias de Internet en tiempo de ejecución.

Computación: programación de GPU y Watsonx.ai

Interactuamos con Operador de GPU NVIDIA para gestionar la aceleración del hardware.

Particionamiento MIG

Para los clústeres A100 o H100, admitimos GPU NVIDIA de instancias múltiples (MIG). El programador TrueFoundry identifica los perfiles MIG disponibles y dirige los pods a la partición lógica correcta, lo que aumenta la densidad de utilización del hardware sin necesidad de una configuración de afinidad manual.

La puerta de enlace unificada

Para equipos que utilizan IBM watsonx.ai, proporcionamos una puerta de enlace de IA unificada.

• Traducción de protocolos: Los desarrolladores utilizan un esquema estándar compatible con OpenAI. El Gateway gestiona la transformación a la API watsonx.ai.
• Telemetría unificada: Registramos las solicitudes a los modelos autohospedados (Llama 3, Mistral) y a los modelos SaaS (Granite, Watsonx) en un solo panel para poder observar los costos y las auditorías.

Figura 3: La pasarela unifica el tráfico entre los pods autohospedados y los servicios gestionados de IBM.

Comparación operativa

La siguiente tabla describe los cambios operativos específicos al superponer TrueFoundry en OpenShift nativo.

Continuidad arquitectónica

La integración de TrueFoundry con IBM Cloud y Red Hat OpenShift le permite mantener la estricta postura de cumplimiento del ecosistema de Red Hat y, al mismo tiempo, acelerar la implementación del modelo. Usted conserva la residencia de los datos en OpenShift, ya sea en las instalaciones o en IBM Cloud, y proporciona a sus equipos de ingeniería una interfaz unificada que elimina las restricciones de infraestructura subyacentes.

‍