KubeVela y Score: dar la plataforma por CLI sin enseñar Kubernetes al desarrollador

Mon, 31 Aug 2026 09:45:00 +0200

Tercer y último artículo de la tanda sobre reconstruir la nube on-premise. El mapa general te situó los huecos y Crossplane cubrió el plano de control de infraestructura. Aquí va la capa de encima, la que tu desarrollador toca todos los días: el autoservicio por CLI centrado en la aplicación.

TL;DR

Crossplane responde “dame una base de datos”, desde la infraestructura. KubeVela y Score responden “despliega mi aplicación”, desde el workload, y lo hacen por CLI, que es justo la experiencia amable que Crossplane deliberadamente no te da. Los dos comparten artículo porque cubren la misma capa desde ángulos distintos. KubeVela es una plataforma completa de entrega: usa el modelo OAM, donde tu equipo de plataforma escribe una vez unas definiciones en el lenguaje CUE y el desarrollador despliega toda su aplicación con un fichero de quince líneas y una CLI (vela up, vela status, vela logs) que se siente como Heroku por fuera y es GitOps por dentro. Score es más modesto y más portable: una especificación de workload en un solo fichero que se traduce por CLI a Docker Compose en local y a Kubernetes en producción, sin correr nada en el cluster.

Lo honesto de entrada son los límites. Ninguno de los dos aparece en la sección “Adopt” del radar tecnológico de la CNCF de principios de 2026, donde sí están Helm, Backstage y Argo CD: son nicho frente al mainstream. La versión 1.11 de KubeVela sigue en alfa, así que la estable es la 1.10; su comunidad es concentrada, con unas 33 personas contribuyendo en 2025. Score es joven, su implementación para Kubernetes tiene pocas estrellas y su patrocinador, Humanitec, fue adquirido por Akamai. Y el poder de KubeVela vive en CUE, un lenguaje poco común y difícil de depurar. La abstracción es real, pero cuando se rompe, tu desarrollador acaba mirando YAML de Kubernetes igual.

La analogía: el formulario de pedido frente a la lista de la compra

Desplegar en Kubernetes crudo es ir al mayorista con una lista de la compra técnica: tienes que saber que quieres un Deployment, un Service, un HorizontalPodAutoscaler, un Ingress, un ConfigMap y un ResourceQuota, y cómo se rellena cada uno. Funciona si conoces el almacén. Pero tu data scientist, que solo quiere servir su modelo, no debería tener que aprenderse el almacén.

KubeVela es un formulario de pedido. En vez de la lista técnica, marcas “quiero servir esta aplicación, con estas réplicas, con esta puerta de enlace”, y detrás alguien que sí conoce el almacén (tu equipo de plataforma) ha definido qué se pide exactamente para que eso funcione. El desarrollador rellena el formulario; la traducción a la lista técnica la hizo otro, una vez, para todos.

Score es el mismo formulario pero pensado para que te valga en dos tiendas distintas. Describes tu pedido una sola vez y la misma hoja sirve para el mercado de al lado (Docker Compose, tu portátil) y para el mayorista (Kubernetes, producción), sin reescribirla. Lo que cambia entre una tienda y otra lo pone quien traduce, no tú. Las dos analogías apuntan a lo mismo: separar lo que el desarrollador quiere de cómo se materializa, para que no tenga que aprender el almacén.

KubeVela: la aplicación como unidad

Qué es y en qué estado llega a 2026

KubeVela es un proyecto de la CNCF en nivel de incubación desde febrero de 2023. Nació como evolución del runtime de OAM en Kubernetes, con contribuciones de arranque de Alibaba Cloud, Microsoft y Upbound, y se apoya en el Open Application Model, la especificación que Alibaba y Microsoft co-crearon para describir aplicaciones de forma independiente de la infraestructura.

