mirror of https://github.com/crossplane/docs.git
Address all warnings in content/master
I tried to address them everywhere but there are literally thousands. Signed-off-by: Nic Cope <nicc@rk0n.org>
This commit is contained in:
Nic Cope
parent
331c389ce9
commit
580593faea
|
|
@ -41,7 +41,7 @@ https://releases.crossplane.io/stable/current/bin
|
|||
|
||||
{{<hint "important" >}}
|
||||
<!-- vale write-good.Passive = NO -->
|
||||
The CLI is named `crank` in the release repository. Download this file.
|
||||
The release repository names the CLI `crank`. Download this file.
|
||||
<!-- vale write-good.Passive = YES -->
|
||||
|
||||
The `crossplane` binary is the Kubernetes Crossplane pod image.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,11 @@ The following flags are available for all commands.
|
|||
|
||||
{{< /table >}}
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
## version
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
The `crossplane version` command returns the version of Crossplane CLI
|
||||
and the control plane.
|
||||
|
|
@ -35,7 +39,9 @@ Client Version: v1.17.0
|
|||
Server Version: v1.17.0
|
||||
```
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
## render
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
The `crossplane render` command previews the output of a
|
||||
[composite resource]({{<ref "../composition/composite-resources">}}) after applying
|
||||
|
|
@ -167,7 +173,7 @@ spec:
|
|||
|
||||
The schema of the resource isn't validated and may contain any data.
|
||||
|
||||
### Mock Extra Resources
|
||||
### Mock extra resources
|
||||
|
||||
Extra Resources allow a Composition to request Crossplane Objects on the cluster that aren't
|
||||
part of the Composition. The `--extra-resources` option points at a directory containing
|
||||
|
|
@ -175,13 +181,17 @@ YAML manifests of resources to mock. Use Extra Resources in combination with a f
|
|||
[function-extra-resources](https://github.com/crossplane-contrib/function-extra-resources) or the
|
||||
built-in support in [function-go-templating](https://github.com/crossplane-contrib/function-go-templating?tab=readme-ov-file#extraresources).
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
## xpkg
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
The `crossplane xpkg` commands create, install and update Crossplane
|
||||
[packages]({{<ref "../packages/configurations">}}) as well as enable authentication
|
||||
[packages]({{<ref "../packages/configurations">}}) and enable authentication
|
||||
and publishing of Crossplane packages to a Crossplane package registry.
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
### xpkg build
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
Using `crossplane xpkg build` provides automation and simplification to build
|
||||
Crossplane packages.
|
||||
|
|
@ -243,7 +253,7 @@ Include YAML files demonstrating how to use the package with `--examples-root`.
|
|||
#### Include a runtime image
|
||||
|
||||
Functions and Providers require YAML files describing their dependencies and
|
||||
settings as well as a container image for their runtime.
|
||||
settings and a container image for their runtime.
|
||||
|
||||
Using `--embed-runtime-image-name` runs a specified image and
|
||||
includes the image inside the function or provider package.
|
||||
|
|
@ -258,7 +268,9 @@ Use `docker pull` to download a missing image.
|
|||
The `--embed-runtime-image-tarball` flag includes a local OCI image tarball
|
||||
inside the function or provider package.
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
### xpkg init
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
The `crossplane xpkg init` command populates the current directory with
|
||||
files to build a package.
|
||||
|
|
@ -279,14 +291,18 @@ The `<template>` value may be one of four well known templates:
|
|||
Instead of a well known template the `<template>` value can be a git repository
|
||||
URL.
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
#### NOTES.txt
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
If the template repository contains a `NOTES.txt` file in its root directory,
|
||||
the `crossplane xpkg init` command prints the contents of the file to the
|
||||
terminal after populating the directory with the template files. This can be
|
||||
useful for providing information about the template.
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
#### init.sh
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
If the template repository contains an `init.sh` file in its root directory, the
|
||||
`crossplane xpkg init` command starts a dialog after populating the
|
||||
|
|
@ -305,7 +321,9 @@ personalize the template.
|
|||
{{< /table >}}
|
||||
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
### xpkg install
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
Download and install packages into Crossplane with `crossplane xpkg install`.
|
||||
|
||||
|
|
@ -375,7 +393,9 @@ Read more about
|
|||
[package revisions]({{< ref "../packages/configurations#configuration-revisions" >}})
|
||||
in the package documentation.
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
### xpkg login
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
Use `xpkg login` to authenticate to registries that host Crossplane packages.
|
||||
|
||||
|
|
@ -430,7 +450,9 @@ Authenticate to a registered organization in the Upbound Marketplace with the
|
|||
For example,
|
||||
`crossplane xpkg login --account=Upbound --username=my-user --password -`.
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
### xpkg logout
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
Use `crossplane xpkg logout` to invalidate the current `crossplane xpkg login`
|
||||
session.
|
||||
|
|
@ -440,7 +462,9 @@ Using `crossplane xpkg logout` removes the `session` from the
|
|||
`~/.crossplane/config.json` file, but doesn't delete the configuration file.
|
||||
{{< /hint >}}
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
### xpkg push
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
Push a Crossplane package file to a package registry.
|
||||
|
||||
|
|
@ -478,7 +502,9 @@ DockerHub organization `crossplane-docs/my-package:v0.14.0` use:
|
|||
| `-f` | `--package-files=PATH` | A comma-separated list of xpkg files to push. |
|
||||
{{< /table >}}
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
### xpkg update
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
The `crossplane xpkg update` command downloads and updates an existing package.
|
||||
|
||||
|
|
@ -499,7 +525,9 @@ For example, to update to the latest version of the
|
|||
`crossplane xpkg update provider xpkg.crossplane.io/crossplane-contrib/provider-aws-s3:v1.21.1`
|
||||
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
## beta
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
Crossplane `beta` commands are experimental. These commands may change the
|
||||
flags, options or outputs in future releases.
|
||||
|
|
@ -508,7 +536,9 @@ Crossplane maintainers may promote or remove commands under `beta` in future
|
|||
releases.
|
||||
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
### beta convert
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
As Crossplane evolves, its APIs and resources may change. To help with the
|
||||
migration to the new APIs and resources, the `crossplane beta convert` command
|
||||
|
|
@ -547,7 +577,9 @@ By default the function name is "function-patch-and-transform."
|
|||
{{< /table >}}
|
||||
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
### beta top
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
The command `crossplane beta top` shows CPU and memory usage of Crossplane
|
||||
related pods.
|
||||
|
|
@ -591,7 +623,9 @@ running the `top` command may produce an error, for example,
|
|||
`crossplane: error: error adding metrics to pod, check if metrics-server is running or wait until metrics are available for the pod: the server is currently unable to handle the request (get pods.metrics.k8s.io crossplane-contrib-provider-helm-b4cc4c2c8db3-6d787f9686-qzmz2)`
|
||||
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
### beta trace
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
Use the `crossplane beta trace` command to display a visual relationship of
|
||||
Crossplane objects. The `trace` command supports XRs, compositions,
|
||||
|
|
@ -826,7 +860,9 @@ Configuration/platform-ref-aws v0.9.0 True
|
|||
# Removed for brevity
|
||||
```
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
### beta validate
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
The `crossplane beta validate` command validates
|
||||
[compositions]({{<ref "../composition/compositions">}}) against provider or XRD
|
||||
|
|
@ -953,7 +989,9 @@ crossplane render xr.yaml composition.yaml function.yaml --include-full-xr | cro
|
|||
Total 5 resources: 0 missing schemas, 4 success cases, 1 failure cases
|
||||
```
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
#### Validate Common Expression Language rules
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
XRDs can define [validation rules](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules) expressed in the Common Expression Language
|
||||
([CEL](https://kubernetes.io/docs/reference/using-api/cel/)).
|
||||
|
|
|
|||
|
|
@ -30,7 +30,11 @@ Crossplane XRDs are like
|
|||
XRDs require fewer fields and add options related to Crossplane, like connection
|
||||
secrets.
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
## Creating a CompositeResourceDefinition
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
Creating a CompositeResourceDefinition consists of:
|
||||
* [Defining a custom API group](#xrd-groups).
|
||||
|
|
@ -88,7 +92,11 @@ recreate the XRD to change the
|
|||
{{<hover label="xrd1" line="7">}}names{{</hover>}}.
|
||||
{{</hint >}}
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
### XRD groups
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
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.
|
||||
|
|
@ -98,7 +106,11 @@ 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.
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
### XRD names
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
The `names` field defines how to refer to this specific XRD.
|
||||
The required name fields are:
|
||||
|
|
@ -137,7 +149,11 @@ spec:
|
|||
```
|
||||
{{</hint >}}
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
### XRD versions
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
<!-- vale gitlab.SentenceLength = NO -->
|
||||
The XRD `version` is like the
|
||||
|
|
@ -567,7 +583,11 @@ spec:
|
|||
# Removed for brevity
|
||||
```
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
## Verify a CompositeResourceDefinition
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
Verify an XRD with `kubectl get compositeresourcedefinition` or the short form,
|
||||
{{<hover label="getxrd" line="1">}}kubectl get xrd{{</hover>}}.
|
||||
|
|
@ -581,7 +601,11 @@ xdatabases.custom-api.example.org True True 22m
|
|||
The `ESTABLISHED` field indicates Crossplane installed the Kubernetes custom
|
||||
resource definition for this XRD.
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
### 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`.
|
||||
|
|
|
|||
|
|
@ -319,15 +319,17 @@ Spec:
|
|||
|
||||
### Composite resource conditions
|
||||
|
||||
<!-- vale Google.Colons = NO -->
|
||||
A composite resource has two status conditions: Synced and Ready.
|
||||
<!-- vale Google.Colons = YES -->
|
||||
|
||||
Crossplane sets the Synced status condition to True when it's able to
|
||||
successfully reconcile the composite resource. If Crossplane can't reconcile the
|
||||
composite resource it'll report an error in the Synced condition.
|
||||
composite resource it reports an error in the Synced condition.
|
||||
|
||||
Crossplane sets the Ready status condition to True when the composite resource's
|
||||
composition function pipeline reports that all of its composed resources are
|
||||
ready. If a composed resource isn't ready Crossplane will report it in the
|
||||
composition function pipeline reports that all its composed resources are
|
||||
ready. If a composed resource isn't ready Crossplane reports it in the
|
||||
Ready condition.
|
||||
|
||||
## Composite resource labels
|
||||
|
|
|
|||
|
|
@ -3,33 +3,33 @@ title: Composition Revisions
|
|||
weight: 35
|
||||
---
|
||||
|
||||
This guide discusses the use of "Composition Revisions" to safely make and roll
|
||||
This guide discusses the use of "Composition Revisions" to make and roll
|
||||
back changes to a Crossplane [`Composition`][composition type]. It assumes
|
||||
familiarity with Crossplane, and particularly with
|
||||
familiarity with Crossplane and
|
||||
[Compositions].
|
||||
|
||||
A `Composition` configures how Crossplane should reconcile a Composite Resource
|
||||
(XR). Put otherwise, when you create an XR the selected `Composition` determines
|
||||
what resources Crossplane will create in response. Let's say for example that
|
||||
what resources Crossplane creates in response. For example,
|
||||
you define a `PlatformDB` XR, which represents your organisation's common
|
||||
database configuration of an Azure MySQL Server and a few firewall rules. The
|
||||
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 are extended by the configuration for the `PlatformDB`.
|
||||
firewall rules that the `PlatformDB` configuration extends.
|
||||
|
||||
A `Composition` is associated with multiple XRs that make use of it. You might
|
||||
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. Usually, in the interest of self-service, the `Composition`
|
||||
is managed by a different team from the actual `PlatformDB` XRs. For example
|
||||
the `Composition` may be written and maintained by a platform team member,
|
||||
while individual application teams create `PlatformDB` XRs that use said
|
||||
`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`.
|
||||
|
||||
Each `Composition` is mutable - you can update it as your organisation's needs
|
||||
change. However, updating a `Composition` without Composition Revisions can be a
|
||||
change. Updating a `Composition` without Composition Revisions can be a
|
||||
risky process. Crossplane constantly uses the `Composition` to ensure that your
|
||||
actual infrastructure - your MySQL Servers and firewall rules - match your
|
||||
desired state. If you have 10 `PlatformDB` XRs all using the `big-platform-db`
|
||||
`Composition`, all 10 of those XRs will be instantly updated in accordance with
|
||||
`Composition`, all 10 of those XRs are instantly updated following
|
||||
any updates you make to the `big-platform-db` `Composition`.
|
||||
|
||||
Composition Revisions allow XRs to opt out of automatic updates. Instead you can
|
||||
|
|
@ -37,19 +37,19 @@ update your XRs to use the latest `Composition` settings at your own pace.
|
|||
This enables you to [canary] changes to your infrastructure, or to roll back
|
||||
some XRs to previous `Composition` settings without rolling back all XRs.
|
||||
|
||||
## Using Composition Revisions
|
||||
## Using composition revisions
|
||||
|
||||
When Composition Revisions are enabled three things happen:
|
||||
When you enable Composition Revisions three things happen:
|
||||
|
||||
1. Crossplane creates a `CompositionRevision` for each `Composition` update.
|
||||
1. Composite Resources gain a `spec.crossplane.compositionRevisionRef` field that specifies
|
||||
which `CompositionRevision` they use.
|
||||
1. Composite Resources gain a `spec.crossplane.compositionUpdatePolicy` field that
|
||||
specifies how they should be updated to new Composition Revisions.
|
||||
specifies how Crossplane should update them to new Composition Revisions.
|
||||
|
||||
Each time you edit a `Composition` Crossplane will automatically create a
|
||||
Each time you edit a `Composition` Crossplane automatically creates a
|
||||
`CompositionRevision` that represents that 'revision' of the `Composition` -
|
||||
that unique state. Each revision is allocated an increasing revision number.
|
||||
that unique state. Crossplane allocates each revision an increasing revision number.
|
||||
This gives `CompositionRevision` consumers an idea about which revision is
|
||||
'newest'.
|
||||
|
||||
|
|
@ -71,19 +71,18 @@ example-xjrdmzz 3 61s
|
|||
|
||||
> A `Composition` is a mutable resource that you can update as your needs
|
||||
> change over time. Each `CompositionRevision` is an immutable snapshot of those
|
||||
> needs at a particular point in time.
|
||||
> needs at a particular time.
|
||||
|
||||
Crossplane behaves the same way by default whether Composition Revisions are
|
||||
enabled or not. This is because when you enable Composition Revisions all XRs
|
||||
Crossplane behaves the same way by default whether you enable Composition Revisions or not. When you enable Composition Revisions all XRs
|
||||
default to the `Automatic` `compositionUpdatePolicy`. XRs support two update
|
||||
policies:
|
||||
|
||||
* `Automatic`: Automatically use the latest `CompositionRevision`. (Default)
|
||||
* `Manual`: Require manual intervention to change `CompositionRevision`.
|
||||
|
||||
The below XR uses the `Manual` policy. When this policy is used the XR will
|
||||
select the latest `CompositionRevision` when it's first created, but must
|
||||
manually be updated when you wish it to use another `CompositionRevision`.
|
||||
The below XR uses the `Manual` policy. When you use this policy the XR
|
||||
selects the latest `CompositionRevision` when it's first created, but must
|
||||
manually update it when you wish it to use another `CompositionRevision`.
|
||||
|
||||
```yaml
|
||||
apiVersion: example.org/v1alpha1
|
||||
|
|
@ -125,12 +124,12 @@ 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 will
|
||||
assign different CompositionRevisions to the created composite resources each time the composition is updated.
|
||||
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.
|
||||
|
||||
### Preparation
|
||||
|
||||
#### Deploy Composition and XRD Examples
|
||||
#### Deploy composition and XRD examples
|
||||
Apply the example Composition.
|
||||
|
||||
```yaml
|
||||
|
|
@ -209,9 +208,9 @@ The label `dev` is automatically created from the Composition.
|
|||
{{< /hint >}}
|
||||
|
||||
|
||||
### Create Composite Resources
|
||||
### Create composite resources
|
||||
This tutorial has four composite resources to cover different update policies and composition selection options.
|
||||
The default behavior is updating XRs to the latest revision of the Composition. However, this can be changed by setting
|
||||
The default behavior is updating XRs to the latest revision of the Composition. You can change this by setting
|
||||
`compositionUpdatePolicy: Manual` in the XR. It's also possible to select the latest revision with a specific label
|
||||
with `compositionRevisionSelector.matchLabels` together with `compositionUpdatePolicy: Automatic`.
|
||||
|
||||
|
|
@ -310,11 +309,11 @@ vpc-staging False <none> Automatic map[c
|
|||
The `vpc-staging` XR label doesn't match any existing Composition Revisions.
|
||||
{{< /hint >}}
|
||||
|
||||
### Create new Composition revisions
|
||||
Crossplane creates a new CompositionRevision when a Composition is created or updated. Label and annotation changes will
|
||||
### 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.
|
||||
|
||||
#### Update the Composition label
|
||||
#### Update the composition label
|
||||
Update the `Composition` label to `channel: staging`:
|
||||
```shell
|
||||
kubectl label composition myvpcs.aws.example.upbound.io channel=staging --overwrite
|
||||
|
|
@ -355,7 +354,7 @@ vpc-staging True myvpcs.aws.example.upbound.io-727b3c8 Automatic map[c
|
|||
`vpc-staging` now matches the label applied to Revision `revision:2`.
|
||||
{{< /hint >}}
|
||||
|
||||
#### Update Composition Spec and Label
|
||||
#### Update composition spec and label
|
||||
Update the Composition to disable DNS support in the VPC and change the label from `staging` back to `dev`.
|
||||
|
||||
Apply the following changes to update the `Composition` spec and label:
|
||||
|
|
@ -414,7 +413,7 @@ Changing the label and the spec values simultaneously is critical for deploying
|
|||
{{< /hint >}}
|
||||
|
||||
Verify Crossplane assigns the Composite Resources `vpc-auto` and `vpc-dev` to Composite `revision:3`.
|
||||
`vpc-staging` is assigned to `revision:2`, and `vpc-man` is still assigned to the original `revision:1`:
|
||||
Crossplane assigns `vpc-staging` to `revision:2`, and still assigns `vpc-man` to the original `revision:1`:
|
||||
|
||||
```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"
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ You use two Crossplane types to create a new custom API:
|
|||
* A Composition - This page. Configures how the XR creates other resources.
|
||||
{{</expand >}}
|
||||
|
||||
## Create a Composition
|
||||
## Create a composition
|
||||
|
||||
Creating a Composition consists of:
|
||||
* [Using composition functions](#use-a-function-in-a-composition) to define the
|
||||
|
|
@ -492,7 +492,7 @@ the container, and `Orphan`, to leave it running.
|
|||
running at the specified target. It uses
|
||||
[gRPC target syntax](https://github.com/grpc/grpc/blob/v1.59.1/doc/naming.md).
|
||||
|
||||
## Verify a Composition
|
||||
## Verify a composition
|
||||
|
||||
View all available Compositions with `kubectl get composition`.
|
||||
|
||||
|
|
|
|||
|
|
@ -34,8 +34,10 @@ environment.
|
|||
{{< /hint >}}
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
## Create an EnvironmentConfig
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
An {{<hover label="env1" line="2">}}EnvironmentConfig{{</hover>}} has a single
|
||||
object field,
|
||||
|
|
@ -63,27 +65,30 @@ data:
|
|||
- item2
|
||||
```
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
## Access EnvironmentConfigs
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
`EnvironmentConfigs` can be accessed by [Composition Functions] supporting
|
||||
[Composition Functions] supporting
|
||||
[extra-resources], for example [function-environment-configs] or
|
||||
[function-go-templating].
|
||||
|
||||
## Migration from Alpha Composition Environment
|
||||
## Migration from alpha composition environment
|
||||
|
||||
Crossplane (`<=v1.17`) natively supported selecting `EnvironmentConfigs`,
|
||||
merging them into an `in-memory environment` and patching between that,
|
||||
composed and composite resources. From `v1.18`, this native capability has been
|
||||
removed, in favor of [Composition Functions].
|
||||
composed and composite resources. From `v1.18`, Crossplane removed this native capability, in favor of [Composition Functions].
|
||||
|
||||
Users that enabled Alpha Composition Environments
|
||||
(`--enable-environment-configs`) and leveraged the native functionality
|
||||
(`--enable-environment-configs`) and leveraged the native features
|
||||
(`spec.environment.patches`, `spec.environment.environmentConfigs` and
|
||||
`*Environment` patches), will have to migrate to Composition Functions to
|
||||
`*Environment` patches), have to migrate to Composition Functions to
|
||||
continue doing so.
|
||||
|
||||
Automated migration to `Pipeline` mode is available through `crossplane beta
|
||||
convert pipeline-composition`, which will move a composition using `Resource`
|
||||
convert pipeline-composition`, which moves a composition using `Resource`
|
||||
mode, to [function-patch-and-transform] and, if needed,
|
||||
[function-environment-configs].
|
||||
|
||||
|
|
@ -96,8 +101,8 @@ migration.
|
|||
|
||||
Select the EnvironmentConfigs to use through [function-environment-configs]'s `Input`.
|
||||
|
||||
The `environmentConfigs` field is a list of `EnvironmentConfigs` we want
|
||||
retrieved, merged and passed to the next step in the pipeline through the
|
||||
The `environmentConfigs` field is a list of `EnvironmentConfigs` to
|
||||
retrieve, merge and pass to the next step in the pipeline through the
|
||||
[Context] at a well known key, `apiextensions.crossplane.io/environment`.
|
||||
|
||||
Select an environment by `Reference` or by `Selector`:
|
||||
|
|
@ -217,7 +222,7 @@ only uses the first environment in the sorted list.
|
|||
|
||||
Set the `selector.mode` to `Multiple` to return all matched EnvironmentConfigs.
|
||||
Use `mode: Single` to return a single environment, and error out if more than
|
||||
one match is found.
|
||||
Crossplane finds one match.
|
||||
|
||||
Sorting and the selection mode only applies to a single `Selector`.
|
||||
|
||||
|
|
@ -347,7 +352,7 @@ the `key` first using a `Value` selector, then define the `Optional`
|
|||
|
||||
For example, the Composition below defines `value: my-default-value` for the key
|
||||
`my-second-label-key`. If the Composite resource defines
|
||||
`spec.parameters.deploy`, [function-environment-configs] will use that instead.
|
||||
`spec.parameters.deploy`, [function-environment-configs] uses that instead.
|
||||
|
||||
```yaml {label="byLabelOptionalDefault",copy-lines="all"}
|
||||
apiVersion: apiextensions.crossplane.io/v1
|
||||
|
|
@ -391,12 +396,12 @@ value.
|
|||
|
||||
## Patching with EnvironmentConfigs using function-patch-and-transform
|
||||
|
||||
`EnvironmentConfigs` selected as explained above, are then merged in an
|
||||
`EnvironmentConfigs` selected as explained earlier, are then merged in an
|
||||
`in-memory environment` by [function-environment-configs] and passed to the
|
||||
next function in the pipeline at a well known key,
|
||||
`apiextensions.crossplane.io/environment`.
|
||||
|
||||
[function-patch-and-transform] can be used to read or write data between the in-memory environment and
|
||||
You can use [function-patch-and-transform] to read or write data between the in-memory environment and
|
||||
composite resource or individual composed resources.
|
||||
|
||||
{{<hint "tip" >}}
|
||||
|
|
@ -442,7 +447,7 @@ spec:
|
|||
|
||||
Individual resources can use any data written to the in-memory environment.
|
||||
|
||||
`CombineFromComposite` and `CombineToComposite` can be used to combine multiple
|
||||
You can use `CombineFromComposite` and `CombineToComposite` to combine multiple
|
||||
values and write the result either to the in-memory environment or the
|
||||
Composite resource, respectively.
|
||||
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ kubectl create secret generic aws-secret \
|
|||
|
||||
{{<hint "important">}}
|
||||
Crossplane providers don't have to store their credentials in a secret. They
|
||||
can load their credentials from various sources.
|
||||
can load their credentials from multiple sources.
|
||||
{{</hint>}}
|
||||
|
||||
Next, [configure the provider](#configure-the-provider) to use the credentials.
|
||||
|
|
|
|||
|
|
@ -17,12 +17,20 @@ If you don't have a Kubernetes cluster create one locally with [Kind](https://ki
|
|||
* An actively [supported Kubernetes version](https://kubernetes.io/releases/patch-releases/#support-period)
|
||||
* [Helm](https://helm.sh/docs/intro/install/) version `v3.2.0` or later
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
## Install Crossplane
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
Install Crossplane using the _Helm chart_.
|
||||
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
### Add the Crossplane Preview Helm repository
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
Add the Crossplane preview repository with the `helm repo add` command.
|
||||
|
||||
|
|
@ -36,7 +44,11 @@ local Helm chart cache with `helm repo update`.
|
|||
helm repo update
|
||||
```
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
### Install the Crossplane Preview Helm chart
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
Install the Crossplane Preview Helm chart with `helm install`.
|
||||
|
||||
|
|
@ -66,7 +78,11 @@ crossplane-rbac-manager-86d9b5cf9f-2vc4s 1/1 Running 0 26m
|
|||
|
||||
## Installation options
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
### Customize the Crossplane Helm chart
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
Crossplane supports customizations at install time by configuring the Helm
|
||||
chart.
|
||||
|
|
|
|||
|
|
@ -1,11 +1,15 @@
|
|||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.HeadingAcronyms = NO -->
|
||||
---
|
||||
title: Configuring Crossplane with Argo CD
|
||||
weight: 270
|
||||
---
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.HeadingAcronyms = YES -->
|
||||
|
||||
[Argo CD](https://argoproj.github.io/cd/) and [Crossplane](https://crossplane.io)
|
||||
are a great combination. Argo CD provides GitOps while Crossplane turns any Kubernetes
|
||||
cluster into a Universal Control Plane for all of your resources. Configuration details are
|
||||
cluster into a Universal Control Plane for all your resources. Configuration details are
|
||||
required in order for the two to work together properly.
|
||||
This doc will help you understand these requirements. It is recommended to use
|
||||
Argo CD version 2.4.8 or later with Crossplane.
|
||||
|
|
@ -15,12 +19,16 @@ with those running in a Kubernetes cluster (GitOps). Argo CD has different ways
|
|||
how it tracks resources. With Crossplane, you need to configure Argo CD
|
||||
to use Annotation based resource tracking. See the [Argo CD docs](https://argo-cd.readthedocs.io/en/latest/user-guide/resource_tracking/) for additional detail.
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.HeadingAcronyms = NO -->
|
||||
### Configuring Argo CD with Crossplane
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.HeadingAcronyms = YES -->
|
||||
|
||||
#### Set Resource Tracking Method
|
||||
#### Set resource tracking method
|
||||
|
||||
In order for Argo CD to correctly track Application resources that contain Crossplane related objects it needs
|
||||
to be configured to use the annotation mechanism.
|
||||
In order for Argo CD to track Application resources that contain Crossplane related objects, configure it
|
||||
to use the annotation mechanism.
|
||||
|
||||
To configure it, edit the `argocd-cm` `ConfigMap` in the `argocd` `Namespace` as such:
|
||||
```yaml
|
||||
|
|
@ -30,11 +38,11 @@ data:
|
|||
application.resourceTrackingMethod: annotation
|
||||
```
|
||||
|
||||
#### Set Health Status
|
||||
#### Set health status
|
||||
|
||||
Argo CD has a built-in health assessment for Kubernetes resources. Some checks are supported by the community directly
|
||||
Argo CD has a built-in health assessment for Kubernetes resources. The community directly supports some checks
|
||||
in Argo's [repository](https://github.com/argoproj/argo-cd/tree/master/resource_customizations). For example the `Provider`
|
||||
from `pkg.crossplane.io` has already been declared which means there no further configuration needed.
|
||||
from `pkg.crossplane.io` already exists which means there no further configuration needed.
|
||||
|
||||
Argo CD also enable customising these checks per instance, and that's the mechanism used to provide support
|
||||
of Provider's CRDs.
|
||||
|
|
@ -180,13 +188,13 @@ data:
|
|||
return health_status
|
||||
```
|
||||
|
||||
#### Set Resource Exclusion
|
||||
#### Set resource exclusion
|
||||
|
||||
Crossplane providers generates a `ProviderConfigUsage` for each of the managed resource (MR) it handles. This resource
|
||||
enable representing the relationship between MR and a ProviderConfig so that the controller can use it as finalizer when a
|
||||
ProviderConfig is deleted. End users of Crossplane aren't expected to interact with this resource.
|
||||
Crossplane providers generate a `ProviderConfigUsage` for each managed resource (MR) they handle. This resource
|
||||
enables representing the relationship between MR and a ProviderConfig so that the controller can use it as a finalizer when you delete a
|
||||
ProviderConfig. End users of Crossplane don't need to interact with this resource.
|
||||
|
||||
Argo CD UI reactivity can be impacted as the number of resource and types grow. To help keep this number low we
|
||||
A growing number of resources and types can impact Argo CD UI reactivity. To help keep this number low, Crossplane
|
||||
recommend hiding all `ProviderConfigUsage` resources from Argo CD UI.
|
||||
|
||||
To configure resource exclusion edit the `argocd-cm` `ConfigMap` in the `argocd` `Namespace` as such:
|
||||
|
|
@ -201,15 +209,19 @@ data:
|
|||
- ProviderConfigUsage
|
||||
```
|
||||
|
||||
The use of `"*"` as apiGroups will enable the mechanism for all Crossplane Providers.
|
||||
The use of `"*"` as apiGroups enables the mechanism for all Crossplane Providers.
|
||||
|
||||
#### Increase Kubernetes Client QPS
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.HeadingAcronyms = NO -->
|
||||
#### Increase Kubernetes client QPS
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.HeadingAcronyms = YES -->
|
||||
|
||||
As the number of CRDs grow on a control plane it will increase the amount of queries Argo CD Application Controller
|
||||
As the number of CRDs grow on a control plane it increases the amount of queries Argo CD Application Controller
|
||||
needs to send to the Kubernetes API. If this is the case you can increase the rate limits of the Argo CD Kubernetes client.
|
||||
|
||||
Set the environment variable `ARGOCD_K8S_CLIENT_QPS` to `300` for improved compatibility with a large number of CRDs.
|
||||
Set the environment variable `ARGOCD_K8S_CLIENT_QPS` to `300` for improved compatibility with multiple CRDs.
|
||||
|
||||
The default value of `ARGOCD_K8S_CLIENT_QPS` is 50, modifying the value will also update `ARGOCD_K8S_CLIENT_BURST` as it
|
||||
The default value of `ARGOCD_K8S_CLIENT_QPS` is 50, modifying the value also updates `ARGOCD_K8S_CLIENT_BURST` as it
|
||||
is default to `ARGOCD_K8S_CLIENT_QPS` x 2.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,9 @@ description: "Configuring build pipelines for Crossplane extensions with GitHub
|
|||
Actions"
|
||||
---
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
## Distributing Crossplane extensions
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
Crossplane provides a packaging specification for extending a Crossplane
|
||||
instance with APIs and business logic for composing resources.
|
||||
|
|
@ -112,7 +114,7 @@ The workflow generates a default version string if user input isn't provided.
|
|||
See [branching conventions](#branching-conventions) for more details on tagging
|
||||
practices and optionally overriding the inferred git tag version.
|
||||
|
||||
## Common Configuration
|
||||
## Common configuration
|
||||
|
||||
While the reusable workflows referenced in the quickstart guides are for
|
||||
convenience, users may choose to write their own custom GitHub Actions.
|
||||
|
|
@ -248,7 +250,7 @@ Edit the following variables to define the target registry:
|
|||
2. `XPKG_REG_ORGS_NO_PROMOTE` - for registries that don't use or infer
|
||||
channel tags.
|
||||
|
||||
For example, the following dual-pushes to `xpkg.crossplane.io` as well as
|
||||
For example, the following dual-pushes to `xpkg.crossplane.io` and
|
||||
`index.docker.io`:
|
||||
|
||||
```make
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Function Patch and Transform
|
||||
weight: 70
|
||||
description: "A function that use patches and transforms to modify inputs from composite resources before creating managed resources"
|
||||
description: "A function that use patches and transforms to change inputs from composite resources before creating managed resources"
|
||||
---
|
||||
|
||||
Function Patch and Transform allows you to write a Composition that specifies
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Metrics
|
||||
weight: 60
|
||||
description: "Metrics are essential for monitoring Crossplane's operations, helping to quickly identify and resolve potential issues."
|
||||
description: "Metrics are essential for monitoring Crossplane's operations, helping to identify and resolve potential issues."
|
||||
---
|
||||
|
||||
Crossplane produces [Prometheus style metrics](https://prometheus.io/docs/introduction/overview/#what-are-metrics) for effective monitoring and alerting in your environment.
|
||||
|
|
|
|||
|
|
@ -1,24 +1,28 @@
|
|||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.HeadingAcronyms = NO -->
|
||||
---
|
||||
title: Self-Signed CA Certs
|
||||
title: Self-signed CA certs
|
||||
weight: 270
|
||||
---
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.HeadingAcronyms = YES -->
|
||||
|
||||
> Using self-signed certificates isn't advised in production, it's
|
||||
recommended to only use self-signed certificates for testing.
|
||||
|
||||
When Crossplane loads Configuration and Provider Packages from private
|
||||
registries, it must be configured to trust the CA and Intermediate certs.
|
||||
registries, you must configure it to trust the CA and Intermediate certs.
|
||||
|
||||
Crossplane needs to be installed via the Helm chart with the
|
||||
You need to install Crossplane via the Helm chart with the
|
||||
`registryCaBundleConfig.name` and `registryCaBundleConfig.key` parameters
|
||||
defined. See [Install Crossplane]({{<ref "../get-started/install" >}}).
|
||||
|
||||
## Configure
|
||||
|
||||
1. Create a CA Bundle (A file containing your Root and Intermediate
|
||||
certificates in a specific order). This can be done with any text editor or
|
||||
certificates in a specific order). You can do this with any text editor or
|
||||
from the command line, so long as the resulting file contains all required crt
|
||||
files in the proper order. In many cases, this will be either a single
|
||||
files in the proper order. Often, this is either a single
|
||||
self-signed Root CA crt file, or an Intermediate crt and Root crt file. The
|
||||
order of the crt files should be from lowest to highest in signing order.
|
||||
For example, if you have a chain of two certificates below your Root
|
||||
|
|
@ -39,7 +43,7 @@ kubectl -n [Crossplane system namespace] create cm ca-bundle-config \
|
|||
`ca-bundle-config` and the `registryCaBundleConfig.key` parameter to
|
||||
`ca-bundle`.
|
||||
|
||||
> Providing Helm with parameter values is covered in the Helm docs,
|
||||
> The Helm docs cover providing Helm with parameter values,
|
||||
[Helm install](https://helm.sh/docs/helm/helm_install/). An example block
|
||||
in an `override.yaml` file would look like this:
|
||||
```
|
||||
|
|
|
|||
|
|
@ -2,22 +2,22 @@
|
|||
title: Troubleshoot Crossplane
|
||||
weight: 306
|
||||
---
|
||||
## Requested Resource Not Found
|
||||
## Requested resource not found
|
||||
|
||||
If you use the Crossplane CLI to install a `Provider` or
|
||||
`Configuration` (for example, `crossplane xpkg install provider
|
||||
xpkg.crossplane.io/crossplane-contrib/provider-aws-s3:v1.21.1`) and get `the server
|
||||
could not find the requested resource` error, more often than not, that's an
|
||||
indicator that the Crossplane CLI you're using is outdated. In other words
|
||||
some Crossplane API has been graduated from alpha to beta or stable and the old
|
||||
indicator that your Crossplane CLI needs updating. In other words
|
||||
Crossplane graduated some API from alpha to beta or stable and the old
|
||||
plugin isn't aware of this change.
|
||||
|
||||
|
||||
## Resource Status and Conditions
|
||||
## Resource status and conditions
|
||||
|
||||
Most Crossplane resources have a `status` section that can represent the current
|
||||
state of that particular resource. Running `kubectl describe` against a
|
||||
Crossplane resource will frequently give insightful information about its
|
||||
Crossplane resource frequently gives insightful information about its
|
||||
condition. For example, to determine the status of a GCP `CloudSQLInstance`
|
||||
managed resource use `kubectl describe` for the resource.
|
||||
|
||||
|
|
@ -35,7 +35,7 @@ Most Crossplane resources set the `Ready` condition. `Ready` represents the
|
|||
availability of the resource - whether it's creating, deleting, available,
|
||||
unavailable, binding, etc.
|
||||
|
||||
## Resource Events
|
||||
## Resource events
|
||||
|
||||
Most Crossplane resources emit _events_ when something interesting happens. You
|
||||
can see the events associated with a resource by running `kubectl describe` -
|
||||
|
|
@ -49,11 +49,15 @@ Events:
|
|||
Warning CannotConnectToProvider 16s (x4 over 46s) managed/postgresqlserver.database.azure.crossplane.io cannot get referenced ProviderConfig: ProviderConfig.azure.crossplane.io "default" not found
|
||||
```
|
||||
|
||||
> Note that events are namespaced, while many Crossplane resources (XRs, etc)
|
||||
> Note that Kubernetes namespaces events, while most Crossplane resources (XRs, etc)
|
||||
> are cluster scoped. Crossplane emits events for cluster scoped resources to
|
||||
> the 'default' namespace.
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
## Crossplane Logs
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
The next place to look to get more information or investigate a failure would be
|
||||
in the Crossplane pod logs, which should be running in the `crossplane-system`
|
||||
|
|
@ -63,16 +67,16 @@ namespace. To get the current Crossplane logs, run the following:
|
|||
kubectl -n crossplane-system logs -lapp=crossplane
|
||||
```
|
||||
|
||||
> Note that Crossplane emits few logs by default - events are typically the best
|
||||
> Note that Crossplane emits minimal logs by default - events are typically the best
|
||||
> place to look for information about what Crossplane is doing. You may need to
|
||||
> restart Crossplane with the `--debug` flag if you can't find what you're
|
||||
> looking for.
|
||||
|
||||
## Provider Logs
|
||||
## Provider logs
|
||||
|
||||
Remember that much of Crossplane's functionality is provided by providers. You
|
||||
Remember that providers provide much of Crossplane's features. You
|
||||
can use `kubectl logs` to view provider logs too. By convention, they also emit
|
||||
few logs by default.
|
||||
minimal logs by default.
|
||||
|
||||
```shell
|
||||
kubectl -n crossplane-system logs <name-of-provider-pod>
|
||||
|
|
@ -110,21 +114,21 @@ spec:
|
|||
name: debug-config
|
||||
```
|
||||
|
||||
> Note that a reference to a `DeploymentRuntimeConfig` can be added to an already
|
||||
> installed `Provider` and it will update its `Deployment` accordingly.
|
||||
> Note that you can add a reference to a `DeploymentRuntimeConfig` to an already
|
||||
> installed `Provider` and it updates its `Deployment` accordingly.
|
||||
|
||||
## Pausing Crossplane
|
||||
|
||||
Sometimes, for example when you encounter a bug, it can be useful to pause
|
||||
Crossplane if you want to stop it from actively attempting to manage your
|
||||
resources. To pause Crossplane without deleting all of its resources, run the
|
||||
resources. To pause Crossplane without deleting all its resources, run the
|
||||
following command to scale down its deployment:
|
||||
|
||||
```shell
|
||||
kubectl -n crossplane-system scale --replicas=0 deployment/crossplane
|
||||
```
|
||||
|
||||
Once you have been able to rectify the problem or smooth things out, you can
|
||||
After you have been able to rectify the problem or smooth things out, you can
|
||||
unpause Crossplane by scaling its deployment back up:
|
||||
|
||||
```shell
|
||||
|
|
@ -133,10 +137,9 @@ kubectl -n crossplane-system scale --replicas=1 deployment/crossplane
|
|||
|
||||
## Pausing Providers
|
||||
|
||||
Providers can also be paused when troubleshooting an issue or orchestrating a
|
||||
You can also pause Providers when troubleshooting an issue or orchestrating a
|
||||
complex migration of resources. Creating and referencing a `DeploymentRuntimeConfig` is
|
||||
the easiest way to scale down a provider, and the `DeploymentRuntimeConfig` can be
|
||||
modified or the reference can be removed to scale it back up:
|
||||
the easiest way to scale down a provider, and you can change the `DeploymentRuntimeConfig` or remove the reference to scale it back up:
|
||||
|
||||
```yaml
|
||||
apiVersion: pkg.crossplane.io/v1beta1
|
||||
|
|
@ -162,23 +165,23 @@ spec:
|
|||
name: scale-config
|
||||
```
|
||||
|
||||
> Note that a reference to a `DeploymentRuntimeConfig` can be added to an already
|
||||
> installed `Provider` and it will update its `Deployment` accordingly.
|
||||
> Note that you can add a reference to a `DeploymentRuntimeConfig` to an already
|
||||
> installed `Provider` and it updates its `Deployment` accordingly.
|
||||
|
||||
## Deleting When a Resource Hangs
|
||||
## Deleting when a resource hangs
|
||||
|
||||
The resources that Crossplane manages will automatically be cleaned up so as not
|
||||
to leave anything running behind. This is accomplished by using finalizers, but
|
||||
The resources that Crossplane manages are automatically cleaned up so as not
|
||||
to leave anything running behind. Crossplane accomplishes this by using finalizers, but
|
||||
in certain scenarios the finalizer can prevent the Kubernetes object from
|
||||
getting deleted.
|
||||
|
||||
To deal with this, we essentially want to patch the object to remove its
|
||||
finalizer, which will then allow it to be deleted completely. Note that this
|
||||
won't necessarily delete the external resource that Crossplane was managing, so
|
||||
you will want to go to your cloud provider's console and look there for any
|
||||
To deal with this, patch the object to remove its
|
||||
finalizer, which then allows Kubernetes to delete it. Note that this
|
||||
doesn't necessarily delete the external resource that Crossplane was managing, so
|
||||
you want to go to your cloud provider's console and look there for any
|
||||
lingering resources to clean up.
|
||||
|
||||
In general, a finalizer can be removed from an object with this command:
|
||||
In general, you can remove a finalizer from an object with this command:
|
||||
|
||||
```shell
|
||||
kubectl patch <resource-type> <resource-name> -p '{"metadata":{"finalizers": []}}' --type=merge
|
||||
|
|
@ -191,9 +194,9 @@ For example, for a `CloudSQLInstance` managed resource (`database.gcp.crossplane
|
|||
kubectl patch cloudsqlinstance my-db -p '{"metadata":{"finalizers": []}}' --type=merge
|
||||
```
|
||||
|
||||
## Tips, Tricks, and Troubleshooting
|
||||
## Tips, tricks, and troubleshooting
|
||||
|
||||
In this section we'll cover some common tips, tricks, and troubleshooting steps
|
||||
This section covers some common tips, tricks, and troubleshooting steps
|
||||
for working with Composite Resources. If you're trying to track down why your
|
||||
Composite Resources aren't working the [Troubleshooting][trouble-ref] page also
|
||||
has some useful information.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,9 @@ in order.
|
|||
This can leave cloud resources running, requiring manual deletion.
|
||||
{{< /hint >}}
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
## Ordered Crossplane uninstall
|
||||
<!-- vale Google.Headings = YES -->
|
||||
Most Crossplane resources have dependencies on other Crossplane resources.
|
||||
|
||||
For example, a _managed resource_ is dependent on the _provider_.
|
||||
|
|
@ -128,7 +130,9 @@ Use `kubectl delete` to remove the resources.
|
|||
kubectl delete bucket.s3.aws.upbound.io/crossplane-bucket-867737b10
|
||||
```
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
### Remove Crossplane providers
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
List the installed _providers_ with `kubectl get providers`.
|
||||
|
||||
|
|
@ -144,7 +148,9 @@ Remove the installed _providers_ with `kubectl delete provider`.
|
|||
kubectl delete provider crossplane-contrib-provider-aws
|
||||
```
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
## Uninstall the Crossplane deployment
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
Uninstall Crossplane using Helm with `helm uninstall`
|
||||
|
||||
|
|
@ -159,7 +165,9 @@ kubectl get pods -n crossplane-system
|
|||
No resources found in crossplane-system namespace.
|
||||
```
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
## Delete the Crossplane namespace
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
When Helm installs Crossplane it creates the `crossplane-system` namespace. Helm
|
||||
doesn't uninstall this namespace with `helm uninstall`.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Learn more about Crossplane.
|
|||
weight: 500
|
||||
---
|
||||
|
||||
If you have any questions, please drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us].
|
||||
If you have any questions, please post in [Crossplane Slack][join-crossplane-slack] or [contact the team][contact-us].
|
||||
|
||||
***Learn more about using Crossplane***
|
||||
- [Latest Design Docs](https://github.com/crossplane/crossplane/tree/main/design)
|
||||
|
|
@ -12,7 +12,9 @@ If you have any questions, please drop us a note on [Crossplane Slack][join-cros
|
|||
- [Crossplane Architecture](https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9xdK29Er45NJeoemxebo/edit?usp=sharing)
|
||||
- [GitLab deploys into multiple clouds from kubectl using Crossplane](https://about.gitlab.com/2019/05/20/gitlab-first-deployed-kubernetes-api-to-multiple-clouds/)
|
||||
- [CNCF Talks & Community Presentations](https://www.youtube.com/playlist?list=PL510POnNVaaZJj9OG6PbgsZvgYbhwJRyE)
|
||||
<!-- vale write-good.Weasel = NO -->
|
||||
- [Software Engineering Daily - Intro Podcast](https://softwareengineeringdaily.com/2019/01/02/crossplane-multicloud-control-plane-with-bassam-tabbara/)
|
||||
<!-- vale write-good.Weasel = YES -->
|
||||
|
||||
***Writing Kubernetes controllers to extend Crossplane***
|
||||
- [Keep the Space Shuttle Flying: Writing Robust Operators](https://www.youtube.com/watch?v=uf97lOApOv8)
|
||||
|
|
@ -21,14 +23,16 @@ If you have any questions, please drop us a note on [Crossplane Slack][join-cros
|
|||
- [Contributor Guide](https://github.com/crossplane/crossplane/blob/main/CONTRIBUTING.md)
|
||||
|
||||
***Join the growing Crossplane community and get involved***
|
||||
- Join our [Community Slack](https://slack.crossplane.io/)!
|
||||
- Join the [Community Slack](https://slack.crossplane.io/)!
|
||||
- Submit an issue on [GitHub](https://github.com/crossplane/crossplane)
|
||||
- Attend our biweekly [Community Meeting](https://github.com/crossplane/crossplane#get-involved)
|
||||
- Join our biweekly live stream: [The Binding Status](https://github.com/crossplane/tbs)
|
||||
- Subscribe to our [YouTube Channel](https://www.youtube.com/channel/UC19FgzMBMqBro361HbE46Fw)
|
||||
- Attend the biweekly [Community Meeting](https://github.com/crossplane/crossplane#get-involved)
|
||||
- Join the biweekly live stream: [The Binding Status](https://github.com/crossplane/tbs)
|
||||
- Subscribe to the [YouTube Channel](https://www.youtube.com/channel/UC19FgzMBMqBro361HbE46Fw)
|
||||
<!-- vale Crossplane.Spelling = NO -->
|
||||
- Drop us a note on Twitter: [@crossplane_io](https://twitter.com/crossplane_io)
|
||||
- Email us: [crossplane-info@lists.cncf.io](mailto:crossplane-info@lists.cncf.io)
|
||||
- Follow on Twitter: [@crossplane_io](https://twitter.com/crossplane_io)
|
||||
<!-- vale gitlab.SubstitutionWarning = NO -->
|
||||
- email: [crossplane-info@lists.cncf.io](mailto:crossplane-info@lists.cncf.io)
|
||||
<!-- vale gitlab.SubstitutionWarning = YES -->
|
||||
<!-- vale Crossplane.Spelling = YES -->
|
||||
|
||||
<!-- Named links -->
|
||||
|
|
|
|||
|
|
@ -5,56 +5,60 @@ weight: 309
|
|||
indent: true
|
||||
---
|
||||
|
||||
# Feature Lifecycle
|
||||
# Feature lifecycle
|
||||
|
||||
Crossplane follows a similar feature lifecycle to [upstream
|
||||
Kubernetes][kube-features]. All major new features must be added in alpha. Alpha
|
||||
features are expected to eventually graduate to beta, and then to general
|
||||
Kubernetes][kube-features]. Crossplane adds all major new features in alpha. Alpha
|
||||
features graduate to beta, and then to general
|
||||
availability (GA). Features that languish at alpha or beta may be subject to
|
||||
deprecation.
|
||||
|
||||
## Alpha Features
|
||||
## Alpha features
|
||||
|
||||
Alpha are off by default, and must be enabled by a feature flag, for example
|
||||
`--enable-composition-revisions`. API types pertaining to alpha features use a
|
||||
Alpha features are off by default, and you must enable them by a feature flag, for example
|
||||
`--enable-composition-revisions`. API types for alpha features use a
|
||||
`vNalphaN` style API version, like `v1alpha`. **Alpha features are subject to
|
||||
removal or breaking changes without notice**, and generally not considered ready
|
||||
removal or breaking changes without notice**, and aren't considered ready
|
||||
for use in production.
|
||||
|
||||
In some cases alpha features require fields be added to existing beta or GA
|
||||
Sometimes alpha features require Crossplane to add fields to existing beta or GA
|
||||
<!-- vale alex.Condescending = NO -->
|
||||
API types. In these cases fields must clearly be marked (for instance in their OpenAPI
|
||||
API types. In these cases you must mark fields (for instance in their OpenAPI
|
||||
<!-- vale alex.Condescending = YES -->
|
||||
schema) as alpha and subject to alpha API constraints (or lack thereof).
|
||||
|
||||
All alpha features should have an issue tracking their graduation to beta.
|
||||
|
||||
## Beta Features
|
||||
## Beta features
|
||||
|
||||
Beta features are on by default, but may be disabled by a feature flag. API
|
||||
types pertaining to beta features use a `vNbetaN` style API version, like
|
||||
`v1beta1`. Beta features are considered to be well tested, and won't be
|
||||
removed completely without being marked deprecated for at least two releases.
|
||||
Beta features are on by default, but you may disable them by a feature flag. API
|
||||
types for beta features use a `vNbetaN` style API version, like
|
||||
`v1beta1`. Crossplane considers beta features to be well tested, and doesn't
|
||||
removed without Crossplane marking them deprecated for at least two releases.
|
||||
|
||||
The schema and/or semantics of objects may change in incompatible ways in a
|
||||
subsequent beta or stable release. When this happens, we will provide
|
||||
later beta or stable release. When this happens, the team provides
|
||||
instructions for migrating to the next version. This may require deleting,
|
||||
editing, and recreating API objects. The editing process may require some
|
||||
thought. This may require downtime for applications that rely on the feature.
|
||||
|
||||
In some cases beta features require fields be added to existing GA API types. In
|
||||
Sometimes beta features require Crossplane to add fields to existing GA API types. In
|
||||
<!-- vale alex.Condescending = NO -->
|
||||
these cases fields must clearly be marked (for instance in their OpenAPI schema) as beta
|
||||
these cases you must mark fields (for instance in their OpenAPI schema) as beta
|
||||
<!-- vale alex.Condescending = YES -->
|
||||
and subject to beta API constraints (or lack thereof).
|
||||
|
||||
All beta features should have an issue tracking their graduation to GA.
|
||||
|
||||
## GA Features
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.HeadingAcronyms = NO -->
|
||||
## GA features
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.HeadingAcronyms = YES -->
|
||||
|
||||
GA features are always enabled - they can't be disabled. API types pertaining
|
||||
GA features are always enabled - you can't disable them. API types pertaining
|
||||
to GA features use `vN` style API versions, like `v1`. GA features are widely
|
||||
used and thoroughly tested. They guarantee API stability - only backward
|
||||
compatible changes are allowed.
|
||||
used and well tested. They guarantee API stability - Crossplane only allows backward
|
||||
compatible changes.
|
||||
|
||||
[kube-features]: https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#feature-stages
|
||||
|
|
@ -3,49 +3,48 @@ title: Release Cycle
|
|||
weight: 308
|
||||
---
|
||||
|
||||
Starting with the v1.10.0 release, Crossplane is released on a quarterly (13
|
||||
week) cadence. A cycle is comprised of three general stages:
|
||||
Starting with the v1.10.0 release, Crossplane releases on a quarterly (13
|
||||
week) cadence. A cycle comprises three general stages:
|
||||
|
||||
- Weeks 1—11: [Active Development]
|
||||
- Week 12: [Feature Freeze]
|
||||
- Week 13: [Code Freeze]
|
||||
|
||||
This results in four releases per year, with the most recent three releases
|
||||
being maintained at any given time. When a new release is cut, the fourth most
|
||||
recent release reaches end of life (EOL). Users can expect any given release to
|
||||
be maintained for nine months.
|
||||
under maintenance at any given time. When Crossplane cuts a new release, the fourth most
|
||||
recent release reaches end of life (EOL). Users can expect Crossplane to maintain any given release
|
||||
for nine months.
|
||||
|
||||
### Definition of maintenance
|
||||
|
||||
The Crossplane community defines maintenance in that relevant bug fixes that are
|
||||
merged to the main development branch will be eligible to be backported to the
|
||||
release branch of any currently maintained version, and patch releases will be
|
||||
cut appropriately. It's also possible that a fix may be merged directly to the
|
||||
The Crossplane community defines maintenance in that relevant bug fixes that
|
||||
merge to the main development branch are eligible for backporting to the
|
||||
release branch of any maintained version, and Crossplane cuts patch releases
|
||||
appropriately. It's also possible that maintainers merge a fix directly to the
|
||||
release branch if no longer applicable on the main development branch.
|
||||
Maintenance doesn't indicate any SLA on response time for user support in the
|
||||
form of Slack messages or issues, but problems will be addressed on a best
|
||||
effort basis by maintainers and contributors for currently maintained releases.
|
||||
Maintenance doesn't include any SLA on response time for user support in the
|
||||
form of Slack messages or issues, but maintainers and contributors address problems on a best
|
||||
effort basis for maintained releases.
|
||||
|
||||
### Patch releases
|
||||
|
||||
_This policy is subject to change in the future._
|
||||
|
||||
Patch releases are cut for currently maintained minor versions on an as needed
|
||||
basis. Any critical backported fixes will be included in a patch release as
|
||||
Crossplane cuts patch releases for maintained minor versions on an as needed
|
||||
basis. Crossplane includes any critical backported fixes in a patch release as
|
||||
soon as possible after merge.
|
||||
|
||||
### Pre-releases
|
||||
|
||||
_This policy is subject to change in the future._
|
||||
|
||||
Alpha, Beta, and RC releases are cut for an upcoming release on an as needed
|
||||
basis. As a policy, at least one pre-release will be cut prior to any minor
|
||||
release. Pre-releases won't be made on release branches.
|
||||
Crossplane cuts Alpha, Beta, and RC releases for an upcoming release on an as needed
|
||||
basis. As a policy, Crossplane cuts at least one pre-release before any minor
|
||||
release. Crossplane doesn't make pre-releases on release branches.
|
||||
|
||||
### Provider releases
|
||||
|
||||
The Crossplane release cycle isn't required to be adhered to by any other
|
||||
Crossplane projects, but a similar cadence is encouraged. Maintainers listed in
|
||||
Other Crossplane projects don't need to adhere to the Crossplane release cycle, but Crossplane encourages a similar cadence. Maintainers listed in
|
||||
each repository's `OWNERS.md` file are responsible for determining and
|
||||
publishing the release cycle for their project.
|
||||
|
||||
|
|
@ -55,32 +54,31 @@ The following stages are the main milestones in a Crossplane release.
|
|||
|
||||
### Active development
|
||||
|
||||
During active development, any code that meets the requisite criteria (such as
|
||||
passing appropriate tests, approved by a maintainer, etc.) will be merged into
|
||||
the main development branch. At present, there is no requirement to formally
|
||||
submit an enhancement proposal prior to the start of the release cycle, but
|
||||
contributors are encouraged to open an issue and gather feedback before starting
|
||||
During active development, maintainers merge any code that meets the requisite criteria (such as
|
||||
passing appropriate tests, approved by a maintainer, etc.) into
|
||||
the main development branch. At present, there is no need to formally
|
||||
submit an enhancement proposal before the start of the release cycle, but
|
||||
Crossplane encourages contributors to open an issue and gather feedback before starting
|
||||
work on a major implementation (see [CONTRIBUTING.md] for more information).
|
||||
|
||||
### Feature freeze
|
||||
|
||||
During feature freeze, no new functionality should be merged into the main
|
||||
development branch. Bug fixes, documentation changes, and non critical changes
|
||||
may be made. In the case that a new feature is deemed absolutely necessary for a
|
||||
release, the Crossplane maintainers will weigh the impact of the change and make
|
||||
a decision on whether it should be included.
|
||||
During feature freeze, maintainers shouldn't merge new features into the main
|
||||
development branch. Maintainers may make bug fixes, documentation changes, and non critical changes. In the case that maintainers deem a new feature essential for a
|
||||
release, the Crossplane maintainers weigh the impact of the change and make
|
||||
a decision on whether to include it.
|
||||
|
||||
### Code freeze
|
||||
|
||||
During code freeze, there should be no changes merged to the main development
|
||||
branch with the following exceptions:
|
||||
- Fixes to a failing test that's deemed to be incorrectly testing
|
||||
functionality.
|
||||
- Documentation only changes. It's possible that a documentation freeze will be
|
||||
implemented in the future, but it's not currently enforced.
|
||||
- Fixes to a critical bug that wasn't previously identified. Merging a bug fix
|
||||
during code freeze requires application for and approval of an exception by
|
||||
Crossplane maintainers. This process is currently informal, but may be
|
||||
features.
|
||||
- Documentation only changes. It's possible that a documentation freeze is
|
||||
implemented in the future, but it's not enforced.
|
||||
- Fixes to a critical bug that wasn't identified before. Merging a bug fix
|
||||
during code freeze requires requesting and approval of an exception by
|
||||
Crossplane maintainers. This process is informal, but may be
|
||||
formalized in the future.
|
||||
|
||||
## Release dates
|
||||
|
|
|
|||
|
|
@ -171,7 +171,7 @@ spec:
|
|||
Matching a controller reference ensures that the matching resource has the same
|
||||
Kubernetes controller reference.
|
||||
|
||||
This is useful for matching a resource that's composed by the same composite
|
||||
Matching a controller reference is useful for matching a resource that's composed by the same composite
|
||||
resource (XR).
|
||||
|
||||
{{<hint "note" >}}
|
||||
|
|
@ -206,7 +206,7 @@ doesn't apply the change. Crossplane never deletes a resource based on a
|
|||
Crossplane behaves differently than other tools like Terraform. Terraform
|
||||
deletes and recreates a resource to change an immutable field. Crossplane only
|
||||
deletes an external resource if their corresponding managed
|
||||
resource object is deleted from Kubernetes.
|
||||
you delete the resource object from Kubernetes.
|
||||
<!-- vale write-good.Passive = YES -->
|
||||
{{< /hint >}}
|
||||
|
||||
|
|
@ -615,7 +615,7 @@ that it might have leaked a resource.
|
|||
{{<hint "note">}}
|
||||
Providers don't remove the creation annotations. They use the timestamps to
|
||||
determine which is most recent. It's normal for a managed resource to have
|
||||
several creation annotations.
|
||||
multiple creation annotations.
|
||||
{{</hint>}}
|
||||
|
||||
The provider knows it might have leaked a resource because it updates all the
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ for the second one.
|
|||
|
||||
## Enable usages
|
||||
<!-- vale write-good.Passive = NO -->
|
||||
Usages are a beta feature. Beta features are enabled by default.
|
||||
Usages are a beta feature. Crossplane enables beta features by default.
|
||||
<!-- vale write-good.Passive = YES -->
|
||||
|
||||
Disable `Usage` support by
|
||||
|
|
@ -270,7 +270,9 @@ spec:
|
|||
name: my-prometheus-chart
|
||||
```
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
## ClusterUsages
|
||||
<!-- vale Google.Headings = YES -->
|
||||
|
||||
Use a `ClusterUsage` to protect cluster scoped resources.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Refer to the
|
|||
details on their usage of packages.
|
||||
{{< /hint >}}
|
||||
|
||||
## Install a Configuration
|
||||
## Install a configuration
|
||||
|
||||
Install a Configuration with a Crossplane
|
||||
{{<hover line="2" label="install">}}Configuration{{</hover>}} object by setting
|
||||
|
|
@ -69,7 +69,11 @@ spec:
|
|||
Crossplane installs the Compositions, Composite Resource Definitions and
|
||||
Providers listed in the Configuration.
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
### Install with Helm
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
Crossplane supports installing Configurations during an initial Crossplane
|
||||
installation with the Crossplane Helm chart.
|
||||
|
|
@ -279,24 +283,24 @@ Crossplane can automatically upgrade a package's dependency version to the minim
|
|||
valid version that satisfies all the constraints. It's an alpha feature that
|
||||
requires enabling with the `--enable-dependency-version-upgrades` flag.
|
||||
|
||||
In some cases, dependency version downgrade is required for proceeding with
|
||||
Sometimes, Crossplane requires dependency version downgrade for proceeding with
|
||||
installations. Suppose configuration A, which depends on package X with the
|
||||
constraint`>=v0.0.0`, is installed on the control plane. In this case, the package
|
||||
constraint`>=v0.0.0`, installs on the control plane. In this case, the package
|
||||
manager installs the latest version of package X, such as `v3.0.0`. Later, you decide
|
||||
to install configuration B, which depends on package X with the constraint `<=v2.0.0`.
|
||||
Since version `v2.0.0`satisfies both conditions, package X must be downgraded to
|
||||
allow the installation of configuration B which is disabled by default.
|
||||
Since version `v2.0.0`satisfies both conditions, Crossplane must downgrade package X to
|
||||
allow the installation of configuration B, which Crossplane disables by default.
|
||||
|
||||
For enabling automatic dependency version downgrades, there is a configuration
|
||||
option as a helm value `packageManager.enableAutomaticDependencyDowngrade=true`.
|
||||
Downgrading a package can cause unexpected behavior, therefore, this
|
||||
option is disabled by default. After enabling this option, the package manager will
|
||||
automatically downgrade a package's dependency version to the maximum valid version
|
||||
Downgrading a package can cause unexpected behavior, so this
|
||||
Crossplane disables this option by default. After enabling this option, the package manager
|
||||
automatically downgrades a package's dependency version to the maximum valid version
|
||||
that satisfies the constraints.
|
||||
|
||||
{{<hint "note" >}}
|
||||
This configuration requires the `--enable-dependency-version-upgrades` flag.
|
||||
Please check the
|
||||
Please see the
|
||||
[configuration options]({{<ref "../get-started/install#customize-the-crossplane-helm-chart">}})
|
||||
and
|
||||
[feature flags]({{<ref "../get-started/install#feature-flags">}})
|
||||
|
|
@ -310,11 +314,15 @@ Enabling automatic dependency downgrades may have unintended consequences, such
|
|||
|
||||
1) CRDs missing in the downgraded version, possibly leaving orphaned MRs without
|
||||
controllers to reconcile them.
|
||||
2) Loss of data if downgraded CRD versions omit fields that were set before.
|
||||
2) Loss of data if downgraded CRD versions omit fields that you set before.
|
||||
3) Changes in the CRD storage version, which may prevent package version update.
|
||||
{{</hint >}}
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
#### Ignore Crossplane version requirements
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
A Configuration package may require a specific or minimum Crossplane version
|
||||
before installing. By default, Crossplane doesn't install a Configuration if
|
||||
|
|
@ -338,7 +346,7 @@ spec:
|
|||
```
|
||||
|
||||
|
||||
### Verify a Configuration
|
||||
### Verify a configuration
|
||||
|
||||
Verify a Configuration with
|
||||
{{<hover label="verify" line="1">}}kubectl get configuration{{</hover >}}.
|
||||
|
|
@ -400,7 +408,7 @@ The {{<hover label="depend" line="18">}}Events{{</hover>}} show a
|
|||
current version of Crossplane doesn't meet the Configuration package
|
||||
requirements.
|
||||
|
||||
## Create a Configuration
|
||||
## Create a configuration
|
||||
|
||||
Crossplane Configuration packages are
|
||||
[OCI container images](https://opencontainers.org/) containing one or more YAML
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Read the [composition]({{<ref "../composition/compositions">}}) documentation to
|
|||
learn how to use functions in a composition.
|
||||
{{</hint>}}
|
||||
|
||||
## Install a Function
|
||||
## Install a function
|
||||
|
||||
Install a Function with a Crossplane
|
||||
{{<hover label="install" line="2">}}Function{{</hover >}} object setting the
|
||||
|
|
|
|||
|
|
@ -91,12 +91,12 @@ Signature verification is an alpha feature and needs to be enabled with the
|
|||
{{< /hint >}}
|
||||
|
||||
You can use `ImageConfig` to configure signature verification for images. When
|
||||
signature verification is enabled, the package manager verifies the signature of
|
||||
you enable signature verification, the package manager verifies the signature of
|
||||
each image before pulling it. If the signature isn't valid, the package manager
|
||||
rejects the package deployment.
|
||||
|
||||
In the following example, the `ImageConfig` resource named `verify-acme-packages`
|
||||
is configured to verify the signature of images with the prefixes
|
||||
configures verification of the signature of images with the prefixes
|
||||
`registry1.com/acme-co/configuration-foo` and
|
||||
`registry1.com/acme-co/configuration-bar`.
|
||||
|
||||
|
|
@ -152,7 +152,7 @@ secret configuration, as described in the previous section.
|
|||
|
||||
### Checking the signature verification status
|
||||
|
||||
When signature verification is enabled, the respective controller reports the
|
||||
When you enable signature verification, the respective controller reports the
|
||||
verification status as a condition of type `Verified` on the package revision
|
||||
resources. This condition indicates whether the signature verification was
|
||||
successful, failed, skipped, or incomplete due to an error.
|
||||
|
|
@ -209,6 +209,6 @@ verifying the signature of the image in the package revision.
|
|||
|
||||
If you can't see this condition on the package revision resource, namely
|
||||
`ProviderRevision`, `ConfigurationRevision`, or `FunctionRevision`, ensure that
|
||||
the feature is enabled.
|
||||
you enable the feature.
|
||||
|
||||
<!-- vale write-good.Passive = YES -->
|
||||
|
|
@ -30,7 +30,7 @@ These endpoints are
|
|||
<!-- vale write-good.Passive = YES -->
|
||||
|
||||
|
||||
## Install a Provider
|
||||
## Install a provider
|
||||
|
||||
Installing a provider creates new Kubernetes resources representing the
|
||||
Provider's APIs. Installing a provider also creates a Provider pod that's
|
||||
|
|
@ -92,7 +92,11 @@ spec:
|
|||
```
|
||||
{{</hint >}}
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
### Install with Helm
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
Crossplane supports installing Providers during an initial Crossplane
|
||||
installation with the Crossplane Helm chart.
|
||||
|
|
@ -303,24 +307,24 @@ Crossplane can automatically upgrade a package's dependency version to the minim
|
|||
valid version that satisfies all the constraints. It's an alpha feature that
|
||||
requires enabling with the `--enable-dependency-version-upgrades` flag.
|
||||
|
||||
In some cases, dependency version downgrade is required for proceeding with
|
||||
Sometimes, Crossplane requires dependency version downgrade for proceeding with
|
||||
installations. Suppose configuration A, which depends on package X with the
|
||||
constraint`>=v0.0.0`, is installed on the control plane. In this case, the package
|
||||
constraint`>=v0.0.0`, installs on the control plane. In this case, the package
|
||||
manager installs the latest version of package X, such as `v3.0.0`. Later, you decide
|
||||
to install configuration B, which depends on package X with the constraint `<=v2.0.0`.
|
||||
Since version `v2.0.0`satisfies both conditions, package X must be downgraded to
|
||||
allow the installation of configuration B which is disabled by default.
|
||||
Since version `v2.0.0`satisfies both conditions, Crossplane must downgrade package X to
|
||||
allow the installation of configuration B, which Crossplane disables by default.
|
||||
|
||||
For enabling automatic dependency version downgrades, there is a configuration
|
||||
option as a helm value `packageManager.enableAutomaticDependencyDowngrade=true`.
|
||||
Downgrading a package can cause unexpected behavior, therefore, this
|
||||
option is disabled by default. After enabling this option, the package manager will
|
||||
automatically downgrade a package's dependency version to the maximum valid version
|
||||
Downgrading a package can cause unexpected behavior, so this
|
||||
Crossplane disables this option by default. After enabling this option, the package manager
|
||||
automatically downgrades a package's dependency version to the maximum valid version
|
||||
that satisfies the constraints.
|
||||
|
||||
{{<hint "note" >}}
|
||||
This configuration requires the `--enable-dependency-version-upgrades` flag.
|
||||
Please check the
|
||||
Please see the
|
||||
[configuration options]({{<ref "../get-started/install#customize-the-crossplane-helm-chart">}})
|
||||
and
|
||||
[feature flags]({{<ref "../get-started/install#feature-flags">}})
|
||||
|
|
@ -334,11 +338,15 @@ Enabling automatic dependency downgrades may have unintended consequences, such
|
|||
|
||||
1) CRDs missing in the downgraded version, possibly leaving orphaned MRs without
|
||||
controllers to reconcile them.
|
||||
2) Loss of data if downgraded CRD versions omit fields that were set before.
|
||||
2) Loss of data if downgraded CRD versions omit fields that you set before.
|
||||
3) Changes in the CRD storage version, which may prevent package version update.
|
||||
{{</hint >}}
|
||||
|
||||
<!-- vale Google.Headings = NO -->
|
||||
<!-- vale Microsoft.Headings = NO -->
|
||||
#### Ignore Crossplane version requirements
|
||||
<!-- vale Google.Headings = YES -->
|
||||
<!-- vale Microsoft.Headings = YES -->
|
||||
|
||||
A Provider package may require a specific or minimum Crossplane version before
|
||||
installing. By default, Crossplane doesn't install a Provider if the Crossplane
|
||||
|
|
@ -409,7 +417,7 @@ The {{<hover label="depend" line="17">}}Events{{</hover>}} show a
|
|||
current version of Crossplane doesn't meet the Configuration package
|
||||
requirements.
|
||||
|
||||
## Upgrade a Provider
|
||||
## Upgrade a provider
|
||||
|
||||
To upgrade an existing Provider edit the installed Provider Package by either
|
||||
applying a new Provider manifest or with `kubectl edit providers`.
|
||||
|
|
@ -441,7 +449,7 @@ change the default value.
|
|||
Only a single revision of a Provider is
|
||||
{{<hover label="getPR" line="4">}}Active{{</hover>}} at a time.
|
||||
|
||||
## Remove a Provider
|
||||
## Remove a provider
|
||||
|
||||
Remove a Provider by deleting the Provider object with
|
||||
`kubectl delete provider`.
|
||||
|
|
@ -681,7 +689,7 @@ the runtime is working and overlay them on top of the values
|
|||
in the runtime configuration. For example, it defaults the replica count
|
||||
to 1 if not set and overrides the label selectors to make sure the Deployment
|
||||
and Service match. It also injects any necessary environment variables,
|
||||
ports as well as volumes and volume mounts.
|
||||
ports and volumes and volume mounts.
|
||||
|
||||
The `Provider` or `Functions`'s `spec.runtimeConfigRef.name` field defaults
|
||||
to value `default`, which means Crossplane uses the default runtime configuration
|
||||
|
|
|
|||
|
|
@ -127,7 +127,7 @@ logic, and work in your preferred language.
|
|||
{{<hint "important">}}
|
||||
Composition functions are like configuration language plugins.
|
||||
|
||||
Functions allow you to write your configuration in several languages, including
|
||||
Functions allow you to write your configuration in multiple languages, including
|
||||
[YAML](https://yaml.org), [KCL](https://www.kcl-lang.io),
|
||||
[Python](https://python.org), and [Go](https://go.dev).
|
||||
{{</hint>}}
|
||||
|
|
@ -229,7 +229,7 @@ The Crossplane package manager lets you install new managed resources and
|
|||
composition functions.
|
||||
|
||||
You can also package any part of a control plane's configuration and install it
|
||||
using the package manager. This allows you to deploy several control planes with
|
||||
using the package manager. This allows you to deploy multiple control planes with
|
||||
identical capabilities - for example one control plane per region or per
|
||||
service.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
/tab
|
||||
/tabs
|
||||
backporting
|
||||
built-in
|
||||
call-outs
|
||||
ClusterRoles`
|
||||
|
|
@ -55,3 +56,4 @@ UpperCamelCased
|
|||
user-defined
|
||||
v2
|
||||
version-specific
|
||||
backporting
|
||||
Loading…
Reference in New Issue