mirror of https://github.com/crossplane/docs.git
docs snapshot for crossplane version `v0.9`
This commit is contained in:
Crossplane
parent
2758ca7e36
commit
c6ce664c04
|
|
@ -10,9 +10,7 @@ features:
|
|||
Kubernetes API.
|
||||
- Management and scheduling of configuration data across multiple Kubernetes
|
||||
clusters.
|
||||
- Separation of concern between [infrastructure
|
||||
owners](infra_operators/overview.md), [application
|
||||
owners](app_operators/overview.md), and [developers](developers/overview.md).
|
||||
- Separation of concern between [infrastructure owners](infra_operators/overview.md), [application owners](app_operators/overview.md), and [developers](developers/overview.md).
|
||||
- Infrastructure agnostic packaging of applications and their dependencies.
|
||||
- Scheduling applications into different clusters, zones, and regions.
|
||||
|
||||
|
|
@ -24,8 +22,7 @@ Crossplane does not:
|
|||
|
||||
Crossplane can be [installed](install.md) into any Kubernetes cluster, and is
|
||||
compatible with any Kubernetes-native project. It manages external services by
|
||||
installing [Custom Resource
|
||||
Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
installing [Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
(CRDs) and
|
||||
[reconciling](https://kubernetes.io/docs/concepts/architecture/controller/)
|
||||
instances of those Custom Resources. Crossplane is built to be extensible,
|
||||
|
|
@ -39,19 +36,13 @@ Crossplane is comprised of four main components:
|
|||
2. **Providers**: the set of Kubernetes CRDs and controllers that provision and
|
||||
manage services on cloud providers. A cloud provider is any service that
|
||||
exposes infrastructure via an API.
|
||||
- Examples: [Google Cloud
|
||||
Platform](https://github.com/crossplane/provider-gcp), [Amazon Web
|
||||
Services](https://github.com/crossplane/provider-aws),
|
||||
[Azure](https://github.com/crossplane/provider-azure),
|
||||
- Examples: [Google Cloud Platform](https://github.com/crossplane/provider-gcp), [Amazon Web Services](https://github.com/crossplane/provider-aws), [Azure](https://github.com/crossplane/provider-azure),
|
||||
[Alibaba](https://github.com/crossplane/provider-alibaba),
|
||||
[Github](https://github.com/crossplane/provider-github)
|
||||
3. **Stacks**: a bundled set of custom resources that together represent an
|
||||
environment on a cloud provider. The bundle of instances can be created by a
|
||||
single custom resource.
|
||||
- Examples: [Stack Minimal
|
||||
GCP](https://github.com/crossplane/stack-minimal-gcp), [Stack Minimal
|
||||
AWS](https://github.com/crossplane/stack-minimal-aws), [Stack Minimal
|
||||
Azure](https://github.com/crossplane/stack-minimal-azure)
|
||||
- Examples: [Stack Minimal GCP](https://github.com/crossplane/stack-minimal-gcp), [Stack Minimal AWS](https://github.com/crossplane/stack-minimal-aws), [Stack Minimal Azure](https://github.com/crossplane/stack-minimal-azure)
|
||||
4. **Applications**: a deployable unit of code and configuration, which, when
|
||||
created, may involve provisioning new services which are managed by a
|
||||
`provider`, or consuming services created by a `stack`.
|
||||
|
|
|
|||
|
|
@ -18,8 +18,7 @@ Crossplane control cluster is configured.
|
|||
[Wordpress](https://wordpress.org/) is a relatively simple monolithic
|
||||
application that only requires compute to run its containerized binary and a
|
||||
connection to a MySQL database. Wordpress is typically installed in a Kubernetes
|
||||
cluster using its official [Helm
|
||||
chart](https://github.com/bitnami/charts/tree/master/bitnami/wordpress).
|
||||
cluster using its official [Helm chart](https://github.com/bitnami/charts/tree/master/bitnami/wordpress).
|
||||
Crossplane applications let you define your application using common
|
||||
configuration tools such as [Helm](https://helm.sh/) and
|
||||
[Kustomize](https://kustomize.io/), but represent them as a
|
||||
|
|
@ -33,9 +32,7 @@ creating our `MinimalGCP` instance. In contrast to the GCP provider and Minimal
|
|||
GCP stack, the Wordpress application will be installed with a `StackInstall`
|
||||
instead of a `ClusterStackInstall`. This means that the installation will only
|
||||
be available in the namespace that we specify. You can read more about the
|
||||
difference between the two in the [infrastructure
|
||||
operators](infra_operators/packaging_a_stack.md) and [application
|
||||
operators](app_operators/packaging_an_app.md) guides.
|
||||
difference between the two in the [infrastructure operators](infra_operators/packaging_a_stack.md) and [application operators](app_operators/packaging_an_app.md) guides.
|
||||
|
||||
Create a file named `wordpress-install.yaml` with the following content:
|
||||
|
||||
|
|
@ -61,8 +58,7 @@ using a single
|
|||
When we do, a `KubernetesCluster` claim and a `MySQLInstance` claim will be
|
||||
created in the namespace, as well as a `KubernetesApplication` that contains the
|
||||
Wordpress application components. The claims will be satisfied by the
|
||||
`GKEClusterClass` and `CloudSQLInstanceClass` we created in the [previous
|
||||
section](stack.md). Let's create a `WordpressInstance` and see what happens.
|
||||
`GKEClusterClass` and `CloudSQLInstanceClass` we created in the [previous section](stack.md). Let's create a `WordpressInstance` and see what happens.
|
||||
|
||||
Create a file named `my-wordpress.yaml` with the following content:
|
||||
|
||||
|
|
|
|||
|
|
@ -7,5 +7,4 @@ weight: 200
|
|||
# Application Operators
|
||||
|
||||
This section of the documentation is a work-in-progress. Let us know what
|
||||
information would be helpful by [opening an
|
||||
issue](https://github.com/crossplane/crossplane/issues/new).
|
||||
information would be helpful by [opening an issue](https://github.com/crossplane/crossplane/issues/new).
|
||||
|
|
|
|||
|
|
@ -13,8 +13,7 @@ take are summarized below:
|
|||
|
||||
In order to manage resources in Azure, you must provide credentials for a Azure
|
||||
service principal that Crossplane can use to authenticate. This assumes that you
|
||||
have already [set up the Azure CLI
|
||||
client](https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli?view=azure-cli-latest)
|
||||
have already [set up the Azure CLI client](https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli?view=azure-cli-latest)
|
||||
with your credentials.
|
||||
|
||||
Create a JSON file that contains all the information needed to connect and
|
||||
|
|
|
|||
|
|
@ -20,8 +20,7 @@ a web browser. You can choose whichever you are more comfortable with.
|
|||
If you have the `gcloud` tool installed, you can run the commands below from the
|
||||
crossplane directory.
|
||||
|
||||
Instructions for installing `gcloud` can be found in the [Google
|
||||
docs](https://cloud.google.com/sdk/install).
|
||||
Instructions for installing `gcloud` can be found in the [Google docs](https://cloud.google.com/sdk/install).
|
||||
|
||||
### Using `gcp-credentials.sh`
|
||||
|
||||
|
|
@ -112,12 +111,10 @@ Create a GCP example project which we will use to host our example GKE cluster,
|
|||
as well as our example CloudSQL instance.
|
||||
|
||||
- Login into [GCP Console](https://console.cloud.google.com)
|
||||
- Create a [new
|
||||
project](https://console.cloud.google.com/flows/enableapi?apiid=container.googleapis.com,sqladmin.googleapis.com,redis.googleapis.com)
|
||||
- Create a [new project](https://console.cloud.google.com/flows/enableapi?apiid=container.googleapis.com,sqladmin.googleapis.com,redis.googleapis.com)
|
||||
(either stand alone or under existing organization)
|
||||
- Create Example Service Account
|
||||
- Navigate to: [Create Service
|
||||
Account](https://console.cloud.google.com/iam-admin/serviceaccounts)
|
||||
- Navigate to: [Create Service Account](https://console.cloud.google.com/iam-admin/serviceaccounts)
|
||||
- `Service Account Name`: type "example"
|
||||
- `Service Account ID`: leave auto assigned
|
||||
- `Service Account Description`: type "Crossplane example"
|
||||
|
|
@ -148,24 +145,20 @@ as well as our example CloudSQL instance.
|
|||
- Save (copy or move) this file into example (this) directory, with new
|
||||
name `crossplane-gcp-provider-key.json`
|
||||
- Enable `Cloud SQL API`
|
||||
- Navigate to [Cloud SQL Admin
|
||||
API](https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview)
|
||||
- Navigate to [Cloud SQL Admin API](https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview)
|
||||
- Click `Enable`
|
||||
- Enable `Kubernetes Engine API`
|
||||
- Navigate to [Kubernetes Engine
|
||||
API](https://console.developers.google.com/apis/api/container.googleapis.com/overview)
|
||||
- Navigate to [Kubernetes Engine API](https://console.developers.google.com/apis/api/container.googleapis.com/overview)
|
||||
- Click `Enable`
|
||||
- Enable `Cloud Memorystore for Redis`
|
||||
- Navigate to [Cloud Memorystore for
|
||||
Redis](https://console.developers.google.com/apis/api/redis.googleapis.com/overview)
|
||||
- Click `Enable`
|
||||
- Enable `Compute Engine API`
|
||||
- Navigate to [Compute Engine
|
||||
API](https://console.developers.google.com/apis/api/compute.googleapis.com/overview)
|
||||
- Navigate to [Compute Engine API](https://console.developers.google.com/apis/api/compute.googleapis.com/overview)
|
||||
- Click `Enable`
|
||||
- Enable `Service Networking API`
|
||||
- Navigate to [Service Networking
|
||||
API](https://console.developers.google.com/apis/api/servicenetworking.googleapis.com/overview)
|
||||
- Navigate to [Service Networking API](https://console.developers.google.com/apis/api/servicenetworking.googleapis.com/overview)
|
||||
- Click `Enable`
|
||||
|
||||
### Enable Billing
|
||||
|
|
|
|||
|
|
@ -7,8 +7,7 @@ weight: 400
|
|||
# Contributing
|
||||
|
||||
The following documentation is for developers who wish to contribute to or
|
||||
extend Crossplane. Please [open an
|
||||
issue](https://github.com/crossplane/crossplane/issues/new) for any additional
|
||||
extend Crossplane. Please [open an issue](https://github.com/crossplane/crossplane/issues/new) for any additional
|
||||
documentation you would like to see in this section.
|
||||
|
||||
1. [Services Developer Guide](services_developer_guide.md)
|
||||
|
|
|
|||
|
|
@ -27,21 +27,21 @@ A typical Crossplane managed service consists of five configuration resources
|
|||
and five controllers. The GCP Provider's support for Google Cloud Memorystore
|
||||
illustrates this. First, the configuration resources:
|
||||
|
||||
1. A [managed resource]. Managed resources are cluster scoped, high-fidelity
|
||||
1. A managed resource. Managed resources are cluster scoped, high-fidelity
|
||||
representations of a resource in an external system such as a cloud
|
||||
provider's API. Managed resources are _non-portable_ across external systems
|
||||
(i.e. cloud providers); they're tightly coupled to the implementation details
|
||||
of the external resource they represent. Managed resources are defined by a
|
||||
Provider. The GCP Provider's [`CloudMemorystoreInstance`] resource is an
|
||||
example of a managed resource.
|
||||
1. A [resource claim]. Resource claims are namespaced abstract declarations of a
|
||||
1. A resource claim. Resource claims are namespaced abstract declarations of a
|
||||
need for a service. Resource claims are frequently portable across external
|
||||
systems. Crossplane defines a series of common resource claim kinds,
|
||||
including [`RedisCluster`]. A resource claim is satisfied by _binding_ to a
|
||||
managed resource.
|
||||
1. A [resource class]. Resource classes represent a class of a specific kind of
|
||||
1. A resource class. Resource classes represent a class of a specific kind of
|
||||
managed resource. They are the template used to create a new managed resource
|
||||
in order to satisfy a resource claim during [dynamic provisioning]. Resource
|
||||
in order to satisfy a resource claim during dynamic provisioning. Resource
|
||||
classes are cluster scoped, and tightly coupled to the managed resources they
|
||||
template. [`CloudMemorystoreInstanceClass`] is an example of a resource
|
||||
class.
|
||||
|
|
@ -1119,10 +1119,6 @@ and implementing support for new managed services. [#sig-services] would highly
|
|||
value any feedback you may have about the services development process!
|
||||
|
||||
[What Makes a Crossplane Managed Service]: #what-makes-a-crossplane-managed-service
|
||||
[managed resource]: concepts.md#managed-resource
|
||||
[resource claim]: concepts.md#resource-claim
|
||||
[resource class]: concepts.md#resource-class
|
||||
[dynamic provisioning]: concepts.md#dynamic-and-static-provisioning
|
||||
[`CloudMemorystoreInstance`]: https://github.com/crossplane/provider-gcp/blob/85a6ed3c669a021f1d61be51b2cbe2714b0bc70b/apis/cache/v1beta1/cloudmemorystore_instance_types.go#L184
|
||||
[`CloudMemorystoreInstanceClass`]: https://github.com/crossplane/provider-gcp/blob/85a6ed3c669a021f1d61be51b2cbe2714b0bc70b/apis/cache/v1beta1/cloudmemorystore_instance_types.go#L217
|
||||
[`Provider`]: https://github.com/crossplane/provider-gcp/blob/85a6ed3c669a021f1d61be51b2cbe2714b0bc70b/apis/v1alpha3/types.go#L41
|
||||
|
|
|
|||
|
|
@ -36,8 +36,7 @@ kubectl crossplane trace KubernetesApplication wordpress-app-83f04457-0b1b-4532-
|
|||
kubectl crossplane trace MySQLInstance wordpress-mysql-83f04457-0b1b-4532-9691-f55cf6c0da6e -n app-project1-dev
|
||||
```
|
||||
|
||||
For more information, see [the trace command
|
||||
documentation](https://github.com/crossplane/crossplane-cli/tree/master/docs/trace-command.md).
|
||||
For more information, see [the trace command documentation](https://github.com/crossplane/crossplane-cli/tree/master/docs/trace-command.md).
|
||||
|
||||
## Resource Status and Conditions
|
||||
|
||||
|
|
@ -156,10 +155,8 @@ namespace segment or over the entire name. In these cases resource labels,
|
|||
owner references, and annotations should be consulted to identify the
|
||||
responsible Stack.
|
||||
|
||||
* [Relationship
|
||||
Labels](https://github.com/crossplane/crossplane/blob/master/design/one-pager-stack-relationship-labels.md)
|
||||
* [Owner
|
||||
References](https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)
|
||||
* [Relationship Labels](https://github.com/crossplane/crossplane/blob/master/design/one-pager-stack-relationship-labels.md)
|
||||
* [Owner References](https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)
|
||||
* Annotations: `tenant.crossplane.io/{singular}-name` and
|
||||
`tenant.crossplane.io/{singular}-namespace` (_singular_ may be `stackinstall`,
|
||||
`clusterstackinstall` or `stack`)
|
||||
|
|
|
|||
|
|
@ -7,5 +7,4 @@ weight: 300
|
|||
# Developers
|
||||
|
||||
This section of the documentation is a work-in-progress. Let us know what
|
||||
information would be helpful by [opening an
|
||||
issue](https://github.com/crossplane/crossplane/issues/new).
|
||||
information would be helpful by [opening an issue](https://github.com/crossplane/crossplane/issues/new).
|
||||
|
|
|
|||
|
|
@ -16,8 +16,7 @@ Kubernetes configuration tools, such as [Helm](https://helm.sh/) and
|
|||
## Setting up a Repository
|
||||
|
||||
The required components of an application repository are minimal. For example,
|
||||
the required components of the [Wordpress
|
||||
application](https://github.com/crossplane/app-wordpress) we deployed in the
|
||||
the required components of the [Wordpress application](https://github.com/crossplane/app-wordpress) we deployed in the
|
||||
quick start are the following:
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -11,11 +11,7 @@ well with many other project. Below is a collection of guides and tutorials that
|
|||
demonstrate how to use Crossplane with a variety of tools in the GitOps, service
|
||||
mesh, and infrastructure provisioning spaces.
|
||||
|
||||
- [Connecting AWS managed services to your Argo CD pipeline with open source
|
||||
Crossplane](https://aws.amazon.com/blogs/opensource/connecting-aws-managed-services-to-your-argo-cd-pipeline-with-open-source-crossplane/)
|
||||
- [Using Crossplane to schedule workloads to Kubernetes clusters provisioned by
|
||||
Cluster API](https://github.com/crossplane/tbs/tree/master/episodes/11/assets)
|
||||
- [Using managed services in your development workflow with Crossplane and
|
||||
Okteto](https://github.com/crossplane/tbs/tree/master/episodes/10/assets)
|
||||
- [Installing Linkerd into remote clusters using
|
||||
Crossplane](https://github.com/crossplane/tbs/tree/master/episodes/12/assets)
|
||||
- [Connecting AWS managed services to your Argo CD pipeline with open source Crossplane](https://aws.amazon.com/blogs/opensource/connecting-aws-managed-services-to-your-argo-cd-pipeline-with-open-source-crossplane/)
|
||||
- [Using Crossplane to schedule workloads to Kubernetes clusters provisioned by Cluster API](https://github.com/crossplane/tbs/tree/master/episodes/11/assets)
|
||||
- [Using managed services in your development workflow with Crossplane and Okteto](https://github.com/crossplane/tbs/tree/master/episodes/10/assets)
|
||||
- [Installing Linkerd into remote clusters using Crossplane](https://github.com/crossplane/tbs/tree/master/episodes/12/assets)
|
||||
|
|
|
|||
|
|
@ -7,8 +7,7 @@ indent: true
|
|||
|
||||
# Manually Adding Existing Kubernetes Clusters
|
||||
|
||||
As discussed in the section on [scheduling applications to remote
|
||||
clusters](../workload.md), Crossplane allows you to import existing Kubernetes
|
||||
As discussed in the section on [scheduling applications to remote clusters](../workload.md), Crossplane allows you to import existing Kubernetes
|
||||
clusters for scheduling. This can be done for any cluster for which you have a
|
||||
`kubeconfig`. Crossplane will be given the same permissions to the remote
|
||||
cluster that are provided to the user in your `kubeconfig`.
|
||||
|
|
|
|||
|
|
@ -7,5 +7,4 @@ weight: 100
|
|||
# Infrastructure Operators
|
||||
|
||||
This section of the documentation is a work-in-progress. Let us know what
|
||||
information would be helpful by [opening an
|
||||
issue](https://github.com/crossplane/crossplane/issues/new).
|
||||
information would be helpful by [opening an issue](https://github.com/crossplane/crossplane/issues/new).
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ weight: 500
|
|||
|
||||
# Overview
|
||||
|
||||
The reference documentation includes answers to frequently asked questions, information about similar projects, and links to resources that can help you learn more about Crossplane and Kubernetes. If you have additional information that you think would be valuable for the community, please feel free to [open a pull request]() and add it.
|
||||
The reference documentation includes answers to frequently asked questions, information about similar projects, and links to resources that can help you learn more about Crossplane and Kubernetes. If you have additional information that you think would be valuable for the community, please feel free to [open a pull request](https://github.com/crossplane/crossplane/pulls) and add it.
|
||||
|
||||
1. [Frequently Asked Questions](faqs.md)
|
||||
2. [Learn More](learn_more.md)
|
||||
|
|
|
|||
|
|
@ -15,8 +15,7 @@ projects, but instead to motivate why Crossplane was created.
|
|||
## Open Service Broker and Service Catalog
|
||||
|
||||
The [Open Service Broker](https://www.openservicebrokerapi.org/) and the
|
||||
[Kubernetes Service
|
||||
Catalog](https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/)
|
||||
[Kubernetes Service Catalog](https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/)
|
||||
are able to dynamically provision managed services in multiple cloud providers
|
||||
from Kubernetes. As a result it shares similar goals with Crossplane. However,
|
||||
service broker is not designed for workload portability, does not have a good
|
||||
|
|
|
|||
|
|
@ -253,8 +253,7 @@ Here is the list of all template stacks:
|
|||
|
||||
Each one should be released as part of a complete release, using the
|
||||
instructions below. To read even more about the template stack release
|
||||
process, see [the release section of this
|
||||
document](https://github.com/crossplane/cicd/blob/master/docs/pipelines.md#how-do-i-cut-a-release)
|
||||
process, see [the release section of this document](https://github.com/crossplane/cicd/blob/master/docs/pipelines.md#how-do-i-cut-a-release)
|
||||
|
||||
Note that there's also the
|
||||
[`templating-controller`](https://github.com/crossplane/templating-controller),
|
||||
|
|
@ -275,12 +274,10 @@ branch. Enter in the new tag to use. If the current release candidate is
|
|||
not the head of `master`, enter in the commit to tag.
|
||||
|
||||
You can find the tag pipeline for the individual stack by going to the
|
||||
[crossplane org in
|
||||
Jenkins](https://jenkinsci.upbound.io/job/crossplane/), finding the
|
||||
[crossplane org in Jenkins](https://jenkinsci.upbound.io/job/crossplane/), finding the
|
||||
folder with the same name as the template stack, and then going to the
|
||||
`tag` job group. Then going to the `master` branch job under the group.
|
||||
For example, here is [a link to the stack-minimal-gcp tag job for
|
||||
master](https://jenkinsci.upbound.io/job/crossplane/job/stack-minimal-gcp/job/tag/job/master/).
|
||||
For example, here is [a link to the stack-minimal-gcp tag job for master](https://jenkinsci.upbound.io/job/crossplane/job/stack-minimal-gcp/job/tag/job/master/).
|
||||
|
||||
> **Note:** The first time you run a pipeline on a new branch, you won't get prompted for the values
|
||||
> to input. The build will quickly fail and then you can run (not replay) it a second time to be
|
||||
|
|
@ -292,8 +289,7 @@ master](https://jenkinsci.upbound.io/job/crossplane/job/stack-minimal-gcp/job/ta
|
|||
|
||||
After the tag pipeline has been run and the repository has been tagged,
|
||||
you can run the `publish` job for the template stack. For example,
|
||||
here's a [link to the stack-minimal-gcp publish
|
||||
job](https://jenkinsci.upbound.io/job/crossplane/job/stack-minimal-gcp/job/publish/job/master/).
|
||||
here's a [link to the stack-minimal-gcp publish job](https://jenkinsci.upbound.io/job/crossplane/job/stack-minimal-gcp/job/publish/job/master/).
|
||||
This will kick off the official release build and upon success, all
|
||||
release artifacts will be officially published. This should also be run
|
||||
from the `master` branch in most cases. Or, if a release branch was
|
||||
|
|
@ -322,22 +318,18 @@ docs and examples to point to the freshly released stack versions.
|
|||
|
||||
* Documentation, such as [Installation
|
||||
instructions](https://github.com/crossplane/crossplane/blob/master/docs/install-crossplane.md#installing-cloud-provider-stacks),
|
||||
and [Stack
|
||||
guides](https://github.com/crossplane/crossplane/blob/master/docs/stacks-guide-gcp.md).
|
||||
and [Stack guides](https://github.com/crossplane/crossplane/blob/master/docs/stacks-guide-gcp.md).
|
||||
* searching for `:master` will help a lot here
|
||||
* `kubectl -k` statements will contain `?ref=master`, which should be updated
|
||||
to the release branch name instead, e.g. `?ref=release-0.4`
|
||||
* Examples, such as [`StackInstall` yaml
|
||||
files](https://github.com/crossplane/crossplane/tree/master/cluster/examples/providers)
|
||||
* [Helm chart
|
||||
defaults](https://github.com/crossplane/crossplane/blob/master/cluster/charts/crossplane/values.yaml.tmpl)
|
||||
* Examples, such as [`StackInstall` yaml files](https://github.com/crossplane/crossplane/tree/master/cluster/examples/providers)
|
||||
* [Helm chart defaults](https://github.com/crossplane/crossplane/blob/master/cluster/charts/crossplane/values.yaml.tmpl)
|
||||
for stack versions
|
||||
|
||||
### Tag Core Crossplane
|
||||
|
||||
Similar to running the `tag` pipelines for each stack, now it's time to run the
|
||||
[`tag`
|
||||
pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fcrossplane%2Fcrossplane-tag/branches)
|
||||
[`tag` pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fcrossplane%2Fcrossplane-tag/branches)
|
||||
for core Crossplane. In fact, the [instructions](#stack-tag-pipeline) are
|
||||
exactly the same:
|
||||
|
||||
|
|
@ -348,8 +340,7 @@ exactly the same:
|
|||
|
||||
### Build and Release Core Crossplane
|
||||
|
||||
After tagging is complete, ensure the [normal build
|
||||
pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fcrossplane%2Fbuild/branches)
|
||||
After tagging is complete, ensure the [normal build pipeline](https://jenkinsci.upbound.io/blue/organizations/jenkins/crossplane%2Fcrossplane%2Fbuild/branches)
|
||||
is run on the release branch. This will be the official release build with an
|
||||
official version number and all of its release artifacts will be published.
|
||||
|
||||
|
|
@ -420,5 +411,4 @@ steps. Please refer to details for each step in the sections above.
|
|||
* Run promote pipeline to promote the patch release to the `alpha` channel
|
||||
|
||||
<!-- Named links -->
|
||||
[github-ui-create-branch]:
|
||||
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-and-deleting-branches-within-your-repository
|
||||
[github-ui-create-branch]: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-and-deleting-branches-within-your-repository
|
||||
|
|
|
|||
|
|
@ -100,12 +100,10 @@ Crossplane will immediately create the managed resources and classes that are
|
|||
part of the Minimal GCP stack.
|
||||
|
||||
Now that we have general set of infrastructure and classes defined in our
|
||||
cluster, it is time to deploy some applications. In the [previous
|
||||
section](workload.md), we bundled resources into a `KubernetesApplication` and
|
||||
cluster, it is time to deploy some applications. In the [previous section](workload.md), we bundled resources into a `KubernetesApplication` and
|
||||
created it in the control cluster. This is useful for applications that are
|
||||
deployed infrequently and are not widely distributed, but can be a burden for
|
||||
someone who is not familiar with the architecture to manage. In the [next
|
||||
section](app.md) we will explore how Crossplane *Applications* make it possible
|
||||
someone who is not familiar with the architecture to manage. In the [next section](app.md) we will explore how Crossplane *Applications* make it possible
|
||||
to package and distribute your configuration, including managed services that an
|
||||
application consumes.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,14 +18,12 @@ a simple example. We will use GCP for this quick start, but you can achieve the
|
|||
same functionality of any of the providers mentioned in the
|
||||
[installation](install.md) and [configuration](configure.md) sections. You
|
||||
should have your provider of choice installed and should have created a
|
||||
`Provider` resource with the necessary credentials. We will use a [GCP
|
||||
`Provider`](cloud-providers/gcp/gcp-provider.md) resource with name
|
||||
`Provider` resource with the necessary credentials. We will use a [GCP `Provider`](cloud-providers/gcp/gcp-provider.md) resource with name
|
||||
`gcp-provider` below.
|
||||
|
||||
## Statically Provision a Redis Cluster on GCP
|
||||
|
||||
GCP provides Redis clusters using [Cloud
|
||||
Memorystore](https://cloud.google.com/memorystore). The GCP Crossplane provider
|
||||
GCP provides Redis clusters using [Cloud Memorystore](https://cloud.google.com/memorystore). The GCP Crossplane provider
|
||||
installs a `CloudMemorystoreInstance`
|
||||
[CustomResourceDefinition](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
(CRD) which makes the API type available in your Kubernetes cluster. Creating an
|
||||
|
|
@ -178,8 +176,7 @@ You will also see that the `CloudMemorystoreInstance` resource is still
|
|||
reporting `Status: Unbound`. This is because we have not *claimed* it for usage
|
||||
yet.
|
||||
|
||||
Crossplane follows a similar pattern to [Kubernetes persistent
|
||||
volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/). When
|
||||
Crossplane follows a similar pattern to [Kubernetes persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/). When
|
||||
you statically provision a resource in Crossplane, the external resource is also
|
||||
created. However, when you want to use a resource, you create an
|
||||
application-focused **claim** for it. In this case, we will create a
|
||||
|
|
|
|||
|
|
@ -327,8 +327,7 @@ Events: <none>
|
|||
> made possible by storing the base64 encoded `kubeconfig` data in a `Secret`,
|
||||
> then manually creating a `KubernetesTarget` to point at it. This is an
|
||||
> advanced workflow, and additional information can be found in the
|
||||
> [infrastructure operator
|
||||
> documentation](/infra_operators/manually_adding_clusters.md).*
|
||||
> [infrastructure operator documentation](/infra_operators/manually_adding_clusters.md).*
|
||||
|
||||
## Clean Up
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue