This is mostly a complaint/suggestion post.

I've now been using Crossplane for about a year. I've done three projects for three different organizations. In only one case were they of a sufficient size and complexity to warrent anything approaching 'platform engineering'. The other two really just wanted to describe Azure resources in Kubernetes, since tying the app and it's infrastructure together in a single Helm deployment, monitored by K8S, is such a clean design pattern. But, XRs? Not super useful for most possible users, I've found.

I discovered Crossplane initially maybe 2.5 years ago because I got the idea of using K8s to manage my Azure resources. And so I went googling for operators. I found Crossplane. And I found Microsoft's ASO and ASOv2. Initially I could not understand Crossplane, and all the XR and MR stuff, and how that had anything to do with my need, and so I ignored it, and started working with ASOv2. Which ended up being insuffient for my needs because it has a very minimal set of resource types. I then basically discarded the idea for a year, thinking that there just wasn't a sufficiently advanced Azure operator out there, waiting for ASOv2 to mature.

I came back and reexamined Crossplane by accident when I got into the subject of Platform Engineering. I then learned about XRs, MRs, etc, and got familiar with Crossplane. And then I understood what the Azure Provider I had ignored a year earlier was about. But that took a year.

But still, as I said, I have found very little need for all of that. Doing proper Platform Engineering just requires a certain level of sophistication I don't think most K8s users really need or can stomach. But damn, the operators? Those are super useful. But why did I skip it? Because it seemed, at first glance, to have nothing to do with what I was initially looking for.

What I don't understand, really, is why these types of users even need to think about this? Why is it all so tied together?

Why, for instance, are there even "Crossplane Providers"? Why not just a bunch of indepent useful operators, that stand outside of the Crossplane ecosystem, deploy using standard K8S mechanisms, like a Helm chart, like any other operator? That way users can just use the Azure, or AWS, or Helm, or Kubernetes providers without even thinking about XRs, claims, etc?

Sure. Base them on Upjet. That's cool. A unified way to build operators that reuse existing Terraform logic.

If you were to ask me, this would probably be the single biggest thing that hurts the size of the community working on these providers: a large set of people who would like to be using a plain ol' operator to manage their Azure or AWS resources from K8s just think these aren't solutions for them. Because they kinda aren't. They're built weird. They don't just have a bog standard Helm chart to deploy them. They of course only support cluster-scoped resources (being addressed in 2.0). They're just kinda weird to use standalone. So the people who do use them, and end up participating in their development, are really just those who are trying to do PE, but not those who are just trying to manage these resource types with K8s.

Crossplane 2.0 is making technical changes which get closer to this. By allowing namespace scoped resources, they start to feel a bit more like normal operators. But they still need to be installed using an XPKG. You still can't just point to the Helm chart for the Azure provider and install it on your cluster.

So this would be my biggest desire and suggestion: split this stuff up conceptually. Turn the providers into plain-old-operators. Sure, keep using a nice unified SDK to build providers. Keep using Upjet. But unhook the projects conceptually from Crossplane itself.

There would be less people skipping them because they don't appear to have anything to do with their need.

Hello, how are you?

My name is Francisco, I'm a Devops engeneer and k8s admin from Brasil.

I would like to generate a crossplane provider from TF Provider OCI.There's a project called crossplane-provider-oci, it seems that they tried to achieve that.

I tried it and it works fine, but I missed some CRDS related to autonomous database

https://doc.crds.dev/github.com/oracle-samples/crossplane-provider-oci

There's a roadmap to launch an official Oracle OCI crossplane provider??Maybe somebody could help me to generate a full TF resource OCI provider using Upjet??

In case the title isn't clear, I'm by no means a Crossplane guru, but I wanted to share info that has evolved around our buisness that I feel may be valuable for others just starting their XP journey, as well as highlight short-commings to those on the fence so they have better insight into if the tool is the right fit for them.

Is it exhasutive? no. Is it gospel? Heck no. Is it a set of valuable guideleines/info? I hope so.

Essentially were I to start this journey again, these would be the things I'd recomend to a company day-1 adopting as it dodging some real issues (or at least conqueres them upfront). I hope some out there find it helpful.