Te doy un dato de realismo sobre su tamaño de comunidad. La retrospectiva oficial de 2025 declara siete releases en el año, 124 commits y unas 33 personas contribuyendo, sobre algo más de 7.600 estrellas en GitHub. No es un proyecto en declive, pero es una comunidad concentrada, con la curva de crecimiento aplanada respecto a su etapa inicial bajo Alibaba. Y un aviso de versión importante: la rama estable es la 1.10, con parches regulares durante 2026; la 1.11 sigue en alfa, así que no te fíes de sus features como si estuvieran disponibles.

El modelo OAM en cinco piezas

Toda tu aplicación se describe en un solo fichero YAML de tipo Application, con cuatro secciones que te toca conocer por nombre. Los components son el artefacto que despliegas, sea una imagen, un chart de Helm o un servicio; los traits son requisitos operativos que cuelgas de cada componente, como el escalado, la puerta de enlace o el almacenamiento; las policies son estrategia global de la aplicación, como la topología multi-cluster o los SLO; y el workflow es el proceso de entrega por pasos, que puede incluir una pausa de aprobación manual o una notificación.

La clave del modelo es que los tipos de componente y de trait no son fijos: son módulos programables que mantiene tu equipo de plataforma, expresados como ComponentDefinition y TraitDefinition. El desarrollador solo consume un tipo y sus propiedades; nunca ve el YAML de Kubernetes que hay debajo. Ese es exactamente el “no exponer Kubernetes crudo” del que va todo esto: tu operador de plataforma escribe la definición una vez, tu data scientist escribe quince líneas de Application.

CUE, el poder y el peaje

Las definiciones se escriben en CUE, y aquí tienes a la vez la fuerza y la debilidad de KubeVela. CUE te deja parametrizar en serio: la definición declara qué inputs expone al desarrollador y qué recursos de Kubernetes renderiza a partir de ellos, con acceso a variables de contexto como el nombre de la aplicación. El flujo real parte de un YAML existente, que vela def init convierte en un esqueleto CUE; lo editas, lo validas con vela def vet y lo publicas con vela def apply, y queda disponible para todos tus desarrolladores.

El peaje es que CUE es un lenguaje poco común, con pocos expertos y difícil de depurar. El coste recae en tu equipo de plataforma, no en el desarrollador, que es la distribución correcta, pero es un coste real que tienes que fichar antes de adoptar. Nadie llega sabiendo CUE.

La CLI vela: Heroku por fuera, GitOps por dentro

Aquí está la respuesta a la pregunta que este blog viene arrastrando sobre el aprovisionamiento por CLI. El día a día con KubeVela se te parece a Heroku: vela up despliega la aplicación desde ficheros locales, vela status te muestra su estado, vela ls lista las aplicaciones, vela logs sigue los registros, vela exec ejecuta un comando dentro del contenedor sin que conozcas el nombre del pod, y vela port-forward te abre un túnel. Tienes incluso vela dry-run, que renderiza los recursos de Kubernetes sin aplicarlos, para que veas qué va a pasar.

La matización honesta es que es “imperativa en la superficie, declarativa por debajo”. Cuando haces vela up no estás ejecutando una orden imperativa tipo heroku scale, estás aplicando un objeto Application declarativo que un controlador reconcilia. La CLI te imita el flujo cómodo de Heroku, pero el modelo subyacente es GitOps, lo que significa que encaja con tu stack de Flux mediante el addon correspondiente, en vez de reemplazarlo.

Multi-cluster, que es lo que a ti te importa

Si tienes una plataforma con varios sites (site01 y site02, en mi caso) la parte de multi-cluster es la que decide. KubeVela orquesta desde un cluster central y solo los recursos ya renderizados llegan a los clusters gestionados, con gobierno centralizado. Una topology policy decide el destino por lista de clusters o por selector de etiquetas (por ejemplo, por región); una override policy ajusta imágenes, réplicas o traits por cluster sin tocar el componente; y el paso de despliegue en el workflow reparte, con la opción de un despliegue por fases: primero al cluster local, luego una puerta de aprobación manual, y solo entonces a producción. Es la clase de gobierno que on-premise tienes que construir y que la nube te daba servido.

VelaUX, el portal ligero de regalo

KubeVela trae una consola web opcional, VelaUX, que enciendes como un addon y te da dashboard, gestión de proyectos, entornos y ciclo de vida de las aplicaciones. Si quieres CLI primero es opcional, más útil para dar visibilidad y control de acceso a operadores que como vía principal. Es un portal ligero “de regalo” que no pretende competir con Backstage, pero que puede ahorrarte montar uno si tus necesidades son modestas.

Score: describe el workload una vez

Qué es y qué resuelve

Score es una especificación abierta de workload, agnóstica de plataforma y de entorno. La idea, en su propia formulación, es que definas el workload una vez y uses una implementación de Score para traducirlo a varias plataformas: Docker Compose, Kubernetes, Fly.io o Cloud Run. El problema que te ataca es concreto y familiar: la divergencia entre lo que corres en tu portátil con Docker Compose y lo que se despliega en producción con Kubernetes, dos descripciones que se desincronizan y te causan el clásico “en mi máquina funcionaba”.

En un fichero score.yaml el desarrollador declara sus contenedores, los puertos de servicio y los recursos que necesita como dependencias (una base de datos, un DNS, una ruta), y los parámetros específicos de cada entorno se inyectan al desplegar. Score entró en el sandbox de la CNCF en julio de 2024. Lo creó y donó Humanitec, una empresa de plataformas de desarrollador, unos dieciocho meses antes de su ingreso en la fundación.

Las dos implementaciones

Score no hace nada por sí solo: es una especificación que necesita una implementación que traduzca. Tienes dos oficiales. score-compose genera Docker Compose para desarrollo local, con comandos init y generate, y provisiona del orden de catorce tipos de recurso, desde Postgres o Redis hasta almacenamiento S3 o colas. score-k8s genera manifiestos de Kubernetes listos para kubectl apply, con flags para la imagen, el namespace y los provisioners. La CLI comercial de Humanitec, humctl, también soporta Score de forma nativa.

El dato de arquitectura más importante es que Score no corre nada en el cluster destino. Es traducción puramente de CLI: te genera manifiestos y se aparta. No hay controlador, no hay CRD, no hay reconciliación. Esa es a la vez su virtud (es ligero, portable y sin lock-in de runtime) y su límite (no orquesta ni despliega, solo traduce).

Score frente a KubeVela y a Helm

El propio posicionamiento oficial de Score aclara las capas, y te lo fijo porque es fácil confundirlas. Score es la capa de especificación de workload, centrada en el desarrollador: describe un workload y sus dependencias y se traduce a N plataformas por CLI, pero no orquesta ni despliega. KubeVela es una plataforma completa de entrega continua, centrada en la aplicación: orquesta múltiples componentes, aplica policies y workflows, hace multi-cluster, y para ello necesita su controlador en el cluster; es, en sus propias palabras, mucho más rico en features que Score. Helm es el empaquetado y el renderizado de manifiestos, sin la abstracción centrada en el desarrollador ni la portabilidad a Compose.

La síntesis limpia es que son capas complementarias, no sustitutas: Score genera, Helm o los manifiestos empaquetan, KubeVela orquesta y despliega. Si te los presentan como rivales, han confundido las capas.

Dónde encaja cada uno: la comparación transversal

Con Crossplane ya en la mano del artículo anterior, la comparación de las tres piezas de autoservicio se te ordena por la pregunta que responde cada una.

Score y KubeVela responden en el plano de la aplicación: el workload que un desarrollador despliega, “despliega esta app”. Crossplane responde en el plano de la infraestructura: el recurso que un desarrollador pide, “dame una Postgres gestionada”. Y Backstage responde en el plano del portal: el catálogo web y los caminos dorados, la capa de descubrimiento que no despliega ni provisiona por sí misma, sino que orquesta a las de abajo.

Lo interesante es que se combinan. Un score.yaml puede declarar sus recursos y delegar la provisión de esos recursos a Crossplane mediante un provisioner, mientras KubeVela orquesta el despliegue de la aplicación y Backstage sirve de fachada. No es un o esto o lo otro; es una pila donde cada capa hace su trabajo. Si tu equipo es pequeño, eliges una sola pieza y ya; la pila completa es para plataformas maduras.

