Add "What's new in v2.0?" page

This page is targeted at folks who're already familiar with v1.x and
just want to know what's new.

Signed-off-by: Nic Cope <nicc@rk0n.org>
This commit is contained in:
Nic Cope 2025-03-28 17:29:15 -07:00
parent 7a596b46dd
commit aac9cda786
4 changed files with 249 additions and 1 deletions

View File

@ -15,6 +15,9 @@ Crossplane organizes its documentation into the following sections:
* [What's Crossplane?]({{<ref "whats-crossplane">}}) introduces Crossplane
and explains why you should use it.
* [What's New in v2?]({{<ref "whats-new">}}) highlights what's changed in
Crossplane v2.
* [Get Started]({{<ref "get-started">}}) explains how to install Crossplane and
create a control plane.

View File

@ -1,6 +1,6 @@
---
title: Get Started
weight: 4
weight: 40
description: Get started with Crossplane.
---

View File

@ -36,6 +36,15 @@ This guide requires:
* An AWS account with permissions to create an S3 storage bucket
* AWS [access keys](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-creds)
{{<hint "note">}}
Only AWS managed resources support the Crossplane v2 preview.
<!-- vale gitlab.FutureTense = NO -->
Maintainers will update the managed resources for other systems including Azure,
GCP, Terraform, Helm, GitHub, etc to support Crossplane v2 soon.
<!-- vale gitlab.FutureTense = YES -->
{{</hint>}}
## Install support for the managed resource
Follow these steps to install support for the `Bucket` managed resource:

View File

@ -0,0 +1,236 @@
---
title: What's New in v2?
weight: 4
description: Learn what's new in the Crossplane v2 preview
---
**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**
Despite these major changes, Crossplane v2 is backward compatible with
Crossplane v1.
```mermaid
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}
```
**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.
{{<hint "tip">}}
Most users can upgrade to Crossplane v2 without breaking changes.
{{</hint>}}
{{<hint "note">}}
This page assumes you're familiar with Crossplane. New to Crossplane? Read
[What's Crossplane]({{<ref "whats-crossplane">}}) instead.
{{</hint>}}
## Namespaced composite resources
Crossplane v2 makes composite resources (XRs) namespaced by default.
A namespaced XR can any resource ([not just Crossplane resources](#compose-any-resource))
in its namespace.
A namespaced XR looks like this:
```yaml
apiVersion: example.crossplane.io/v1
kind: App
metadata:
namespace: default
name: my-app
spec:
image: nginx
crossplane:
compositionRef:
name: app-kcl
compositionRevisionRef:
name: app-kcl-41b6efe
resourceRefs:
- apiVersion: apps/v1
kind: Deployment
name: my-app-9bj8j
- apiVersion: v1
kind: Service
name: my-app-bflc4
```
{{<hint "note">}}
Crossplane v2 moves all an XR's "Crossplane machinery" under `spec.crossplane`.
This makes it easier for users to tell which fields are important to them, and
which are just "Crossplane stuff" they can ignore.
{{</hint>}}
Composite resource definitions (XRDs) now have a `scope` field. The `scope`
field defaults to `Namespaced` in the new v2alpha1 version of the XRD API.
```yaml
apiVersion: apiextensions.crossplane.io/v2alpha1
kind: CompositeResourceDefinition
metadata:
name: apps.example.crossplane.io
spec:
scope: Namespaced
group: example.crossplane.io
names:
kind: App
plural: apps
versions:
- name: v1
# 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.**
{{<hint "tip">}}
Crossplane v2 is backward compatible with v1-style XRs.
When you use v1 of the XRD API `scope` defaults to a special `LegacyCluster`
mode. `LegacyCluster` XRs support claims and don't use `spec.crossplane`.
{{</hint>}}
## Namespaced managed resources
Crossplane v2 makes all managed resources (MRs) namespaced.
This enables a namespaced XR to compose 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](https://cluster-api.sigs.k8s.io) `Cluster`.
A namespaced MR looks like this:
```yaml
apiVersion: s3.aws.m.upbound.io/v1beta1
kind: Bucket
metadata:
namespace: default
generateName: my-bucket
spec:
forProvider:
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.
{{<hint "note">}}
During the Crossplane v2 preview only namespaced AWS managed resources are
available.
<!-- vale gitlab.FutureTense = NO -->
Maintainers will update the managed resources for other systems including Azure,
GCP, Terraform, Helm, GitHub, etc to support namespaced MRs soon.
<!-- vale gitlab.FutureTense = YES -->
{{</hint>}}
{{<hint "tip">}}
Crossplane v2 is backward compatible with v1-style cluster scoped MRs.
<!-- vale gitlab.FutureTense = NO -->
New provider releases will support both namespaced and cluster scoped MRs.
Crossplane v2 considers cluster scoped MRs a legacy feature. Crossplane will
deprecate and remove cluster scoped MRs at a future date.
<!-- vale gitlab.FutureTense = YES -->
{{</hint>}}
## 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](https://cloudnative-pg.io) PostgreSQL `Cluster`.
```mermaid
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.
{{<hint "important">}}
As long as you're not using these deprecated or alpha features, Crossplane v2 is
backward compatible with Crossplane v1.x.
{{</hint>}}
<!-- vale gitlab.FutureTense = NO -->
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.
<!-- vale gitlab.FutureTense = YES -->