Crossplane Concepts TODEPLETE: Difference between revisions
| (42 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=Internal= | =Internal= | ||
* [[Crossplane | * [[Crossplane]] | ||
=Crossplane Distributions= | =Crossplane Distributions= | ||
| Line 37: | Line 27: | ||
A control plane is made up of several controllers, which are responsible for the life cycle of a resource. Each resource is responsible for provisioning, health, scaling, failover and actively responding to external changes that deviate from the desired configuration. | A control plane is made up of several controllers, which are responsible for the life cycle of a resource. Each resource is responsible for provisioning, health, scaling, failover and actively responding to external changes that deviate from the desired configuration. | ||
=Provisioning Infrastructure= | |||
<font color=darkkhaki>TO PROCESS: provision https://crossplane.io/docs/v1.9/getting-started/provision-infrastructure.html#claim-your-infrastructure and consume https://crossplane.io/docs/v1.9/getting-started/provision-infrastructure.html#consume-your-infrastructure infrastructure</font> | |||
=Configuration= | |||
A configuration extends Crossplane to expose new APIs. | |||
A configuration package includes, for example, a <code>PostgreSQLInsstance</code> type and a <code>Composition</code> of managed resources that mapped to it. Crossplane allows defining [[#XR|composite resources (XRs)]] and [[#Composition|compositions]] and packaging them up to be distributed as [[OCI]] images. | |||
A configuration need not contain one [[#XRD|XRD]] and one [[#Composition|composition]]. It could include only an XRD, only a composition, several compositions, or any combination thereof. | |||
Also see: {{Internal|Crossplane_Programming_Model#Create_a_Configuration|Configuration Programming Model}} | |||
==Configuration Directory== | |||
A configuration directory contains at its root a <code>[[#crossplane.yaml|crossplane.yaml]]</code> file, and one or more [[#XRD|XR definitions (XRD)]] and [[#Composition|composition]] definitions. | |||
==<tt>crossplane.yaml</tt>== | |||
The <code>crossplane.yaml</code> metadata file sits in the root of a [[#Configuration|configuration]] directory. It contains metadata about the configuration. | |||
<syntaxhighlight lang='yaml'> | |||
apiVersion: meta.pkg.crossplane.io/v1 | |||
kind: Configuration | |||
metadata: | |||
name: getting-started-with-aws | |||
annotations: | |||
guide: quickstart | |||
provider: aws | |||
vpc: default | |||
spec: | |||
crossplane: | |||
version: ">=v1.4.0-0" | |||
dependsOn: | |||
- provider: crossplane/provider-aws | |||
version: ">=v0.18.2" | |||
</syntaxhighlight> | |||
==Building a Configuration== | |||
<syntaxhighlight lang='bash'> | |||
kubectl crossplane build configuration | |||
</syntaxhighlight> | |||
=Resource= | =Resource= | ||
| Line 43: | Line 68: | ||
==<span id='XR'></span>Composite Resource (XR)== | ==<span id='XR'></span>Composite Resource (XR)== | ||
A composite resource can be used to represent a VPC network or an SQL instance. | A composite resource can be used to represent a VPC network or an SQL instance. A composite resource is cluster-scoped, it exists outside a namespace. | ||
A composite resource is cluster-scoped, it exists outside a namespace. | |||
Each XR is exposed as an API endpoint. A platform team can define and document the OpenAPI schema of each XR and enforce RBAC at the API level. This means that if a platform team decides to frame the abstraction they offer to their development teams as "an AcmeCo PostgreSQL database" they can grant RBAC access to create, read, update, or delete an AcmeCo PostgreSQL database, rather than having to manage access to various underlying cloud concepts like RDS instances or subnet groups. Crossplane builds upon the Kubernetes RBAC system. | |||
<syntaxhighlight lang='bash'> | <syntaxhighlight lang='bash'> | ||
kubectl get composite | kubectl get composite | ||
</syntaxhighlight> | </syntaxhighlight> | ||
The composite resource is the Crossplane equivalent of a [[Terraform_Concepts#Module|Terraform module]]. | |||
Crossplane decouples XR's inputs and outputs ([[Kubernetes_Concepts#spec_and_status|specs and status]]) from its implementation, which is described by a [[#Composition|Composition]]. | |||
===<span id='XRD'></span>Composite Resource Definition (XRD)=== | |||
<code>definition.yaml</code> | |||
<font color=darkkhaki>TO PROCESS: https://crossplane.io/docs/v1.9/getting-started/create-configuration.html#create-compositeresourcedefinition</font> | |||
==<span id='XRC'></span>Composite Resource Claim (XRC)== | ==<span id='XRC'></span>Composite Resource Claim (XRC)== | ||
| Line 63: | Line 99: | ||
=Composition= | =Composition= | ||
<code>composition.yaml</code> | |||
<font color=darkkhaki>TO PROCESS: https://crossplane.io/docs/v1.9/getting-started/create-configuration.html#create-compositions. Specifies how to provision a public PostrgreSQL instance on a chosen provider.</font> | |||
A Composition is an implementation of a [[#XR|Composite Resource (XR)]]. | |||
=Provider= | =Provider= | ||
{{External|https://crossplane.io/docs/v1.9/concepts/providers.html}} | {{External|https://crossplane.io/docs/v1.9/concepts/providers.html}} | ||
A provider extends Crossplane to orchestrate new kinds of applications and infrastructure. | A provider extends Crossplane to orchestrate new kinds of applications and infrastructure. | ||
<syntaxhighlight lang='bash'> | |||
kubectl get <name-of-provider> | |||
</syntaxhighlight> | |||
=Operator= | =Operator= | ||
==Infrastructure Operator== | ==Infrastructure Operator== | ||
| Line 76: | Line 118: | ||
==Application Operator== | ==Application Operator== | ||
An application operator is restricted to their team's namespace. | An application operator is restricted to their team's namespace. | ||
=Crossplane Resource Model (XRM)= | |||
<font color=darkkhaki>What is it? Definition?</font> | |||
XRM promotes loose coupling and eventual consistency. In Crossplane, every pieced of infrastructure is an API endpoint that supports CRUD operations. Crossplane does not need to calculate a graph of dependencies to make a change. | |||
=Crossplane API= | |||
Crossplane does not expose any old REST API, but it builds upon the Kubernetes API. | |||
Latest revision as of 01:43, 28 February 2023
Internal
Crossplane Distributions
Upstream
Upstream - the Open Source, GitHub-hosted.
Downstream
Universal Crossplane (UXP)
Downstream - Upbound's free and open source downstream distribution, called Universal Crossplane (UXP). UXP connects to Upbound's hosted management console and registry.
Control Plane
What is a control plane?
Control planes are self-healing, they automatically correct drift.
Control planes offer a single point of control for policy and permissions.
Control planes integrate easily with other systems because they expose an API, not just a command line.
A control plane orchestrates any infrastructure or managed services.
Crossplane can be used to design ad implement a control plane that expose declarative APIs tailored to your unique orchestration needs.
A control plane is made up of several controllers, which are responsible for the life cycle of a resource. Each resource is responsible for provisioning, health, scaling, failover and actively responding to external changes that deviate from the desired configuration.
Provisioning Infrastructure
TO PROCESS: provision https://crossplane.io/docs/v1.9/getting-started/provision-infrastructure.html#claim-your-infrastructure and consume https://crossplane.io/docs/v1.9/getting-started/provision-infrastructure.html#consume-your-infrastructure infrastructure
Configuration
A configuration extends Crossplane to expose new APIs.
A configuration package includes, for example, a PostgreSQLInsstance type and a Composition of managed resources that mapped to it. Crossplane allows defining composite resources (XRs) and compositions and packaging them up to be distributed as OCI images.
A configuration need not contain one XRD and one composition. It could include only an XRD, only a composition, several compositions, or any combination thereof.
Also see:
Configuration Directory
A configuration directory contains at its root a crossplane.yaml file, and one or more XR definitions (XRD) and composition definitions.
crossplane.yaml
The crossplane.yaml metadata file sits in the root of a configuration directory. It contains metadata about the configuration.
apiVersion: meta.pkg.crossplane.io/v1
kind: Configuration
metadata:
name: getting-started-with-aws
annotations:
guide: quickstart
provider: aws
vpc: default
spec:
crossplane:
version: ">=v1.4.0-0"
dependsOn:
- provider: crossplane/provider-aws
version: ">=v0.18.2"
Building a Configuration
kubectl crossplane build configuration
Resource
Crossplane resources can be composed into higher level abstractions, that can be versioned, managed, deployed and consumed using your favorite tools and existing processes.
Composite Resource (XR)
A composite resource can be used to represent a VPC network or an SQL instance. A composite resource is cluster-scoped, it exists outside a namespace.
Each XR is exposed as an API endpoint. A platform team can define and document the OpenAPI schema of each XR and enforce RBAC at the API level. This means that if a platform team decides to frame the abstraction they offer to their development teams as "an AcmeCo PostgreSQL database" they can grant RBAC access to create, read, update, or delete an AcmeCo PostgreSQL database, rather than having to manage access to various underlying cloud concepts like RDS instances or subnet groups. Crossplane builds upon the Kubernetes RBAC system.
kubectl get composite
The composite resource is the Crossplane equivalent of a Terraform module.
Crossplane decouples XR's inputs and outputs (specs and status) from its implementation, which is described by a Composition.
Composite Resource Definition (XRD)
definition.yaml
TO PROCESS: https://crossplane.io/docs/v1.9/getting-started/create-configuration.html#create-compositeresourcedefinition
Composite Resource Claim (XRC)
An XRC is a namespaced proxy for an XR. The schema of an XRC is identical to that of the corresponding XR. When an application operator creates an XRC, the corresponding backing XR is created automatically. The model has similarities with the Persistent Volume (PV) and Persistent Volume Claim (PVC) mechanism in Kubernetes.
kubectl get claim
Managed Resource
A resource that represents a unit of external infrastructure.
kubectl get managed
Composition
composition.yaml
TO PROCESS: https://crossplane.io/docs/v1.9/getting-started/create-configuration.html#create-compositions. Specifies how to provision a public PostrgreSQL instance on a chosen provider.
A Composition is an implementation of a Composite Resource (XR).
Provider
A provider extends Crossplane to orchestrate new kinds of applications and infrastructure.
kubectl get <name-of-provider>
Operator
Infrastructure Operator
The infrastructure operator offers their application operators a composite resource claim (XRC).
Application Operator
An application operator is restricted to their team's namespace.
Crossplane Resource Model (XRM)
What is it? Definition? XRM promotes loose coupling and eventual consistency. In Crossplane, every pieced of infrastructure is an API endpoint that supports CRUD operations. Crossplane does not need to calculate a graph of dependencies to make a change.
Crossplane API
Crossplane does not expose any old REST API, but it builds upon the Kubernetes API.