Crossplane: el plano de control que convierte tu cluster en una API de nube privada

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

Segundo artículo de la tanda sobre reconstruir la experiencia de nube on-premise. El mapa general te situó los huecos; este entra en el plano de control de aprovisionamiento, esa API que on-premise no viene dada. El tercero sube una capa, al autoservicio centrado en la aplicación con KubeVela y Score.

TL;DR

Crossplane te resuelve el hueco del “abre un ticket y espera”. En la nube pides una base de datos por una API y aparece con permisos, copias y monitorización; on-premise ese aprovisionamiento lo haces a mano o por scripts. Crossplane lleva el modelo de APIs declarativas de Kubernetes a la infraestructura: tu equipo de plataforma define una API propia (una base de datos, un endpoint de inferencia) y el desarrollador la consume con un kubectl apply de pocos campos, mientras controladores dentro del cluster reconcilian el estado deseado contra la realidad y corrigen la deriva de forma continua. Se graduó en la CNCF en noviembre de 2025, con más de tres mil contribuidores y adoptantes como Nike, SAP, IBM o la nube científica de la NASA.

La diferencia con Terraform es de naturaleza, no de features: Terraform aplica un plan bajo demanda y se va; Crossplane es un plano de control que vive dentro del cluster y no deja de reconciliar. Eso te da autocorrección de deriva y GitOps nativo, y a cambio te quita la red de seguridad del plan y te obliga a operar el propio plano de control, con providers que crean cientos de definiciones de recursos y un estado que vive en etcd. Y te aviso de una cosa incómoda de entrada: Crossplane no es una CLI imperativa tipo aws ..., es declarativo primero. Sobre el encaje con inferencia GPU, que hasta hace poco era solo un patrón sin caso público, ya tienes una referencia real, Modelplane, del propio equipo de Crossplane, aunque en versión 0.1 y componiendo vLLM directamente sin pasar por KServe. Te lo detallo al final.

La analogía: el termostato frente al interruptor

Piénsalo así: Terraform es un interruptor de la luz. Lo accionas, la luz se enciende, y ahí se queda hasta que vuelvas a tocarlo. Si alguien más lo cambia, la luz obedece a quien lo tocó por última vez, y tú no te enteras hasta que vas a mirar. Es aprovisionamiento por acción puntual: ejecutas, aplica, termina.

Crossplane es un termostato. No le dices “enciende la calefacción”, le dices “quiero veintiún grados”, y a partir de ahí un mecanismo vigila la temperatura y actúa solo, de forma continua, para mantenerla. Si alguien abre una ventana y baja el termómetro, el termostato reacciona sin que tú intervengas. Eso es la reconciliación continua: declaras el estado deseado una vez y un controlador se encarga de que la realidad no se aparte de él.

La analogía también te avisa del coste. Un termostato es más cómodo que un interruptor, pero es un aparato más que tienes que instalar, alimentar y arreglar cuando falla, y si lo programas mal te ajusta la temperatura a algo que no querías, sin preguntar. Un interruptor no se rompe casi nunca y siempre sabes en qué estado está. Crossplane te da la comodidad del termostato a cambio de que operes el termostato.

Qué es Crossplane y en qué estado llega a 2026

Crossplane nació en Upbound en 2018 y siguió el recorrido de madurez de la CNCF sin atajos: sandbox en 2020, incubación en 2021 y graduación el 6 de noviembre de 2025. La graduación importa porque es el sello que la CNCF reserva para proyectos que considera listos para producción, el mismo nivel de Kubernetes o Prometheus. Las cifras que acompañaron el anuncio son sólidas: más de tres mil contribuidores de más de 450 organizaciones, más de mil autores de pull requests (lo que lo mete en el 10 % superior de los proyectos de la fundación por esa métrica), más de cien releases y dos auditorías de seguridad completadas. Entre los más de setenta adoptantes públicos tienes a Nike, Nokia, Grafana, la nube científica de la NASA, SAP e IBM.

La descripción oficial del proyecto es “el plano de control nativo de la nube”, y esa frase te resume exacto lo que hace. El principal vendor detrás sigue siendo Upbound, que en la graduación enmarcó el futuro del proyecto hacia infraestructura “AI-native”, un dato que te retomo al hablar de inferencia, con la cautela de que es posicionamiento de un vendor, no un caso probado.

La cadencia de releases es trimestral, con una ventana de soporte de nueve meses y tres versiones con mantenimiento activo en cualquier momento. A la fecha de escribir esto, la rama v2 es la vigente, con la v1.20 como último cierre de la rama v1.

El giro de la v2 (que te cambia cómo lo piensas)

Crossplane 2.0 llegó a disponibilidad general en agosto de 2025 y trae cuatro cambios estructurales que te toca conocer, porque buena parte del material antiguo describe un modelo que ya no es el recomendado.

El primero es que los recursos pasan a estar dentro de un namespace por defecto. Tanto los recursos compuestos como los gestionados, que antes eran de ámbito de cluster, ahora viven en un namespace, lo que te habilita control de acceso fino y multi-tenancy natural, justo lo que necesitas en una plataforma soberana con varios equipos.

El segundo es que una composición puede incluir cualquier recurso de Kubernetes, no solo recursos de Crossplane. Antes una composición se limitaba a los recursos gestionados del propio Crossplane; ahora puede incluir Deployments, Services o CRDs de terceros, así que puedes componer abstracciones que mezclan aplicación e infraestructura en un mismo objeto. Este cambio es el que hace viable el patrón de inferencia que verás.

El tercero es que desaparecen los Claims. En el modelo v1 había una dualidad entre el recurso compuesto, de ámbito de cluster, y el Claim, su cara dentro de un namespace que consumía el desarrollador. Al ser ahora el recurso compuesto directamente de namespace, esa dualidad sobra: el desarrollador consume el recurso compuesto sin intermediario. Si te encuentras documentación que habla de Claims, es del modelo anterior.

El cuarto es un tipo nuevo, Operations, para tareas operativas puntuales o programadas que ejecutan un pipeline de funciones hasta completarse, como un Job de Kubernetes pero dentro del modelo de Crossplane.

Hay una eliminación que merece punto y aparte, porque es la que más sorprende: en v2 se retiró el patch-and-transform nativo, el mecanismo clásico de parcheo de las composiciones. No se relegó, se quitó. Todo pasa ahora por composition functions, y a eso llego en un momento. La migración de v1 a v2 es en su mayoría sin rupturas y las APIs v1 siguen funcionando, así que adoptar v2 es opcional, pero el modelo nuevo es el que te toca aprender.

El modelo, pieza por pieza

Crossplane tiene una jerga densa y te la desmonto con calma, porque una vez colocadas las piezas el conjunto es coherente.

Un provider es un paquete que instala controladores y definiciones de recursos para hablar con una API externa, sea AWS, GCP, un cluster de Kubernetes remoto, Helm o Terraform. Se instala de forma declarativa, aplicando un objeto Provider. Los providers de los grandes proveedores cloud se generan con Upjet, un framework que produce el código a partir de los providers de Terraform, lo que te explica por qué existen tantos y también por qué algunos son enormes.

Un managed resource es la representación uno a uno, dentro de Kubernetes, de un recurso del proveedor externo: un bucket, una instancia, una base de datos. Es la unidad que el controlador reconcilia. Cuando creas un managed resource de tipo bucket, el controlador del provider crea el bucket real y luego vigila que siga existiendo y con la configuración que declaraste.

Sobre esos ladrillos construyes la abstracción, que es donde está el valor real, con tres conceptos:

La CompositeResourceDefinition, o XRD, define el esquema de tu API propia: qué campos puede pedir el usuario. Es la que convierte “una base de datos” en un tipo de recurso con sus parámetros.

La Composition es la plantilla y la lógica que, dado uno de esos recursos, materializa los N recursos gestionados que hacen falta por debajo. La documentación lo dice sin rodeos: una composición es un pipeline de composition functions.

El Composite Resource, o XR, es la instancia concreta: el objeto que el desarrollador crea con kubectl apply, con los pocos campos que la XRD expone.

