Crossplane Fundamentals
Crossplane is a Kubernetes add-on that lets you provision and manage cloud infrastructure using Kubernetes-style declarative YAML. It extends the Kubernetes API with custom resources representing cloud services, enabling platform teams to offer self-service infrastructure through familiar kubectl workflows.
itCloud native tools and technologies | OpenSkills.info
Intro
Crossplane Fundamentals
Crossplane is a framework for building control planes on Kubernetes. A control plane exposes an API, accepts a desired state, and keeps the systems behind that API aligned with the request. Crossplane supplies reusable controllers and a composition engine, so you can design platform APIs without writing every controller yourself.
The useful mental model is an API factory plus continuous reconciliation. A platform team defines an API such as App or Database. A developer creates one object through the Kubernetes API. Crossplane turns that request into Kubernetes resources, external services, or both. It then watches those resources and corrects drift.
Why Crossplane exists
Kubernetes gives you an API, custom resources, and controllers. Building a production controller for every internal platform service still takes substantial engineering. Crossplane moves much of that work into configuration and reusable function pipelines.
This separation gives two groups a clean contract:
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://docs.crossplane.io/latest/whats-crossplane/
Supports
- Crossplane as a control plane framework for platform engineering built on Kubernetes
- Desired-state control planes, lifecycle monitoring, and drift correction
- Four components: Composition, managed resources, Operations, and package manager
- Composition Function pipeline mental model and example App resource graph
- Managed resources as ready-made Kubernetes custom resources
- Operation, CronOperation, and WatchOperation modes and alpha status
- Package manager installation and reuse goals
- https://docs.crossplane.io/latest/whats-new/
Supports
- Namespaced XRs and managed resources in Crossplane v2
- Namespaced XRD default scope and cluster scope alternative
- Composition of any Kubernetes resource
- Legacy v1 compatibility and migration cautions
- Native patch and transform removal in favor of Composition Functions
- https://docs.crossplane.io/latest/get-started/install/
Supports
- Crossplane installation into an existing Kubernetes cluster with Helm
- Crossplane system namespace and installed components
- Provider, Function, and Configuration resources enabled after installation
- https://docs.crossplane.io/latest/managed-resources/managed-resources/
Supports
- Managed resource and external resource distinction
- Provider mapping of external services to managed resources
- forProvider as desired external configuration and source of truth by default
- atProvider as observed external state
- Direct use of managed resources
- https://docs.crossplane.io/latest/packages/providers/
Supports
- Providers as external API integrations with authentication, API calls, and controller logic
- Provider installation, pod behavior, health, configuration, and package revisions
- Continuous reconciliation of managed resources with external resources
- Digest pinning and revision activation options
- https://docs.crossplane.io/latest/composition/composite-resource-definitions/
Supports
- XRD as a custom API schema and XR as an instance of that API
- XRD names, versions, schema, and scope
- Namespaced, Cluster, and LegacyCluster scope behavior
- https://docs.crossplane.io/latest/composition/composite-resources/
Supports
- XR as a single Kubernetes object representing a set of resources
- Requirement for an XRD and Composition
- XRD and Composition roles in creating a custom API
- https://docs.crossplane.io/latest/composition/compositions/
Supports
- Composition type matching and ordered Function pipelines
- Function input, observed state, desired state, and returned resource behavior
- Composed resources as any Kubernetes resource
- Crossplane service account access and RBAC requirement for other resource kinds
- Local rendering command, Docker requirement, and YAML output
- https://docs.crossplane.io/latest/composition/composition-revisions/
Supports
- Immutable Composition revisions created for Composition changes
- Revision selection and update controls for composite resources
- https://docs.crossplane.io/latest/packages/functions/
Supports
- Functions as packages that extend Composition behavior
- Function installation through a Function package object
- https://docs.crossplane.io/latest/packages/configurations/
Supports
- Configuration packages as portable collections of Crossplane resources
- Packaging of XRDs, Compositions, and dependencies for reuse
- https://docs.crossplane.io/latest/operations/
Supports
- Operations as alpha in Crossplane v2
- Once, scheduled, and resource-change task modes
- https://github.com/crossplane/crossplane
Supports
- Crossplane v2.3 as the current maintained release on the verification date
- Crossplane project release support schedule