El encaje con inferencia: patrón, no receta oficial

Igual que con Crossplane, aquí te toca honestidad: no existe una definición oficial y mantenida de KServe en el catálogo por defecto de KubeVela ni un tipo de recurso de inferencia en Score. Lo que sigue es un patrón de diseño con piezas confirmadas por separado, no una receta documentada.

El patrón con KubeVela sería que tu operador de plataforma define una vez, en CUE, un ComponentDefinition llamado por ejemplo inference-service, que por debajo renderiza un servicio de inferencia de KServe con runtime vLLM, con los límites de GPU, las cuotas de namespace y el autoescalado ya cableados. Tu data scientist escribe entonces una Application de quince líneas con el tipo inference-service y sus propiedades (el modelo, las réplicas), sin tocar KServe, sin conocer las cuotas de GPU ni la clase de runtime, y opera con vela up, vela status y vela logs. El multi-site te lo resuelven la topology policy, que decide en qué cluster con GPU aterriza, y la override policy, que ajusta réplicas o modelo por sitio, con una aprobación manual en el workflow antes de producción.

La alternativa con Score sería un score.yaml con un recurso de tipo inference-endpoint que score-k8s, con un provisioner a medida, emite como un servicio de inferencia de KServe. Más portable, pero hoy te exige ese provisioner propio, porque KServe no es un tipo por defecto. En ambos casos, la capa de abstracción se apoya en piezas que ya son estándar (KServe pasó a incubación en la CNCF a finales de 2025 y vLLM es su runtime generativo de referencia), pero la abstracción de inferencia la construyes tú. Tómalo como propuesta, no como caso probado.

Te dejo una nota: en 2026 KServe estrenó un tipo dedicado a modelos grandes, LLMInferenceService, todavía en alfa y con vLLM como runtime, que es el ladrillo que una definición de KubeVela o un provisioner de Score renderizarían por debajo. Y en la capa de infraestructura, no en esta, el equipo de Crossplane publicó Modelplane, un plano de control de inferencia hecho de composiciones que sirve vLLM directamente. Ninguno de los dos es un tipo de KubeVela ni de Score, pero ambos te confirman que el ladrillo de abajo se está estandarizando, que es lo que hace viable poner una fachada de autoservicio encima.

Caveats, sin adornos

Esta es la sección que separa el artículo del folleto, y con estos dos proyectos te hace especial falta.

La adopción es nicho, y hay un dato duro. El radar tecnológico de la CNCF de principios de 2026, sobre más de 400 desarrolladores, coloca en “Adopt” a Helm, Backstage y Argo CD. Ni KubeVela, ni Score, ni Crossplane se mencionan. Son herramientas de nicho frente al mainstream, y elegirlas es apostar por una curva de adopción que puede no despegar.

Score es joven y su patrocinador cambió de manos. Su implementación para Kubernetes tiene pocas estrellas, la especificación está en versiones 0.x, y Humanitec, que lo patrocina, fue adquirida por Akamai en 2025, así que te toca vigilar la continuidad de la inversión en la parte open source.

KubeVela tiene comunidad concentrada y v1.11 en alfa. Las 33 personas contribuyendo en 2025 y la curva de estrellas plana son señal de meseta. No construyas sobre features de la 1.11 hasta que sea estable.

La curva de CUE es real. El poder de KubeVela vive en definiciones CUE, y CUE es difícil. El coste recae en la plataforma, pero existe.

Y el riesgo de siempre con las abstracciones: la fuga. Tanto KubeVela como Score añaden una indirección sobre Kubernetes y KServe. Cuando algo falla por debajo, la abstracción se agrieta y tu desarrollador acaba mirando el YAML de KServe igualmente, más el lock-in en tus propias definiciones. Una abstracción que no aguanta el fallo te devuelve justo la complejidad que prometía esconder.

Para tu factoría de inferencia soberana

