Kubernetes de autoservicio: qué puede pedir el desarrollador y qué controla plataforma

HPE ha dibujado dónde pone la frontera del autoservicio en Kubernetes: el desarrollador pide entornos desde un catálogo aprobado y el equipo de plataforma conserva la política, la red, la identidad y el ciclo de vida. La compañía lo cuenta a través de dos de sus responsables de producto, Marius Bogoevici y Karthik Subramanian, así que es su versión sobre un problema que existe.

El punto de partida no es discutible. Kubernetes upstream trae orquestación y APIs declarativas, pero no un modelo operativo cerrado: alguien tiene que elegir y mantener el CNI, el CSI, el ingress, la identidad y la aplicación de políticas, y ese ecosistema de proyectos de la CNCF cambia todo el rato. A eso se suma el día 2. Levantar un clúster es lo fácil; mantenerlo al día en desarrollo, QA, preproducción y producción es donde se acumula el trabajo, y cada salto de versión hay que validarlo contra los componentes que lo rodean. Si los clústeres además reparten cargas entre bare metal, nube privada, edge y nube pública, los scripts a medida y las configuraciones por entorno acaban generando deriva.

La tentación es abrir la API de Kubernetes al desarrollador y quitarse el problema de encima. La compañía sostiene lo contrario: sin una capa de gobierno, quien programa acaba depurando manifiestos y drivers de almacenamiento en lugar de escribir código, y operaciones se encuentra con aprovisionamiento de más, clústeres ociosos y configuraciones que llegan a producción sin revisión.

Qué se elige y qué se hereda

Su propuesta son catálogos de servicio sobre HPE Morpheus Software, con plantillas reutilizables, flujos de aprobación, control de acceso por roles y APIs. El desarrollador no escribe YAML para ingress, clases de almacenamiento o RBAC, pero mantiene el acceso a Kubernetes por las interfaces de siempre cuando está permitido. Del menú puede escoger versiones aprobadas y probadas del runtime, tamaños de clúster y número de nodos, cuotas de CPU, RAM y almacenamiento persistente, las herramientas e imágenes de contenedor que necesite y una fecha de caducidad para entornos temporales. El aislamiento de red, la integración con el proveedor de identidad, la política de seguridad y la imputación de costes no se tocan: viajan con la plantilla aprobada.

"Los mejores candidatos para el autoservicio son las peticiones repetibles, de bajo riesgo y bien entendidas", dice Bogoevici. Y añade que el equipo de plataforma decide cómo es una configuración segura y el desarrollador elige dentro de un menú que la soporta.

Todo esto viene con una advertencia: HPE describe su propio producto y no ha enseñado cifras de cuánto se reduce el trabajo operativo ni qué parte del catálogo es realmente abstraíble. Las versiones Advanced y Enterprise de Morpheus cubren el caso de nube privada en local y el híbrido con nube pública, respectivamente, siempre sobre su distribución de Kubernetes certificada por la CNCF.

La discusión de fondo no es técnica sino de reparto: cada decisión que se sube al catálogo es una decisión que el equipo de plataforma deja de tomar caso por caso, y eso solo funciona si el catálogo cubre de verdad la mayor parte de lo que se pide. Si no, el ticket vuelve.