El patrón completo es este: tu operador de plataforma publica la abstracción (la XRD más la Composition, que dicen “esto es lo que significa una base de datos aquí”), y el desarrollador solo aplica un recurso compuesto con cuatro campos. Deja de importarle cómo se construye por debajo, igual que en la nube no te importa cómo AWS te monta la base de datos gestionada.

Composition functions: la lógica real

El mecanismo de composición en v2, y el único, son las composition functions. Una composición es un pipeline de funciones que Crossplane invoca por gRPC; cada función recibe el estado observado, el deseado, su input y un contexto compartido, y encadena su salida a la siguiente. El YAML de los ejemplos es ilustrativo, pero por debajo no se procesa como YAML: se ejecuta como funciones.

Las funciones disponibles cubren varios estilos. Tienes function-patch-and-transform, que reimplementa el viejo modelo ahora como una función más. Están function-go-templating para plantillas al estilo Helm, function-kcl para el lenguaje KCL, function-python para lógica en Python y function-cue para CUE.

El porqué del cambio es lo que te interesa entender. El patch-and-transform clásico no tenía bucles ni condicionales, así que una operación tan simple como transformar un array de strings se te convertía en decenas de líneas de parcheo, y la comunidad lo llegó a calificar de directamente malo. Las funciones te dejan lógica de programación completa (bucles, condicionales, llamadas externas) en un lenguaje real. La contrapartida honesta es que la complejidad no desaparece: se te desplaza de “escribir parches verbosos” a “escribir y operar funciones”, que es otro tipo de trabajo, no menos trabajo.

Crossplane frente a Terraform, OpenTofu y Pulumi

Esta es la comparación que hace todo el mundo, y te la hago bien porque la diferencia es de categoría. Según la propia documentación de Pulumi, que compara con honestidad, Crossplane es un plano de control declarativo con reconciliación continua dentro de Kubernetes, mientras que Terraform y Pulumi son infraestructura como código de ejecución puntual, del lado del cliente y bajo demanda.

Las consecuencias prácticas se ordenan en pocos ejes. Ante la deriva de configuración, Crossplane la corrige de forma continua y automática, mientras Terraform y Pulumi la detectan solo cuando ejecutas un refresco. Crossplane necesita un cluster donde correr, porque son controladores; Terraform y Pulumi no. Crossplane es GitOps nativo, se aplica con kubectl y encaja con Flux sin adaptador; Pulumi necesita su operador de Kubernetes para lo mismo. Y en cuanto al lenguaje, Crossplane usa YAML y CRDs con lógica en las funciones, mientras Pulumi usa lenguajes de programación generales.

El punto que más se olvida es que no tienes que elegir uno u otro. Existe un provider de Terraform (y otro de OpenTofu, recomendado para versiones nuevas porque el de Terraform quedó congelado en la última versión con licencia libre) que ejecuta HCL dentro de Crossplane, envolviendo tus módulos existentes como un recurso gestionado. Puedes reutilizar toda tu inversión en Terraform y aun así ganar la reconciliación continua para lo que la necesite. Si ya tienes Terraform en producción, este patrón híbrido suele ser tu ruta sensata, no la reescritura.

Sobre la adopción comparada te toca ser sobrio: no hay una cifra oficial y fiable de “Crossplane frente a Terraform”, y la crítica documentada más repetida es que a Crossplane le falta el ecosistema maduro de módulos que Terraform lleva años acumulando. Es una diferencia cualitativa real, no un detalle.

La pregunta incómoda: ¿es una CLI tipo AWS?

Como en este blog vengo tirando del hilo del aprovisionamiento por CLI, te respondo directo: no. Crossplane no te ofrece una experiencia imperativa tipo aws s3 create-bucket. Es declarativo primero. Aprovisionas con kubectl apply de un recurso, y el binario crossplane te sirve para construir, empaquetar, probar y depurar, no para “crear un bucket” de un tirón.

Los subcomandos te lo dejan claro. crossplane render renderiza una composición y sus funciones en local, para que pruebes sin cluster. La familia crossplane xpkg build, push, install te gestiona los paquetes OCI de providers, configuraciones y funciones. Y crossplane beta validate, trace y top validan esquemas, dibujan el árbol de recursos y muestran el consumo dentro del cluster. Es la caja de herramientas del que construye la plataforma, no la del que la consume a diario. La CLI up de Upbound añade más, pero orientada a su producto comercial.