La decisión práctica se te ordena por el perfil de tus usuarios. Si tu gente vive en la CLI y piensa en aplicaciones, KubeVela te da la experiencia tipo Heroku sobre tu propio hierro, con multi-cluster real, a cambio de que tu equipo de plataforma aprenda CUE. Si lo que más te duele es la divergencia entre local y producción, Score te resuelve eso con lo mínimo, sin meter un runtime más en el cluster. Y si quieres las dos cosas más un portal, la pila Score, Crossplane, KubeVela y Backstage existe, pero es para una plataforma que ya sirve a muchos equipos, no para el arranque.

El criterio de sobriedad es el mismo que en toda esta tanda: estas herramientas te tapan un hueco real de la nube que dejaste, pero cada una es un sistema más que operar. Para dos equipos que se conocen, un buen Helm y un repositorio de GitOps ordenado te hacen el trabajo sin CUE ni definiciones propias. El autoservicio centrado en la aplicación empieza a pagarte cuando el número de gente que despliega supera al número de gente que sabe Kubernetes, que es justo el momento en que una factoría de inferencia deja de ser un proyecto y empieza a ser una plataforma.

Con esto se cierra la tanda. El mapa te dibujó los huecos de salir de la nube, Crossplane cubrió el plano de control de infraestructura, y KubeVela con Score cubren la cara que el desarrollador toca. Tu casa propia ya se parece bastante al hotel, y el dato se quedó dentro.

Ver también

De la nube pública a la privada: el mapa — el problema completo que esta tanda desglosa.
Crossplane: el plano de control de nube privada — la capa de infraestructura, complementaria a esta.
Backstage como portal de autoservicio — la tercera vía de autoservicio, la del portal web.
KServe y el protocolo abierto de inferencia — lo que las definiciones de inferencia materializarían por debajo.
GitOps del stack de inferencia con Flux — el motor con el que KubeVela convive.

Fuentes

KubeVela, State of KubeVela 2025 — https://kubevela.io/blog/2025/12/20/state-of-kubevela-2025/
CNCF, KubeVela brings software delivery control plane capabilities to the CNCF incubator — https://www.cncf.io/blog/2023/02/27/kubevela-brings-software-delivery-control-plane-capabilities-to-cncf-incubator/
KubeVela Docs, Core Concept — https://kubevela.io/docs/getting-started/core-concept/
KubeVela Docs, vela CLI reference — https://kubevela.io/docs/cli/vela/
KubeVela Docs, Custom Component with CUE — https://kubevela.io/docs/platform-engineers/components/custom-component/
KubeVela Docs, Multi-cluster delivery — https://kubevela.io/docs/case-studies/multi-cluster/
KubeVela Docs, VelaUX addon — https://kubevela.io/docs/reference/addons/velaux/
CNCF, Score accepted as a CNCF Sandbox Project — https://www.cncf.io/blog/2024/08/08/score-accepted-as-a-cncf-sandbox-project/
Score Docs, Overview — https://docs.score.dev/docs/
Score, Score vs the Open Application Model and KubeVela — https://score.dev/blog/score-vs-open-application-model-kubevela/
GitHub, score-compose — https://github.com/score-spec/score-compose
GitHub, score-k8s — https://github.com/score-spec/score-k8s
CNCF, KServe becomes a CNCF Incubating Project — https://www.cncf.io/blog/2025/11/11/kserve-becomes-a-cncf-incubating-project/
KServe Docs, Understanding LLMInferenceService — https://kserve.github.io/website/docs/model-serving/generative-inference/llmisvc/llmisvc-overview
Crossplane Blog, Building Modelplane on Crossplane — https://blog.crossplane.io/building-modelplane/ · https://modelplane.ai
CNCF y SlashData, Technology Radar Q1 2026: Platform Engineering — https://www.cncf.io/announcements/2026/03/24/cncf-and-slashdata-report-finds-platform-engineering-tools-maturing-as-organizations-prepare-for-ai-driven-infrastructure/

Developer-Experience on lo0 — Blog Técnico