What’s New in v2?

Crossplane v2 makes Crossplane more useful, more intuitive, and less opinionated.

Crossplane v2 makes three major changes:

• Composite resources are now namespaced
• Managed resources are now namespaced
• Composition supports any Kubernetes resource

Crossplane v2 is better suited to building control planes for applications, not just infrastructure. It removes the need for awkward abstractions like claims and provider-kubernetes Objects.

flowchart LR
  user(User)

  subgraph ns [my-namespace]
    direction LR
    xr("App (XR)")
  	dply("Deployment")
    svc("Service")
    rds("RDSInstance (MR)")
  end

  user --create-->xr
  xr compose-dply@--compose--> dply
  xr compose-svc@--compose--> svc
  xr compose-rds@--compose--> rds
compose-dply@{animate: true}

compose-dply@{animate: true}
compose-svc@{animate: true}
compose-rds@{animate: true}

Namespaced composite resources

Crossplane v2 makes composite resources (XRs) namespaced by default.

A namespaced XR can compose any resource (not just Crossplane resources) in its namespace.

A namespaced XR looks like this:

 1apiVersion: example.crossplane.io/v1
 2kind: App
 3metadata:
 4  namespace: default
 5  name: my-app
 6spec:
 7  image: nginx
 8  crossplane:
 9    compositionRef:
10      name: app-kcl
11    compositionRevisionRef:
12      name: app-kcl-41b6efe
13    resourceRefs:
14    - apiVersion: apps/v1
15      kind: Deployment
16      name: my-app-9bj8j
17    - apiVersion: v1
18      kind: Service
19      name: my-app-bflc4

Composite resource definitions (XRDs) now have a scope field. The scope field defaults to Namespaced in the new v2alpha1 version of the XRD API.

 1apiVersion: apiextensions.crossplane.io/v2alpha1
 2kind: CompositeResourceDefinition
 3metadata:
 4  name: apps.example.crossplane.io
 5spec:
 6  scope: Namespaced
 7  group: example.crossplane.io
 8  names:
 9    kind: App
10    plural: apps
11  versions:
12  - name: v1
13  # Removed for brevity

You can also set the scope field to Cluster to create a cluster scoped XR. A cluster scoped XR can compose any cluster scoped resource. A cluster scoped XR can also compose any namespaced resource in any namespace.

With namespaced XRs there’s no longer a need for claims. The new namespaced and cluster scoped XRs in Crossplane v2 don’t support claims.

Namespaced managed resources

Crossplane v2 makes all managed resources (MRs) namespaced.

This enables a namespaced XR to by composed entirely of namespaced resources - whether they’re a Crossplane MR like an RDSInstance, a Kubernetes resource like a Deployment, or a third party custom resource like a Cluster API Cluster.

A namespaced MR looks like this:

1apiVersion: s3.aws.m.upbound.io/v1beta1
2kind: Bucket
3metadata:
4  namespace: default
5  generateName: my-bucket
6spec:
7  forProvider:
8    region: us-east-2

Namespaced MRs work great with or without composition. Crossplane v2 isn’t opinionated about using composition and MRs together. Namespaces enable fine grained access control over who can create what MRs.

Compose any resource

Crossplane v2 isn’t opinionated about using composition together with managed resources.

You can create a composite resource (XR) that composes any resource, whether it’s a Crossplane MR like an RDSInstance, a Kubernetes resource like a Deployment, or a third party custom resource like a CloudNativePG PostgreSQL Cluster.

flowchart LR
  user(User)

  subgraph ns [my-namespace]
    direction LR
    xr("App (XR)")
  	dply("Deployment")
    svc("Service")
    pg("CloudNativePG Cluster")
  end

  user --create-->xr
  xr compose-dply@--compose--> dply
  xr compose-svc@--compose--> svc
  xr compose-pg@--compose--> pg
compose-dply@{animate: true}

compose-dply@{animate: true}
compose-svc@{animate: true}
compose-pg@{animate: true}

This opens composition to exciting new use cases - for example building custom app models with Crossplane.

Backward compatibility

Crossplane v2 makes the following breaking changes:

• It removes native patch and transform composition.
• It removes the ControllerConfig type.
• It removes support for external secret stores.

Crossplane deprecated native patch and transform composition in Crossplane v1.17. It’s replaced by composition functions.

Crossplane deprecated the ControllerConfig type in v1.11. It’s replaced by the DeploymentRuntimeConfig type.

Crossplane added external secret stores in v1.7. External secret stores have remained in alpha for over two years and are now unmaintained.

Crossplane v2 supports legacy v1-style XRs and MRs. Most users will be able to upgrade from v1.x to Crossplane v2 without breaking changes.

Existing Compositions will require minor updates to work with Crossplane v2 style XRs. A migration guide will be available closer to the final release of Crossplane v2.