La conclusión te importa para fijar expectativas: la experiencia imperativa tipo consola de AWS, si la quieres, la construyes encima de Crossplane, con Backstage, un portal o un wrapper propio. Crossplane te pone la API declarativa; la cara amable la pones aparte. Si lo que buscas es una CLI imperativa de aprovisionamiento, encajas mejor con el modelo de KubeVela y Score, que es justo el tema del siguiente artículo.

Providers on-premise: aprovisionar sin tocar AWS

Para una plataforma soberana tu pregunta es qué puedes aprovisionar sin pisar una nube pública, y la respuesta es más de lo que parece, con madurez desigual.

El más versátil es provider-kubernetes, que gestiona cualquier objeto de Kubernetes en clusters remotos a través de un recurso Object. Es la base del patrón multi-cluster on-premise: desde un cluster central materializas recursos en tus RKE2 secundarios. Junto a él, provider-helm instala y gestiona charts de Helm de forma declarativa mediante un recurso Release, con lo que despliegas cosas como vLLM o KServe como parte de una composición.

Para la parte de identidad y almacenamiento tienes piezas concretas: provider-keycloak configura realms, clientes y roles de Keycloak de forma declarativa, útil para el IAM soberano que ya montamos en el artículo de autenticación con Keycloak; y provider-minio gestiona buckets y políticas del almacenamiento S3-compatible on-premise. Para vSphere no tienes un provider nativo de primera clase, pero lo cubres generándolo desde el provider de Terraform, el patrón habitual para infraestructura VMware.

Un aviso honesto: para KubeVirt, Harvester o CloudNativePG no hay providers nativos maduros y de primera clase; en la práctica los gestionas aplicando sus CRDs a través de provider-kubernetes o envolviendo su Terraform. Funciona, pero no es la experiencia pulida de un provider dedicado. Con la combinación de provider-kubernetes, provider-helm, provider-minio y provider-keycloak, más provider-terraform para lo que falte, montas un catálogo de autoservicio cien por cien on-premise, con la advertencia de que la madurez te varía pieza a pieza.

El encaje con inferencia GPU: de patrón a Modelplane

Esta es la sección que en la primera versión de este texto iba con la máxima cautela, porque no había un caso público de Crossplane orquestando GPU e inferencia y todo quedaba en patrón de diseño. A mitad de 2026 eso cambió, y el caso lo publicó el propio equipo que hace Crossplane.

Modelplane es un plano de control open source para inferencia de IA, con licencia Apache y una primera versión 0.1 de junio de 2026, y lo interesante es cómo está hecho: enteramente sobre composiciones de Crossplane y composition functions en Python, sin controladores propios. Compone vLLM directamente, con la imagen vllm/vllm-openai, sin pasar por KServe, y su API de autoservicio para los equipos de ML es un recurso ModelDeployment donde declaras el modelo, el motor, la topología y el hardware. Por debajo, un recurso ModelReplica representa cada réplica, y el equipo de plataforma declara sus pools de GPU con recursos InferenceCluster e InferenceClass, usando un modelo de atributos y expresiones CEL tomado de la asignación dinámica de recursos de Kubernetes. Su pieza más avanzada es un planificador de flota de dos niveles escrito como función pura, que coloca réplicas por toda la infraestructura y delega en el planificador de cada cluster. Es la prueba de que el patrón funciona, con el aviso de que es una versión 0.1 en desarrollo abierto, no algo para meter en producción a ciegas, y de que adoptarlo te ata la plataforma a sus tipos de recurso.

El otro habilitador reciente está en KServe, que estrenó un tipo dedicado a modelos grandes, LLMInferenceService, todavía en alfa y construido sobre el proyecto llm-d, con separación de prefill y decode y ejecución multi-nodo, y que corre vLLM como runtime. Es distinto del InferenceService clásico, reservado para el ML predictivo. Ese tipo nuevo es tu ladrillo ideal si prefieres componer KServe en vez de vLLM a pelo.

Con eso, el camino dorado propio deja de ser hipótesis. Defines una XRD, por ejemplo InferenceEndpoint, con campos como el modelo, el número y tipo de GPU y las réplicas. Su composición, aprovechando que en v2 puede incluir cualquier recurso de Kubernetes, materializa en un solo pipeline el namespace del equipo, la cuota para nvidia.com/gpu y un LLMInferenceService de KServe apuntando al modelo con runtime vLLM, y el desarrollador solo aplica el InferenceEndpoint con cuatro campos, sin conocer KServe ni las cuotas por debajo. KServe soporta vLLM y GPU de forma nativa, como vimos en el artículo sobre KServe.

La lectura honesta es que estás en la frontera, no en terreno trillado. Fuera de Modelplane, hecho por Upbound, todavía no hay un cuerpo de casos independientes montando Crossplane con vLLM, y el tipo de KServe está en alfa. Es una arquitectura coherente, con una referencia real que la respalda y un margen amplio para que seas de los primeros en documentarla sobre hierro propio.

Lo que te cuesta operar tu propio plano de control

Ninguna herramienta que te devuelve control es gratis, y Crossplane tiene costes bien documentados que te toca presupuestar antes, no descubrir después.

La curva de aprendizaje es empinada, reconocido incluso en la cobertura de su graduación. Los adoptantes reportan dificultades de depuración cuando una composición o un provider se comportan mal, y echan en falta el ecosistema de módulos de Terraform.

Las composiciones tienden a la complejidad. Hay practicantes que describen definiciones que abarcan miles de líneas con mala navegación, y la ausencia de un framework de testing integrado. Las funciones mejoran esto, pero como te dije, te desplazan la complejidad más que eliminarla.

No hay plan. A diferencia del ciclo plan y apply de Terraform, Crossplane aplica los cambios de inmediato. Pierdes la red de seguridad de revisar qué va a pasar antes de que pase, con el riesgo de modificaciones que no querías.

Operar el propio plano de control cuesta. Los providers grandes crean cientos de definiciones de recursos (el de GCP llegó a 347), con riesgo de indisponibilidad del servidor de API y de dejarte el cluster colgado. El estado vive en etcd, lo que te complica la recuperación ante desastres y la migración del control entre clusters. Y hay un peligro concreto: un borrado accidental de recursos cloud al actualizar XRDs, providers o composiciones, por la propiedad que Crossplane mantiene sobre lo que creó.

Hay quien decidió no adoptarlo. El equipo de Masterpoint lo descartó por la falta de fuentes de datos y de ignore_changes, por una cobertura incompleta de servicios de AWS, y por el coste de abandonar su experiencia acumulada en Terraform. Es una decisión legítima, y citártela es parte de un artículo honesto.

Cómo convive con lo que ya tienes

Si ya operas una plataforma, tu pregunta no es Crossplane sí o no, sino Crossplane con qué. Tres relaciones te importan.

Con Backstage son complementarios, no rivales. Backstage es el portal y las plantillas que generan manifiestos o pull requests, el día cero; Crossplane aprovisiona y reconcilia el estado real, el día dos. El patrón habitual, que algunos llaman el triángulo dorado, es Backstage como interfaz, Crossplane como plano de control y Argo CD o Flux como GitOps. Cada uno hace una capa.

Con Flux, que probablemente ya usas, la relación es de suma. Flux reconcilia manifiestos hacia los clusters, pero no te da una API de abstracción de plataforma: no sabe qué es “una base de datos”, solo aplica el YAML que le das. Crossplane te añade justo esa capa de abstracción, y ambos coexisten, con Flux desplegando los recursos compuestos y Crossplane materializándolos. Si ya tienes Flux, el valor de Crossplane es precisamente esa capa de API de autoservicio, a cambio del coste de operar el plano de control que te describí arriba.

Con KubeVela y Score, el tema del siguiente artículo, la frontera es de capa: Crossplane responde “dame una Postgres”, desde la infraestructura; KubeVela y Score responden “despliega mi aplicación”, desde el workload. No compiten, se apilan.

Para tu factoría de inferencia soberana

La decisión práctica se te reduce a esto. Crossplane tiene sentido cuando quieres exponer una API de autoservicio propia sobre tu infraestructura on-premise y estás dispuesto a operar un plano de control para conseguirlo. Si tu plataforma la usan dos equipos que se conocen y aprovisionas con un repositorio de Flux ordenado, Crossplane es coste sin retorno todavía. El disparador es la escala: cuando el aprovisionamiento manual se te convierte en un cuello de botella de tickets, la API declarativa empieza a pagarte su coste.

Tu ruta de entrada sensata no es reescribir todo. Es empezar por un provider que ya te sirva (provider-kubernetes y provider-helm cubren mucho), envolver tu Terraform existente con el provider correspondiente en vez de tirarlo, y modelar una sola abstracción de valor claro, probablemente el InferenceEndpoint que comentamos, como camino dorado. A partir de ahí, creces por demanda. Y siempre con la cuenta clara de que has cambiado la red de seguridad del plan y un puñado de scripts por un termostato que tienes que mantener encendido.

El siguiente artículo sube la capa, del recurso de infraestructura al workload de la aplicación, con KubeVela y Score, que es donde por fin aparece la CLI amable que Crossplane deliberadamente no te da.

Ver también

De la nube pública a la privada: el mapa — dónde encaja este plano de control en el conjunto.
KubeVela y Score: autoservicio por CLI — la capa de aplicación, la CLI que Crossplane no ofrece.
Backstage como portal de autoservicio — la interfaz que se monta encima del plano de control.
GitOps del stack de inferencia con Flux — el motor con el que Crossplane convive, no compite.
KServe y el protocolo abierto de inferencia — lo que el camino dorado de inferencia materializaría por debajo.

Fuentes

CNCF, Announces Graduation of Crossplane (6-nov-2025) — https://www.cncf.io/announcements/2025/11/06/cloud-native-computing-foundation-announces-graduation-of-crossplane/
Crossplane Blog, Announcing Crossplane’s CNCF Graduation — https://blog.crossplane.io/crossplane-cncf-graduation/
Crossplane Blog, Announcing Crossplane 2.0 — https://blog.crossplane.io/announcing-crossplane-2-0/
Crossplane Docs, What’s New in v2 — https://docs.crossplane.io/latest/whats-new/
Crossplane Docs, Compositions — https://docs.crossplane.io/latest/composition/compositions/
Crossplane Docs, Release Cycle — https://docs.crossplane.io/latest/learn/release-cycle/
Crossplane Docs, Crossplane CLI — https://docs.crossplane.io/latest/cli/
Upbound, Crossplane Graduates From CNCF, Upbound Redefines AI-Native Infrastructure — https://www.upbound.io/blog/crossplane-graduates-from-cncf-upbound-redefines-ai-native-infrastructure
InfoQ, Crossplane Reaches Production Maturity by Graduating CNCF — https://www.infoq.com/news/2025/11/crossplane-grad/
Pulumi Docs, Pulumi vs. Crossplane — https://www.pulumi.com/docs/iac/comparisons/crossplane/
Upbound Marketplace, provider-terraform — https://marketplace.upbound.io/providers/upbound/provider-terraform/latest
GitHub, provider-kubernetes — https://github.com/crossplane-contrib/provider-kubernetes
GitHub, provider-helm — https://github.com/crossplane-contrib/provider-helm
GitHub, provider-keycloak — https://github.com/crossplane-contrib/provider-keycloak
VSHN, provider-minio — https://github.com/vshn/provider-minio
Masterpoint, Crossplane: Why it Didn’t Work for Us — https://masterpoint.io/blog/passing-on-crossplane/
CECG, Crossplane: the good, the bad and the ugly — https://www.cecg.io/blog/crossplane-the-good-the-bad-the-ugly
Taloflow, Backstage vs Crossplane for Platform Engineering — https://www.taloflow.ai/guides/comparisons/backstage-vs-crossplane-platform-engineering
Crossplane Blog, Building Modelplane on Crossplane — https://blog.crossplane.io/building-modelplane/
Modelplane — https://modelplane.ai · https://github.com/modelplaneai/modelplane
KServe Docs, Understanding LLMInferenceService — https://kserve.github.io/website/docs/model-serving/generative-inference/llmisvc/llmisvc-overview

Terraform on lo0 — Blog Técnico