Crossplane Concepts TODEPLETE
Internal
Organizatorium
- https://blog.upbound.io/introducing-crossplane-open-source-multicloud-control-plane/
- https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9xdK29Er45NJeoemxebo/edit
- https://blog.crossplane.io/crossplane-vs-terraform/
Overview
Crossplane is an open source Kubernetes add-on that transforms the Kubernetes cluster into a universal control plane. Crossplane enables platform teams to assemble infrastructure from multiple vendors, and expose higher level self-service APIs for application teams to consume. Crossplane enables applications and infrastructure configuration to co-exist in the same control plane. Control planes built with Crossplane integrate with CI/CD pipelines, so team can create, track and approve changes using GitOps best practices. Crossplane offers separation of concerns: allows implementing organizational concepts and policy at the API level.
Crossplane is a Cloud Native Compute Foundation project.
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
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.
kubectl get composite
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
Provider
A provider extends Crossplane to orchestrate new kinds of applications and infrastructure.
kubectl get <name-of-provider>
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.
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.