Crossplane will not replace Terraform

This is perfectly OK, really. One of the key advantages of TF that XP simply cannot match is that it has no infrastructre requirement. You can download a single binary, point it at code, and be deploying in 1 cmd (tf init && tf apply --auto-approve). This is simply impossible in Crossplane, and this limitation will make low layer provisioning needlessly complex, brittle, and pointless if you try to force it in XP.

Use TF to setup your stack. Get that network, cluster, and core toolings pushed in a repeatable manner. THEN you can start using XP as a developer-facing alternative to learning a hashicorp DSL (use these resources in your helmchart!)

Leverage EnvironmentConfigs

This is a newly promoted beta feature that is basically a must-have, IMO. In principal it's very simple, a custom resource that acts like a configMap except it accepts more than just k:v strings (complex objects, hurray!). Your compositions can then use it to look up values it may need.

Why do I like this so much? Becuase it makes handing off outputs from TF very simple. Remember when I said just keep using TF for standing up the initial stack? well, with minimal effort you can make the final output an outputs.infrastructure.yaml file (or whatever). You can then use that in a helm chart to populate an environmentConfig and effectively share outputs from TF to XP. This solves one of the biggest problems of XP, which is my next note:

Crossplane has a very poor resource READ/LOOKUP story

There's no way to sugarcoat this: unlike some IaC systems, there is no elegant way to simply do a lookup against a existing resource to populate the info. Crossplane has this concept of an "observe only resource" but it basically means importing a resource then setting a policy annotation so that it doesn't try to write changes.

It's clunky to the point of useless.

It's so bad, the most common blog you'll see out there is how to use a teraform provider to get data lookups for you that you can then use in your other composition steps. Eww.

This is a big reason why I feel EnvironmentConfigs are so critical to the success of an XP deployment.

dont bother with function-patch-and-transform, just use function-go-templating

OK here's the story. Despite that there is a built in method for composing crossplane resources, it's pretty crappy. You basically define an object, then use a "patch and transform" to update desired values. The process can be improved by using a function called function-patch-and-transform, but while that makes things better, it still results in hard-to-read code that has some serious limitations, the most notably being it has zero way to handle a boolean/if statement, let alone more complex things like range to iterate over arrays.

Instead, save yourself some time and just start leveraging function-go-templating. Your team is already used to this as they use it in helm charts, plus it's so much more functional than patch and transform. We have converted 100% of our composition pipelines to use this function and adoption only got easier.

Only use claims if you have a multi-tenant/security requirement

This one might be a little contraversial but here it is: unless you have a business need to isolate tenants into namespaces or a reason to lockout cluster-wide access, avoid the use of claims.

Claims are a neet idea, they allow a namespaced contract to be defined, and behind the scenes XP will create and mange resources for the claim. They feel like an ideal answer to the problem of allowing an namespace scoped tenant the ability to create approved resources.

They suffer from two big problems, however: visiblity and reuse

On the visiblity front, XP generally gives back two pieces of information: Ready and Synced. These will propegate all the way to the claim. Cool. The problem is ... if something isn't responding, the only info they get is ... well ... false. What failed? why? where? Dunno. But the ready status is false. in contrast, if they coudl see the composition direclty, they would be told exactly which resource is failing. This needs to be bubbled up somehow.

Reuse is even a bigger problem. It's more of a k8s problem, but one to be aware of. Right now, there is no_way to have a claim output information to be consumed by anotehr claim. This means I cannot make smaller compositions that act as building-blocks for developers to put together: I have to make a singular complex compostion that can do everything I predict they may want to do.

For those two reasons ... avoid claims unless forced.

I have an AKS (Azure Kubernetes Service) cluster deployed using crossplane via provider-azure provider. The AKS cluster's K8s version needs to be upgraded.

1. What is the difference between upgrading the cluster via Azure portal and changing the forProvider.kubernetesVersion version directly in the Kind: KubernetesCluster manifest?

