Crossplane Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
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

Crossplane Concepts 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

Kubernetes Custom Resources

Clarify the relationship between Crossplane composite resources and Kubernetes custom resources. Are XR custom resources?

Managed Resource (MR)

https://crossplane.io/docs/v1.10/concepts/managed-resources.html

Managed Resource Name

https://crossplane.io/docs/v1.10/concepts/managed-resources.html#external-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)

https://crossplane.io/docs/v1.10/concepts/terminology.html#crossplane-resource-model
  • Standard Crossplane Resource Model fields.

Package

Package Format

https://github.com/crossplane/crossplane/blob/1aa83092172bdf0d2ed64754d33517c612ff7368/design/one-pager-package-format-v2.md#package-format-v2

Package Varieties

Provider Package

https://crossplane.io/docs/v1.10/concepts/packages.html#provider-packages

Configuration Package

https://crossplane.io/docs/v1.10/concepts/packages.html#configuration-packages

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.

Control Plane