Verificación de conocimientos - Contenedores y plataforma de IA
Un equipo que migra una capa web pública a un clúster público de Managed Kubernetes declara un Service de tipo LoadBalancer y asume que ahora cuenta con un balanceador de carga externo altamente disponible que preserva la IP de origen, equivalente al Managed Network Load Balancer utilizado en otras partes del entorno. El arquitecto se opone. ¿Por qué es incorrecta esta suposición y cuál es la forma correcta de frontear la carga de trabajo?
En Managed Kubernetes, un Service de tipo LoadBalancer no aprovisiona un balanceador de carga externo administrado. IONOS CLOUD reserva una IP pública estática y la adjunta como IP secundaria a un nodo de trabajo, y kube-proxy aplica NAT al tráfico hacia el pod de destino, por lo que no hay alta disponibilidad, se pierde la IP de origen a menos que externalTrafficPolicy se establezca en Local, y el rendimiento está limitado al tope público de ese único nodo. La entrada de producción se construye aprovisionando un balanceador de carga por separado y ejecutando un controlador de entrada dentro del clúster, porque los manifiestos no aprovisionan automáticamente un balanceador de carga administrado. Escalar el pool o cambiar externalTrafficPolicy no convierte el único nodo de entrada en un balanceador L4 administrado de múltiples nodos.
Un equipo consciente de los costos que ejecuta trabajos por lotes en un Cluster de Managed Kubernetes desea que el pool de Node baje a cero Node durante la noche cuando no se ejecutan trabajos, y también desea que los eventos del control-plane del Cluster fluyan al Logging Service centralizado junto con sus registros de aplicación. El arquitecto explica que ambas expectativas chocan con las limitaciones de la plataforma. ¿Qué enunciado describe correctamente dichas limitaciones?
El mínimo del autoscaler en Managed Kubernetes es un Node cálido; no existe la escalación a cero, por lo que un diseño por lotes debe suponer que al menos un Node está siempre en ejecución y facturable. Por separado, los eventos del control-plane no se exponen a través del Logging Service, por lo que la observabilidad centralizada del control plane administrado no está disponible y la visibilidad debe obtenerse de señales dentro del Cluster. Estas limitaciones son independientes del tipo de Cluster y no se desbloquean al alternar el escaneo o la exportación de auditoría.
Un arquitecto está diseñando un clúster privado de Managed Kubernetes para una carga de trabajo regulada y enumera los requisitos previos. La construcción es para un clúster privado cuyo plano de datos debe estar aislado, cuyo servidor de API debe permanecer accesible solo para el equipo de operaciones y cuyos nodos deben comunicarse a través de un segundo VDC. ¿Qué conjunto de decisiones es correcto?
Los clústeres privados aíslan el plano de datos, no el punto de acceso de la API, por lo que el servidor de API sigue siendo accesible y debe protegerse con una lista de permisos de IP. Las dos dependencias de red, una NAT Gateway para el tráfico de salida y un Cross-Connect para el tráfico de nodos entre VDC, deben existir antes de construir el clúster, y el tipo de pool de nodos es inmutable después de la creación, por lo que debe elegirse correctamente desde el inicio. Los grupos de seguridad se vinculan a las NIC de los workers, no a un objeto de clúster, y colocar el plano de control en la misma región es lo que preserva la soberanía.
Un equipo de plataforma desea gobernar el acceso a su Container Registry de la misma manera en que gestiona sus cuentas de nube, definiendo roles como desarrollador de solo lectura, pipeline-pusher y administrador, y vinculando usuarios y grupos humanos a dichos roles. También desean un nivel de extracción pública anónima para imágenes de código abierto. El arquitecto explica que el registro no funciona de esa manera. ¿Cuál es el modelo de gobernanza correcto?
El Container Registry proporciona acceso solo mediante tokens, sin RBAC y sin vinculaciones de roles a usuarios, por lo que no hay herencia de roles IAM ni un nivel de extracción pública anónima. La gobernanza se aplica a través de la disciplina de tokens: un token de alcance estrecho por etapa de la pipeline, con caducidad y rotación, y los tokens se eliminan en lugar de deshabilitarse cuando se retiran. Las opciones incorrectas inventan RBAC, un nivel de extracción pública y una acción de deshabilitación que el servicio no proporciona.
Una empresa desea incorporar inteligencia artificial generativa a una aplicación regulada y de un país específico, y debe mantener todo el procesamiento en Alemania, evitar la ejecución y el parcheo de infraestructura de GPU, e integrar mediante sus bibliotecas de cliente de OpenAI existentes. También necesita recuperación sobre un corpus privado. ¿Qué enfoque se ajusta a la configuración predeterminada para empresas de la plataforma y a su dirección actual?
La inferencia administrada en el Model Hub es la configuración predeterminada para empresas: una API compatible con OpenAI con precios por token, un servicio sin estado y un procesamiento que ocurre dentro del país, lo cual elimina la carga de ejecutar y aplicar parches al servicio de GPU. Para la recuperación, el patrón duradero es el construido por el cliente, utilizando embeddings del hub, vectores almacenados en Managed PostgreSQL y el corpus en Object Storage, evitando deliberadamente la función de almacén de vectores administrado que está en proceso de deprecación. Enrutar a una región de EE. UU. incumple el requisito de procesamiento dentro del país, y el autoalojamiento desde el primer día asume responsabilidades de SLA y redundancia que los requisitos no solicitaron.
Un cliente despliega un modelo de código abierto en el AI Model Hub y pregunta cómo se asignan las responsabilidades de la Ley de IA de la UE, incluido el caso en el que IONOS CLOUD modifica un modelo, por ejemplo, mediante su cuantización. ¿Cuál es la asignación correcta?
Según la Ley de IA de la UE, el cliente es el desplegador, o el proveedor de su propio sistema de IA, y es responsable de su propia evaluación de riesgos. Para la mayoría de los modelos de código abierto no modificados en el hub, IONOS CLOUD actúa como distribuidor o intermediario, pero cuando IONOS CLOUD modifica un modelo, por ejemplo mediante cuantización, asume las obligaciones de transparencia de proveedor de IA para dicha modificación. La ausencia de estado y el procesamiento en el país son propiedades de soberanía y no eximen a ninguna de las partes de la Ley.