mirror of https://github.com/crossplane/docs.git
Merge pull request #959 from negz/plus-one
Update content/master to use v2 stable instead of preview
This commit is contained in:
Nic Cope
GitHub
commit
ad7f75a96d
|
|
@ -27,7 +27,7 @@ To download the latest version for your CPU architecture with the Crossplane
|
|||
install script.
|
||||
|
||||
```shell
|
||||
curl -sL "https://raw.githubusercontent.com/crossplane/crossplane/main/install.sh" | XP_CHANNEL=preview sh
|
||||
curl -sL "https://raw.githubusercontent.com/crossplane/crossplane/main/install.sh" | sh
|
||||
```
|
||||
|
||||
[The script](https://raw.githubusercontent.com/crossplane/crossplane/main/install.sh)
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ weight: 20
|
|||
description: "Composite Resource Definitions or XRDs define custom API schemas"
|
||||
---
|
||||
|
||||
Composite resource definitions (`XRDs`) define the schema for a custom API.
|
||||
Composite resource definitions (`XRDs`) define the schema for a custom API.
|
||||
Users create composite resources (`XRs`) using the API schema defined by an
|
||||
XRD.
|
||||
|
||||
|
|
@ -20,15 +20,15 @@ A [composite resource]({{<ref "./composite-resources">}}) or XR is a custom API.
|
|||
|
||||
You use two Crossplane types to create a new custom API:
|
||||
|
||||
* A Composite Resource Definition (XRD) - This page. Defines the XR's schema.
|
||||
* A Composite Resource Definition (XRD) - This page. Defines the XR's schema.
|
||||
* A [Composition]({{<ref "./compositions" >}}) - Configures how the XR creates
|
||||
other resources.
|
||||
{{</expand >}}
|
||||
|
||||
Crossplane XRDs are like
|
||||
[Kubernetes custom resource definitions](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
|
||||
Crossplane XRDs are like
|
||||
[Kubernetes custom resource definitions](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
|
||||
XRDs require fewer fields and add options related to Crossplane, like connection
|
||||
secrets.
|
||||
secrets.
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
|
|
@ -40,24 +40,26 @@ Creating a CompositeResourceDefinition consists of:
|
|||
* [Defining a custom API group](#xrd-groups).
|
||||
* [Defining a custom API name](#xrd-names).
|
||||
* [Defining a custom API schema and version](#xrd-versions).
|
||||
|
||||
* [Setting the scope](#xrd-scope) (namespaced or cluster-scoped).
|
||||
|
||||
Optionally, CompositeResourceDefinitions also support:
|
||||
* [Setting composite resource defaults](#set-composite-resource-defaults).
|
||||
|
||||
Composite resource definitions (`XRDs`) create new API endpoints inside a
|
||||
Kubernetes cluster.
|
||||
|
||||
Creating a new API requires defining an API
|
||||
{{<hover label="xrd1" line="6">}}group{{</hover>}},
|
||||
{{<hover label="xrd1" line="7">}}name{{</hover>}} and
|
||||
{{<hover label="xrd1" line="10">}}version{{</hover>}}.
|
||||
Composite resource definitions (`XRDs`) create new API endpoints inside a
|
||||
Kubernetes cluster.
|
||||
|
||||
Creating a new API requires defining an API
|
||||
{{<hover label="xrd1" line="7">}}group{{</hover>}},
|
||||
{{<hover label="xrd1" line="8">}}name{{</hover>}} and
|
||||
{{<hover label="xrd1" line="11">}}version{{</hover>}}.
|
||||
|
||||
```yaml {label="xrd1",copy-lines="none"}
|
||||
apiVersion: apiextensions.crossplane.io/v1
|
||||
apiVersion: apiextensions.crossplane.io/v2
|
||||
kind: CompositeResourceDefinition
|
||||
metadata:
|
||||
metadata:
|
||||
name: mydatabases.example.org
|
||||
spec:
|
||||
scope: Namespaced
|
||||
group: example.org
|
||||
names:
|
||||
kind: XMyDatabase
|
||||
|
|
@ -70,10 +72,10 @@ spec:
|
|||
After applying an XRD, Crossplane creates a new Kubernetes custom resource
|
||||
definition matching the defined API.
|
||||
|
||||
For example, the XRD
|
||||
{{<hover label="xrd1" line="4">}}mydatabases.example.org{{</hover >}}
|
||||
creates a custom resource definition
|
||||
{{<hover label="kubeapi" line="2">}}mydatabases.example.org{{</hover >}}.
|
||||
For example, the XRD
|
||||
{{<hover label="xrd1" line="4">}}mydatabases.example.org{{</hover >}}
|
||||
creates a custom resource definition
|
||||
{{<hover label="kubeapi" line="2">}}mydatabases.example.org{{</hover >}}.
|
||||
|
||||
```shell {label="kubeapi",copy-lines="3"}
|
||||
kubectl api-resources
|
||||
|
|
@ -85,9 +87,9 @@ mydatabases.example.org v1alpha1 true
|
|||
{{<hint "warning">}}
|
||||
You can't change the XRD
|
||||
{{<hover label="xrd1" line="6">}}group{{</hover>}} or
|
||||
{{<hover label="xrd1" line="7">}}names{{</hover>}}.
|
||||
{{<hover label="xrd1" line="7">}}names{{</hover>}}.
|
||||
You must delete and
|
||||
recreate the XRD to change the
|
||||
recreate the XRD to change the
|
||||
{{<hover label="xrd1" line="6">}}group{{</hover>}} or
|
||||
{{<hover label="xrd1" line="7">}}names{{</hover>}}.
|
||||
{{</hint >}}
|
||||
|
|
@ -102,9 +104,9 @@ Groups define a collection of related API endpoints. The `group` can be any
|
|||
value, but common convention is to map to a fully qualified domain name.
|
||||
|
||||
<!-- vale write-good.Weasel = NO -->
|
||||
Many XRDs may use the same `group` to create a logical collection of APIs.
|
||||
Many XRDs may use the same `group` to create a logical collection of APIs.
|
||||
<!-- vale write-good.Weasel = YES -->
|
||||
For example a `database` group may have a `relational` and `nosql` kinds.
|
||||
For example a `database` group may have a `relational` and `nosql` kinds.
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
|
|
@ -112,33 +114,33 @@ For example a `database` group may have a `relational` and `nosql` kinds.
|
|||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
The `names` field defines how to refer to this specific XRD.
|
||||
The required name fields are:
|
||||
The `names` field defines how to refer to this specific XRD.
|
||||
The required name fields are:
|
||||
|
||||
* `kind` - the `kind` value to use when calling this API. The kind is
|
||||
[UpperCamelCased](https://kubernetes.io/docs/contribute/style/style-guide/#use-upper-camel-case-for-api-objects).
|
||||
Crossplane recommends starting XRD `kinds` with an `X` to show
|
||||
it's a custom Crossplane API definition.
|
||||
Crossplane recommends starting XRD `kinds` with an `X` to show
|
||||
it's a custom Crossplane API definition.
|
||||
* `plural` - the plural name used for the API URL. The plural name must be
|
||||
lowercase.
|
||||
lowercase.
|
||||
|
||||
{{<hint "important" >}}
|
||||
The XRD
|
||||
{{<hover label="xrdName" line="4">}}metadata.name{{</hover>}} must be
|
||||
The XRD
|
||||
{{<hover label="xrdName" line="4">}}metadata.name{{</hover>}} must be
|
||||
{{<hover label="xrdName" line="9">}}plural{{</hover>}} name, `.` (dot character),
|
||||
{{<hover label="xrdName" line="6">}}group{{</hover>}}.
|
||||
|
||||
For example, {{<hover label="xrdName"
|
||||
line="4">}}mydatabases.example.org{{</hover>}} matches the {{<hover
|
||||
label="xrdName" line="9">}}plural{{</hover>}} name
|
||||
{{<hover label="xrdName" line="9">}}mydatabases{{</hover>}}, `.`
|
||||
{{<hover label="xrdName" line="6">}}group{{</hover>}} name,
|
||||
{{<hover label="xrdName" line="9">}}mydatabases{{</hover>}}, `.`
|
||||
{{<hover label="xrdName" line="6">}}group{{</hover>}} name,
|
||||
{{<hover label="xrdName" line="6">}}example.org{{</hover>}}.
|
||||
|
||||
```yaml {label="xrdName",copy-lines="none"}
|
||||
apiVersion: apiextensions.crossplane.io/v1
|
||||
kind: CompositeResourceDefinition
|
||||
metadata:
|
||||
metadata:
|
||||
name: mydatabases.example.org
|
||||
spec:
|
||||
group: example.org
|
||||
|
|
@ -156,21 +158,21 @@ spec:
|
|||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
<!-- vale gitlab.SentenceLength = NO -->
|
||||
The XRD `version` is like the
|
||||
The XRD `version` is like the
|
||||
[API versioning used by Kubernetes](https://kubernetes.io/docs/reference/using-api/#api-versioning).
|
||||
The version shows how mature or stable the API is and increments when changing,
|
||||
adding or removing fields in the API.
|
||||
<!-- vale gitlab.SentenceLength = YES -->
|
||||
|
||||
Crossplane doesn't require specific versions or a specific version naming
|
||||
convention, but following
|
||||
Crossplane doesn't require specific versions or a specific version naming
|
||||
convention, but following
|
||||
[Kubernetes API versioning guidelines](https://kubernetes.io/docs/reference/using-api/#api-versioning)
|
||||
is strongly recommended.
|
||||
is strongly recommended.
|
||||
|
||||
* `v1alpha1` - A new API that may change at any time.
|
||||
* `v1beta1` - An existing API that's considered stable. Breaking changes are
|
||||
strongly discouraged.
|
||||
* `v1` - A stable API that doesn't have breaking changes.
|
||||
* `v1` - A stable API that doesn't have breaking changes.
|
||||
|
||||
#### Define a schema
|
||||
|
||||
|
|
@ -178,24 +180,24 @@ is strongly recommended.
|
|||
<!-- vale write-good.TooWordy = NO -->
|
||||
The `schema` defines the names
|
||||
of the parameters, the data types of the parameters and which parameters are
|
||||
required or optional.
|
||||
required or optional.
|
||||
<!-- vale write-good.Passive = YES -->
|
||||
<!-- vale write-good.TooWordy = YES -->
|
||||
|
||||
{{<hint "note" >}}
|
||||
All `schemas` follow the Kubernetes custom resource definition
|
||||
[OpenAPIv3 structural schema](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema).
|
||||
All `schemas` follow the Kubernetes custom resource definition
|
||||
[OpenAPIv3 structural schema](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema).
|
||||
{{< /hint >}}
|
||||
|
||||
Each
|
||||
{{<hover label="schema" line="11">}}version{{</hover>}} of the API has a unique
|
||||
{{<hover label="schema" line="12">}}schema{{</hover>}}.
|
||||
Each
|
||||
{{<hover label="schema" line="11">}}version{{</hover>}} of the API has a unique
|
||||
{{<hover label="schema" line="12">}}schema{{</hover>}}.
|
||||
|
||||
All XRD {{<hover label="schema" line="12">}}schemas{{</hover>}} validate against
|
||||
the {{<hover label="schema" line="13">}}openAPIV3Schema{{</hover>}}. The schema
|
||||
is an OpenAPI
|
||||
{{<hover label="schema" line="14">}}object{{</hover>}} with the
|
||||
{{<hover label="schema" line="15">}}properties{{</hover>}} of a
|
||||
is an OpenAPI
|
||||
{{<hover label="schema" line="14">}}object{{</hover>}} with the
|
||||
{{<hover label="schema" line="15">}}properties{{</hover>}} of a
|
||||
{{<hover label="schema" line="16">}}spec{{</hover>}}
|
||||
{{<hover label="schema" line="17">}}object{{</hover>}}.
|
||||
|
||||
|
|
@ -229,31 +231,31 @@ spec:
|
|||
# Removed for brevity
|
||||
```
|
||||
|
||||
A composite resource using this API references the
|
||||
{{<hover label="xr" line="1">}}group/version{{</hover>}} and
|
||||
{{<hover label="xr" line="2">}}kind{{</hover>}}. The
|
||||
{{<hover label="xr" line="5">}}spec{{</hover>}} has the
|
||||
{{<hover label="xr" line="6">}}region{{</hover>}} key with a string value.
|
||||
A composite resource using this API references the
|
||||
{{<hover label="xr" line="1">}}group/version{{</hover>}} and
|
||||
{{<hover label="xr" line="2">}}kind{{</hover>}}. The
|
||||
{{<hover label="xr" line="5">}}spec{{</hover>}} has the
|
||||
{{<hover label="xr" line="6">}}region{{</hover>}} key with a string value.
|
||||
|
||||
```yaml {label="xr"}
|
||||
apiVersion: custom-api.example.org/v1alpha1
|
||||
kind: xDatabase
|
||||
metadata:
|
||||
name: my-composite-resource
|
||||
spec:
|
||||
spec:
|
||||
region: "US"
|
||||
```
|
||||
|
||||
|
||||
{{<hint "tip" >}}
|
||||
The custom API defined inside the
|
||||
The custom API defined inside the
|
||||
{{<hover label="schema" line="18">}}spec.properties{{</hover>}} is an OpenAPIv3
|
||||
specification. The
|
||||
[data models page](https://swagger.io/docs/specification/data-models/) of
|
||||
specification. The
|
||||
[data models page](https://swagger.io/docs/specification/data-models/) of
|
||||
the Swagger documentation provides a list of examples using data types and input
|
||||
restrictions.
|
||||
restrictions.
|
||||
|
||||
The Kubernetes documentation lists
|
||||
The Kubernetes documentation lists
|
||||
[the set of special restrictions](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation)
|
||||
on what your OpenAPIv3 custom API can use.
|
||||
{{< /hint >}}
|
||||
|
|
@ -266,13 +268,13 @@ Changing or expanding the XRD schema requires restarting the [Crossplane pod]({{
|
|||
##### Required fields
|
||||
|
||||
By default all fields in a schema are optional. Define a parameter as required
|
||||
with the
|
||||
{{< hover label="required" line="25">}}required{{</hover>}} attribute.
|
||||
with the
|
||||
{{< hover label="required" line="25">}}required{{</hover>}} attribute.
|
||||
|
||||
In this example the XRD requires
|
||||
{{< hover label="required" line="19">}}region{{</hover>}} and
|
||||
In this example the XRD requires
|
||||
{{< hover label="required" line="19">}}region{{</hover>}} and
|
||||
{{< hover label="required" line="21">}}size{{</hover>}} but
|
||||
{{< hover label="required" line="23">}}name{{</hover>}} is optional.
|
||||
{{< hover label="required" line="23">}}name{{</hover>}} is optional.
|
||||
```yaml {label="required",copy-lines="none"}
|
||||
apiVersion: apiextensions.crossplane.io/v1
|
||||
kind: CompositeResourceDefinition
|
||||
|
|
@ -293,13 +295,13 @@ spec:
|
|||
type: object
|
||||
properties:
|
||||
region:
|
||||
type: string
|
||||
type: string
|
||||
size:
|
||||
type: string
|
||||
type: string
|
||||
name:
|
||||
type: string
|
||||
required:
|
||||
- region
|
||||
type: string
|
||||
required:
|
||||
- region
|
||||
- size
|
||||
# Removed for brevity
|
||||
```
|
||||
|
|
@ -312,15 +314,15 @@ This XRD defines two objects:
|
|||
1. the top-level {{<hover label="required2" line="7">}}spec{{</hover>}} object
|
||||
2. a second {{<hover label="required2" line="14">}}location{{</hover>}} object
|
||||
|
||||
The {{<hover label="required2" line="7">}}spec{{</hover>}} object
|
||||
{{<hover label="required2" line="23">}}requires{{</hover>}} the
|
||||
{{<hover label="required2" line="10">}}size{{</hover>}} and
|
||||
{{<hover label="required2" line="14">}}location{{</hover>}} but
|
||||
The {{<hover label="required2" line="7">}}spec{{</hover>}} object
|
||||
{{<hover label="required2" line="23">}}requires{{</hover>}} the
|
||||
{{<hover label="required2" line="10">}}size{{</hover>}} and
|
||||
{{<hover label="required2" line="14">}}location{{</hover>}} but
|
||||
{{<hover label="required2" line="12">}}name{{</hover>}} is optional.
|
||||
|
||||
Inside the required {{<hover label="required2" line="14">}}location{{</hover>}}
|
||||
Inside the required {{<hover label="required2" line="14">}}location{{</hover>}}
|
||||
object,
|
||||
{{<hover label="required2" line="17">}}country{{</hover>}} is
|
||||
{{<hover label="required2" line="17">}}country{{</hover>}} is
|
||||
{{<hover label="required2" line="21">}}required{{</hover>}} and
|
||||
{{<hover label="required2" line="19">}}zone{{</hover>}} is optional.
|
||||
|
||||
|
|
@ -335,25 +337,25 @@ object,
|
|||
type: object
|
||||
properties:
|
||||
size:
|
||||
type: string
|
||||
type: string
|
||||
name:
|
||||
type: string
|
||||
type: string
|
||||
location:
|
||||
type: object
|
||||
properties:
|
||||
country:
|
||||
type: string
|
||||
country:
|
||||
type: string
|
||||
zone:
|
||||
type: string
|
||||
required:
|
||||
- country
|
||||
required:
|
||||
required:
|
||||
- size
|
||||
- location
|
||||
```
|
||||
|
||||
The Swagger "[Describing Parameters](https://swagger.io/docs/specification/describing-parameters/)"
|
||||
documentation has more examples.
|
||||
documentation has more examples.
|
||||
|
||||
##### Crossplane reserved fields
|
||||
|
||||
|
|
@ -368,7 +370,7 @@ Crossplane ignores any fields matching the reserved fields.
|
|||
|
||||
To use a schema it must be
|
||||
{{<hover label="served" line="12" >}}served: true{{</hover >}}
|
||||
and
|
||||
and
|
||||
{{<hover label="served" line="13" >}}referenceable: true{{</hover>}}.
|
||||
|
||||
```yaml {label="served"}
|
||||
|
|
@ -393,26 +395,26 @@ spec:
|
|||
type: object
|
||||
properties:
|
||||
region:
|
||||
type: string
|
||||
type: string
|
||||
```
|
||||
|
||||
Composite resources can use any schema version set as
|
||||
{{<hover label="served" line="12" >}}served: true{{</hover >}}.
|
||||
Composite resources can use any schema version set as
|
||||
{{<hover label="served" line="12" >}}served: true{{</hover >}}.
|
||||
Kubernetes rejects any composite resource using a schema version set as `served:
|
||||
false`.
|
||||
|
||||
{{< hint "tip" >}}
|
||||
Setting a schema version as `served:false` causes errors for users using an older
|
||||
schema. This can be an effective way to identify and upgrade users before
|
||||
deleting the older schema version.
|
||||
deleting the older schema version.
|
||||
{{< /hint >}}
|
||||
|
||||
The {{<hover label="served" line="13" >}}referenceable: true{{</hover>}}
|
||||
field indicates which version of the schema Compositions use. Only one
|
||||
version can be `referenceable`.
|
||||
version can be `referenceable`.
|
||||
|
||||
{{< hint "note" >}}
|
||||
Changing which version is `referenceable:true` requires [updating the `compositeTypeRef.apiVersion`]({{<ref "./compositions#match-composite-resources" >}})
|
||||
Changing which version is `referenceable:true` requires [updating the `compositeTypeRef.apiVersion`]({{<ref "./compositions#match-composite-resources" >}})
|
||||
of any Compositions referencing that XRD.
|
||||
{{< /hint >}}
|
||||
|
||||
|
|
@ -431,27 +433,27 @@ a "breaking change."
|
|||
<!-- vale Crossplane.Spelling = NO -->
|
||||
<!-- ignore to allow for CRDs -->
|
||||
<!-- don't add to the spelling exceptions to catch when it's used instead of XRD -->
|
||||
Crossplane XRDs use Kubernetes custom resource definitions for versioning.
|
||||
Read the Kubernetes documentation on
|
||||
Crossplane XRDs use Kubernetes custom resource definitions for versioning.
|
||||
Read the Kubernetes documentation on
|
||||
[versions in CustomResourceDefinitions](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/)
|
||||
for more background on versions and breaking changes.
|
||||
for more background on versions and breaking changes.
|
||||
<!-- vale Crossplane.Spelling = YES -->
|
||||
|
||||
Crossplane recommends implementing breaking schema changes as brand new XRDs.
|
||||
{{< /hint >}}
|
||||
|
||||
For XRDs, to create a new version of an API add a new
|
||||
For XRDs, to create a new version of an API add a new
|
||||
{{<hover label="ver" line="21">}}name{{</hover>}} in the
|
||||
{{<hover label="ver" line="10">}}versions{{</hover>}}
|
||||
list.
|
||||
list.
|
||||
|
||||
For example, this XRD version
|
||||
{{<hover label="ver" line="11">}}v1alpha1{{</hover>}} only has the field
|
||||
For example, this XRD version
|
||||
{{<hover label="ver" line="11">}}v1alpha1{{</hover>}} only has the field
|
||||
{{<hover label="ver" line="19">}}region{{</hover>}}.
|
||||
|
||||
A second version,
|
||||
{{<hover label="ver" line="21">}}v1{{</hover>}} expands the API to have both
|
||||
{{<hover label="ver" line="29">}}region{{</hover>}} and
|
||||
A second version,
|
||||
{{<hover label="ver" line="21">}}v1{{</hover>}} expands the API to have both
|
||||
{{<hover label="ver" line="29">}}region{{</hover>}} and
|
||||
{{<hover label="ver" line="31">}}size{{</hover>}}.
|
||||
|
||||
```yaml {label="ver",copy-lines="none"}
|
||||
|
|
@ -474,7 +476,7 @@ spec:
|
|||
type: object
|
||||
properties:
|
||||
region:
|
||||
type: string
|
||||
type: string
|
||||
- name: v1
|
||||
schema:
|
||||
openAPIV3Schema:
|
||||
|
|
@ -484,9 +486,9 @@ spec:
|
|||
type: object
|
||||
properties:
|
||||
region:
|
||||
type: string
|
||||
type: string
|
||||
size:
|
||||
type: string
|
||||
type: string
|
||||
```
|
||||
|
||||
{{<hint "important" >}}
|
||||
|
|
@ -494,6 +496,41 @@ spec:
|
|||
Changing or expanding the XRD schema requires restarting the [Crossplane pod]({{<ref "../guides/pods#crossplane-pod">}}) to take effect.
|
||||
{{< /hint >}}
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
### XRD scope
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
The {{<hover label="xrdscope" line="6">}}scope{{</hover>}} field determines
|
||||
whether composite resources created from this XRD exist in a namespace or
|
||||
at cluster scope.
|
||||
|
||||
```yaml {label="xrdscope",copy-lines="none"}
|
||||
apiVersion: apiextensions.crossplane.io/v2
|
||||
kind: CompositeResourceDefinition
|
||||
metadata:
|
||||
name: mydatabases.example.org
|
||||
spec:
|
||||
scope: Namespaced
|
||||
# Removed for brevity
|
||||
```
|
||||
|
||||
The scope field supports three values:
|
||||
|
||||
* `Namespaced` - **(Default in v2)** - Composite resources exist in a
|
||||
namespace and can only compose resources in the same namespace.
|
||||
* `Cluster` - Composite resources are cluster-scoped and can compose resources
|
||||
in any namespace or at cluster scope.
|
||||
* `LegacyCluster` - Cluster-scoped with support for claims (v1 compatibility
|
||||
mode).
|
||||
|
||||
{{<hint "note" >}}
|
||||
Most XRDs should use `Namespaced` scope. This provides better security
|
||||
isolation and follows standard Kubernetes patterns. Use `Cluster` scope only
|
||||
for platform level resources like RBAC or cluster configuration.
|
||||
{{< /hint >}}
|
||||
|
||||
### Set composite resource defaults
|
||||
XRDs can set default parameters for composite resources.
|
||||
|
||||
|
|
@ -502,13 +539,13 @@ XRDs can set default parameters for composite resources.
|
|||
<!-- vale on -->
|
||||
It's possible for multiple [Compositions]({{<ref "./compositions">}}) to
|
||||
reference the same XRD. If more than one Composition references the same XRD,
|
||||
the composite resource must select which Composition to use.
|
||||
the composite resource must select which Composition to use.
|
||||
|
||||
An XRD can define the default Composition to use with the
|
||||
`defaultCompositionRef` value.
|
||||
`defaultCompositionRef` value.
|
||||
|
||||
Set a
|
||||
{{<hover label="defaultComp" line="6">}}defaultCompositionRef{{</hover>}}
|
||||
{{<hover label="defaultComp" line="6">}}defaultCompositionRef{{</hover>}}
|
||||
to set the default Composition.
|
||||
|
||||
```yaml {label="defaultComp",copy-lines="none"}
|
||||
|
|
@ -517,7 +554,7 @@ kind: CompositeResourceDefinition
|
|||
metadata:
|
||||
name: xdatabases.custom-api.example.org
|
||||
spec:
|
||||
defaultCompositionRef:
|
||||
defaultCompositionRef:
|
||||
name: myComposition
|
||||
group: custom-api.example.org
|
||||
names:
|
||||
|
|
@ -531,10 +568,10 @@ spec:
|
|||
<!-- vale on -->
|
||||
|
||||
Changes to a Composition generate a new Composition revision. By default all
|
||||
composite resources use the updated Composition revision.
|
||||
composite resources use the updated Composition revision.
|
||||
|
||||
Set the XRD `defaultCompositionUpdatePolicy` to `Manual` to prevent composite
|
||||
resources from automatically using the new revision.
|
||||
resources from automatically using the new revision.
|
||||
|
||||
The default value is `defaultCompositionUpdatePolicy: Automatic`.
|
||||
|
||||
|
|
@ -563,9 +600,9 @@ To require all composite resources to use a specific Composition use the
|
|||
`enforcedCompositionRef` setting in the XRD.
|
||||
|
||||
For example, to require all composite resources using this XRD to use the
|
||||
Composition
|
||||
{{<hover label="enforceComp" line="6">}}myComposition{{</hover>}}
|
||||
set
|
||||
Composition
|
||||
{{<hover label="enforceComp" line="6">}}myComposition{{</hover>}}
|
||||
set
|
||||
{{<hover label="enforceComp" line="6">}}enforcedCompositionRef.name: myComposition{{</hover>}}.
|
||||
|
||||
```yaml {label="defaultComp",copy-lines="none"}
|
||||
|
|
@ -574,7 +611,7 @@ kind: CompositeResourceDefinition
|
|||
metadata:
|
||||
name: xdatabases.custom-api.example.org
|
||||
spec:
|
||||
enforcedCompositionRef:
|
||||
enforcedCompositionRef:
|
||||
name: myComposition
|
||||
group: custom-api.example.org
|
||||
names:
|
||||
|
|
@ -589,11 +626,11 @@ spec:
|
|||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
Verify an XRD with `kubectl get compositeresourcedefinition` or the short form,
|
||||
Verify an XRD with `kubectl get compositeresourcedefinition` or the short form,
|
||||
{{<hover label="getxrd" line="1">}}kubectl get xrd{{</hover>}}.
|
||||
|
||||
```yaml {label="getxrd",copy-lines="1"}
|
||||
kubectl get xrd
|
||||
kubectl get xrd
|
||||
NAME ESTABLISHED OFFERED AGE
|
||||
xdatabases.custom-api.example.org True True 22m
|
||||
```
|
||||
|
|
@ -606,9 +643,9 @@ resource definition for this XRD.
|
|||
### XRD conditions
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
Crossplane uses a standard set of `Conditions` for XRDs.
|
||||
View the conditions of a XRD under their `Status` with
|
||||
`kubectl describe xrd`.
|
||||
Crossplane uses a standard set of `Conditions` for XRDs.
|
||||
View the conditions of a XRD under their `Status` with
|
||||
`kubectl describe xrd`.
|
||||
|
||||
```yaml {copy-lines="none"}
|
||||
kubectl describe xrd
|
||||
|
|
@ -628,8 +665,8 @@ Status:
|
|||
#### WatchingCompositeResource
|
||||
<!-- vale on -->
|
||||
`Reason: WatchingCompositeResource` indicates Crossplane defined the new
|
||||
Kubernetes custom resource definitions related to the composite resource and is
|
||||
watching for the creation of new composite resources.
|
||||
Kubernetes custom resource definitions related to the composite resource and is
|
||||
watching for the creation of new composite resources.
|
||||
|
||||
```yaml
|
||||
Type: Established
|
||||
|
|
@ -641,7 +678,7 @@ Reason: WatchingCompositeResource
|
|||
#### TerminatingCompositeResource
|
||||
<!-- vale on -->
|
||||
`Reason: TerminatingCompositeResource` indicates Crossplane is deleting the
|
||||
custom resource definitions related to the composite resource and is
|
||||
custom resource definitions related to the composite resource and is
|
||||
terminating the composite resource controller.
|
||||
|
||||
```yaml
|
||||
|
|
|
|||
|
|
@ -16,10 +16,10 @@ database configuration of an Azure MySQL Server and some firewall rules. The
|
|||
`Composition` contains the 'base' configuration for the MySQL server and the
|
||||
firewall rules that the `PlatformDB` configuration extends.
|
||||
|
||||
A `Composition` associates with multiple XRs that use it. You might
|
||||
define a `Composition` named `big-platform-db` that's used by ten different
|
||||
`PlatformDB` XRs. Often, in the interest of self-service, a different team manages the `Composition`
|
||||
than the actual `PlatformDB` XRs. For example
|
||||
A `Composition` associates with multiple XRs that use it. You might
|
||||
define a `Composition` named `big-platform-db` that's used by ten different
|
||||
`PlatformDB` XRs. Often, in the interest of self-service, a different team manages the `Composition`
|
||||
than the actual `PlatformDB` XRs. For example
|
||||
a platform team member may write and maintain the `Composition`,
|
||||
while individual app teams create `PlatformDB` XRs that use said
|
||||
`Composition`.
|
||||
|
|
@ -88,6 +88,7 @@ manually update it when you wish it to use another `CompositionRevision`.
|
|||
apiVersion: example.org/v1alpha1
|
||||
kind: PlatformDB
|
||||
metadata:
|
||||
namespace: default
|
||||
name: example
|
||||
spec:
|
||||
storageGB: 20
|
||||
|
|
@ -108,6 +109,7 @@ use a different `CompositionRevision`.
|
|||
apiVersion: example.org/v1alpha1
|
||||
kind: PlatformDB
|
||||
metadata:
|
||||
namespace: default
|
||||
name: example
|
||||
spec:
|
||||
storageGB: 20
|
||||
|
|
@ -125,9 +127,9 @@ spec:
|
|||
This tutorial discusses how CompositionRevisions work and how they manage Composite Resource
|
||||
(XR) updates. This starts with a `Composition` and `CompositeResourceDefinition` (XRD) that defines a `MyVPC`
|
||||
resource and continues with creating multiple XRs to observe different upgrade paths. Crossplane
|
||||
assigns different CompositionRevisions to composite resources each time you update the composition.
|
||||
assigns different CompositionRevisions to composite resources each time you update the composition.
|
||||
|
||||
### Preparation
|
||||
### Preparation
|
||||
|
||||
#### Deploy composition and XRD examples
|
||||
Apply the example Composition.
|
||||
|
|
@ -177,18 +179,18 @@ spec:
|
|||
plural: myvpcs
|
||||
versions:
|
||||
- name: v1alpha1
|
||||
served: true
|
||||
referenceable: true
|
||||
served: true
|
||||
referenceable: true
|
||||
schema:
|
||||
openAPIV3Schema:
|
||||
type: object
|
||||
type: object
|
||||
properties:
|
||||
spec:
|
||||
type: object
|
||||
type: object
|
||||
properties:
|
||||
id:
|
||||
type: string
|
||||
description: ID of this VPC that other objects will use to refer to it.
|
||||
type: string
|
||||
description: ID of this VPC that other objects will use to refer to it.
|
||||
required:
|
||||
- id
|
||||
```
|
||||
|
|
@ -228,7 +230,7 @@ spec:
|
|||
Expected Output:
|
||||
```shell
|
||||
myvpc.aws.example.upbound.io/vpc-auto created
|
||||
```
|
||||
```
|
||||
|
||||
#### Manual update policy
|
||||
Create a Composite Resource with `compositionUpdatePolicy: Manual` and `compositionRevisionRef`.
|
||||
|
|
@ -249,7 +251,7 @@ spec:
|
|||
Expected Output:
|
||||
```shell
|
||||
myvpc.aws.example.upbound.io/vpc-man created
|
||||
```
|
||||
```
|
||||
|
||||
#### Using a selector
|
||||
Create an XR with a `compositionRevisionSelector` of `channel: dev`:
|
||||
|
|
@ -269,7 +271,7 @@ spec:
|
|||
Expected Output:
|
||||
```shell
|
||||
myvpc.aws.example.upbound.io/vpc-dev created
|
||||
```
|
||||
```
|
||||
|
||||
Create an XR with a `compositionRevisionSelector` of `channel: staging`:
|
||||
```yaml
|
||||
|
|
@ -289,9 +291,9 @@ spec:
|
|||
Expected Output:
|
||||
```shell
|
||||
myvpc.aws.example.upbound.io/vpc-staging created
|
||||
```
|
||||
```
|
||||
|
||||
Verify the Composite Resource with the label `channel: staging` doesn't have a `REVISION`.
|
||||
Verify the Composite Resource with the label `channel: staging` doesn't have a `REVISION`.
|
||||
All other XRs have a `REVISION` matching the created Composition Revision.
|
||||
```shell
|
||||
kubectl get composite -o="custom-columns=NAME:.metadata.name,SYNCED:.status.conditions[0].status,REVISION:.spec.crossplane.compositionRevisionRef.name,POLICY:.spec.crossplane.compositionUpdatePolicy,MATCHLABEL:.spec.crossplane.compositionRevisionSelector.matchLabels"
|
||||
|
|
@ -303,7 +305,7 @@ vpc-auto True myvpcs.aws.example.upbound.io-ad265bc Automatic <none
|
|||
vpc-dev True myvpcs.aws.example.upbound.io-ad265bc Automatic map[channel:dev]
|
||||
vpc-man True myvpcs.aws.example.upbound.io-ad265bc Manual <none>
|
||||
vpc-staging False <none> Automatic map[channel:staging]
|
||||
```
|
||||
```
|
||||
|
||||
{{< hint "note" >}}
|
||||
The `vpc-staging` XR label doesn't match any existing Composition Revisions.
|
||||
|
|
@ -311,7 +313,7 @@ The `vpc-staging` XR label doesn't match any existing Composition Revisions.
|
|||
|
||||
### Create new composition revisions
|
||||
Crossplane creates a new CompositionRevision when you create or update a Composition. Label and annotation changes
|
||||
also trigger a new CompositionRevision.
|
||||
also trigger a new CompositionRevision.
|
||||
|
||||
#### Update the composition label
|
||||
Update the `Composition` label to `channel: staging`:
|
||||
|
|
@ -321,7 +323,7 @@ kubectl label composition myvpcs.aws.example.upbound.io channel=staging --overwr
|
|||
Expected Output:
|
||||
```shell
|
||||
composition.apiextensions.crossplane.io/myvpcs.aws.example.upbound.io labeled
|
||||
```
|
||||
```
|
||||
|
||||
Verify that Crossplane creates a new Composition revision:
|
||||
```shell
|
||||
|
|
@ -332,9 +334,9 @@ Expected Output:
|
|||
NAME REVISION CHANNEL
|
||||
myvpcs.aws.example.upbound.io-727b3c8 2 staging
|
||||
myvpcs.aws.example.upbound.io-ad265bc 1 dev
|
||||
```
|
||||
```
|
||||
|
||||
Verify that Crossplane assigns the Composite Resources `vpc-auto` and `vpc-staging` to Composite `revision:2`.
|
||||
Verify that Crossplane assigns the Composite Resources `vpc-auto` and `vpc-staging` to Composite `revision:2`.
|
||||
XRs `vpc-man` and `vpc-dev` are still assigned to the original `revision:1`:
|
||||
|
||||
```shell
|
||||
|
|
@ -347,10 +349,10 @@ vpc-auto True myvpcs.aws.example.upbound.io-727b3c8 Automatic <none
|
|||
vpc-dev True myvpcs.aws.example.upbound.io-ad265bc Automatic map[channel:dev]
|
||||
vpc-man True myvpcs.aws.example.upbound.io-ad265bc Manual <none>
|
||||
vpc-staging True myvpcs.aws.example.upbound.io-727b3c8 Automatic map[channel:staging]
|
||||
```
|
||||
```
|
||||
|
||||
{{< hint "note" >}}
|
||||
`vpc-auto` always use the latest Revision.
|
||||
`vpc-auto` always use the latest Revision.
|
||||
`vpc-staging` now matches the label applied to Revision `revision:2`.
|
||||
{{< /hint >}}
|
||||
|
||||
|
|
@ -393,7 +395,7 @@ spec:
|
|||
Expected Output:
|
||||
```shell
|
||||
composition.apiextensions.crossplane.io/myvpcs.aws.example.upbound.io configured
|
||||
```
|
||||
```
|
||||
|
||||
Verify that Crossplane creates a new Composition revision:
|
||||
|
||||
|
|
@ -406,13 +408,13 @@ NAME REVISION CHANNEL
|
|||
myvpcs.aws.example.upbound.io-727b3c8 2 staging
|
||||
myvpcs.aws.example.upbound.io-ad265bc 1 dev
|
||||
myvpcs.aws.example.upbound.io-f81c553 3 dev
|
||||
```
|
||||
```
|
||||
|
||||
{{< hint "note" >}}
|
||||
Changing the label and the spec values simultaneously is critical for deploying new changes to the `dev` channel.
|
||||
{{< /hint >}}
|
||||
|
||||
Verify Crossplane assigns the Composite Resources `vpc-auto` and `vpc-dev` to Composite `revision:3`.
|
||||
Verify Crossplane assigns the Composite Resources `vpc-auto` and `vpc-dev` to Composite `revision:3`.
|
||||
Crossplane assigns `vpc-staging` to `revision:2`, and still assigns `vpc-man` to the original `revision:1`:
|
||||
|
||||
```shell
|
||||
|
|
@ -425,7 +427,7 @@ vpc-auto True myvpcs.aws.example.upbound.io-f81c553 Automatic <none
|
|||
vpc-dev True myvpcs.aws.example.upbound.io-f81c553 Automatic map[channel:dev]
|
||||
vpc-man True myvpcs.aws.example.upbound.io-ad265bc Manual <none>
|
||||
vpc-staging True myvpcs.aws.example.upbound.io-727b3c8 Automatic map[channel:staging]
|
||||
```
|
||||
```
|
||||
|
||||
|
||||
{{< hint "note" >}}
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ that supports REST APIs to work with apps.
|
|||
This guide requires:
|
||||
|
||||
* A Kubernetes cluster with at least 2 GB of RAM
|
||||
* The Crossplane v2 preview [installed on the Kubernetes cluster]({{<ref "install">}})
|
||||
* Crossplane v2 [installed on the Kubernetes cluster]({{<ref "install">}})
|
||||
|
||||
## Create the custom resource
|
||||
|
||||
|
|
|
|||
|
|
@ -32,16 +32,16 @@ Kubernetes calls third party API resources _custom resources_.
|
|||
This guide requires:
|
||||
|
||||
* A Kubernetes cluster with at least 2 GB of RAM
|
||||
* The Crossplane v2 preview [installed on the Kubernetes cluster]({{<ref "install">}})
|
||||
* Crossplane v2 [installed on the Kubernetes cluster]({{<ref "install">}})
|
||||
* 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.
|
||||
AWS managed resources fully support Crossplane v2.
|
||||
|
||||
<!-- 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.
|
||||
Maintainers are actively working to update managed resources for other systems including Azure,
|
||||
GCP, Terraform, Helm, GitHub, etc to support Crossplane v2.
|
||||
<!-- vale gitlab.FutureTense = YES -->
|
||||
{{</hint>}}
|
||||
|
||||
|
|
@ -69,7 +69,7 @@ kind: Provider
|
|||
metadata:
|
||||
name: crossplane-contrib-provider-aws-s3
|
||||
spec:
|
||||
package: xpkg.crossplane.io/crossplane-contrib/provider-aws-s3:v1.24.0-crossplane-v2-preview.0
|
||||
package: xpkg.crossplane.io/crossplane-contrib/provider-aws-s3:v2.0.0
|
||||
```
|
||||
|
||||
Save this as `provider.yaml` and apply it:
|
||||
|
|
@ -83,8 +83,8 @@ Check that Crossplane installed the provider:
|
|||
```shell {copy-lines="1",label="getProvider"}
|
||||
kubectl get providers
|
||||
NAME INSTALLED HEALTHY PACKAGE AGE
|
||||
crossplane-contrib-provider-family-aws True True xpkg.crossplane.io/crossplane-contrib/provider-family-aws:v1.24.0-crossplane-v2-preview.0 27s
|
||||
crossplane-contrib-provider-aws-s3 True True xpkg.crossplane.io/crossplane-contrib/provider-aws-s3:v1.24.0-crossplane-v2-preview.0 31s
|
||||
crossplane-contrib-provider-family-aws True True xpkg.crossplane.io/crossplane-contrib/provider-family-aws:v2.0.0 27s
|
||||
crossplane-contrib-provider-aws-s3 True True xpkg.crossplane.io/crossplane-contrib/provider-aws-s3:v2.0.0 31s
|
||||
```
|
||||
|
||||
{{<hint "note">}}
|
||||
|
|
|
|||
|
|
@ -28,14 +28,14 @@ Install Crossplane using the _Helm chart_.
|
|||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
### Add the Crossplane Preview Helm repository
|
||||
### Add the Crossplane Helm repository
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
Add the Crossplane preview repository with the `helm repo add` command.
|
||||
Add the Crossplane stable repository with the `helm repo add` command.
|
||||
|
||||
```shell
|
||||
helm repo add crossplane-preview https://charts.crossplane.io/preview
|
||||
helm repo add crossplane-stable https://charts.crossplane.io/stable
|
||||
```
|
||||
|
||||
Update the
|
||||
|
|
@ -46,11 +46,11 @@ helm repo update
|
|||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
### Install the Crossplane Preview Helm chart
|
||||
### Install the Crossplane Helm chart
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
Install the Crossplane Preview Helm chart with `helm install`.
|
||||
Install the Crossplane Helm chart with `helm install`.
|
||||
|
||||
{{< hint "tip" >}}
|
||||
View the changes Crossplane makes to your cluster with the
|
||||
|
|
@ -63,8 +63,7 @@ Crossplane creates and installs into the `crossplane-system` namespace.
|
|||
```shell
|
||||
helm install crossplane \
|
||||
--namespace crossplane-system \
|
||||
--create-namespace crossplane-preview/crossplane \
|
||||
--version v2.0.0-preview.1
|
||||
--create-namespace crossplane-stable/crossplane
|
||||
```
|
||||
|
||||
View the installed Crossplane pods with `kubectl get pods -n crossplane-system`.
|
||||
|
|
|
|||
|
|
@ -10,14 +10,14 @@ The recommended upgrade method for an existing Crossplane install is to use
|
|||
* [Helm](https://helm.sh/docs/intro/install/) version `v3.2.0` or later
|
||||
|
||||
|
||||
## Add the Crossplane Preview Helm repository
|
||||
## Add the Crossplane Helm repository
|
||||
Verify Helm has the Crossplane repository.
|
||||
|
||||
```shell
|
||||
helm repo add crossplane-preview https://charts.crossplane.io/preview
|
||||
helm repo add crossplane-stable https://charts.crossplane.io/stable
|
||||
```
|
||||
|
||||
## Update the Helm Preview repository
|
||||
## Update the Helm repository
|
||||
|
||||
Update the local Crossplane Helm chart with `helm repo update`.
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ By default, Crossplane installs into the `crossplane-system`
|
|||
namespace.
|
||||
|
||||
```shell
|
||||
helm upgrade crossplane --namespace crossplane-system crossplane-preview/crossplane --devel
|
||||
helm upgrade crossplane --namespace crossplane-system crossplane-stable/crossplane
|
||||
```
|
||||
|
||||
Helm preserves any arguments or flags originally used when installing
|
||||
|
|
@ -56,5 +56,5 @@ with the upgrade command.
|
|||
|
||||
For example, to maintain the original image registry use
|
||||
```shell
|
||||
helm upgrade crossplane --namespace crossplane-system crossplane-preview/crossplane --set 'args={"--registry=index.docker.io"}'
|
||||
helm upgrade crossplane --namespace crossplane-system crossplane-stable/crossplane --set 'args={"--registry=index.docker.io"}'
|
||||
```
|
||||
|
|
|
|||
|
|
@ -20,11 +20,11 @@ Examples of managed resources include:
|
|||
* Microsoft Azure PostgreSQL `Database` defined in [provider-upjet-azure](https://github.com/crossplane-contrib/provider-upjet-azure).
|
||||
|
||||
{{<hint "important">}}
|
||||
Only AWS managed resources support the Crossplane v2 preview.
|
||||
AWS managed resources fully support Crossplane v2.
|
||||
|
||||
<!-- 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.
|
||||
Maintainers are actively working to update managed resources for other systems including Azure,
|
||||
GCP, Terraform, Helm, GitHub, etc to support Crossplane v2.
|
||||
<!-- vale gitlab.FutureTense = YES -->
|
||||
{{</hint>}}
|
||||
|
||||
|
|
@ -419,7 +419,7 @@ For example, when creating an AWS RDS database instance with the Crossplane
|
|||
[community AWS provider](https://github.com/crossplane-contrib/provider-aws)
|
||||
generates an endpoint, password, port and username data. The Provider saves
|
||||
these variables in the Kubernetes secret
|
||||
{{<hover label="secretname" line="9" >}}rds-secret{{</hover>}}, referenced by
|
||||
{{<hover label="secretname" line="10" >}}rds-secret{{</hover>}}, referenced by
|
||||
the
|
||||
{{<hover label="secretname" line="9" >}}writeConnectionSecretToRef{{</hover>}}
|
||||
field.
|
||||
|
|
@ -428,6 +428,7 @@ field.
|
|||
apiVersion: database.aws.m.crossplane.io/v1beta1
|
||||
kind: RDSInstance
|
||||
metadata:
|
||||
namespace: default
|
||||
name: my-rds-instance
|
||||
spec:
|
||||
forProvider:
|
||||
|
|
|
|||
|
|
@ -216,11 +216,11 @@ Follow [Get Started with Managed Resources]({{<ref "../get-started/get-started-w
|
|||
to see how managed resources work.
|
||||
|
||||
{{<hint "note">}}
|
||||
Only AWS managed resources support the Crossplane v2 preview.
|
||||
AWS managed resources fully support Crossplane v2.
|
||||
|
||||
<!-- 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.
|
||||
Maintainers are actively working to update managed resources for other systems including Azure,
|
||||
GCP, Terraform, Helm, GitHub, etc to support Crossplane v2.
|
||||
<!-- vale gitlab.FutureTense = YES -->
|
||||
{{</hint>}}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: What's New in v2?
|
||||
weight: 4
|
||||
description: Learn what's new in the Crossplane v2 preview
|
||||
description: Learn what's new in Crossplane v2
|
||||
---
|
||||
**Crossplane v2 makes Crossplane more useful, more intuitive, and less
|
||||
opinionated.**
|
||||
|
|
@ -151,12 +151,11 @@ 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.
|
||||
Namespaced AWS managed resources are fully available in Crossplane v2.
|
||||
|
||||
<!-- 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.
|
||||
Maintainers are actively working to update managed resources for other systems including Azure,
|
||||
GCP, Terraform, Helm, GitHub, etc to support namespaced MRs.
|
||||
<!-- vale gitlab.FutureTense = YES -->
|
||||
{{</hint>}}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue