Crossplane Concepts: Difference between revisions
| Line 64: | Line 64: | ||
=Crossplane Architecture= | =Crossplane Architecture= | ||
==Core Crossplane Controller== | ==Core Crossplane Controller== | ||
=Terraform vs. Crossplane= | =Miscellanea= | ||
==Terraform vs. Crossplane== | |||
Terraform is a command line tool, not a control plane. It is a short lived, one-shot process that only attempts to reconcile the desired configuration with the actual infrastructure when it is invoked (either from a CI/CD pipeline or command line on a laptop). Terraform offers a command-line interface to control plane APIs, while Crossplane is itself a control plane that can be used to build abstractions atop other control planes. It enables the platform team to offer their own control plane. Terraform offers discrete state reconciliation. Crossplane offers continuous state reconciliation. Crossplane is built as a series of long lived, always-on control loops. It constantly observes and corrects an organisation’s infrastructure to match its desired configuration whether changes are expected or not. This disincentivizes teams from circumventing Crossplane. When Crossplane has been asked to manage a piece of infrastructure any change made outside it will be automatically and persistently reverted. | Terraform is a command line tool, not a control plane. It is a short lived, one-shot process that only attempts to reconcile the desired configuration with the actual infrastructure when it is invoked (either from a CI/CD pipeline or command line on a laptop). Terraform offers a command-line interface to control plane APIs, while Crossplane is itself a control plane that can be used to build abstractions atop other control planes. It enables the platform team to offer their own control plane. Terraform offers discrete state reconciliation. Crossplane offers continuous state reconciliation. Crossplane is built as a series of long lived, always-on control loops. It constantly observes and corrects an organisation’s infrastructure to match its desired configuration whether changes are expected or not. This disincentivizes teams from circumventing Crossplane. When Crossplane has been asked to manage a piece of infrastructure any change made outside it will be automatically and persistently reverted. | ||
==Control Plane== | |||
Revision as of 18:49, 2 November 2022
External
Internal
TODEPLETE
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.
Resources in a Crossplane Context
Custom Resource
Clarify the relationship between Crossplane composite resources and Kubernetes custom resources. Are XR custom resources?
Managed Resource (MR)
Managed Resource Name
Reconciliation
Composite Resource (XR)
- It can be thought of as a type. Can it, or it's the Composite Resource Definition that can be thought of as a type?
- An arbitrary number of compositions (implementations) can be mapped onto one composite resource type.
- Type of composite resource - defined with a Composite Resource Definition.
- Type of claim - defined with a Composite Resource Definition.
External Resource
Composite Resource Claim (Claim, XRC)
Composite Resource Definition (XRD)
Composition
Why do we need a 'composition' to define how a composite resource maps onto managed resources? Why is not that information built into the composite resource definition itself?
Crossplane Resource Model (XRM)
- Standard Crossplane Resource Model fields.
Package
Package Format
Package Varieties
Provider Package
Configuration Package
Crossplane Package Manager
Provider
Is the provider a package?
Provider Kinds
Kubernetes Provider
Helm Provider
Configuration
Is the configuration a package?
Crossplane Architecture
Core Crossplane Controller
Miscellanea
Terraform vs. Crossplane
Terraform is a command line tool, not a control plane. It is a short lived, one-shot process that only attempts to reconcile the desired configuration with the actual infrastructure when it is invoked (either from a CI/CD pipeline or command line on a laptop). Terraform offers a command-line interface to control plane APIs, while Crossplane is itself a control plane that can be used to build abstractions atop other control planes. It enables the platform team to offer their own control plane. Terraform offers discrete state reconciliation. Crossplane offers continuous state reconciliation. Crossplane is built as a series of long lived, always-on control loops. It constantly observes and corrects an organisation’s infrastructure to match its desired configuration whether changes are expected or not. This disincentivizes teams from circumventing Crossplane. When Crossplane has been asked to manage a piece of infrastructure any change made outside it will be automatically and persistently reverted.