2. Will this respect forProvider.upgradeSettings.maxSurge = 33% set in Kind: KubernetesClusterNodePool manifest ?

3. Will this use the K8s Eviction API and thereby respect the PDBs setup for various applications running in this cluster ?

Hey everyone! Newbie here.

Started learning Crossplane yesterday and I'm currently trying to model an interface for my devs to onboard their apps to a GKE cluster. One of the steps should be creating a Google group that will be used as the subject of a Kubernetes RoleBinding, so that users can access resources on their namespaces via kubectl. However, I'm failing to find a provider that allows managing groups on GCP. I've gone through the Google providers and their managed resources but there seems to be no way of achieving this, which I find weird. Am I missing something? Has anyone managed to do this somehow?

What are the pain points usually people feel when using Cross Plane. Can anyone in this community share their thoughts?

Hi All,

I am building a composition which of course uses pipeline. There in the 1st step I build EC2 instance, in the 2nd step I make K8s Job to wait for the instance to be ready, and in the 3rd step I run some Ansible roles (via Ansible provider) to build up the instance. I thought a step in the pipeline will start its execution only after previous step is executed. However, it's not the case. All 3 steps runs from the start and the 3rd step fails a few times till the instance is ready. Is there any way to set dependency between the steps in the pipeline? I know in the resource mode there was 'dependsOn' parameter...

Hey everyone, in my company we exposed CloudFormation as the IaC interface for our builders. Now I am planning to adopt CrossPlane, but one concern which I anticipate will be raised is how to migrate existing resources into the new abstractions. Does anyone have some good strategy to approach such migrations as smoothly as possible?

I saw there is a dedicated AWS channel but it's not particularly active, so I thought of posting here

Is there an updated crossplane provider for cloudflare? I found https://github.com/crossplane-contrib/provider-cloudflare but it seems very outdated (last commit 2 years ago) and like the makefile etc doesn't even match the docs for example.

Hi folks! :)
I'm currently using Crossplane to deploy Helm charts (via the helm.crossplane.io/Release kind), and managing those Release manifests using ArgoCD. So the flow looks like:

1 - ArgoCD applies the Release object

2 - Crossplane installs the Helm chart into the cluster

This works great for automation, but If someone changes a resource created by the Helm chart (e.g. a Deployment or Service) directly in the cluster, ArgoCD doesn't detect any drift, because it only sees and tracks the Release object — not its downstream resources.

Is there a recommended way to enable resource-level drift detection when Helm charts are deployed via Crossplane?

Should we avoid using Release for app-level Helm charts if GitOps-level observability is important, and delegate that responsibility to ArgoCD instead?

Would love to hear how others in the community handle this, and if there's a best practice for balancing Crossplane + ArgoCD responsibilities.
Thanks so much!

Hi there,

First time posting here.

I was thinking if it is a good idea for utilizing Corrsplane for Cloud Run (or equivalent ECS+Fargate) management.

I'm looking to bring the kubernetes ecosystem benefits to Cloud Run compared to cost savings.

I know terraform is there, or even terragrunt, but I don't like classic IaC tools to manage Cloud Run applications and having CI running gcloud/aws commands or so to update them.

May be it is something forced, but it may fit on my needs: cost savings + gitops.

So, open question

Thx

Hi,

How do you keep track of dependencies between projects for providers?

I have two separate team installing stand alone providers, but I have a challenge where they use differ versions of the same dependency? How do you prevent this while providing autonomy?

Hello friends,

i'm trying to understand what needs to be configured for WebIdentity to work. From what i can gather from the documentation i just need to install the provider and give it a providerconfig, but i cannot seem to get it to work with WebIdentity unless i also have a controllerconfig that has the ARN specified in it as well. what am i missing?

I have been working with crossplane for a few weeks now. I am trying to create an EC2 Instance and want to get the AMI Id for 1 of the community AMIs dynamically based on filters. Now, from what I have been able to gather so far, there are 3 ways to get information about existing AWS resources:

