crossplane

Build and operate Crossplane v2 control planes with XRDs, Compositions, functions, and packages.

Updated Apr 11, 2026
One-click install
npx skills add https://github.com/lurodrisilva/personal-skills --skill crossplane-lurodrisilva
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: crossplane
Source: https://github.com/lurodrisilva/personal-skills/tree/main/platform-engineering/crossplane
Command: npx skills add https://github.com/lurodrisilva/personal-skills --skill crossplane-lurodrisilva

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Extending Kubernetes into a self-service platform API requires deep knowledge of Crossplane's evolving surface — Managed Resources, XRDs, Compositions, Composition Functions, and packages — and the v1-to-v2 model changes (namespaced XRs, removed Claims, functions-only pipelines) make outdated guidance a real risk. This Skill encodes the correct v2-first authoring and operating rules so platform engineers avoid misconfigurations like bumping Composition to a nonexistent v2 apiVersion or installing monolithic providers. ## Core Features & Use Cases - Full authoring lifecycle: Install Crossplane via Helm, wire ProviderConfig credentials (Secret, IRSA, GKE/AKS workload identity), write Managed Resources with managementPolicies and deletionPolicy, design versioned XRDs, and compose function pipelines (function-patch-and-transform, function-auto-ready, function-environment-configs). - Packaging, GitOps, and testing: Build and sign xpkg packages with ImageConfig and Cosign, deliver via ArgoCD/Flux, and test compositions with crossplane render, validate, and trace. - Read-only triage scripts: Four bash + kubectl scripts audit control-plane health, stuck Managed Resources, safe-start MRD/MRAP activation posture, and package digest-pinning without ever mutating the cluster. - Use Case: A platform team needs to offer a self-service "App" API to developers. Use this Skill to author the XRD, write a Pipeline-mode Composition, install provider family members with least-privilege credentials, and verify everything with the health-check script. ## Quick Start Ask the AI to design a Crossplane v2 XRD and Composition for a namespaced composite resource backed by an AWS S3 bucket Managed Resource.

Frequently Asked Questions about crossplane

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a Crossplane Composition in v2?▼

In Crossplane v2 every Composition uses mode: Pipeline with ordered function steps, keeping apiVersion apiextensions.crossplane.io/v1 even though the XRD moved to v2. Native patch-and-transform is removed, so use function-patch-and-transform as a pipeline step and typically end with function-auto-ready.

What changed between Crossplane v1 and v2?▼

Crossplane v2 made XRs namespaced by default, removed Claims, moved Managed Resources to namespaced .m. API groups, added ClusterProviderConfig, and made composition functions-only. Run crossplane beta upgrade check before migrating; scope: LegacyCluster preserves v1 behavior during transition.

How do I configure Crossplane provider credentials on EKS or GKE?▼

Prefer workload identity over static Secrets: annotate the provider ServiceAccount with the IAM role ARN for IRSA on EKS, or the GCP service account for Workload Identity on GKE. Reference the credentials in a namespaced ProviderConfig or cluster-wide ClusterProviderConfig selected via providerConfigRef.

Why does my Crossplane Managed Resource fail schema validation?▼

The most common cause is unquoted YAML scalars in forProvider fields: a region like 012345 becomes an integer and a version like 1.20 becomes a float, which the provider schema rejects. Quote every string-typed forProvider field in the manifest.

Can I import existing cloud resources into Crossplane?▼

Yes, create the Managed Resource with managementPolicies set to Observe only and set the crossplane.io/external-name annotation to the cloud resource ID. After reading discovered values from status.atProvider, copy needed fields into spec.forProvider and switch to full management deliberately.

When should I not use the monolithic provider-aws?▼

Avoid monolithic providers in production because they install hundreds of CRDs that bloat the API server and slow GitOps tooling. Install provider family members like provider-aws-s3 instead, or use ManagedResourceActivationPolicy to activate only the CRDs you actually use.