Skip to content

Crossplane IaC Subject Area View

Key Points

  1. This is a Declarative Approach that builds on how Kubernetes works.
  2. Think Build Blocks !! and Bill Of Materials
  3. All Services required to fulfill the Bill Of Materials must be accessible via APIs AND a Crossplane Provider needs to be created to access those services. For Example:
    1. If, as resources are provisioned they need to be registered in a corporate CMDB
    2. the IP addresses need to be pulled from an IPAM ( IP Address Management ) service
    3. key APIs for an app need to be registered in an API Gateway service
    4. an audit log service
  4. Note that because this is a following a Declarative solution, the calls to providers not only includes the creation, it will also include all updates AND deletions from those services IF the service provides the API.
  5. Existing declarative specifications ( e.g. Helm Charts ) can be leveraged in this approach.
  6. Creating Crossplane XRDs requires a good understanding of the provider you are working with AND K8S CRDs.
  7. ALL Resources created via Crossplane ( e.g. Compositions, CompositeResourceDefinitions, ManagedResourceDefinitions... ) are registered in the Kubernetes EtcD service running in the context of the K8S cluster that is serving as the Control Plane. THUS... it becomes a "CDMB" that has a information on ALL resources provisioned and active.

Connecting the dots from a usage standpoint

Thanks to Georgios Anastasiou ( Georgios.Anastasiou@kyndryl.com ) for the picture below.

The following are some of the links I used to build out my understanding.

Last update: November 3, 2024
Back to top