Crossplane

Este material aún está en desarrollo

Antes de comenzar a entender, si has llegado de improviso, Crossplane es una herramienta IaC desarrollada para Kubernetes. Declaramos lo que queremos a través de manifiestos yaml para Kubernetes y Crossplane con sus respectivos Providers trabajarán para transformar el estado deseado en estado real. A diferencia de Terraform que posee un statefile para guardar lo que fue provisionado, Crossplane guarda toda la información dentro del propio ETCD de Kubernetes, la base de datos de objetos de Kubernetes.

No tiene sentido aprender Crossplane si no entiendes Kubernetes. Si crees que podrás hacerlo, lamento decir que no será posible, tal vez has llegado aquí demasiado pronto. ¡Vuelve más tarde!

Crossplane es una herramienta open-source que está creciendo rápidamente. Su propuesta es extender la API de Kubernetes para crear nuevos control planes para gestionar el ciclo de vida de recursos de cualquier tipo, transformando Kubernetes en un controlador universal. Te permite gestionar cualquier cosa, en cualquier lugar, todo a través de APIs estándar de Kubernetes.

Es el poder que le falta a tu IDP, puedes estar seguro.

Los planos de control verifican constantemente si los recursos deseados existen, reportan cuando el estado deseado no corresponde a la realidad y actúan para corregir las diferencias. Este es un principio fundamental del enfoque declarativo de Kubernetes que Crossplane extiende para recursos externos.

Con Crossplane, los equipos de plataforma pueden crear nuevas abstracciones y APIs personalizadas con todo el poder de las políticas, namespaces y controles de acceso basados en roles de Kubernetes. Crossplane permite que ingenieros de plataforma creen APIs y abstracciones personalizadas combinando recursos nativos de Kubernetes y recursos de nube bajo un único plano de control.

Estamos aprovechando que la API de Kubernetes es extensible y haciéndola universal.

Github Crossplane

¿Cómo actúa Crossplane?

A través de Custom Resources Definitions en Kubernetes, se crean recursos externos a Kubernetes como objetos nativos de Kubernetes. De esta forma, es posible usar el comando kubectl create y kubectl describe para esos objetos. Para ellos, Crossplane será el controlador y forzará una imposición del estado de ese recurso.

Para tener una idea, es una especie de Terraform aplicado por Kubernetes, pero con importantes diferencias:

En realidad es mucho más que eso, pues podemos crear abstracciones para cualquier cosa. Pasando de consumidor de APIs a proveedores de API.

• Crossplane es nativo de Kubernetes y utiliza su API extensible
• La gestión del estado se realiza directamente en el ETCD del clúster
• Posibilita abstracciones más avanzadas a través de las Compositions

Los usuarios solamente se comunican con Kubernetes definiendo recursos utilizando manifiestos, y Crossplane será el controlador comunicándose con los recursos externos para entregar lo que fue pedido. La idea es empaquetar todo lo que el usuario desea hacer creando un Custom Resource para eso y por debajo realizar todas las operaciones necesarias.

Con APIs personalizadas, los usuarios no necesitan saber detalles sobre los recursos o requisitos subyacentes, solo los detalles expuestos por la plataforma.

Conceptos Iniciales

Crossplane usa varios componentes principales para gestionar los diversos elementos de creación y gestión de recursos externos a través de Kubernetes:

• Los pods Crossplane incluyen el pod Crossplane principal y el pod gestor Crossplane RBAC. Juntos, estos pods gestionan todos los componentes y recursos de Crossplane.

• Los providers conectan Kubernetes a cualquier proveedor externo, como AWS, Azure o GCP, de forma similar a lo que hace Terraform. Los providers traducen manifiestos nativos de Kubernetes y llamadas de API en llamadas de API externas. Los providers son responsables de crear, eliminar y gestionar el ciclo de vida de sus recursos, siendo nuestro punto de conexión con sistemas externos.

• Managed resources son objetos de Kubernetes que representan recursos que el Provider creó fuera de Kubernetes. Crear un recurso gestionado en Kubernetes requiere que un Provider cree un recurso correspondiente en el sistema externo. Eliminar un recurso gestionado requiere que un Provider elimine el recurso externo asociado.

• Compositions son plantillas de recursos gestionados. Compositions describen despliegues más complejos, combinando múltiples recursos gestionados y cualquier personalización necesaria. No pienses en esto solamente como recurso en cloud, piensa más grande. A veces, para crear una composition, podemos utilizar varios recursos gestionados diferentes que utilizan providers diferentes. Lo importante es entregar a nuestro usuario lo que quiere a través de una petición simple, ocultando la complejidad.

• Composite Resource Definitions representan una API personalizada, creada por ingenieros de plataforma y consumida por desarrolladores o usuarios finales. Composite resource definitions usan un esquema OpenAPIv3 para extender aún más Kubernetes con endpoints de API personalizados, revisiones y mucho más.

  • Composite Resources representan todos los objetos creados por un usuario llamando a la API personalizada. Cada vez que un usuario accede a la API personalizada, Crossplane crea un único Composite Resource y vincula todos los recursos gestionados relacionados a él.

  • Si te has fijado bien, en lo que tenemos que concentrarnos realmente para dominar Crossplane de verdad son las composiciones.

• Claims son como Composite Resources, pero a nivel de namespace.

• EnvironmentConfigs: son como el Kubernetes ConfigMap. Son útiles para mapeo de recursos personalizados o para almacenar y recuperar datos en Claims y Composite Resources.

• Usages definen recursos críticos o mapeos de dependencia personalizados. Pueden impedir que Crossplane elimine o pueden garantizar que un recurso padre espere a que Crossplane elimine todos los recursos hijos primero. Sería como el depends_on de Terraform.

Aún tenemos los conceptos de Package e ImageConfigs que serán abordados en detalle posteriormente.

Mantenedores

Upbound es la empresa detrás del desarrollo de Crossplane. Tiene un papel fundamental en el ecosistema Crossplane de varias maneras:

• Mantenedora Principal liderando el desarrollo del core de Crossplane y contribuye con la mayor parte del código.
• Ofrece Upbound Cloud, una plataforma gestionada para Crossplane.
• Desarrolla y mantiene algunos providers oficiales.
• Responsable del Upbound Marketplace para distribución de los providers.
• Mantiene la documentación oficial.
• Coordina la comunidad de desarrolladores.

Aunque Upbound sea la empresa principal detrás de Crossplane, el proyecto es open source y forma parte de la Cloud Native Computing Foundation (CNCF), permitiendo contribuciones de la comunidad global.