Skip to main content

Crossplane Issues

Crossplane resources follow a three-level hierarchy: Claim → Composite Resource (XR) → Managed Resource (MR). Errors typically originate at the MR level (from the external provider, such as Azure) and propagate up to the Claim.

Quick Diagnosis with crossplane beta trace​

The crossplane beta trace command displays the entire resource hierarchy with status at each level:

# Trace a resource by its Claim type and name
crossplane beta trace BlobStorage ${RESOURCE_NAME} -n ${NAMESPACE}

Example output:

NAME                                              SYNCED   READY   STATUS
BlobStorage/my-storage (default)                  True     True    Available
└─ XBlobStorage/my-storage-xyz123                 True     True    Available
   ├─ Container/my-storage-xyz123-abc             True     True    Available
   └─ EnvironmentConfig/my-storage-xyz123-cfg     -        -

Reading the output:

  • SYNCED: True means the desired state (spec) matches the observed state (status)
  • READY: True means the external resource, an Azure Blob Container in this case, is healthy and available
  • Look for the first resource in the tree with False in either column — that's where the problem is

Note: If Ready and Synced are both -, then that resource is considered ready simply by existing. This is usually because it is just configuration data needed for kubernetes (e.g. a ConfigMap)

Troubleshooting by Issue Type​

  • Sync Issues - Resource is not synced (SYNCED=False)
  • Ready Issues - Resource is synced but not ready, composition errors, managed resource errors

When to Contact Ybor Support​

Contact Ybor support when:

  • Composition rendering errors (can't render composed resource)
  • Crossplane permission errors accessing the external provider (e.g. AuthorizationFailed from Azure)
  • MR configuration values appear incorrect for what you specified in your Claim
  • Issues persist after troubleshooting with the steps above

Information to provide:

  • Output of crossplane beta trace <ClaimType> <name> -n <namespace> -o json
  • Output of kubectl describe for the failing MR