Crossplane convierte la infraestructura en un plano de control, y ese es el argumento entero

La afirmación interesante sobre Crossplane no es que gestione infraestructura desde Kubernetes. Es que cambia el modelo de ejecución.

Un pipeline aplica un estado deseado cuando alguien lo ejecuta. Entre ejecuciones, la realidad puede divergir y nada se entera hasta el siguiente plan, que es por lo que la detección de deriva es un trabajo programado que tienes que acordarte de construir. Un controlador ejecuta un bucle de reconciliación: compara lo deseado con lo real de forma continua y corrige la diferencia. A quien cambie un grupo de seguridad por consola se le revierte dentro del intervalo de reconciliación.

Es una diferencia real de comportamiento, y si compensa o no depende de qué estés intentando construir.

Las dos cosas que ofrece de verdad

Reconciliación continua. La deriva se corrige en vez de reportarse. Para un entorno donde los cambios por consola durante incidentes son un problema recurrente, esta es la funcionalidad.

Composición, que es la mitad más interesante. Defines un recurso personalizado que representa algo que tu organización ofrece, como una base de datos o un entorno, y una composición que lo expande en los recursos de nube subyacentes. Los equipos de aplicación piden entonces la abstracción sin saber ni preocuparse por en qué se expande.

Esa segunda parte es lo que convierte esto en ingeniería de plataforma y no en un Terraform alternativo. La abstracción es una API de Kubernetes de verdad, así que tiene esquema, validación, condiciones de estado y control de acceso, y los equipos la consumen con las herramientas que ya usan. Una petición autoservida de base de datos pasa a ser un manifiesto en el repositorio de un equipo, reconciliado por la plataforma.

Dónde encaja y dónde no

Encaja cuando estás construyendo una plataforma interna con una superficie de autoservicio para varios equipos, cuando ya ejecutas Kubernetes como sustrato operativo principal, cuando la deriva por cambios manuales es un problema real y recurrente, y cuando quieres que la abstracción sea una API en vez de un módulo que la gente copia.

No encaja cuando tienes un equipo gestionando un entorno, donde un pipeline es más simple y está mejor entendido. Cuando tu infraestructura es sobre todo fundacional y cambia poco, porque la reconciliación resuelve un problema que no tienes. Cuando necesitas un servicio o una propiedad que el proveedor todavía no cubre, que es una restricción real. O cuando nadie puede ser dueño de otro plano de control.

La comparación honesta no es Crossplane contra Terraform, es Crossplane contra Terraform más GitOps. Un pipeline disparado por una fusión, con una comprobación de deriva programada, te lleva casi hasta el final, y los patrones de Argo CD en producción ya te dan reconciliación para todo lo que corre en el clúster.

Lo que asumes

Otro plano de control, en el camino crítico. Lo que gestiona tu infraestructura corre ahora dentro de la infraestructura que gestiona. Piensa bien el problema de arranque: cómo creas el clúster que ejecuta Crossplane, y qué pasa si se pierde ese clúster. La respuesta común es un clúster de gestión pequeño, separado y bien protegido, que es otra cosa que operar.

La madurez de los proveedores varía bastante. La cobertura de los recursos comunes es buena. La de servicios nuevos, funciones en vista previa y propiedades poco frecuentes es más irregular que la del proveedor equivalente de Terraform, que tiene años más de superficie acumulada. Comprueba los recursos concretos que necesitas antes de comprometerte, no el titular de soporte.

Depurar es más difícil. Cuando falla un pipeline lees la salida. Cuando falla un controlador estás leyendo condiciones de estado en recursos anidados, averiguando qué recurso gestionado no está listo y por qué, y correlacionando con los registros del controlador. Es otra habilidad y el bucle de realimentación es más lento.

La composición es potente y puede volverse ilegible. Una composición que parchea valores entre recursos a través de transformaciones es genuinamente difícil de seguir. El enfoque más reciente de funciones de composición mejora esto al permitir escribir lógica como corresponde, lo cual es mejor y añade otro componente. Mantén las composiciones aburridas por la misma razón por la que mantienes aburridos los módulos, como se argumenta en el diseño de módulos.

No hay plan. Esta es la pérdida que más se nota. No obtienes una descripción revisable de lo que va a cambiar antes de que cambie, lo que elimina el artefacto que hace de leer un plan de Terraform la red de seguridad que es. Obtienes una diferencia de un manifiesto y después un controlador que actúa. Para recursos con radio de impacto alto eso es una regresión real, y es la razón de que las políticas de borrado importen enormemente aquí.

Reglas prácticas si lo adoptas

Fija la política de borrado a conciencia en todo. Un recurso personalizado borrado por accidente puede borrar la base de datos que representa. Deja huérfano en vez de borrar todo lo que tenga estado, con el mismo instinto que la discusión sobre la política de recuperación en cargas con estado en Kubernetes.

Mantén el clúster de gestión pequeño, separado y aburrido. No debería ejecutar cargas de aplicación.

Divide el entorno. La infraestructura fundacional y de movimiento lento, como redes, cuentas y el propio clúster de gestión, se queda en Terraform, donde existen el plan y la revisión. La infraestructura pegada a las aplicaciones y pedida con frecuencia, como bases de datos, cubos y colas, se mueve a composiciones, donde el autoservicio es el objetivo. Las adopciones exitosas que hemos visto son híbridas, no sustituciones.

Versiona las composiciones y trata un cambio de composición como un cambio a todas las peticiones que la usan, porque lo es. Despliégalo primero contra una petición de no producción.

Vigila los controladores. Un bucle de reconciliación que se ha detenido es silencioso, y el silencio se parece exactamente a que todo va bien, que es la misma trampa que se describe en alertas que la gente atiende.

Lo que se olvida

• Las credenciales de todo el entorno viven en un clúster. Ese clúster es ahora una de las cosas más sensibles que ejecutas, y el manejo de secretos de un Secret de Kubernetes es base64 aplica con fuerza.
• La reconciliación cuesta llamadas a la API. Un entorno grande con un intervalo corto genera tráfico constante hacia las APIs de la nube y puede topar con límites de frecuencia.
• Importar recursos existentes es posible y engorroso. Planifica el camino de migración antes de necesitarlo.
• Los cambios de composición se propagan de inmediato. No hay despliegue escalonado salvo que lo construyas.
• El estado no siempre es fiable. Un recurso que se reporta listo puede haberse creado con una propiedad que no pretendías, porque el proveedor ignoró en silencio un campo no soportado.

Qué hacer esta semana

Antes de evaluar la herramienta, mide el problema. Ejecuta un plan contra cada espacio de trabajo de producción y cuenta los recursos que difieren del código. Si la respuesta es cero, la deriva no es tu problema y la reconciliación continua está resolviendo algo que no tienes. Si es una lista larga, has encontrado el argumento, y una comprobación de deriva programada podría seguir siendo el arreglo más barato. Hacemos esa medición en la fase de plataforma de un proyecto cloud.