crossplane
/
docs
mirror of https://github.com/crossplane/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix all Vale errors 

Signed-off-by: Jared Watts <jbw976@gmail.com>
This commit is contained in:
Jared Watts 2024-09-09 16:55:36 -07:00
parent 1b48f47189
commit b263c2fcbb
No known key found for this signature in database
GPG Key ID: 0467EEAE3B6EC0D2
49 changed files with 439 additions and 399 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
content/contribute/_index.md
View File

@ -55,10 +55,9 @@ here.
generator, CSS layouts and JavaScript.
## Licensing
The Crossplane documentation is under the [Creative Commons
Attribution](https://creativecommons.org/licenses/by/4.0/) license. CC-BY allows
reuse, remixing and republishing of Crossplane documentation with attribution to
the Crossplane organization.
The Crossplane documentation is under the [Creative Commons Attribution](https://creativecommons.org/licenses/by/4.0/)
license. CC-BY allows reuse, remixing and republishing of Crossplane
documentation with attribution to the Crossplane organization.
## Issues and feature requests
Open an [issue](https://github.com/crossplane/crossplane/issues)

5
content/contribute/writing-style-guide.md
View File

@ -23,7 +23,7 @@ The most important points of the style guide include:
users. When in doubt, spell it out first.
* Avoid assuming the reader already knows the background.
* Don't use [cliches](https://www.topcreativewritingcourses.com/blog/common-cliches-in-writing-and-how-to-avoid-them).
* Cliches make writing sound unprofessional and are not internationally inclusive.
* Cliches make writing sound unprofessional and aren't internationally inclusive.
* Use contractions for phrases like "do not," "cannot," "is not" and related terms.
* It's easy to miss "not" in "do not." It's hard to misunderstand "don't."
* Don't use Latin terms (i.e., e.g., etc.).
@ -48,8 +48,7 @@ users. When in doubt, spell it out first.
Crossplane relies on [Vale](https://github.com/errata-ai/vale) to enforce the
complete style guide.
Read more about [using Vale with the Crossplane
documentation]({{<ref "Vale" >}}).
Read more about [using Vale with the Crossplane documentation]({{<ref "Vale" >}}).
## Italics

16
content/master/concepts/composition-revisions.md
View File

@ -93,7 +93,7 @@ metadata:
spec:
parameters:
storageGB: 20
# The Manual policy specifies that you do not want this XR to update to the
# The Manual policy specifies that you don't want this XR to update to the
# latest CompositionRevision automatically.
compositionUpdatePolicy: Manual
compositionRef:
@ -348,8 +348,8 @@ 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.
XRs `vpc-man` and `vpc-dev` are still assigned to the original revision:1:
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
kubectl get composite -o="custom-columns=NAME:.metadata.name,SYNCED:.status.conditions[0].status,REVISION:.spec.compositionRevisionRef.name,POLICY:.spec.compositionUpdatePolicy,MATCHLABEL:.spec.compositionRevisionSelector.matchLabels"
@ -365,7 +365,7 @@ vpc-staging True myvpcs.aws.example.upbound.io-727b3c8 Automatic map[c
{{< hint "note" >}}
`vpc-auto` always use the latest Revision.
`vpc-staging` now matches the label applied to Revision revision:2.
`vpc-staging` now matches the label applied to Revision `revision:2`.
{{< /hint >}}
#### Update Composition Spec and Label
@ -427,8 +427,8 @@ myvpcs.aws.example.upbound.io-f81c553 3 dev
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.
`vpc-staging` is assigned to revision:2, and `vpc-man` is still assigned to the original revision:1:
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`:
```shell
kubectl get composite -o="custom-columns=NAME:.metadata.name,SYNCED:.status.conditions[0].status,REVISION:.spec.compositionRevisionRef.name,POLICY:.spec.compositionUpdatePolicy,MATCHLABEL:.spec.compositionRevisionSelector.matchLabels"
@ -444,8 +444,8 @@ vpc-staging True myvpcs.aws.example.upbound.io-727b3c8 Automatic map[c
{{< hint "note" >}}
`vpc-dev` matches the updated label applied to Revision revision:3.
`vpc-staging` matches the label applied to Revision revision:2.
`vpc-dev` matches the updated label applied to Revision `revision:3`.
`vpc-staging` matches the label applied to Revision `revision:2`.
{{< /hint >}}

2
content/master/concepts/packages.md
View File

@ -339,7 +339,7 @@ Status:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning LintPackage 29s (x2 over 29s) packages/configurationrevision.pkg.crossplane.io incompatible Crossplane version: package is not compatible with Crossplane version (v1.12.0)
Warning LintPackage 29s (x2 over 29s) packages/configurationrevision.pkg.crossplane.io incompatible Crossplane version: package isn't compatible with Crossplane version (v1.12.0)
```
The {{<hover label="depend" line="18">}}Events{{</hover>}} show a

2
content/master/concepts/providers.md
View File

@ -351,7 +351,7 @@ Status:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning LintPackage 41s (x3 over 47s) packages/providerrevision.pkg.crossplane.io incompatible Crossplane version: package is not compatible with Crossplane version (v1.10.0)
Warning LintPackage 41s (x3 over 47s) packages/providerrevision.pkg.crossplane.io incompatible Crossplane version: package isn't compatible with Crossplane version (v1.10.0)
```
The {{<hover label="depend" line="17">}}Events{{</hover>}} show a

14
content/master/guides/crossplane-with-argo-cd.md
View File

@ -5,14 +5,14 @@ weight: 270
[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. There are
configuration details required in order for the two to work together properly.
cluster into a Universal Control Plane for all of 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.
Argo CD synchronizes Kubernetes resource manifests stored in a Git repository
with those running in a Kubernetes cluster (GitOps). There are different ways to configure
how Argo CD tracks resources. With Crossplane, you need to configure Argo CD
with those running in a Kubernetes cluster (GitOps). Argo CD has different ways to configure
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.
### Configuring Argo CD with Crossplane
@ -185,12 +185,12 @@ data:
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 are not expected to interact with this resource.
ProviderConfig is deleted. End users of Crossplane aren't expected 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
recommend hiding all `ProviderConfigUsage` resources from Argo CD UI.
To configure resource exclusion edit the `argocd-cm` `ConfigMap` in the `argocd` `Namespace` as such:
To configure resource exclusion edit the `argocd-cm` `ConfigMap` in the `argocd` `Namespace` as such:
```yaml
apiVersion: v1
kind: ConfigMap
@ -204,7 +204,7 @@ data:
The use of `"*"` as apiGroups will enable the mechanism for all Crossplane Providers.
#### Increase K8s Client QPS
#### Increase Kubernetes Client QPS
As the number of CRDs grow on a control plane it will increase 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.

36
content/master/guides/multi-tenant.md
View File

@ -5,9 +5,9 @@ weight: 240
This guide describes how to use Crossplane effectively in multi-tenant
environments by utilizing Kubernetes primitives and compatible policy
enforcement projects in the cloud-native ecosystem.
enforcement projects in the cloud native ecosystem.
## TL;DR
## Summary
Infrastructure operators in multi-tenant Crossplane environments typically
utilize composition and Kubernetes RBAC to define lightweight, standardized
@ -21,7 +21,7 @@ those with more complex environments, may choose to incorporate third-party
policy engines, or scale to multiple Crossplane clusters. The following sections
describe each of these scenarios in greater detail.
- [TL;DR](#tldr)
- [Summary](#summary)
- [Background](#background)
- [Cluster-Scoped Managed Resources](#cluster-scoped-managed-resources)
- [Namespace Scoped Claims](#namespace-scoped-claims)
@ -109,7 +109,7 @@ in response to the creation of an instance of the XRD. More information about
this architecture can be found in the [Composition] documentation.
Every XRD is exposed at the cluster scope, but only those with `spec.claimNames`
defined will have a namespace-scoped variant.
defined will have a namespace scoped variant.
```yaml
apiVersion: apiextensions.crossplane.io/v1
@ -131,7 +131,7 @@ When the example above is created, Crossplane will produce two
[CustomResourceDefinitions]:
1. A cluster-scoped type with `kind: XMySQLInstance`. This is referred to as a
**Composite Resource (XR)**.
2. A namespace-scoped type with `kind: MySQLInstance`. This is referred to as a
2. A namespace scoped type with `kind: MySQLInstance`. This is referred to as a
**Claim (XRC)**.
Platform builders may choose to define an arbitrary number of Compositions that
@ -160,13 +160,13 @@ This feature serves as a lightweight policy mechanism by only giving the
consumer the ability to customize the underlying resources to the extent the
platform builder desires. For instance, in the examples above, a platform
builder may choose to define a `spec.location` field in the schema of the
`XMySQLInstance` that is an enum with options `east` and `west`. In the
`XMySQLInstance` that's an enum with options `east` and `west`. In the
Composition, those fields could map to the `RDSInstance` `spec.region` field,
making the value either `us-east-1` or `us-west-1`. If no other patches were
defined for the `RDSInstance`, giving a user the ability (using RBAC) to create
a `XMySQLInstance` / `MySQLInstance` would be akin to giving the ability to
create a very specifically configured `RDSInstance`, where they can only decide
the region where it lives and they are restricted to two options.
create a specifically configured `RDSInstance`, where they can only decide
the region where it lives and they're restricted to two options.
This model is in contrast to many infrastructure as code tools where the end
user must have provider credentials to create the underlying resources that are
@ -182,11 +182,11 @@ standardizing on Kubernetes RBAC.
While the ability to define abstract schemas and patches to concrete resource
types using composition is powerful, the ability to define Claim types at the
namespace scope enhances the functionality further by enabling RBAC to be
applied with namespace restrictions. Most users in a cluster do not have access
to cluster-scoped resources as they are considered only relevant to
applied with namespace restrictions. Most users in a cluster don't have access
to cluster-scoped resources as they're considered only relevant to
infrastructure admins by both Kubernetes and Crossplane.
Building on our simple `XMySQLInstance` / `MySQLInstance` example, a platform
Building on our `XMySQLInstance` / `MySQLInstance` example, a platform
builder may choose to define permissions on `MySQLInstance` at the namespace
scope using a `Role`. This allows for giving users the ability to create and
manage `MySQLInstances` in their given namespace, but not the ability to see
@ -249,15 +249,15 @@ namespace the corresponding `MySQLInstance` was created in.
### Policy Enforcement with Open Policy Agent
In some Crossplane deployment models, only using composition and RBAC to define
policy will not be flexible enough. However, because Crossplane brings
management of external infrastructure to the Kubernetes API, it is well suited
to integrate with other projects in the cloud-native ecosystem. Organizations
policy won't be flexible enough. However, because Crossplane brings
management of external infrastructure to the Kubernetes API, it's well suited
to integrate with other projects in the cloud native ecosystem. Organizations
and individuals that need a more robust policy engine, or just prefer a more
general language for defining policy, often turn to [Open Policy Agent] (OPA).
OPA allows platform builders to write custom logic in [Rego], a domain-specific
OPA allows platform builders to write custom logic in [Rego], a domain specific
language. Writing policy in this manner allows for not only incorporating the
information available in the specific resource being evaluated, but also using
other state represented in the cluster. Crossplane users typically install OPA's
other state represented in the cluster. Crossplane users typically install OPA
[Gatekeeper] to make policy management as streamlined as possible.
> A live demo of using OPA with Crossplane can be viewed [here].
@ -271,14 +271,16 @@ simpler.
### Reproducible Platforms with Configuration Packages
[Configuration packages] allow platform builders to package their XRDs and
Compositions into [OCI images] that can be distributed via any OCI-compliant
Compositions into [OCI images] that can be distributed via any OCI compliant
image registry. These packages can also declare dependencies on providers,
meaning that a single package can declare all of the granular managed resources,
the controllers that must be deployed to reconcile them, and the abstract types
that expose the underlying resources using composition.
Organizations with many Crossplane deployments utilize Configuration packages to
<!-- vale alex.Condescending = NO -->
reproduce their platform in each cluster. This can be as simple as installing
<!-- vale alex.Condescending = YES -->
Crossplane with the flag to automatically install a Configuration package
alongside it.

4
content/master/guides/self-signed-ca-certs.md
View File

@ -3,7 +3,7 @@ title: Self-Signed CA Certs
weight: 270
---
> Using self-signed certificates is not advised in production, it is
> 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
@ -39,7 +39,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 convered in the Helm docs,
> Providing Helm with parameter values is covered in the Helm docs,
[Helm install](https://helm.sh/docs/helm/helm_install/). An example block
in an `override.yaml` file would look like this:
```

53
content/master/guides/troubleshoot-crossplane.md
View File

@ -5,12 +5,12 @@ weight: 306
## Requested Resource Not Found
If you use the Crossplane CLI to install a `Provider` or
`Configuration` (e.g. `crossplane install provider
`Configuration` (for example, `crossplane install provider
xpkg.upbound.io/crossplane-contrib/provider-aws:v0.33.0`) and get `the server
could not find the requested resource` error, more often than not, that is an
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
plugin is not aware of this change.
plugin isn't aware of this change.
## Resource Status and Conditions
@ -32,14 +32,14 @@ Status:
```
Most Crossplane resources set the `Ready` condition. `Ready` represents the
availability of the resource - whether it is creating, deleting, available,
availability of the resource - whether it's creating, deleting, available,
unavailable, binding, etc.
## Resource Events
Most Crossplane resources emit _events_ when something interesting happens. You
can see the events associated with a resource by running `kubectl describe` -
e.g. `kubectl describe cloudsqlinstance my-db`. You can also see all events in a
for example, `kubectl describe cloudsqlinstance my-db`. You can also see all events in a
particular namespace by running `kubectl get events`.
```console
@ -112,7 +112,7 @@ Crossplane and its providers log most error messages to resources' event fields.
1. Get the events for the root resource using `kubectl describe` or `kubectl get event`
2. If there are errors in the events, address them.
3. If there are no errors, follow its sub-resources.
3. If there are no errors, follow its subresources.
`kubectl get <KIND> <NAME> -o=jsonpath='{.spec.resourceRef}{" "}{.spec.resourceRefs}' | jq`
4. Repeat this process for each resource returned.
@ -120,7 +120,7 @@ Crossplane and its providers log most error messages to resources' event fields.
{{< hint "note" >}}
The rest of this section show you how to debug issues related to compositions without using external tooling.
If you are using ArgoCD or FluxCD with UI, you can visualize object relationships in the UI.
You can also use the kube-lineage plugin to visualize object relationships in your terminal.
You can also use the `kube-lineage` plugin to visualize object relationships in your terminal.
{{< /hint >}}
### Examples
@ -135,7 +135,7 @@ The example application never reaches available state as shown below.
1. View the claim.
```bash
```shell
kubectl describe exampleapp example-application
Status:
@ -149,7 +149,7 @@ The example application never reaches available state as shown below.
2. If the claim doesn't have errors, inspect the `.spec.resourceRef` field of the claim.
```bash
```shell
kubectl get exampleapp example-application -o=jsonpath='{.spec.resourceRef}{" "}{.spec.resourceRefs}' | jq
{
@ -161,7 +161,7 @@ The example application never reaches available state as shown below.
3. In the preceding output, you see the cluster scoped resource for this claim. Kind = `XExampleApp` name = `example-application-xqlsz`
4. View the cluster scoped resource's events.
```bash
```shell
kubectl describe xexampleapp example-application-xqlsz
Events:
@ -172,9 +172,9 @@ The example application never reaches available state as shown below.
Warning ComposeResources 6s (x6 over 10s) defined/compositeresourcedefinition.apiextensions.crossplane.io can't render composed resource from resource template at index 3: can't use dry-run create to name composed resource: an empty namespace may not be set during creation
Normal ComposeResources 6s (x6 over 10s) defined/compositeresourcedefinition.apiextensions.crossplane.io Successfully composed resources
```
5. You see errors in the events. it's complaining about not specifying namespace in its compositions. For this particular kind of error, you can get its sub-resources and check which one isn't created.
5. You see errors in the events. it's complaining about not specifying namespace in its compositions. For this particular kind of error, you can get its subresources and check which one isn't created.
```bash
```shell
kubectl get xexampleapp example-application-xqlsz -o=jsonpath='{.spec.resourceRef}{" "}{.spec.resourceRefs}' | jq
[
@ -207,7 +207,7 @@ Debugging Composite Resource Definition (XRD) is like debugging Compositions.
1. Get the XRD
```bash
```shell
kubectl get xrd testing.awsblueprints.io
NAME ESTABLISHED OFFERED AGE
@ -215,7 +215,7 @@ Debugging Composite Resource Definition (XRD) is like debugging Compositions.
```
2. Notice its status it not established. You describe this XRD to get its events.
```bash
```shell
kubectl describe xrd testing.awsblueprints.io
Events:
@ -231,14 +231,13 @@ Debugging Composite Resource Definition (XRD) is like debugging Compositions.
You can use install providers in two ways: `configuration.pkg.crossplane.io` and `provider.pkg.crossplane.io`. You can use either one to install providers with no functional differences to providers themselves.
If you define a `configuration.pkg.crossplane.io` object, Crossplane creates a
`provider.pkg.crossplane.io` object and manages it. Refer to [the Packages
documentation]({{<ref "/master/concepts/packages">}})
`provider.pkg.crossplane.io` object and manages it. Refer to [the Packages documentation]({{<ref "/master/concepts/packages">}})
for more information about Crossplane Packages.
If you are experiencing provider issues, steps below are a good starting point.
1. Check the status of provider object.
```bash
```shell
kubectl describe provider.pkg.crossplane.io provider-aws
Status:
@ -264,7 +263,7 @@ If you are experiencing provider issues, steps below are a good starting point.
2. When you create a provider object, Crossplane creates a `ProviderRevision` object based on the contents of the OCI image. In this example, you're specifying the OCI image to be `crossplane/provider-aws:v0.29.0`. This image contains a YAML file which defines Kubernetes objects such as Deployment, ServiceAccount, and CRDs.
The `ProviderRevision` object creates resources necessary for a provider to function based on the contents of the YAML file. To inspect what's deployed as part of the provider package, you inspect the ProviderRevision object. The `Current Revision` field above indicates which ProviderRevision object this provider uses.
```bash
```shell
kubectl get providerrevision provider-aws-a2e16ca2fc1a
NAME HEALTHY REVISION IMAGE STATE DEP-FOUND DEP-INSTALLED AGE
@ -273,7 +272,7 @@ The `ProviderRevision` object creates resources necessary for a provider to func
When you describe the object, you find all CRDs managed by this object.
```bash
```shell
kubectl describe providerrevision provider-aws-a2e16ca2fc1a
Status:
@ -297,7 +296,7 @@ The `ProviderRevision` object creates resources necessary for a provider to func
<!-- vale Google.WordList = YES -->
3. If you don't see any errors in the event field above, you should check if Crossplane provisioned deployments and their status.
```bash
```shell
kubectl get deployment -n crossplane-system
NAME READY UP-TO-DATE AVAILABLE AGE
@ -320,16 +319,16 @@ The `ProviderRevision` object creates resources necessary for a provider to func
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
following command to simply scale down its deployment:
following command to scale down its deployment:
```bash
```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
unpause Crossplane simply by scaling its deployment back up:
unpause Crossplane by scaling its deployment back up:
```bash
```shell
kubectl -n crossplane-system scale --replicas=1 deployment/crossplane
```
@ -405,9 +404,9 @@ kubectl describe postgresqlinstance.database.example.org my-db
```
Per Kubernetes convention, Crossplane keeps errors close to the place they
happen. This means that if your claim is not becoming ready due to an issue with
happen. This means that if your claim isn't becoming ready due to an issue with
your `Composition` or with a composed resource you'll need to "follow the
references" to find out why. Your claim will only tell you that the XR is not
references" to find out why. Your claim will only tell you that the XR isn't
yet ready.
To follow the references:
@ -420,7 +419,7 @@ To follow the references:
look for the "Resource Refs" (or `spec.resourceRefs`) to find your composed
resources.
1. Run `kubectl describe` on each referenced composed resource to determine
whether it is ready and what issues, if any, it is encountering.
whether it's ready and what issues, if any, it's encountering.

5
content/master/guides/vault-as-secret-store.md
View File

@ -32,8 +32,7 @@ This guide requires [Helm](https://helm.sh) version 3.11 or later.
## Install Vault
{{<hint "note" >}}
Detailed instructions on [installing
Vault](https://developer.hashicorp.com/vault/docs/platform/k8s/helm)
Detailed instructions on [installing Vault](https://developer.hashicorp.com/vault/docs/platform/k8s/helm)
are available from the Vault documentation.
{{< /hint >}}
@ -527,7 +526,7 @@ is the name of the Claim's
{{<hover label="claim" line="12">}}publishConnectionDetailsTo{{</hover>}}
configuration.
Check connection secrets in the "crossplane-system" Vault scope.
Check connection secrets in the `crossplane-system` Vault scope.
```shell {copy-lines="1",label="scope-key"}
kubectl -n vault-system exec -i vault-0 -- vault kv list /secret/crossplane-system
Keys

32
content/master/guides/vault-injection.md
View File

@ -14,15 +14,15 @@ following sources:
- Filesystem
A provider may optionally support additional credentials sources, but the common
sources cover a wide variety of use cases. One specific use case that is popular
sources cover a wide variety of use cases. One specific use case that's popular
among organizations that use [Vault] for secrets management is using a sidecar
to inject credentials into the filesystem. This guide will demonstrate how to
use the [Vault Kubernetes Sidecar] to provide credentials for [provider-gcp]
and [provider-aws].
> Note: in this guide we will copy GCP credentials and AWS access keys
> into Vault's KV secrets engine. This is a simple generic approach to
> managing secrets with Vault, but is not as robust as using Vault's
> into Vault's KV secrets engine. This is a generic approach to
> managing secrets with Vault, but isn't as robust as using Vault's
> dedicated cloud provider secrets engines for [AWS], [Azure], and [GCP].
## Setup
@ -32,7 +32,7 @@ and [provider-aws].
> outside the cluster but has Kubernetes authentication enabled.
Before getting started, you must ensure that you have installed Crossplane and
Vault and that they are running in your cluster.
Vault and that they're running in your cluster.
1. Install Crossplane
@ -66,9 +66,9 @@ kubectl exec vault-0 -- vault operator unseal $VAULT_UNSEAL_KEY
4. Enable Kubernetes Authentication Method
In order for Vault to be able to authenticate requests based on Kubernetes
service accounts, the [Kubernetes authentication backend] must be enabled. This
service accounts, the [Kubernetes authentication method] must be enabled. This
requires logging in to Vault and configuring it with a service account token,
API server address, and certificate. Because we are running Vault in Kubernetes,
API server address, and certificate. Because we're running Vault in Kubernetes,
these values are already available via the container filesystem and environment
variables.
@ -136,7 +136,7 @@ secrets engine].
> Note: the steps below involve copying credentials into the container
> filesystem before storing them in Vault. You may also choose to use Vault's
> HTTP API or UI by port-forwarding the container to your local environment
> HTTP API or UI by port forwarding the container to your local environment
> (`kubectl port-forward vault-0 8200:8200`).
1. Copy Credentials File into Vault Container
@ -254,7 +254,7 @@ EOF
1. Create Role
The last step is to create a role that is bound to the policy you created and
The last step is to create a role that's bound to the policy you created and
associate it with a group of Kubernetes service accounts. This role can be
assumed by any (`*`) service account in the `crossplane-system` namespace.
@ -286,10 +286,9 @@ by any number of `Provider` objects that wish to use its configuration. In the
example below, the `Pod` annotations indicate to the Vault mutating webhook that
we want for the secret stored at `secret/provider-creds/gcp-default` to be
injected into the container filesystem by assuming role `crossplane-providers`.
There is also so template formatting added to make sure the secret data is
Template formatting has been added to make sure the secret data is
presented in a form that `provider-gcp` is expecting.
{% raw %}
```console
echo "apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
@ -315,7 +314,6 @@ spec:
controllerConfigRef:
name: vault-config" | kubectl apply -f -
```
{% endraw %}
## Configure provider-gcp
@ -323,7 +321,7 @@ One `provider-gcp` is installed and running, you will want to create a
`ProviderConfig` that specifies the credentials in the filesystem that should be
used to provision managed resources that reference this `ProviderConfig`.
Because the name of this `ProviderConfig` is `default` it will be used by any
managed resources that do not explicitly reference a `ProviderConfig`.
managed resources that don't explicitly reference a `ProviderConfig`.
> Note: make sure that the `PROJECT_ID` environment variable that was defined
> earlier is still set correctly.
@ -352,7 +350,7 @@ kubectl -n crossplane-system exec -it $PROVIDER_CONTROLLER_POD -c provider-gcp -
## Provision Infrastructure
The final step is to actually provision a `CloudSQLInstance`. Creating the
object below will result in the creation of a Cloud SQL Postgres database on
object below will result in the creation of a Cloud SQL PostgreSQL database on
GCP.
```console
@ -392,10 +390,9 @@ by any number of `Provider` objects that wish to use its configuration. In the
example below, the `Pod` annotations indicate to the Vault mutating webhook that
we want for the secret stored at `secret/provider-creds/aws-default` to be
injected into the container filesystem by assuming role `crossplane-providers`.
There is also some template formatting added to make sure the secret data is
Template formatting has been added to make sure the secret data is
presented in a form that `provider-aws` is expecting.
{% raw %}
```console
echo "apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
@ -425,7 +422,6 @@ spec:
controllerConfigRef:
name: aws-vault-config" | kubectl apply -f -
```
{% endraw %}
## Configure provider-aws
@ -433,7 +429,7 @@ Once `provider-aws` is installed and running, you will want to create a
`ProviderConfig` that specifies the credentials in the filesystem that should be
used to provision managed resources that reference this `ProviderConfig`.
Because the name of this `ProviderConfig` is `default` it will be used by any
managed resources that do not explicitly reference a `ProviderConfig`.
managed resources that don't explicitly reference a `ProviderConfig`.
```console
echo "apiVersion: aws.crossplane.io/v1beta1
@ -501,6 +497,6 @@ kubectl get bucket -w
[Azure]: https://www.vaultproject.io/docs/secrets/azure
[GCP]: https://www.vaultproject.io/docs/secrets/gcp
[unsealed]: https://www.vaultproject.io/docs/concepts/seal
[Kubernetes authentication backend]: https://www.vaultproject.io/docs/auth/kubernetes
[Kubernetes authentication method]: https://www.vaultproject.io/docs/auth/kubernetes
[kv secrets engine]: https://www.vaultproject.io/docs/secrets/kv/kv-v2
[policy]: https://www.vaultproject.io/docs/concepts/policies

10
content/master/learn/_index.md
View File

@ -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 drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us].
***Learn more about using Crossplane***
- [Latest Design Docs](https://github.com/crossplane/crossplane/tree/main/design)
@ -20,14 +20,16 @@ If you have any questions, please drop us a note on [Crossplane Slack][join-cros
- [Programming Kubernetes Book](https://www.oreilly.com/library/view/programming-kubernetes/9781492047094/)
- [Contributor Guide](https://github.com/crossplane/crossplane/blob/main/CONTRIBUTING.md)
***Join the growing Crossplane community and get involved!***
***Join the growing Crossplane community and get involved***
- Join our [Community Slack](https://slack.crossplane.io/)!
- Submit an issue on [GitHub](https://github.com/crossplane/crossplane)
- Attend our bi-weekly [Community Meeting](https://github.com/crossplane/crossplane#get-involved)
- Join our bi-weekly live stream: [The Binding Status](https://github.com/crossplane/tbs)
- 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)
<!-- vale Crossplane.Spelling = NO -->
- Drop us a note on Twitter: [@crossplane_io](https://twitter.com/crossplane_io)
- Email us: [info@crossplane.io](mailto:info@crossplane.io)
<!-- vale Crossplane.Spelling = YES -->
<!-- Named links -->

14
content/master/learn/feature-lifecycle.md
View File

@ -22,7 +22,9 @@ removal or breaking changes without notice**, and generally not considered ready
for use in production.
In some cases alpha features require fields be added to existing beta or GA
API types. In these cases fields must clearly be marked (i.e in their OpenAPI
<!-- vale alex.Condescending = NO -->
API types. In these cases fields must clearly be marked (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.
@ -31,24 +33,26 @@ All alpha features should have an issue tracking their graduation to beta.
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 will not be
`v1beta1`. Beta features are considered to be well tested, and won't be
removed completely without being marked 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
instructions for migrating to the next version. This may require deleting,
editing, and re-creating API objects. The editing process may require some
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
these cases fields must clearly be marked (i.e in their OpenAPI schema) as beta
<!-- vale alex.Condescending = NO -->
these cases fields must clearly be marked (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
GA features are always enabled - they cannot be disabled. API types pertaining
GA features are always enabled - they can't be disabled. 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.

12
content/master/learn/release-cycle.md
View File

@ -18,7 +18,7 @@ be maintained 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 back-ported to the
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
release branch if no longer applicable on the main development branch.
@ -30,15 +30,15 @@ effort basis by maintainers and contributors for currently maintained 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 back-ported fixes will be included in a patch release as
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
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
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.
@ -55,7 +55,7 @@ The following stages are the main milestones in a Crossplane release.
### Active development
During active development, any code that meets the requisite criteria (i.e.
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
@ -65,7 +65,7 @@ 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
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.

16
content/v1.15/concepts/composition-revisions.md
View File

@ -93,7 +93,7 @@ metadata:
spec:
parameters:
storageGB: 20
# The Manual policy specifies that you do not want this XR to update to the
# The Manual policy specifies that you don't want this XR to update to the
# latest CompositionRevision automatically.
compositionUpdatePolicy: Manual
compositionRef:
@ -340,8 +340,8 @@ 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.
XRs `vpc-man` and `vpc-dev` are still assigned to the original revision:1:
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
kubectl get composite -o="custom-columns=NAME:.metadata.name,SYNCED:.status.conditions[0].status,REVISION:.spec.compositionRevisionRef.name,POLICY:.spec.compositionUpdatePolicy,MATCHLABEL:.spec.compositionRevisionSelector.matchLabels"
@ -357,7 +357,7 @@ vpc-staging True myvpcs.aws.example.upbound.io-727b3c8 Automatic map[c
{{< hint "note" >}}
`vpc-auto` always use the latest Revision.
`vpc-staging` now matches the label applied to Revision revision:2.
`vpc-staging` now matches the label applied to Revision `revision:2`.
{{< /hint >}}
#### Update Composition Spec and Label
@ -411,8 +411,8 @@ myvpcs.aws.example.upbound.io-f81c553 3 dev
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.
`vpc-staging` is assigned to revision:2, and `vpc-man` is still assigned to the original revision:1:
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`:
```shell
kubectl get composite -o="custom-columns=NAME:.metadata.name,SYNCED:.status.conditions[0].status,REVISION:.spec.compositionRevisionRef.name,POLICY:.spec.compositionUpdatePolicy,MATCHLABEL:.spec.compositionRevisionSelector.matchLabels"
@ -428,8 +428,8 @@ vpc-staging True myvpcs.aws.example.upbound.io-727b3c8 Automatic map[c
{{< hint "note" >}}
`vpc-dev` matches the updated label applied to Revision revision:3.
`vpc-staging` matches the label applied to Revision revision:2.
`vpc-dev` matches the updated label applied to Revision `revision:3`.
`vpc-staging` matches the label applied to Revision `revision:2`.
{{< /hint >}}

14
content/v1.15/guides/crossplane-with-argo-cd.md
View File

@ -5,14 +5,14 @@ weight: 270
[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. There are
configuration details required in order for the two to work together properly.
cluster into a Universal Control Plane for all of 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.
Argo CD synchronizes Kubernetes resource manifests stored in a Git repository
with those running in a Kubernetes cluster (GitOps). There are different ways to configure
how Argo CD tracks resources. With Crossplane, you need to configure Argo CD
with those running in a Kubernetes cluster (GitOps). Argo CD has different ways to configure
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.
### Configuring Argo CD with Crossplane
@ -185,12 +185,12 @@ data:
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 are not expected to interact with this resource.
ProviderConfig is deleted. End users of Crossplane aren't expected 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
recommend hiding all `ProviderConfigUsage` resources from Argo CD UI.
To configure resource exclusion edit the `argocd-cm` `ConfigMap` in the `argocd` `Namespace` as such:
To configure resource exclusion edit the `argocd-cm` `ConfigMap` in the `argocd` `Namespace` as such:
```yaml
apiVersion: v1
kind: ConfigMap
@ -204,7 +204,7 @@ data:
The use of `"*"` as apiGroups will enable the mechanism for all Crossplane Providers.
#### Increase K8s Client QPS
#### Increase Kubernetes Client QPS
As the number of CRDs grow on a control plane it will increase 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.

36
content/v1.15/guides/multi-tenant.md
View File

@ -5,9 +5,9 @@ weight: 240
This guide describes how to use Crossplane effectively in multi-tenant
environments by utilizing Kubernetes primitives and compatible policy
enforcement projects in the cloud-native ecosystem.
enforcement projects in the cloud native ecosystem.
## TL;DR
## Summary
Infrastructure operators in multi-tenant Crossplane environments typically
utilize composition and Kubernetes RBAC to define lightweight, standardized
@ -21,7 +21,7 @@ those with more complex environments, may choose to incorporate third-party
policy engines, or scale to multiple Crossplane clusters. The following sections
describe each of these scenarios in greater detail.
- [TL;DR](#tldr)
- [Summary](#summary)
- [Background](#background)
- [Cluster-Scoped Managed Resources](#cluster-scoped-managed-resources)
- [Namespace Scoped Claims](#namespace-scoped-claims)
@ -109,7 +109,7 @@ in response to the creation of an instance of the XRD. More information about
this architecture can be found in the [Composition] documentation.
Every XRD is exposed at the cluster scope, but only those with `spec.claimNames`
defined will have a namespace-scoped variant.
defined will have a namespace scoped variant.
```yaml
apiVersion: apiextensions.crossplane.io/v1
@ -131,7 +131,7 @@ When the example above is created, Crossplane will produce two
[CustomResourceDefinitions]:
1. A cluster-scoped type with `kind: XMySQLInstance`. This is referred to as a
**Composite Resource (XR)**.
2. A namespace-scoped type with `kind: MySQLInstance`. This is referred to as a
2. A namespace scoped type with `kind: MySQLInstance`. This is referred to as a
**Claim (XRC)**.
Platform builders may choose to define an arbitrary number of Compositions that
@ -160,13 +160,13 @@ This feature serves as a lightweight policy mechanism by only giving the
consumer the ability to customize the underlying resources to the extent the
platform builder desires. For instance, in the examples above, a platform
builder may choose to define a `spec.location` field in the schema of the
`XMySQLInstance` that is an enum with options `east` and `west`. In the
`XMySQLInstance` that's an enum with options `east` and `west`. In the
Composition, those fields could map to the `RDSInstance` `spec.region` field,
making the value either `us-east-1` or `us-west-1`. If no other patches were
defined for the `RDSInstance`, giving a user the ability (using RBAC) to create
a `XMySQLInstance` / `MySQLInstance` would be akin to giving the ability to
create a very specifically configured `RDSInstance`, where they can only decide
the region where it lives and they are restricted to two options.
create a specifically configured `RDSInstance`, where they can only decide
the region where it lives and they're restricted to two options.
This model is in contrast to many infrastructure as code tools where the end
user must have provider credentials to create the underlying resources that are
@ -182,11 +182,11 @@ standardizing on Kubernetes RBAC.
While the ability to define abstract schemas and patches to concrete resource
types using composition is powerful, the ability to define Claim types at the
namespace scope enhances the functionality further by enabling RBAC to be
applied with namespace restrictions. Most users in a cluster do not have access
to cluster-scoped resources as they are considered only relevant to
applied with namespace restrictions. Most users in a cluster don't have access
to cluster-scoped resources as they're considered only relevant to
infrastructure admins by both Kubernetes and Crossplane.
Building on our simple `XMySQLInstance` / `MySQLInstance` example, a platform
Building on our `XMySQLInstance` / `MySQLInstance` example, a platform
builder may choose to define permissions on `MySQLInstance` at the namespace
scope using a `Role`. This allows for giving users the ability to create and
manage `MySQLInstances` in their given namespace, but not the ability to see
@ -249,15 +249,15 @@ namespace the corresponding `MySQLInstance` was created in.
### Policy Enforcement with Open Policy Agent
In some Crossplane deployment models, only using composition and RBAC to define
policy will not be flexible enough. However, because Crossplane brings
management of external infrastructure to the Kubernetes API, it is well suited
to integrate with other projects in the cloud-native ecosystem. Organizations
policy won't be flexible enough. However, because Crossplane brings
management of external infrastructure to the Kubernetes API, it's well suited
to integrate with other projects in the cloud native ecosystem. Organizations
and individuals that need a more robust policy engine, or just prefer a more
general language for defining policy, often turn to [Open Policy Agent] (OPA).
OPA allows platform builders to write custom logic in [Rego], a domain-specific
OPA allows platform builders to write custom logic in [Rego], a domain specific
language. Writing policy in this manner allows for not only incorporating the
information available in the specific resource being evaluated, but also using
other state represented in the cluster. Crossplane users typically install OPA's
other state represented in the cluster. Crossplane users typically install OPA
[Gatekeeper] to make policy management as streamlined as possible.
> A live demo of using OPA with Crossplane can be viewed [here].
@ -271,14 +271,16 @@ simpler.
### Reproducible Platforms with Configuration Packages
[Configuration packages] allow platform builders to package their XRDs and
Compositions into [OCI images] that can be distributed via any OCI-compliant
Compositions into [OCI images] that can be distributed via any OCI compliant
image registry. These packages can also declare dependencies on providers,
meaning that a single package can declare all of the granular managed resources,
the controllers that must be deployed to reconcile them, and the abstract types
that expose the underlying resources using composition.
Organizations with many Crossplane deployments utilize Configuration packages to
<!-- vale alex.Condescending = NO -->
reproduce their platform in each cluster. This can be as simple as installing
<!-- vale alex.Condescending = YES -->
Crossplane with the flag to automatically install a Configuration package
alongside it.

4
content/v1.15/guides/self-signed-ca-certs.md
View File

@ -3,7 +3,7 @@ title: Self-Signed CA Certs
weight: 270
---
> Using self-signed certificates is not advised in production, it is
> 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
@ -39,7 +39,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 convered in the Helm docs,
> Providing Helm with parameter values is covered in the Helm docs,
[Helm install](https://helm.sh/docs/helm/helm_install/). An example block
in an `override.yaml` file would look like this:
```

53
content/v1.15/guides/troubleshoot-crossplane.md
View File

@ -5,12 +5,12 @@ weight: 306
## Requested Resource Not Found
If you use the Crossplane CLI to install a `Provider` or
`Configuration` (e.g. `crossplane install provider
`Configuration` (for example, `crossplane install provider
xpkg.upbound.io/crossplane-contrib/provider-aws:v0.33.0`) and get `the server
could not find the requested resource` error, more often than not, that is an
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
plugin is not aware of this change.
plugin isn't aware of this change.
## Resource Status and Conditions
@ -32,14 +32,14 @@ Status:
```
Most Crossplane resources set the `Ready` condition. `Ready` represents the
availability of the resource - whether it is creating, deleting, available,
availability of the resource - whether it's creating, deleting, available,
unavailable, binding, etc.
## Resource Events
Most Crossplane resources emit _events_ when something interesting happens. You
can see the events associated with a resource by running `kubectl describe` -
e.g. `kubectl describe cloudsqlinstance my-db`. You can also see all events in a
for example, `kubectl describe cloudsqlinstance my-db`. You can also see all events in a
particular namespace by running `kubectl get events`.
```console
@ -112,7 +112,7 @@ Crossplane and its providers log most error messages to resources' event fields.
1. Get the events for the root resource using `kubectl describe` or `kubectl get event`
2. If there are errors in the events, address them.
3. If there are no errors, follow its sub-resources.
3. If there are no errors, follow its subresources.
`kubectl get <KIND> <NAME> -o=jsonpath='{.spec.resourceRef}{" "}{.spec.resourceRefs}' | jq`
4. Repeat this process for each resource returned.
@ -120,7 +120,7 @@ Crossplane and its providers log most error messages to resources' event fields.
{{< hint "note" >}}
The rest of this section show you how to debug issues related to compositions without using external tooling.
If you are using ArgoCD or FluxCD with UI, you can visualize object relationships in the UI.
You can also use the kube-lineage plugin to visualize object relationships in your terminal.
You can also use the `kube-lineage` plugin to visualize object relationships in your terminal.
{{< /hint >}}
### Examples
@ -135,7 +135,7 @@ The example application never reaches available state as shown below.
1. View the claim.
```bash
```shell
kubectl describe exampleapp example-application
Status:
@ -149,7 +149,7 @@ The example application never reaches available state as shown below.
2. If the claim doesn't have errors, inspect the `.spec.resourceRef` field of the claim.
```bash
```shell
kubectl get exampleapp example-application -o=jsonpath='{.spec.resourceRef}{" "}{.spec.resourceRefs}' | jq
{
@ -161,7 +161,7 @@ The example application never reaches available state as shown below.
3. In the preceding output, you see the cluster scoped resource for this claim. Kind = `XExampleApp` name = `example-application-xqlsz`
4. View the cluster scoped resource's events.
```bash
```shell
kubectl describe xexampleapp example-application-xqlsz
Events:
@ -172,9 +172,9 @@ The example application never reaches available state as shown below.
Warning ComposeResources 6s (x6 over 10s) defined/compositeresourcedefinition.apiextensions.crossplane.io can't render composed resource from resource template at index 3: can't use dry-run create to name composed resource: an empty namespace may not be set during creation
Normal ComposeResources 6s (x6 over 10s) defined/compositeresourcedefinition.apiextensions.crossplane.io Successfully composed resources
```
5. You see errors in the events. it's complaining about not specifying namespace in its compositions. For this particular kind of error, you can get its sub-resources and check which one isn't created.
5. You see errors in the events. it's complaining about not specifying namespace in its compositions. For this particular kind of error, you can get its subresources and check which one isn't created.
```bash
```shell
kubectl get xexampleapp example-application-xqlsz -o=jsonpath='{.spec.resourceRef}{" "}{.spec.resourceRefs}' | jq
[
@ -207,7 +207,7 @@ Debugging Composite Resource Definition (XRD) is like debugging Compositions.
1. Get the XRD
```bash
```shell
kubectl get xrd testing.awsblueprints.io
NAME ESTABLISHED OFFERED AGE
@ -215,7 +215,7 @@ Debugging Composite Resource Definition (XRD) is like debugging Compositions.
```
2. Notice its status it not established. You describe this XRD to get its events.
```bash
```shell
kubectl describe xrd testing.awsblueprints.io
Events:
@ -231,14 +231,13 @@ Debugging Composite Resource Definition (XRD) is like debugging Compositions.
You can use install providers in two ways: `configuration.pkg.crossplane.io` and `provider.pkg.crossplane.io`. You can use either one to install providers with no functional differences to providers themselves.
If you define a `configuration.pkg.crossplane.io` object, Crossplane creates a
`provider.pkg.crossplane.io` object and manages it. Refer to [the Packages
documentation]({{<ref "/master/concepts/packages">}})
`provider.pkg.crossplane.io` object and manages it. Refer to [the Packages documentation]({{<ref "/master/concepts/packages">}})
for more information about Crossplane Packages.
If you are experiencing provider issues, steps below are a good starting point.
1. Check the status of provider object.
```bash
```shell
kubectl describe provider.pkg.crossplane.io provider-aws
Status:
@ -264,7 +263,7 @@ If you are experiencing provider issues, steps below are a good starting point.
2. When you create a provider object, Crossplane creates a `ProviderRevision` object based on the contents of the OCI image. In this example, you're specifying the OCI image to be `crossplane/provider-aws:v0.29.0`. This image contains a YAML file which defines Kubernetes objects such as Deployment, ServiceAccount, and CRDs.
The `ProviderRevision` object creates resources necessary for a provider to function based on the contents of the YAML file. To inspect what's deployed as part of the provider package, you inspect the ProviderRevision object. The `Current Revision` field above indicates which ProviderRevision object this provider uses.
```bash
```shell
kubectl get providerrevision provider-aws-a2e16ca2fc1a
NAME HEALTHY REVISION IMAGE STATE DEP-FOUND DEP-INSTALLED AGE
@ -273,7 +272,7 @@ The `ProviderRevision` object creates resources necessary for a provider to func
When you describe the object, you find all CRDs managed by this object.
```bash
```shell
kubectl describe providerrevision provider-aws-a2e16ca2fc1a
Status:
@ -297,7 +296,7 @@ The `ProviderRevision` object creates resources necessary for a provider to func
<!-- vale Google.WordList = YES -->
3. If you don't see any errors in the event field above, you should check if Crossplane provisioned deployments and their status.
```bash
```shell
kubectl get deployment -n crossplane-system
NAME READY UP-TO-DATE AVAILABLE AGE
@ -320,16 +319,16 @@ The `ProviderRevision` object creates resources necessary for a provider to func
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
following command to simply scale down its deployment:
following command to scale down its deployment:
```bash
```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
unpause Crossplane simply by scaling its deployment back up:
unpause Crossplane by scaling its deployment back up:
```bash
```shell
kubectl -n crossplane-system scale --replicas=1 deployment/crossplane
```
@ -405,9 +404,9 @@ kubectl describe postgresqlinstance.database.example.org my-db
```
Per Kubernetes convention, Crossplane keeps errors close to the place they
happen. This means that if your claim is not becoming ready due to an issue with
happen. This means that if your claim isn't becoming ready due to an issue with
your `Composition` or with a composed resource you'll need to "follow the
references" to find out why. Your claim will only tell you that the XR is not
references" to find out why. Your claim will only tell you that the XR isn't
yet ready.
To follow the references:
@ -420,7 +419,7 @@ To follow the references:
look for the "Resource Refs" (or `spec.resourceRefs`) to find your composed
resources.
1. Run `kubectl describe` on each referenced composed resource to determine
whether it is ready and what issues, if any, it is encountering.
whether it's ready and what issues, if any, it's encountering.

5
content/v1.15/guides/vault-as-secret-store.md
View File

@ -32,8 +32,7 @@ This guide requires [Helm](https://helm.sh) version 3.11 or later.
## Install Vault
{{<hint "note" >}}
Detailed instructions on [installing
Vault](https://developer.hashicorp.com/vault/docs/platform/k8s/helm)
Detailed instructions on [installing Vault](https://developer.hashicorp.com/vault/docs/platform/k8s/helm)
are available from the Vault documentation.
{{< /hint >}}
@ -515,7 +514,7 @@ is the name of the Claim's
{{<hover label="claim" line="12">}}publishConnectionDetailsTo{{</hover>}}
configuration.
Check connection secrets in the "crossplane-system" Vault scope.
Check connection secrets in the `crossplane-system` Vault scope.
```shell {copy-lines="1",label="scope-key"}
kubectl -n vault-system exec -i vault-0 -- vault kv list /secret/crossplane-system
Keys

32
content/v1.15/guides/vault-injection.md
View File

@ -14,15 +14,15 @@ following sources:
- Filesystem
A provider may optionally support additional credentials sources, but the common
sources cover a wide variety of use cases. One specific use case that is popular
sources cover a wide variety of use cases. One specific use case that's popular
among organizations that use [Vault] for secrets management is using a sidecar
to inject credentials into the filesystem. This guide will demonstrate how to
use the [Vault Kubernetes Sidecar] to provide credentials for [provider-gcp]
and [provider-aws].
> Note: in this guide we will copy GCP credentials and AWS access keys
> into Vault's KV secrets engine. This is a simple generic approach to
> managing secrets with Vault, but is not as robust as using Vault's
> into Vault's KV secrets engine. This is a generic approach to
> managing secrets with Vault, but isn't as robust as using Vault's
> dedicated cloud provider secrets engines for [AWS], [Azure], and [GCP].
## Setup
@ -32,7 +32,7 @@ and [provider-aws].
> outside the cluster but has Kubernetes authentication enabled.
Before getting started, you must ensure that you have installed Crossplane and
Vault and that they are running in your cluster.
Vault and that they're running in your cluster.
1. Install Crossplane
@ -66,9 +66,9 @@ kubectl exec vault-0 -- vault operator unseal $VAULT_UNSEAL_KEY
4. Enable Kubernetes Authentication Method
In order for Vault to be able to authenticate requests based on Kubernetes
service accounts, the [Kubernetes authentication backend] must be enabled. This
service accounts, the [Kubernetes authentication method] must be enabled. This
requires logging in to Vault and configuring it with a service account token,
API server address, and certificate. Because we are running Vault in Kubernetes,
API server address, and certificate. Because we're running Vault in Kubernetes,
these values are already available via the container filesystem and environment
variables.
@ -136,7 +136,7 @@ secrets engine].
> Note: the steps below involve copying credentials into the container
> filesystem before storing them in Vault. You may also choose to use Vault's
> HTTP API or UI by port-forwarding the container to your local environment
> HTTP API or UI by port forwarding the container to your local environment
> (`kubectl port-forward vault-0 8200:8200`).
1. Copy Credentials File into Vault Container
@ -254,7 +254,7 @@ EOF
1. Create Role
The last step is to create a role that is bound to the policy you created and
The last step is to create a role that's bound to the policy you created and
associate it with a group of Kubernetes service accounts. This role can be
assumed by any (`*`) service account in the `crossplane-system` namespace.
@ -286,10 +286,9 @@ by any number of `Provider` objects that wish to use its configuration. In the
example below, the `Pod` annotations indicate to the Vault mutating webhook that
we want for the secret stored at `secret/provider-creds/gcp-default` to be
injected into the container filesystem by assuming role `crossplane-providers`.
There is also so template formatting added to make sure the secret data is
Template formatting has been added to make sure the secret data is
presented in a form that `provider-gcp` is expecting.
{% raw %}
```console
echo "apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
@ -315,7 +314,6 @@ spec:
controllerConfigRef:
name: vault-config" | kubectl apply -f -
```
{% endraw %}
## Configure provider-gcp
@ -323,7 +321,7 @@ One `provider-gcp` is installed and running, you will want to create a
`ProviderConfig` that specifies the credentials in the filesystem that should be
used to provision managed resources that reference this `ProviderConfig`.
Because the name of this `ProviderConfig` is `default` it will be used by any
managed resources that do not explicitly reference a `ProviderConfig`.
managed resources that don't explicitly reference a `ProviderConfig`.
> Note: make sure that the `PROJECT_ID` environment variable that was defined
> earlier is still set correctly.
@ -352,7 +350,7 @@ kubectl -n crossplane-system exec -it $PROVIDER_CONTROLLER_POD -c provider-gcp -
## Provision Infrastructure
The final step is to actually provision a `CloudSQLInstance`. Creating the
object below will result in the creation of a Cloud SQL Postgres database on
object below will result in the creation of a Cloud SQL PostgreSQL database on
GCP.
```console
@ -392,10 +390,9 @@ by any number of `Provider` objects that wish to use its configuration. In the
example below, the `Pod` annotations indicate to the Vault mutating webhook that
we want for the secret stored at `secret/provider-creds/aws-default` to be
injected into the container filesystem by assuming role `crossplane-providers`.
There is also some template formatting added to make sure the secret data is
Template formatting has been added to make sure the secret data is
presented in a form that `provider-aws` is expecting.
{% raw %}
```console
echo "apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
@ -425,7 +422,6 @@ spec:
controllerConfigRef:
name: aws-vault-config" | kubectl apply -f -
```
{% endraw %}
## Configure provider-aws
@ -433,7 +429,7 @@ Once `provider-aws` is installed and running, you will want to create a
`ProviderConfig` that specifies the credentials in the filesystem that should be
used to provision managed resources that reference this `ProviderConfig`.
Because the name of this `ProviderConfig` is `default` it will be used by any
managed resources that do not explicitly reference a `ProviderConfig`.
managed resources that don't explicitly reference a `ProviderConfig`.
```console
echo "apiVersion: aws.crossplane.io/v1beta1
@ -501,6 +497,6 @@ kubectl get bucket -w
[Azure]: https://www.vaultproject.io/docs/secrets/azure
[GCP]: https://www.vaultproject.io/docs/secrets/gcp
[unsealed]: https://www.vaultproject.io/docs/concepts/seal
[Kubernetes authentication backend]: https://www.vaultproject.io/docs/auth/kubernetes
[Kubernetes authentication method]: https://www.vaultproject.io/docs/auth/kubernetes
[kv secrets engine]: https://www.vaultproject.io/docs/secrets/kv/kv-v2
[policy]: https://www.vaultproject.io/docs/concepts/policies

10
content/v1.15/learn/_index.md
View File

@ -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 drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us].
***Learn more about using Crossplane***
- [Latest Design Docs](https://github.com/crossplane/crossplane/tree/main/design)
@ -20,14 +20,16 @@ If you have any questions, please drop us a note on [Crossplane Slack][join-cros
- [Programming Kubernetes Book](https://www.oreilly.com/library/view/programming-kubernetes/9781492047094/)
- [Contributor Guide](https://github.com/crossplane/crossplane/blob/main/CONTRIBUTING.md)
***Join the growing Crossplane community and get involved!***
***Join the growing Crossplane community and get involved***
- Join our [Community Slack](https://slack.crossplane.io/)!
- Submit an issue on [GitHub](https://github.com/crossplane/crossplane)
- Attend our bi-weekly [Community Meeting](https://github.com/crossplane/crossplane#get-involved)
- Join our bi-weekly live stream: [The Binding Status](https://github.com/crossplane/tbs)
- 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)
<!-- vale Crossplane.Spelling = NO -->
- Drop us a note on Twitter: [@crossplane_io](https://twitter.com/crossplane_io)
- Email us: [info@crossplane.io](mailto:info@crossplane.io)
<!-- vale Crossplane.Spelling = YES -->
<!-- Named links -->

14
content/v1.15/learn/feature-lifecycle.md
View File

@ -22,7 +22,9 @@ removal or breaking changes without notice**, and generally not considered ready
for use in production.
In some cases alpha features require fields be added to existing beta or GA
API types. In these cases fields must clearly be marked (i.e in their OpenAPI
<!-- vale alex.Condescending = NO -->
API types. In these cases fields must clearly be marked (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.
@ -31,24 +33,26 @@ All alpha features should have an issue tracking their graduation to beta.
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 will not be
`v1beta1`. Beta features are considered to be well tested, and won't be
removed completely without being marked 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
instructions for migrating to the next version. This may require deleting,
editing, and re-creating API objects. The editing process may require some
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
these cases fields must clearly be marked (i.e in their OpenAPI schema) as beta
<!-- vale alex.Condescending = NO -->
these cases fields must clearly be marked (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
GA features are always enabled - they cannot be disabled. API types pertaining
GA features are always enabled - they can't be disabled. 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.

12
content/v1.15/learn/release-cycle.md
View File

@ -18,7 +18,7 @@ be maintained 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 back-ported to the
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
release branch if no longer applicable on the main development branch.
@ -30,15 +30,15 @@ effort basis by maintainers and contributors for currently maintained 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 back-ported fixes will be included in a patch release as
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
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
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.
@ -55,7 +55,7 @@ The following stages are the main milestones in a Crossplane release.
### Active development
During active development, any code that meets the requisite criteria (i.e.
During active development, any code that meets the requisite criteria (F
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
@ -65,7 +65,7 @@ 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
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.

16
content/v1.16/concepts/composition-revisions.md
View File

@ -93,7 +93,7 @@ metadata:
spec:
parameters:
storageGB: 20
# The Manual policy specifies that you do not want this XR to update to the
# The Manual policy specifies that you don't want this XR to update to the
# latest CompositionRevision automatically.
compositionUpdatePolicy: Manual
compositionRef:
@ -340,8 +340,8 @@ 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.
XRs `vpc-man` and `vpc-dev` are still assigned to the original revision:1:
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
kubectl get composite -o="custom-columns=NAME:.metadata.name,SYNCED:.status.conditions[0].status,REVISION:.spec.compositionRevisionRef.name,POLICY:.spec.compositionUpdatePolicy,MATCHLABEL:.spec.compositionRevisionSelector.matchLabels"
@ -357,7 +357,7 @@ vpc-staging True myvpcs.aws.example.upbound.io-727b3c8 Automatic map[c
{{< hint "note" >}}
`vpc-auto` always use the latest Revision.
`vpc-staging` now matches the label applied to Revision revision:2.
`vpc-staging` now matches the label applied to Revision `revision:2`.
{{< /hint >}}
#### Update Composition Spec and Label
@ -411,8 +411,8 @@ myvpcs.aws.example.upbound.io-f81c553 3 dev
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.
`vpc-staging` is assigned to revision:2, and `vpc-man` is still assigned to the original revision:1:
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`:
```shell
kubectl get composite -o="custom-columns=NAME:.metadata.name,SYNCED:.status.conditions[0].status,REVISION:.spec.compositionRevisionRef.name,POLICY:.spec.compositionUpdatePolicy,MATCHLABEL:.spec.compositionRevisionSelector.matchLabels"
@ -428,8 +428,8 @@ vpc-staging True myvpcs.aws.example.upbound.io-727b3c8 Automatic map[c
{{< hint "note" >}}
`vpc-dev` matches the updated label applied to Revision revision:3.
`vpc-staging` matches the label applied to Revision revision:2.
`vpc-dev` matches the updated label applied to Revision `revision:3`.
`vpc-staging` matches the label applied to Revision `revision:2`.
{{< /hint >}}

14
content/v1.16/guides/crossplane-with-argo-cd.md
View File

@ -5,14 +5,14 @@ weight: 270
[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. There are
configuration details required in order for the two to work together properly.
cluster into a Universal Control Plane for all of 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.
Argo CD synchronizes Kubernetes resource manifests stored in a Git repository
with those running in a Kubernetes cluster (GitOps). There are different ways to configure
how Argo CD tracks resources. With Crossplane, you need to configure Argo CD
with those running in a Kubernetes cluster (GitOps). Argo CD has different ways to configure
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.
### Configuring Argo CD with Crossplane
@ -185,12 +185,12 @@ data:
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 are not expected to interact with this resource.
ProviderConfig is deleted. End users of Crossplane aren't expected 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
recommend hiding all `ProviderConfigUsage` resources from Argo CD UI.
To configure resource exclusion edit the `argocd-cm` `ConfigMap` in the `argocd` `Namespace` as such:
To configure resource exclusion edit the `argocd-cm` `ConfigMap` in the `argocd` `Namespace` as such:
```yaml
apiVersion: v1
kind: ConfigMap
@ -204,7 +204,7 @@ data:
The use of `"*"` as apiGroups will enable the mechanism for all Crossplane Providers.
#### Increase K8s Client QPS
#### Increase Kubernetes Client QPS
As the number of CRDs grow on a control plane it will increase 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.

36
content/v1.16/guides/multi-tenant.md
View File

@ -5,9 +5,9 @@ weight: 240
This guide describes how to use Crossplane effectively in multi-tenant
environments by utilizing Kubernetes primitives and compatible policy
enforcement projects in the cloud-native ecosystem.
enforcement projects in the cloud native ecosystem.
## TL;DR
## Summary
Infrastructure operators in multi-tenant Crossplane environments typically
utilize composition and Kubernetes RBAC to define lightweight, standardized
@ -21,7 +21,7 @@ those with more complex environments, may choose to incorporate third-party
policy engines, or scale to multiple Crossplane clusters. The following sections
describe each of these scenarios in greater detail.
- [TL;DR](#tldr)
- [Summary](#summary)
- [Background](#background)
- [Cluster-Scoped Managed Resources](#cluster-scoped-managed-resources)
- [Namespace Scoped Claims](#namespace-scoped-claims)
@ -109,7 +109,7 @@ in response to the creation of an instance of the XRD. More information about
this architecture can be found in the [Composition] documentation.
Every XRD is exposed at the cluster scope, but only those with `spec.claimNames`
defined will have a namespace-scoped variant.
defined will have a namespace scoped variant.
```yaml
apiVersion: apiextensions.crossplane.io/v1
@ -131,7 +131,7 @@ When the example above is created, Crossplane will produce two
[CustomResourceDefinitions]:
1. A cluster-scoped type with `kind: XMySQLInstance`. This is referred to as a
**Composite Resource (XR)**.
2. A namespace-scoped type with `kind: MySQLInstance`. This is referred to as a
2. A namespace scoped type with `kind: MySQLInstance`. This is referred to as a
**Claim (XRC)**.
Platform builders may choose to define an arbitrary number of Compositions that
@ -160,13 +160,13 @@ This feature serves as a lightweight policy mechanism by only giving the
consumer the ability to customize the underlying resources to the extent the
platform builder desires. For instance, in the examples above, a platform
builder may choose to define a `spec.location` field in the schema of the
`XMySQLInstance` that is an enum with options `east` and `west`. In the
`XMySQLInstance` that's an enum with options `east` and `west`. In the
Composition, those fields could map to the `RDSInstance` `spec.region` field,
making the value either `us-east-1` or `us-west-1`. If no other patches were
defined for the `RDSInstance`, giving a user the ability (using RBAC) to create
a `XMySQLInstance` / `MySQLInstance` would be akin to giving the ability to
create a very specifically configured `RDSInstance`, where they can only decide
the region where it lives and they are restricted to two options.
create a specifically configured `RDSInstance`, where they can only decide
the region where it lives and they're restricted to two options.
This model is in contrast to many infrastructure as code tools where the end
user must have provider credentials to create the underlying resources that are
@ -182,11 +182,11 @@ standardizing on Kubernetes RBAC.
While the ability to define abstract schemas and patches to concrete resource
types using composition is powerful, the ability to define Claim types at the
namespace scope enhances the functionality further by enabling RBAC to be
applied with namespace restrictions. Most users in a cluster do not have access
to cluster-scoped resources as they are considered only relevant to
applied with namespace restrictions. Most users in a cluster don't have access
to cluster-scoped resources as they're considered only relevant to
infrastructure admins by both Kubernetes and Crossplane.
Building on our simple `XMySQLInstance` / `MySQLInstance` example, a platform
Building on our `XMySQLInstance` / `MySQLInstance` example, a platform
builder may choose to define permissions on `MySQLInstance` at the namespace
scope using a `Role`. This allows for giving users the ability to create and
manage `MySQLInstances` in their given namespace, but not the ability to see
@ -249,15 +249,15 @@ namespace the corresponding `MySQLInstance` was created in.
### Policy Enforcement with Open Policy Agent
In some Crossplane deployment models, only using composition and RBAC to define
policy will not be flexible enough. However, because Crossplane brings
management of external infrastructure to the Kubernetes API, it is well suited
to integrate with other projects in the cloud-native ecosystem. Organizations
policy won't be flexible enough. However, because Crossplane brings
management of external infrastructure to the Kubernetes API, it's well suited
to integrate with other projects in the cloud native ecosystem. Organizations
and individuals that need a more robust policy engine, or just prefer a more
general language for defining policy, often turn to [Open Policy Agent] (OPA).
OPA allows platform builders to write custom logic in [Rego], a domain-specific
OPA allows platform builders to write custom logic in [Rego], a domain specific
language. Writing policy in this manner allows for not only incorporating the
information available in the specific resource being evaluated, but also using
other state represented in the cluster. Crossplane users typically install OPA's
other state represented in the cluster. Crossplane users typically install OPA
[Gatekeeper] to make policy management as streamlined as possible.
> A live demo of using OPA with Crossplane can be viewed [here].
@ -271,14 +271,16 @@ simpler.
### Reproducible Platforms with Configuration Packages
[Configuration packages] allow platform builders to package their XRDs and
Compositions into [OCI images] that can be distributed via any OCI-compliant
Compositions into [OCI images] that can be distributed via any OCI compliant
image registry. These packages can also declare dependencies on providers,
meaning that a single package can declare all of the granular managed resources,
the controllers that must be deployed to reconcile them, and the abstract types
that expose the underlying resources using composition.
Organizations with many Crossplane deployments utilize Configuration packages to
<!-- vale alex.Condescending = NO -->
reproduce their platform in each cluster. This can be as simple as installing
<!-- vale alex.Condescending = YES -->
Crossplane with the flag to automatically install a Configuration package
alongside it.

4
content/v1.16/guides/self-signed-ca-certs.md
View File

@ -3,7 +3,7 @@ title: Self-Signed CA Certs
weight: 270
---
> Using self-signed certificates is not advised in production, it is
> 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
@ -39,7 +39,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 convered in the Helm docs,
> Providing Helm with parameter values is covered in the Helm docs,
[Helm install](https://helm.sh/docs/helm/helm_install/). An example block
in an `override.yaml` file would look like this:
```

53
content/v1.16/guides/troubleshoot-crossplane.md
View File

@ -5,12 +5,12 @@ weight: 306
## Requested Resource Not Found
If you use the Crossplane CLI to install a `Provider` or
`Configuration` (e.g. `crossplane install provider
`Configuration` (for example, `crossplane install provider
xpkg.upbound.io/crossplane-contrib/provider-aws:v0.33.0`) and get `the server
could not find the requested resource` error, more often than not, that is an
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
plugin is not aware of this change.
plugin isn't aware of this change.
## Resource Status and Conditions
@ -32,14 +32,14 @@ Status:
```
Most Crossplane resources set the `Ready` condition. `Ready` represents the
availability of the resource - whether it is creating, deleting, available,
availability of the resource - whether it's creating, deleting, available,
unavailable, binding, etc.
## Resource Events
Most Crossplane resources emit _events_ when something interesting happens. You
can see the events associated with a resource by running `kubectl describe` -
e.g. `kubectl describe cloudsqlinstance my-db`. You can also see all events in a
for example, `kubectl describe cloudsqlinstance my-db`. You can also see all events in a
particular namespace by running `kubectl get events`.
```console
@ -112,7 +112,7 @@ Crossplane and its providers log most error messages to resources' event fields.
1. Get the events for the root resource using `kubectl describe` or `kubectl get event`
2. If there are errors in the events, address them.
3. If there are no errors, follow its sub-resources.
3. If there are no errors, follow its subresources.
`kubectl get <KIND> <NAME> -o=jsonpath='{.spec.resourceRef}{" "}{.spec.resourceRefs}' | jq`
4. Repeat this process for each resource returned.
@ -120,7 +120,7 @@ Crossplane and its providers log most error messages to resources' event fields.
{{< hint "note" >}}
The rest of this section show you how to debug issues related to compositions without using external tooling.
If you are using ArgoCD or FluxCD with UI, you can visualize object relationships in the UI.
You can also use the kube-lineage plugin to visualize object relationships in your terminal.
You can also use the `kube-lineage` plugin to visualize object relationships in your terminal.
{{< /hint >}}
### Examples
@ -135,7 +135,7 @@ The example application never reaches available state as shown below.
1. View the claim.
```bash
```shell
kubectl describe exampleapp example-application
Status:
@ -149,7 +149,7 @@ The example application never reaches available state as shown below.
2. If the claim doesn't have errors, inspect the `.spec.resourceRef` field of the claim.
```bash
```shell
kubectl get exampleapp example-application -o=jsonpath='{.spec.resourceRef}{" "}{.spec.resourceRefs}' | jq
{
@ -161,7 +161,7 @@ The example application never reaches available state as shown below.
3. In the preceding output, you see the cluster scoped resource for this claim. Kind = `XExampleApp` name = `example-application-xqlsz`
4. View the cluster scoped resource's events.
```bash
```shell
kubectl describe xexampleapp example-application-xqlsz
Events:
@ -172,9 +172,9 @@ The example application never reaches available state as shown below.
Warning ComposeResources 6s (x6 over 10s) defined/compositeresourcedefinition.apiextensions.crossplane.io can't render composed resource from resource template at index 3: can't use dry-run create to name composed resource: an empty namespace may not be set during creation
Normal ComposeResources 6s (x6 over 10s) defined/compositeresourcedefinition.apiextensions.crossplane.io Successfully composed resources
```
5. You see errors in the events. it's complaining about not specifying namespace in its compositions. For this particular kind of error, you can get its sub-resources and check which one isn't created.
5. You see errors in the events. it's complaining about not specifying namespace in its compositions. For this particular kind of error, you can get its subresources and check which one isn't created.
```bash
```shell
kubectl get xexampleapp example-application-xqlsz -o=jsonpath='{.spec.resourceRef}{" "}{.spec.resourceRefs}' | jq
[
@ -207,7 +207,7 @@ Debugging Composite Resource Definition (XRD) is like debugging Compositions.
1. Get the XRD
```bash
```shell
kubectl get xrd testing.awsblueprints.io
NAME ESTABLISHED OFFERED AGE
@ -215,7 +215,7 @@ Debugging Composite Resource Definition (XRD) is like debugging Compositions.
```
2. Notice its status it not established. You describe this XRD to get its events.
```bash
```shell
kubectl describe xrd testing.awsblueprints.io
Events:
@ -231,14 +231,13 @@ Debugging Composite Resource Definition (XRD) is like debugging Compositions.
You can use install providers in two ways: `configuration.pkg.crossplane.io` and `provider.pkg.crossplane.io`. You can use either one to install providers with no functional differences to providers themselves.
If you define a `configuration.pkg.crossplane.io` object, Crossplane creates a
`provider.pkg.crossplane.io` object and manages it. Refer to [the Packages
documentation]({{<ref "/master/concepts/packages">}})
`provider.pkg.crossplane.io` object and manages it. Refer to [the Packages documentation]({{<ref "/master/concepts/packages">}})
for more information about Crossplane Packages.
If you are experiencing provider issues, steps below are a good starting point.
1. Check the status of provider object.
```bash
```shell
kubectl describe provider.pkg.crossplane.io provider-aws
Status:
@ -264,7 +263,7 @@ If you are experiencing provider issues, steps below are a good starting point.
2. When you create a provider object, Crossplane creates a `ProviderRevision` object based on the contents of the OCI image. In this example, you're specifying the OCI image to be `crossplane/provider-aws:v0.29.0`. This image contains a YAML file which defines Kubernetes objects such as Deployment, ServiceAccount, and CRDs.
The `ProviderRevision` object creates resources necessary for a provider to function based on the contents of the YAML file. To inspect what's deployed as part of the provider package, you inspect the ProviderRevision object. The `Current Revision` field above indicates which ProviderRevision object this provider uses.
```bash
```shell
kubectl get providerrevision provider-aws-a2e16ca2fc1a
NAME HEALTHY REVISION IMAGE STATE DEP-FOUND DEP-INSTALLED AGE
@ -273,7 +272,7 @@ The `ProviderRevision` object creates resources necessary for a provider to func
When you describe the object, you find all CRDs managed by this object.
```bash
```shell
kubectl describe providerrevision provider-aws-a2e16ca2fc1a
Status:
@ -297,7 +296,7 @@ The `ProviderRevision` object creates resources necessary for a provider to func
<!-- vale Google.WordList = YES -->
3. If you don't see any errors in the event field above, you should check if Crossplane provisioned deployments and their status.
```bash
```shell
kubectl get deployment -n crossplane-system
NAME READY UP-TO-DATE AVAILABLE AGE
@ -320,16 +319,16 @@ The `ProviderRevision` object creates resources necessary for a provider to func
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
following command to simply scale down its deployment:
following command to scale down its deployment:
```bash
```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
unpause Crossplane simply by scaling its deployment back up:
unpause Crossplane by scaling its deployment back up:
```bash
```shell
kubectl -n crossplane-system scale --replicas=1 deployment/crossplane
```
@ -405,9 +404,9 @@ kubectl describe postgresqlinstance.database.example.org my-db
```
Per Kubernetes convention, Crossplane keeps errors close to the place they
happen. This means that if your claim is not becoming ready due to an issue with
happen. This means that if your claim isn't becoming ready due to an issue with
your `Composition` or with a composed resource you'll need to "follow the
references" to find out why. Your claim will only tell you that the XR is not
references" to find out why. Your claim will only tell you that the XR isn't
yet ready.
To follow the references:
@ -420,7 +419,7 @@ To follow the references:
look for the "Resource Refs" (or `spec.resourceRefs`) to find your composed
resources.
1. Run `kubectl describe` on each referenced composed resource to determine
whether it is ready and what issues, if any, it is encountering.
whether it's ready and what issues, if any, it's encountering.

5
content/v1.16/guides/vault-as-secret-store.md
View File

@ -32,8 +32,7 @@ This guide requires [Helm](https://helm.sh) version 3.11 or later.
## Install Vault
{{<hint "note" >}}
Detailed instructions on [installing
Vault](https://developer.hashicorp.com/vault/docs/platform/k8s/helm)
Detailed instructions on [installing Vault](https://developer.hashicorp.com/vault/docs/platform/k8s/helm)
are available from the Vault documentation.
{{< /hint >}}
@ -515,7 +514,7 @@ is the name of the Claim's
{{<hover label="claim" line="12">}}publishConnectionDetailsTo{{</hover>}}
configuration.
Check connection secrets in the "crossplane-system" Vault scope.
Check connection secrets in the `crossplane-system` Vault scope.
```shell {copy-lines="1",label="scope-key"}
kubectl -n vault-system exec -i vault-0 -- vault kv list /secret/crossplane-system
Keys

32
content/v1.16/guides/vault-injection.md
View File

@ -14,15 +14,15 @@ following sources:
- Filesystem
A provider may optionally support additional credentials sources, but the common
sources cover a wide variety of use cases. One specific use case that is popular
sources cover a wide variety of use cases. One specific use case that's popular
among organizations that use [Vault] for secrets management is using a sidecar
to inject credentials into the filesystem. This guide will demonstrate how to
use the [Vault Kubernetes Sidecar] to provide credentials for [provider-gcp]
and [provider-aws].
> Note: in this guide we will copy GCP credentials and AWS access keys
> into Vault's KV secrets engine. This is a simple generic approach to
> managing secrets with Vault, but is not as robust as using Vault's
> into Vault's KV secrets engine. This is a generic approach to
> managing secrets with Vault, but isn't as robust as using Vault's
> dedicated cloud provider secrets engines for [AWS], [Azure], and [GCP].
## Setup
@ -32,7 +32,7 @@ and [provider-aws].
> outside the cluster but has Kubernetes authentication enabled.
Before getting started, you must ensure that you have installed Crossplane and
Vault and that they are running in your cluster.
Vault and that they're running in your cluster.
1. Install Crossplane
@ -66,9 +66,9 @@ kubectl exec vault-0 -- vault operator unseal $VAULT_UNSEAL_KEY
4. Enable Kubernetes Authentication Method
In order for Vault to be able to authenticate requests based on Kubernetes
service accounts, the [Kubernetes authentication backend] must be enabled. This
service accounts, the [Kubernetes authentication method] must be enabled. This
requires logging in to Vault and configuring it with a service account token,
API server address, and certificate. Because we are running Vault in Kubernetes,
API server address, and certificate. Because we're running Vault in Kubernetes,
these values are already available via the container filesystem and environment
variables.
@ -136,7 +136,7 @@ secrets engine].
> Note: the steps below involve copying credentials into the container
> filesystem before storing them in Vault. You may also choose to use Vault's
> HTTP API or UI by port-forwarding the container to your local environment
> HTTP API or UI by port forwarding the container to your local environment
> (`kubectl port-forward vault-0 8200:8200`).
1. Copy Credentials File into Vault Container
@ -254,7 +254,7 @@ EOF
1. Create Role
The last step is to create a role that is bound to the policy you created and
The last step is to create a role that's bound to the policy you created and
associate it with a group of Kubernetes service accounts. This role can be
assumed by any (`*`) service account in the `crossplane-system` namespace.
@ -286,10 +286,9 @@ by any number of `Provider` objects that wish to use its configuration. In the
example below, the `Pod` annotations indicate to the Vault mutating webhook that
we want for the secret stored at `secret/provider-creds/gcp-default` to be
injected into the container filesystem by assuming role `crossplane-providers`.
There is also so template formatting added to make sure the secret data is
Template formatting has been added to make sure the secret data is
presented in a form that `provider-gcp` is expecting.
{% raw %}
```console
echo "apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
@ -315,7 +314,6 @@ spec:
controllerConfigRef:
name: vault-config" | kubectl apply -f -
```
{% endraw %}
## Configure provider-gcp
@ -323,7 +321,7 @@ One `provider-gcp` is installed and running, you will want to create a
`ProviderConfig` that specifies the credentials in the filesystem that should be
used to provision managed resources that reference this `ProviderConfig`.
Because the name of this `ProviderConfig` is `default` it will be used by any
managed resources that do not explicitly reference a `ProviderConfig`.
managed resources that don't explicitly reference a `ProviderConfig`.
> Note: make sure that the `PROJECT_ID` environment variable that was defined
> earlier is still set correctly.
@ -352,7 +350,7 @@ kubectl -n crossplane-system exec -it $PROVIDER_CONTROLLER_POD -c provider-gcp -
## Provision Infrastructure
The final step is to actually provision a `CloudSQLInstance`. Creating the
object below will result in the creation of a Cloud SQL Postgres database on
object below will result in the creation of a Cloud SQL PostgreSQL database on
GCP.
```console
@ -392,10 +390,9 @@ by any number of `Provider` objects that wish to use its configuration. In the
example below, the `Pod` annotations indicate to the Vault mutating webhook that
we want for the secret stored at `secret/provider-creds/aws-default` to be
injected into the container filesystem by assuming role `crossplane-providers`.
There is also some template formatting added to make sure the secret data is
Template formatting has been added to make sure the secret data is
presented in a form that `provider-aws` is expecting.
{% raw %}
```console
echo "apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
@ -425,7 +422,6 @@ spec:
controllerConfigRef:
name: aws-vault-config" | kubectl apply -f -
```
{% endraw %}
## Configure provider-aws
@ -433,7 +429,7 @@ Once `provider-aws` is installed and running, you will want to create a
`ProviderConfig` that specifies the credentials in the filesystem that should be
used to provision managed resources that reference this `ProviderConfig`.
Because the name of this `ProviderConfig` is `default` it will be used by any
managed resources that do not explicitly reference a `ProviderConfig`.
managed resources that don't explicitly reference a `ProviderConfig`.
```console
echo "apiVersion: aws.crossplane.io/v1beta1
@ -501,6 +497,6 @@ kubectl get bucket -w
[Azure]: https://www.vaultproject.io/docs/secrets/azure
[GCP]: https://www.vaultproject.io/docs/secrets/gcp
[unsealed]: https://www.vaultproject.io/docs/concepts/seal
[Kubernetes authentication backend]: https://www.vaultproject.io/docs/auth/kubernetes
[Kubernetes authentication method]: https://www.vaultproject.io/docs/auth/kubernetes
[kv secrets engine]: https://www.vaultproject.io/docs/secrets/kv/kv-v2
[policy]: https://www.vaultproject.io/docs/concepts/policies

10
content/v1.16/learn/_index.md
View File

@ -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 drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us].
***Learn more about using Crossplane***
- [Latest Design Docs](https://github.com/crossplane/crossplane/tree/main/design)
@ -20,14 +20,16 @@ If you have any questions, please drop us a note on [Crossplane Slack][join-cros
- [Programming Kubernetes Book](https://www.oreilly.com/library/view/programming-kubernetes/9781492047094/)
- [Contributor Guide](https://github.com/crossplane/crossplane/blob/main/CONTRIBUTING.md)
***Join the growing Crossplane community and get involved!***
***Join the growing Crossplane community and get involved***
- Join our [Community Slack](https://slack.crossplane.io/)!
- Submit an issue on [GitHub](https://github.com/crossplane/crossplane)
- Attend our bi-weekly [Community Meeting](https://github.com/crossplane/crossplane#get-involved)
- Join our bi-weekly live stream: [The Binding Status](https://github.com/crossplane/tbs)
- 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)
<!-- vale Crossplane.Spelling = NO -->
- Drop us a note on Twitter: [@crossplane_io](https://twitter.com/crossplane_io)
- Email us: [info@crossplane.io](mailto:info@crossplane.io)
<!-- vale Crossplane.Spelling = YES -->
<!-- Named links -->

14
content/v1.16/learn/feature-lifecycle.md
View File

@ -22,7 +22,9 @@ removal or breaking changes without notice**, and generally not considered ready
for use in production.
In some cases alpha features require fields be added to existing beta or GA
API types. In these cases fields must clearly be marked (i.e in their OpenAPI
<!-- vale alex.Condescending = NO -->
API types. In these cases fields must clearly be marked (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.
@ -31,24 +33,26 @@ All alpha features should have an issue tracking their graduation to beta.
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 will not be
`v1beta1`. Beta features are considered to be well tested, and won't be
removed completely without being marked 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
instructions for migrating to the next version. This may require deleting,
editing, and re-creating API objects. The editing process may require some
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
these cases fields must clearly be marked (i.e in their OpenAPI schema) as beta
<!-- vale alex.Condescending = NO -->
these cases fields must clearly be marked (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
GA features are always enabled - they cannot be disabled. API types pertaining
GA features are always enabled - they can't be disabled. 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.

12
content/v1.16/learn/release-cycle.md
View File

@ -18,7 +18,7 @@ be maintained 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 back-ported to the
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
release branch if no longer applicable on the main development branch.
@ -30,15 +30,15 @@ effort basis by maintainers and contributors for currently maintained 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 back-ported fixes will be included in a patch release as
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
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
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.
@ -55,7 +55,7 @@ The following stages are the main milestones in a Crossplane release.
### Active development
During active development, any code that meets the requisite criteria (i.e.
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
@ -65,7 +65,7 @@ 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
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.

16
content/v1.17/concepts/composition-revisions.md
View File

@ -93,7 +93,7 @@ metadata:
spec:
parameters:
storageGB: 20
# The Manual policy specifies that you do not want this XR to update to the
# The Manual policy specifies that you don't want this XR to update to the
# latest CompositionRevision automatically.
compositionUpdatePolicy: Manual
compositionRef:
@ -348,8 +348,8 @@ 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.
XRs `vpc-man` and `vpc-dev` are still assigned to the original revision:1:
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
kubectl get composite -o="custom-columns=NAME:.metadata.name,SYNCED:.status.conditions[0].status,REVISION:.spec.compositionRevisionRef.name,POLICY:.spec.compositionUpdatePolicy,MATCHLABEL:.spec.compositionRevisionSelector.matchLabels"
@ -365,7 +365,7 @@ vpc-staging True myvpcs.aws.example.upbound.io-727b3c8 Automatic map[c
{{< hint "note" >}}
`vpc-auto` always use the latest Revision.
`vpc-staging` now matches the label applied to Revision revision:2.
`vpc-staging` now matches the label applied to Revision `revision:2`.
{{< /hint >}}
#### Update Composition Spec and Label
@ -427,8 +427,8 @@ myvpcs.aws.example.upbound.io-f81c553 3 dev
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.
`vpc-staging` is assigned to revision:2, and `vpc-man` is still assigned to the original revision:1:
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`:
```shell
kubectl get composite -o="custom-columns=NAME:.metadata.name,SYNCED:.status.conditions[0].status,REVISION:.spec.compositionRevisionRef.name,POLICY:.spec.compositionUpdatePolicy,MATCHLABEL:.spec.compositionRevisionSelector.matchLabels"
@ -444,8 +444,8 @@ vpc-staging True myvpcs.aws.example.upbound.io-727b3c8 Automatic map[c
{{< hint "note" >}}
`vpc-dev` matches the updated label applied to Revision revision:3.
`vpc-staging` matches the label applied to Revision revision:2.
`vpc-dev` matches the updated label applied to Revision `revision:3`.
`vpc-staging` matches the label applied to Revision `revision:2`.
{{< /hint >}}

14
content/v1.17/guides/crossplane-with-argo-cd.md
View File

@ -5,14 +5,14 @@ weight: 270
[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. There are
configuration details required in order for the two to work together properly.
cluster into a Universal Control Plane for all of 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.
Argo CD synchronizes Kubernetes resource manifests stored in a Git repository
with those running in a Kubernetes cluster (GitOps). There are different ways to configure
how Argo CD tracks resources. With Crossplane, you need to configure Argo CD
with those running in a Kubernetes cluster (GitOps). Argo CD has different ways to configure
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.
### Configuring Argo CD with Crossplane
@ -185,12 +185,12 @@ data:
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 are not expected to interact with this resource.
ProviderConfig is deleted. End users of Crossplane aren't expected 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
recommend hiding all `ProviderConfigUsage` resources from Argo CD UI.
To configure resource exclusion edit the `argocd-cm` `ConfigMap` in the `argocd` `Namespace` as such:
To configure resource exclusion edit the `argocd-cm` `ConfigMap` in the `argocd` `Namespace` as such:
```yaml
apiVersion: v1
kind: ConfigMap
@ -204,7 +204,7 @@ data:
The use of `"*"` as apiGroups will enable the mechanism for all Crossplane Providers.
#### Increase K8s Client QPS
#### Increase Kubernetes Client QPS
As the number of CRDs grow on a control plane it will increase 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.

36
content/v1.17/guides/multi-tenant.md
View File

@ -5,9 +5,9 @@ weight: 240
This guide describes how to use Crossplane effectively in multi-tenant
environments by utilizing Kubernetes primitives and compatible policy
enforcement projects in the cloud-native ecosystem.
enforcement projects in the cloud native ecosystem.
## TL;DR
## Summary
Infrastructure operators in multi-tenant Crossplane environments typically
utilize composition and Kubernetes RBAC to define lightweight, standardized
@ -21,7 +21,7 @@ those with more complex environments, may choose to incorporate third-party
policy engines, or scale to multiple Crossplane clusters. The following sections
describe each of these scenarios in greater detail.
- [TL;DR](#tldr)
- [Summary](#summary)
- [Background](#background)
- [Cluster-Scoped Managed Resources](#cluster-scoped-managed-resources)
- [Namespace Scoped Claims](#namespace-scoped-claims)
@ -109,7 +109,7 @@ in response to the creation of an instance of the XRD. More information about
this architecture can be found in the [Composition] documentation.
Every XRD is exposed at the cluster scope, but only those with `spec.claimNames`
defined will have a namespace-scoped variant.
defined will have a namespace scoped variant.
```yaml
apiVersion: apiextensions.crossplane.io/v1
@ -131,7 +131,7 @@ When the example above is created, Crossplane will produce two
[CustomResourceDefinitions]:
1. A cluster-scoped type with `kind: XMySQLInstance`. This is referred to as a
**Composite Resource (XR)**.
2. A namespace-scoped type with `kind: MySQLInstance`. This is referred to as a
2. A namespace scoped type with `kind: MySQLInstance`. This is referred to as a
**Claim (XRC)**.
Platform builders may choose to define an arbitrary number of Compositions that
@ -160,13 +160,13 @@ This feature serves as a lightweight policy mechanism by only giving the
consumer the ability to customize the underlying resources to the extent the
platform builder desires. For instance, in the examples above, a platform
builder may choose to define a `spec.location` field in the schema of the
`XMySQLInstance` that is an enum with options `east` and `west`. In the
`XMySQLInstance` that's an enum with options `east` and `west`. In the
Composition, those fields could map to the `RDSInstance` `spec.region` field,
making the value either `us-east-1` or `us-west-1`. If no other patches were
defined for the `RDSInstance`, giving a user the ability (using RBAC) to create
a `XMySQLInstance` / `MySQLInstance` would be akin to giving the ability to
create a very specifically configured `RDSInstance`, where they can only decide
the region where it lives and they are restricted to two options.
create a specifically configured `RDSInstance`, where they can only decide
the region where it lives and they're restricted to two options.
This model is in contrast to many infrastructure as code tools where the end
user must have provider credentials to create the underlying resources that are
@ -182,11 +182,11 @@ standardizing on Kubernetes RBAC.
While the ability to define abstract schemas and patches to concrete resource
types using composition is powerful, the ability to define Claim types at the
namespace scope enhances the functionality further by enabling RBAC to be
applied with namespace restrictions. Most users in a cluster do not have access
to cluster-scoped resources as they are considered only relevant to
applied with namespace restrictions. Most users in a cluster don't have access
to cluster-scoped resources as they're considered only relevant to
infrastructure admins by both Kubernetes and Crossplane.
Building on our simple `XMySQLInstance` / `MySQLInstance` example, a platform
Building on our `XMySQLInstance` / `MySQLInstance` example, a platform
builder may choose to define permissions on `MySQLInstance` at the namespace
scope using a `Role`. This allows for giving users the ability to create and
manage `MySQLInstances` in their given namespace, but not the ability to see
@ -249,15 +249,15 @@ namespace the corresponding `MySQLInstance` was created in.
### Policy Enforcement with Open Policy Agent
In some Crossplane deployment models, only using composition and RBAC to define
policy will not be flexible enough. However, because Crossplane brings
management of external infrastructure to the Kubernetes API, it is well suited
to integrate with other projects in the cloud-native ecosystem. Organizations
policy won't be flexible enough. However, because Crossplane brings
management of external infrastructure to the Kubernetes API, it's well suited
to integrate with other projects in the cloud native ecosystem. Organizations
and individuals that need a more robust policy engine, or just prefer a more
general language for defining policy, often turn to [Open Policy Agent] (OPA).
OPA allows platform builders to write custom logic in [Rego], a domain-specific
OPA allows platform builders to write custom logic in [Rego], a domain specific
language. Writing policy in this manner allows for not only incorporating the
information available in the specific resource being evaluated, but also using
other state represented in the cluster. Crossplane users typically install OPA's
other state represented in the cluster. Crossplane users typically install OPA
[Gatekeeper] to make policy management as streamlined as possible.
> A live demo of using OPA with Crossplane can be viewed [here].
@ -271,14 +271,16 @@ simpler.
### Reproducible Platforms with Configuration Packages
[Configuration packages] allow platform builders to package their XRDs and
Compositions into [OCI images] that can be distributed via any OCI-compliant
Compositions into [OCI images] that can be distributed via any OCI compliant
image registry. These packages can also declare dependencies on providers,
meaning that a single package can declare all of the granular managed resources,
the controllers that must be deployed to reconcile them, and the abstract types
that expose the underlying resources using composition.
Organizations with many Crossplane deployments utilize Configuration packages to
<!-- vale alex.Condescending = NO -->
reproduce their platform in each cluster. This can be as simple as installing
<!-- vale alex.Condescending = YES -->
Crossplane with the flag to automatically install a Configuration package
alongside it.

4
content/v1.17/guides/self-signed-ca-certs.md
View File

@ -3,7 +3,7 @@ title: Self-Signed CA Certs
weight: 270
---
> Using self-signed certificates is not advised in production, it is
> 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
@ -39,7 +39,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 convered in the Helm docs,
> Providing Helm with parameter values is covered in the Helm docs,
[Helm install](https://helm.sh/docs/helm/helm_install/). An example block
in an `override.yaml` file would look like this:
```

53
content/v1.17/guides/troubleshoot-crossplane.md
View File

@ -5,12 +5,12 @@ weight: 306
## Requested Resource Not Found
If you use the Crossplane CLI to install a `Provider` or
`Configuration` (e.g. `crossplane install provider
`Configuration` (for example, `crossplane install provider
xpkg.upbound.io/crossplane-contrib/provider-aws:v0.33.0`) and get `the server
could not find the requested resource` error, more often than not, that is an
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
plugin is not aware of this change.
plugin isn't aware of this change.
## Resource Status and Conditions
@ -32,14 +32,14 @@ Status:
```
Most Crossplane resources set the `Ready` condition. `Ready` represents the
availability of the resource - whether it is creating, deleting, available,
availability of the resource - whether it's creating, deleting, available,
unavailable, binding, etc.
## Resource Events
Most Crossplane resources emit _events_ when something interesting happens. You
can see the events associated with a resource by running `kubectl describe` -
e.g. `kubectl describe cloudsqlinstance my-db`. You can also see all events in a
for example, `kubectl describe cloudsqlinstance my-db`. You can also see all events in a
particular namespace by running `kubectl get events`.
```console
@ -112,7 +112,7 @@ Crossplane and its providers log most error messages to resources' event fields.
1. Get the events for the root resource using `kubectl describe` or `kubectl get event`
2. If there are errors in the events, address them.
3. If there are no errors, follow its sub-resources.
3. If there are no errors, follow its subresources.
`kubectl get <KIND> <NAME> -o=jsonpath='{.spec.resourceRef}{" "}{.spec.resourceRefs}' | jq`
4. Repeat this process for each resource returned.
@ -120,7 +120,7 @@ Crossplane and its providers log most error messages to resources' event fields.
{{< hint "note" >}}
The rest of this section show you how to debug issues related to compositions without using external tooling.
If you are using ArgoCD or FluxCD with UI, you can visualize object relationships in the UI.
You can also use the kube-lineage plugin to visualize object relationships in your terminal.
You can also use the `kube-lineage` plugin to visualize object relationships in your terminal.
{{< /hint >}}
### Examples
@ -135,7 +135,7 @@ The example application never reaches available state as shown below.
1. View the claim.
```bash
```shell
kubectl describe exampleapp example-application
Status:
@ -149,7 +149,7 @@ The example application never reaches available state as shown below.
2. If the claim doesn't have errors, inspect the `.spec.resourceRef` field of the claim.
```bash
```shell
kubectl get exampleapp example-application -o=jsonpath='{.spec.resourceRef}{" "}{.spec.resourceRefs}' | jq
{
@ -161,7 +161,7 @@ The example application never reaches available state as shown below.
3. In the preceding output, you see the cluster scoped resource for this claim. Kind = `XExampleApp` name = `example-application-xqlsz`
4. View the cluster scoped resource's events.
```bash
```shell
kubectl describe xexampleapp example-application-xqlsz
Events:
@ -172,9 +172,9 @@ The example application never reaches available state as shown below.
Warning ComposeResources 6s (x6 over 10s) defined/compositeresourcedefinition.apiextensions.crossplane.io can't render composed resource from resource template at index 3: can't use dry-run create to name composed resource: an empty namespace may not be set during creation
Normal ComposeResources 6s (x6 over 10s) defined/compositeresourcedefinition.apiextensions.crossplane.io Successfully composed resources
```
5. You see errors in the events. it's complaining about not specifying namespace in its compositions. For this particular kind of error, you can get its sub-resources and check which one isn't created.
5. You see errors in the events. it's complaining about not specifying namespace in its compositions. For this particular kind of error, you can get its subresources and check which one isn't created.
```bash
```shell
kubectl get xexampleapp example-application-xqlsz -o=jsonpath='{.spec.resourceRef}{" "}{.spec.resourceRefs}' | jq
[
@ -207,7 +207,7 @@ Debugging Composite Resource Definition (XRD) is like debugging Compositions.
1. Get the XRD
```bash
```shell
kubectl get xrd testing.awsblueprints.io
NAME ESTABLISHED OFFERED AGE
@ -215,7 +215,7 @@ Debugging Composite Resource Definition (XRD) is like debugging Compositions.
```
2. Notice its status it not established. You describe this XRD to get its events.
```bash
```shell
kubectl describe xrd testing.awsblueprints.io
Events:
@ -231,14 +231,13 @@ Debugging Composite Resource Definition (XRD) is like debugging Compositions.
You can use install providers in two ways: `configuration.pkg.crossplane.io` and `provider.pkg.crossplane.io`. You can use either one to install providers with no functional differences to providers themselves.
If you define a `configuration.pkg.crossplane.io` object, Crossplane creates a
`provider.pkg.crossplane.io` object and manages it. Refer to [the Packages
documentation]({{<ref "/master/concepts/packages">}})
`provider.pkg.crossplane.io` object and manages it. Refer to [the Packages documentation]({{<ref "/master/concepts/packages">}})
for more information about Crossplane Packages.
If you are experiencing provider issues, steps below are a good starting point.
1. Check the status of provider object.
```bash
```shell
kubectl describe provider.pkg.crossplane.io provider-aws
Status:
@ -264,7 +263,7 @@ If you are experiencing provider issues, steps below are a good starting point.
2. When you create a provider object, Crossplane creates a `ProviderRevision` object based on the contents of the OCI image. In this example, you're specifying the OCI image to be `crossplane/provider-aws:v0.29.0`. This image contains a YAML file which defines Kubernetes objects such as Deployment, ServiceAccount, and CRDs.
The `ProviderRevision` object creates resources necessary for a provider to function based on the contents of the YAML file. To inspect what's deployed as part of the provider package, you inspect the ProviderRevision object. The `Current Revision` field above indicates which ProviderRevision object this provider uses.
```bash
```shell
kubectl get providerrevision provider-aws-a2e16ca2fc1a
NAME HEALTHY REVISION IMAGE STATE DEP-FOUND DEP-INSTALLED AGE
@ -273,7 +272,7 @@ The `ProviderRevision` object creates resources necessary for a provider to func
When you describe the object, you find all CRDs managed by this object.
```bash
```shell
kubectl describe providerrevision provider-aws-a2e16ca2fc1a
Status:
@ -297,7 +296,7 @@ The `ProviderRevision` object creates resources necessary for a provider to func
<!-- vale Google.WordList = YES -->
3. If you don't see any errors in the event field above, you should check if Crossplane provisioned deployments and their status.
```bash
```shell
kubectl get deployment -n crossplane-system
NAME READY UP-TO-DATE AVAILABLE AGE
@ -320,16 +319,16 @@ The `ProviderRevision` object creates resources necessary for a provider to func
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
following command to simply scale down its deployment:
following command to scale down its deployment:
```bash
```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
unpause Crossplane simply by scaling its deployment back up:
unpause Crossplane by scaling its deployment back up:
```bash
```shell
kubectl -n crossplane-system scale --replicas=1 deployment/crossplane
```
@ -405,9 +404,9 @@ kubectl describe postgresqlinstance.database.example.org my-db
```
Per Kubernetes convention, Crossplane keeps errors close to the place they
happen. This means that if your claim is not becoming ready due to an issue with
happen. This means that if your claim isn't becoming ready due to an issue with
your `Composition` or with a composed resource you'll need to "follow the
references" to find out why. Your claim will only tell you that the XR is not
references" to find out why. Your claim will only tell you that the XR isn't
yet ready.
To follow the references:
@ -420,7 +419,7 @@ To follow the references:
look for the "Resource Refs" (or `spec.resourceRefs`) to find your composed
resources.
1. Run `kubectl describe` on each referenced composed resource to determine
whether it is ready and what issues, if any, it is encountering.
whether it's ready and what issues, if any, it's encountering.

5
content/v1.17/guides/vault-as-secret-store.md
View File

@ -32,8 +32,7 @@ This guide requires [Helm](https://helm.sh) version 3.11 or later.
## Install Vault
{{<hint "note" >}}
Detailed instructions on [installing
Vault](https://developer.hashicorp.com/vault/docs/platform/k8s/helm)
Detailed instructions on [installing Vault](https://developer.hashicorp.com/vault/docs/platform/k8s/helm)
are available from the Vault documentation.
{{< /hint >}}
@ -527,7 +526,7 @@ is the name of the Claim's
{{<hover label="claim" line="12">}}publishConnectionDetailsTo{{</hover>}}
configuration.
Check connection secrets in the "crossplane-system" Vault scope.
Check connection secrets in the `crossplane-system` Vault scope.
```shell {copy-lines="1",label="scope-key"}
kubectl -n vault-system exec -i vault-0 -- vault kv list /secret/crossplane-system
Keys

32
content/v1.17/guides/vault-injection.md
View File

@ -14,15 +14,15 @@ following sources:
- Filesystem
A provider may optionally support additional credentials sources, but the common
sources cover a wide variety of use cases. One specific use case that is popular
sources cover a wide variety of use cases. One specific use case that's popular
among organizations that use [Vault] for secrets management is using a sidecar
to inject credentials into the filesystem. This guide will demonstrate how to
use the [Vault Kubernetes Sidecar] to provide credentials for [provider-gcp]
and [provider-aws].
> Note: in this guide we will copy GCP credentials and AWS access keys
> into Vault's KV secrets engine. This is a simple generic approach to
> managing secrets with Vault, but is not as robust as using Vault's
> into Vault's KV secrets engine. This is a generic approach to
> managing secrets with Vault, but isn't as robust as using Vault's
> dedicated cloud provider secrets engines for [AWS], [Azure], and [GCP].
## Setup
@ -32,7 +32,7 @@ and [provider-aws].
> outside the cluster but has Kubernetes authentication enabled.
Before getting started, you must ensure that you have installed Crossplane and
Vault and that they are running in your cluster.
Vault and that they're running in your cluster.
1. Install Crossplane
@ -66,9 +66,9 @@ kubectl exec vault-0 -- vault operator unseal $VAULT_UNSEAL_KEY
4. Enable Kubernetes Authentication Method
In order for Vault to be able to authenticate requests based on Kubernetes
service accounts, the [Kubernetes authentication backend] must be enabled. This
service accounts, the [Kubernetes authentication method] must be enabled. This
requires logging in to Vault and configuring it with a service account token,
API server address, and certificate. Because we are running Vault in Kubernetes,
API server address, and certificate. Because we're running Vault in Kubernetes,
these values are already available via the container filesystem and environment
variables.
@ -136,7 +136,7 @@ secrets engine].
> Note: the steps below involve copying credentials into the container
> filesystem before storing them in Vault. You may also choose to use Vault's
> HTTP API or UI by port-forwarding the container to your local environment
> HTTP API or UI by port forwarding the container to your local environment
> (`kubectl port-forward vault-0 8200:8200`).
1. Copy Credentials File into Vault Container
@ -254,7 +254,7 @@ EOF
1. Create Role
The last step is to create a role that is bound to the policy you created and
The last step is to create a role that's bound to the policy you created and
associate it with a group of Kubernetes service accounts. This role can be
assumed by any (`*`) service account in the `crossplane-system` namespace.
@ -286,10 +286,9 @@ by any number of `Provider` objects that wish to use its configuration. In the
example below, the `Pod` annotations indicate to the Vault mutating webhook that
we want for the secret stored at `secret/provider-creds/gcp-default` to be
injected into the container filesystem by assuming role `crossplane-providers`.
There is also so template formatting added to make sure the secret data is
Template formatting has been added to make sure the secret data is
presented in a form that `provider-gcp` is expecting.
{% raw %}
```console
echo "apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
@ -315,7 +314,6 @@ spec:
controllerConfigRef:
name: vault-config" | kubectl apply -f -
```
{% endraw %}
## Configure provider-gcp
@ -323,7 +321,7 @@ One `provider-gcp` is installed and running, you will want to create a
`ProviderConfig` that specifies the credentials in the filesystem that should be
used to provision managed resources that reference this `ProviderConfig`.
Because the name of this `ProviderConfig` is `default` it will be used by any
managed resources that do not explicitly reference a `ProviderConfig`.
managed resources that don't explicitly reference a `ProviderConfig`.
> Note: make sure that the `PROJECT_ID` environment variable that was defined
> earlier is still set correctly.
@ -352,7 +350,7 @@ kubectl -n crossplane-system exec -it $PROVIDER_CONTROLLER_POD -c provider-gcp -
## Provision Infrastructure
The final step is to actually provision a `CloudSQLInstance`. Creating the
object below will result in the creation of a Cloud SQL Postgres database on
object below will result in the creation of a Cloud SQL PostgreSQL database on
GCP.
```console
@ -392,10 +390,9 @@ by any number of `Provider` objects that wish to use its configuration. In the
example below, the `Pod` annotations indicate to the Vault mutating webhook that
we want for the secret stored at `secret/provider-creds/aws-default` to be
injected into the container filesystem by assuming role `crossplane-providers`.
There is also some template formatting added to make sure the secret data is
Template formatting has been added to make sure the secret data is
presented in a form that `provider-aws` is expecting.
{% raw %}
```console
echo "apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
@ -425,7 +422,6 @@ spec:
controllerConfigRef:
name: aws-vault-config" | kubectl apply -f -
```
{% endraw %}
## Configure provider-aws
@ -433,7 +429,7 @@ Once `provider-aws` is installed and running, you will want to create a
`ProviderConfig` that specifies the credentials in the filesystem that should be
used to provision managed resources that reference this `ProviderConfig`.
Because the name of this `ProviderConfig` is `default` it will be used by any
managed resources that do not explicitly reference a `ProviderConfig`.
managed resources that don't explicitly reference a `ProviderConfig`.
```console
echo "apiVersion: aws.crossplane.io/v1beta1
@ -501,6 +497,6 @@ kubectl get bucket -w
[Azure]: https://www.vaultproject.io/docs/secrets/azure
[GCP]: https://www.vaultproject.io/docs/secrets/gcp
[unsealed]: https://www.vaultproject.io/docs/concepts/seal
[Kubernetes authentication backend]: https://www.vaultproject.io/docs/auth/kubernetes
[Kubernetes authentication method]: https://www.vaultproject.io/docs/auth/kubernetes
[kv secrets engine]: https://www.vaultproject.io/docs/secrets/kv/kv-v2
[policy]: https://www.vaultproject.io/docs/concepts/policies

10
content/v1.17/learn/_index.md
View File

@ -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 drop us a note on [Crossplane Slack][join-crossplane-slack] or [contact us][contact-us].
***Learn more about using Crossplane***
- [Latest Design Docs](https://github.com/crossplane/crossplane/tree/main/design)
@ -20,14 +20,16 @@ If you have any questions, please drop us a note on [Crossplane Slack][join-cros
- [Programming Kubernetes Book](https://www.oreilly.com/library/view/programming-kubernetes/9781492047094/)
- [Contributor Guide](https://github.com/crossplane/crossplane/blob/main/CONTRIBUTING.md)
***Join the growing Crossplane community and get involved!***
***Join the growing Crossplane community and get involved***
- Join our [Community Slack](https://slack.crossplane.io/)!
- Submit an issue on [GitHub](https://github.com/crossplane/crossplane)
- Attend our bi-weekly [Community Meeting](https://github.com/crossplane/crossplane#get-involved)
- Join our bi-weekly live stream: [The Binding Status](https://github.com/crossplane/tbs)
- 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)
<!-- vale Crossplane.Spelling = NO -->
- Drop us a note on Twitter: [@crossplane_io](https://twitter.com/crossplane_io)
- Email us: [info@crossplane.io](mailto:info@crossplane.io)
<!-- vale Crossplane.Spelling = YES -->
<!-- Named links -->

14
content/v1.17/learn/feature-lifecycle.md
View File

@ -22,7 +22,9 @@ removal or breaking changes without notice**, and generally not considered ready
for use in production.
In some cases alpha features require fields be added to existing beta or GA
API types. In these cases fields must clearly be marked (i.e in their OpenAPI
<!-- vale alex.Condescending = NO -->
API types. In these cases fields must clearly be marked (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.
@ -31,24 +33,26 @@ All alpha features should have an issue tracking their graduation to beta.
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 will not be
`v1beta1`. Beta features are considered to be well tested, and won't be
removed completely without being marked 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
instructions for migrating to the next version. This may require deleting,
editing, and re-creating API objects. The editing process may require some
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
these cases fields must clearly be marked (i.e in their OpenAPI schema) as beta
<!-- vale alex.Condescending = NO -->
these cases fields must clearly be marked (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
GA features are always enabled - they cannot be disabled. API types pertaining
GA features are always enabled - they can't be disabled. 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.

12
content/v1.17/learn/release-cycle.md
View File

@ -18,7 +18,7 @@ be maintained 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 back-ported to the
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
release branch if no longer applicable on the main development branch.
@ -30,15 +30,15 @@ effort basis by maintainers and contributors for currently maintained 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 back-ported fixes will be included in a patch release as
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
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
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.
@ -55,7 +55,7 @@ The following stages are the main milestones in a Crossplane release.
### Active development
During active development, any code that meets the requisite criteria (i.e.
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
@ -65,7 +65,7 @@ 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
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.

18
utils/vale/styles/Crossplane/allowed-jargon.txt
View File

@ -3,6 +3,8 @@
API's
APIs
autoscaler
backoff
backported
base64
bool
boolean
@ -18,24 +20,32 @@ ClusterRoles
command-line
ConfigMap
CRD
crt
CSS
CUE
CVEs
DatabaseInstance
DNS
docs-specific
emptyDir
enum
Enum
Env
EOL
ESS
float64
GitOps
Go
gRPC
IAM
imagePullSecret
init.sh
IRSA
JSONPath
key-pair
key-value
KV
kv
kube-apiserver
kube-controller-manager
kubeconfig
@ -49,9 +59,12 @@ namespaces
NOTES.txt
OCI
PersistentVolumeClaim
Pre-releases
pre-releases
PriorityClass
proselint
protobuf
QPS
RBAC
RPC
RPCs
@ -68,6 +81,7 @@ SHA-256
SHA-512
shortcode
shortcodes
SLA
SLAs
stdin
stdout
@ -77,6 +91,6 @@ Substrings
syscall
TLS
tolerations
UI
VM
YAML
backoff
YAML

5
utils/vale/styles/Crossplane/brands.txt
View File

@ -1,10 +1,13 @@
Algolia
ArgoCD
Bootstrap
CC-BY
CloudSQL
CNCF
Commonmark
DockerHub
DocSearch
FluxCD
Geekdocs
Goldmark
Grammarly
@ -15,6 +18,7 @@ Kustomize
Netlify
NodeJS
NPM
OPA
OpenAPI
OpenAPIv3
PostCSS
@ -23,6 +27,7 @@ postcss-sort-media-queries
PostgreSQL
Protobuf
PurgeCSS
Rego
Upbound
Upbound's
Upjet

4
utils/vale/styles/Crossplane/crossplane-words.txt
View File

@ -1,5 +1,6 @@
ActivePackageRevision
Adler32
apiGroups
clampMax
clampMin
CombineFromComposite
@ -9,8 +10,10 @@ CombineToEnvironment
CompositeResourceDefinition
CompositeResourceDefinitions
composition.yaml
CompositionRevision
CompositionRevisions
config
CONTRIBUTING.md
ControllerConfig
ControllerConfigs
CRDs
@ -47,6 +50,7 @@ PatchSet
PatchSets
ProviderConfig
ProviderConfigs
ProviderRevision
RunFunctionRequest
RunFunctionResponse
StoreConfig

3
utils/vale/styles/Crossplane/provider-words.txt
View File

@ -7,8 +7,11 @@ europe-central2
GCP
GCP's
GKE
provider-aws
provider-aws-iam
provider-aws-s3
provider-gcp
provider-helm
Pub/Sub
PubSub
S3

8
utils/vale/styles/Crossplane/spelling-exceptions.txt
View File

@ -1,5 +1,6 @@
/tab
/tabs
built-in
call-outs
ClusterRoles`
comma-separated
@ -19,7 +20,10 @@ how-to
in-depth
in-memory
left-hand
multi-cluster
multi-region
multi-tenant
multi-tenancy
non-empty
non-Kubernetes
per-element
@ -34,9 +38,13 @@ read-only
resource-specific
right-hand
run-time
self-signed
self-service
step-by-step
subresources
third-party
top-level
unpause
untrusted
UpperCamelCase
UpperCamelCased