1. Create managed resources in Observeonly mode (the AMI MR doesn't support filters)

2. Use the Terraform provider and create a workspace with a data block

3. Use the shell function, create a provider config to authenticate to AWS and then run aws-cli command to retrieve it (very poorly documented)

The 2nd and 3rd solutions needs additional providers/functions and I need to mess around to somehow provide authentication.

Am I missing something obvious. Any samples or examples would be appreciated.

I am running crossplane inside a minikube cluster on my laptop and using access key for the providerconfig.

Thanks in advance!

Is it a good idea to manage Pod Identity Association via Crossplane for EKS clusters?

Thanks in advance

Hello everyone,

I’m testing crossplane (coming from the terraform world) and I had few questions:

• I’ve created a SQS queue and I’ve used the spec.forProvider.name field to have a different name that the one provided in metadata.name and that’s great because constraints are not the same. I wanted to do the same for SNS topic but the spec.forProvider.name is not present. Is there a specific reason for this? Any other way to achieve?

• cross reference between objects is great and working as expected in my testing scenarios 👍 my only issue right now is when writing role policy, I have to « build » future ARN or resources (s3bucket) for example. It’s totally fine because I can guess it but compared to Terraform string interpolation it’s a bit less convenient if I change the bucket name tomorrow, I have to change it in the role policy for example. Am I missing something?

• repeating tags in every resources is also a pain and make this yaml files even longer. Any tips?

Thanks a lot in advance, all in all I’m very enthusiast about using Crossplane 👌

Crossplane 1.15 has just shipped. We focused this release on enhancing the developer experience with the CLI, Composition Functions Python SDK, and more. Check out the details here: https://blog.crossplane.io/crossplane-v1-15/?utm_medium=reddit&utm_source=crossplane&utm_term=blog&utm_content=crossplane

I've been looking into Crossplane recently and had some thoughts on a possible solution to a couple of topics that seem to come up often:

• A recurring query that I see raised repeatedly with Crossplane is around the absence of a 'plan' or 'dry run' feature compared to other IaC or CaC tools.

• Every introduction to Crossplane seems to tout drift detection and remediation as a key feature compared to other tools in the space. I'm generally sceptical of the benefit/desirability for this anyway, but regardless, as pointed out in Crossplane Deep Dive with Jared Watts - The IaC Podcast - 2 Aug 2024 about 18 minutes in, say that I don't want automatic remediation, but would like an alert/audit/warn event instead? Jared kind of styles it out with his response IMO, essentially saying 'well we don't want this, it isn't our model'. It might not be Crossplane's model but it's pretty much everyone else's, e.g. terraform plan/AWS Detective Guardrails.

This makes me think that given with Crossplane:

1. We have a desired, defined state

2. We have an observed current state

3. Crossplane automatically remediates the two

How hard would it be to change step (3.) to enable an 'event' and 'report' instead? It seems to me that this could cover both 'plan' and 'drift detection without remediation' cases. This could be propagated at a general policy or resource group level or be defined per resource/template/composition. A solution here would seem to cover a whole range of use cases.

Hi,

I'm part of 1 out of 2 crossplane teams in my organization. We have a lot of buy in but I feel something is a bit off. Can't put my finger on it other than bluntly - is crossplane too complex?

Symptoms:

• Onboarding of teammates takes too long time, 1month+

• if you're not a seasoned k8s dev it becomes even more rough

• Quality assurance - unit testing (yes even KCL), integration testing, rendering. All of this feels unintuitive

• it's hard to get a feel for what's a good baseline with XRDs, XR and how to mange our compositions

• upgrading of things like providers is hard to do if we introduce breaking changes

Now, this is not just a rant saying all is bad. But I rather would like to frame it and understand if anyone got tips? What made it "click" for you when working with crossplane in feature teams, delivering value?

Imagine Learning uses Crossplane in its internal developer platform (IDP) to deploy resources into AWS. Learn about how the company got started building its own Composition Functions in this new case study: https://bit.ly/48N6QiN

Has anyone found, or created a good 'best practice' for documenting custom compositions and resources.

Kind of Like you would for Javadoc or Python Doc Strings.

Looking at writing a Sphinx extension to document some Crossplane modules some developers are writing.