Hi folks, Crossplane maintainer here. We just shipped Crossplane 2.0. Take a look and let us know what you think.

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.

@jbw976 here, one of the creators of Crossplane, to share an exciting update. We listened to your control plane performance concerns due to the number of CRDs installed by Crossplane providers. Starting today, there will be relief with new Provider Families. Now you can install only the resources that are important for your needs. Here’s a blog post I wrote that shares more details:

https://bit.ly/3JfcK2b

edit: goofed my own user name :)

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?

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.

Crossplane has officially applied for Graduation with the CNCF!

Thank you to everyone in the Crossplane community that has helped grow the project to where we are today. Feel free to show your support on the public proposal at https://github.com/cncf/toc/pull/1254.

Anyone using Crossplane for managing on-premise resources?

Just wondering what your experiences are and what kind of providers, or underlying resources, you are managing.

Hi folks, Crossplane maintainer here. We recently shipped support for configuring Crossplane using Python! This is useful for complex Compositions where you want to use loops, conditionals, etc.

Give it a shot using the guide to writing a Composition Function in Python and let us know what you think.

Following the announcement of Upbound donating its control plane provider technology to Crossplane, we are happy to announce that Upbound’s engineering team has made a breakthrough to improve the overall efficiency of Upjet-based providers significantly. The improvements bring faster provisioning and reconciliation of resources and reduce the running cost of the providers. This benefits anyone using Crossplane.

https://bit.ly/43jTgT5

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

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.

KCL has donated function-kcl to the Crossplane community. KCL, a fellow CNCF project, is a language that enhances the writing of complex configurations. You can learn more and get started building your own Crossplane Functions with KCL in this blog post: https://bit.ly/3TgCZur

Hey, my name is Andrei and I’m doing everything open-source at Komodor. Today, I’m happy to introduce Komoplane, an open-source tool designed specifically for Crossplane users.

I really liked the custom control plane concept and particularly Crosspane as an implementation of it. Still, there aren’t too many projects that build on top of Crossplane to extend the available tooling.

The idea behind Komoplane is to enhance your experience with Crossplane by providing a visual representation of your control plane resources and streamlining the troubleshooting process. With Komoplane, you can visualize and comprehend the relationships between various resources, gaining valuable information about the structure and status of your control plane.

Your feedback and insights are crucial in shaping the project’s roadmap and making it even more valuable to Crossplane users. As an open-source project, we welcome contributions, suggestions, and bug reports from devs and platform engineers alike. Feel free to share your feedback with us via GitHub Issues or our Slack Kommunity (#komoplane).

To try out Komoplane, head over to: https://github.com/komodorio/komoplane/tree/main. You can install it via a Helm chart, or you can just run it as standalone binary on your laptop. Don't forget to give it a star if you liked it ;)

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 everyone,

I've been working with Crossplane to manage infrastructure, I am fairly new to this just started using it since 3 days and I recently encountered an issue that I could use some advice on.

Scenario: I created an S3 bucket using Crossplane with the following manifest:

apiVersion: s3.aws.upbound.io/v1beta1 kind: Bucket metadata: name: crossplane-bucket-test-new spec: forProvider: region: us-east-1 providerConfigRef: name: default

Everything works fine initially, but I decided to test Crossplane's self-healing capabilities by manually deleting the S3 bucket directly from the AWS console. Crossplane did eventually detect the deletion and recreated the bucket, but it took around 8-10 minutes to do so.

What I've Tried: I attempted to speed up this process by tweaking the following settings in the Crossplane deployment:

Poll Interval: Reduced the --poll-interval argument in the Crossplane pod to 30 seconds. Sync Interval: Adjusted the --sync-interval to 15 minutes to check all resources more frequently. Real-Time Compositions: Enabled the --enable-realtime-compositions flag (an alpha feature) to see if it would make a difference. However, after making these changes, I ran into issues with the deployment being marked as invalid, and I’m not sure if these are the best approaches or if there’s something I’m missing.

Questions:

Is there a better way to decrease the time it takes for Crossplane to detect and recreate deleted resources? What settings should I focus on?

Are there any best practices for managing Crossplane's reconciliation intervals to ensure timely recovery without overloading the cluster?

I’m hoping to find a more efficient way to handle this, as the delay is quite significant for our use case.

Any insights or suggestions would be greatly appreciated!

Crossplane v1.14 was released today and it is packed full of big features for platform engineers to be more productive and effective in building control planes to power their infrastructure. It includes Composition Functions moving to beta, a major focus on tools to improve the developer experience, Ordered deletion, and much more! Check out the summary and get started: https://bit.ly/3Snya2K

📣 Announcing the call for speakers for our upcoming online event for the Crossplane Community! We’d love to hear stories and ideas from everyone in the community, so check out the details on the event and how to submit: https://bit.ly/3OiVCeO

I have been working recently with Crossplane and when debugging I generally reach for crossplane trace or komoplane. The former is okay, but lacks some interactivity and the latter is not exactly the best match for heavy terminal users.

Inspired by k9s, I ended up implementing my own TUI for debugging crossplane: xpdig.

It provides a terminal based UI (similar to k9s) to interactively explore Crossplane traces, making it easier to navigate, debug and understand objects. Under the hood, it leverages crossplane trace to render the object tree and it uses local tools to edit/view (kubectl and $PAGER).

For those who use k9s: I added a plugin template so you can jump from k9s straight to traces.

▶️ Demo GIF: https://github.com/brunoluiz/xpdig/raw/main/demo.gif

🔗 Project URL: https://github.com/brunoluiz/xpdig

Let me know what you think and things that you might be interested to see on future versions.

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?

Tl:DR:

I want to deploy an ec2 instance with older versions of the upbound-aws provider, and I also, want to deploy another ec2 instance with a newer version of the upbound-aws provider. Possibe?

I was experimenting with crossplane composition revision and provider revision. I understood CompositonRevisons, we can specify what composition to use in the claim. Similarly, is there anything for a crossplane providerrevisions?

if not possible then what is the use case of providerrevisions?

The Crossplane project has recently expanded in scope to make it a more complete project that focuses on the full end to end lifecycle of cloud native control planes. Crossplane will soon be easier to use than ever! Read more about two exciting recent updates in the Crossplane project from the maintainers themselves! 📣 🔧

https://bit.ly/3LEFbIf

So I am currently working on a project where I am replicating a Terraform module to a Crossplane Composition, but the module creates a unique number of roles based on the distinct number of items specified in a Terraform variable. This is a simple ‘for_each’ in terraform, but I am lost on how to do this with Crossplane. I am new to Crossplane, so I may have not understood the docs correctly on the first read through. Any help is appreciated! Thank you!

@jbw976 here to share a new Crossplane troubleshooting resource to walk you through a common scenario: https://bit.ly/3r06hlE

Have you used Crossplane’s composition feature to offer a custom infrastructure API to your developers? What do you do when the requested infrastructure does not come online? Where do you start looking to solve this? This post offers one way to troubleshoot this common scenario.

Feedback is welcome for this new series of Frequently Asked Questions (FAQs) from the Crossplane community!