Skip to content

Crossplane IaC Subject Area View

Key Points

  1. This is a Declarative Approach that builds on how Kubernetes works.
  2. Think Building 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.

Details of this picture follow the picture

The following text was provided by Google Gemini 2.0. The pictures were drawn by Gary Zeien. The output was reviewed.

Please provide an explanation of this picture that includes details on the key objects in the picture, the relationships, and a summary of the key points being covered in this picture.

This diagram illustrates the architecture and core concepts of Crossplane, an open-source Kubernetes add-on that extends Kubernetes to manage external infrastructure and services. It essentially turns your Kubernetes cluster into a universal control plane for managing anything, not just containerized applications.

Key Objects:

  • Kubernetes Cluster: The underlying Kubernetes cluster where Crossplane is installed.
  • Kubernetes API: The API server of the Kubernetes cluster, which Crossplane interacts with.
  • KubeCli: The Kubernetes command-line interface used to interact with the Kubernetes API.
  • Control Plane: The core components of Kubernetes that manage the cluster.
  • Crossplane (the "engine"): The core of Crossplane, responsible for reconciling the desired state of external resources with their actual state.
  • Provider: Represents a specific cloud provider (AWS, GCP, Azure, etc.) or other external system that Crossplane can manage.
  • ProviderConfig: Credentials and configuration required to connect to a specific provider account (e.g., AWS account credentials).
  • Service Provider API: The API exposed by the cloud provider or external system.
  • Managed Resource (MR): Represents an instance of an external resource (e.g., an AWS S3 bucket, a GCP Cloud SQL instance).
  • Custom Resource Definition (CRD): Extends the Kubernetes API to define new resource types for Managed Resources.
  • Controller: A Kubernetes controller that watches for changes to CRDs and manages the lifecycle of Managed Resources.
  • "Kind": A Kubernetes concept referring to the type of a resource (e.g., Pod, Service, Deployment). Crossplane uses CRDs to define new "Kinds" for external resources.
  • Composite Resource Definition (XRD): Defines a higher-level, composite resource that can be composed of multiple Managed Resources.
  • Composite Resource (X): An instance of a Composite Resource, representing a complete application or infrastructure stack.
  • Claim (aka Composite Resource Claim) (XRC): A request for a Composite Resource. Users interact with Claims to provision infrastructure.
  • Composition: Defines how a Composite Resource is composed of Managed Resources. This specifies the dependencies and order of operations.
  • Crossplane Package: A distributable unit containing CRDs, XRDs, Compositions, and other resources.
  • Open Container Image (OCI): The packaging format used for Crossplane Packages.
  • Package Repository: A repository where Crossplane Packages are stored and distributed.
  • KBs yaml File: Kubernetes YAML files used to define resources.
  • GitHub Repo: A source code repository (like GitHub) where Crossplane Packages are developed and maintained.
  • OR/CUCD Pipeline: A CI/CD pipeline used to build and publish Crossplane Packages.
  • Solution Blueprint: A pre-defined configuration or template for deploying a specific type of application or infrastructure.

Relationships and Flow:

  1. Crossplane extends Kubernetes: Crossplane installs into a Kubernetes cluster and extends its API using CRDs.
  2. Providers connect to external systems: Providers contain the logic to interact with specific cloud provider APIs.
  3. ProviderConfigs provide credentials: ProviderConfigs store the credentials needed to access provider accounts.
  4. CRDs define Managed Resources: CRDs define the schema and behavior of Managed Resources.
  5. Controllers manage Managed Resources: Controllers watch for changes to MRs and reconcile their state with the external system.
  6. XRDs define Composite Resources: XRDs define higher-level resources composed of multiple MRs.
  7. Compositions define resource relationships: Compositions specify how MRs are combined to form a Composite Resource.
  8. Claims request Composite Resources: Users create Claims to request the provisioning of Composite Resources.
  9. Crossplane Packages distribute configurations: Packages bundle CRDs, XRDs, and Compositions for easy distribution and reuse.
  10. Dependencies and order of execution are controlled: The Composition defines the dependencies between resources and the order in which they should be created or updated.

Key Points:

  • Universal Control Plane: Crossplane allows you to manage any infrastructure or service that has an API, using Kubernetes as the central control plane.
  • Infrastructure as Code: Infrastructure is defined as declarative YAML configurations, enabling version control and automation.
  • Abstraction and Portability: Crossplane abstracts away the underlying infrastructure details, allowing you to deploy applications across different cloud providers without rewriting your code.
  • Composition and Reusability: Composite Resources and Compositions enable you to create reusable infrastructure blueprints.
  • Extensibility: Crossplane is extensible through Providers and Packages, allowing you to manage a wide range of external systems.

In essence, Crossplane allows you to use Kubernetes principles (declarative configuration, reconciliation loops, controllers) to manage your entire infrastructure, not just containerized applications. This simplifies infrastructure management, improves automation, and enables greater portability across different environments.

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: January 15, 2025
Back to top