To date, Crossplane has enabled us to write ‘secrets’ to a Crossplane in-cluster Kubernetes Secret. These are resource/provider specific, but typically include things like username, password, host address, port, etc.. These secrets stored in the Crossplane cluster can then be retrieved by platform and application engineers to further configure a service and/or by Crossplane to automatically configure a ProviderConfig.

But what if you wanted to provision a K8s cluster, a managed database service, and a pod in that provisioned cluster that needs to authenticate to the managed database, without manual configuration? The pod isn’t running in the Crossplane cluster, so it can’t refer to the secret created for the database. Continue reading →

I’ve been at Upbound.io just about three months now and figured it’s a good time to post a consolidated summary of my Getting Started with Crossplane series. If you’re just getting started with Crossplane or are interested in some intermediate topics like GitOps, I’m sure these will be useful.

• The Universal Control Plane – Crossplane 101
• The Universal Control Plane – Crossplane 102 – XRDs
• The Universal Control Plane – Crossplane 103 – Composition
• Crossplane – Bringing the Basics Together
• Crossplane – Composition Patches – FromCompositeFieldPath
• Crossplane – Composition Patches – ToCompositeFieldPath
• Crossplane – Composition Patches – Combine Patches
• Crossplane – All the Patches with AWS IRSA Config
• Crossplane – Beyond the Basics – Nested XRs and Composition Selectors
• Automating Crossplane Package Builds – Update Through Rollout
• Crossplane with Argo CD – XRC or XR?

In my last post I covered using a private image registry for Crossplane Packages. In this post, I cover setting up a repo with Github Actions to automate the building of a Crossplane Package. I’ll combine that with GitOps to show an end-to-end update to rollout. Continue reading →

Crossplane uses Composite Resource Definitions, Compositions, Providers, and Resource Manifests to elevate a Kubernetes cluster to a Universal Control Plane (Plenty on that in my previous posts). We can package all of these things into Crossplane Packages, serialized as OCI images, and then store and install them to/from any OCI image registry.

In this post, I’ll cover something you might run into if you’re testing Packages with a private registry that is configured with a self-signed certificate. It is relatively simple to implement a private registry running in Kubernetes with a free ACME cert configured via cert-manager. This avoids needing to configure things like Docker, containerd, and Crossplane to trust the signer of the cert. But it requires publicly  resolvable DNS records, and some other details that make it more of a burden when all we want to do is basic testing. Continue reading →

This post is out of date based on enhancements made in both projects. See this post for updated guidance.

TL;DR – Use XRC and configure Argo CD to ignore XRs created by them. A GitOps platform should only track resources in the repo matching the same resources to the cluster, anything created beyond that should be the responsibility of an operator to determine sync.

Edit note: This post has undergone a fairly significant revision based on further thought and collaboration. I believe this revision best covers the topic and issue.

This topic remains somewhat unresolved from my previous post. In that post, I had to make some implementation opinions on cluster vs. namespace scoped Crossplane resources when used with Argo CD. In this post I’ll dig a little deeper into the issue and then share my current opinions on the matter. Continue reading →

THIS POST IS PARTIALLY OUT OF DATE BASED ON ENHANCEMENTS WITHIN THE PROJECTS. SEE THIS POST FOR  UPDATED GUIDANCE.

This is a video-centric post. I figure it will take longer for you to read (and me to write) about this topic than can be conveyed via a video.

It requires some prerequisite knowledge. First, you need to be fairly comfortable with Crossplane concepts. If you are not yet, my previous five posts provide the necessary understanding. Second, you’ll need to understand Git and GitOps. Continue reading →

Now that we’ve covered the basics, let’s go a bit deeper (If you missed my previous 100 level series, start here). In this post I’ll move into some 200 level concepts, beginning with nested Composite Resources and Composition Selectors.

A nested XR is one created via a higher-order XR/Composition pair. So far, we’ve looked at a virtual network created by directly instantiating an XR/Composition. While network infrastructure is required in nearly all cases, it isn’t necessarily something we want the creator of ‘things’ to be engaged with. Continue reading →

My previous three posts introduced Crossplane and two of its key components (XR and Composition). This post will primarily be video based to demonstrate those concepts. But first I’ll take a moment to cover XR Claims, as I left them out of the XR introduction to avoid potential confusion. If you missed the post on Composite Resources, you can find it here.

As we now know, XRs call on Compositions to get the Crossplane machine doing something new for us. We looked at how an XRD is converted to a CRD in our cluster. To recap that flow, we define a CompositeResourceDefinition and create it, Crossplane creates a K8s CRD from the XRD with the schema we defined. We then create an instance of that CRD which becomes our XR. Continue reading →

In the previous posts of this series, I introduced core Crossplane and more detail on Composite Resource (XR). In this post, I’ll dig deeper into Composition. This is where we get to see how Crossplane does something with the data we feed it.

In review, Managed Resources (MR) are high-fidelity Crossplane representations of various external API resources (i.e., they have values that are essentially a 1:1 match for the external resources they represent). They are the most discreet entity in the Crossplane machine.  Similar to a K8s Pod, we could create MRs directly. But like a K8s pod, we’re generally better served with an abstraction that does a bit more than just creating something and forgetting about it. So let’s spend a few seconds looking at why the XR -> Composition -> MR pattern is more desirable. Continue reading →

In the previous post, I introduced the basic components of the Crossplane machine. In this post, I’ll dig a little deeper into Compositions and Composite Resource Definitions.

We know Kubernetes allows us to extend the functionality of a K8s control plane with Custom Controllers and Custom Resources. The Custom Resource Definition (CRD) API provides us with the interface to define our custom resources and register them with the K8s API server. Continue reading →