I’ve covered Composite Resources (XRs) and Compositions in previous posts. I’ll provide a brief summary here, but you can review them in more detail if needed.. In the next series of posts, I’ll cover how we use Composition patches to pass values between/to related resources (all patch methods are documented here).

It is important to keep the concepts of Composite Resource and Composition clearly separated in your understanding. A Composite Resource (XR) defines a custom API, exposed via kube-apiserver. It selects a Composition that composes it into a collection of Managed Resources . The Composition is simply a ‘recipe’ to compose the Composite Resource(s). We patch to, from, and within Composite Resources via a Composition. We do not patch Compositions.

Continue reading →

As an update to my previous config of Crossplane with Argo CD, we can now configure Argo CD to use Annotations for sync tracking. This means we no longer have to configure resource ignore/deny rules per Composite Resource as we did with Label based tracking.

That said, I’m still undecided on XRC or XR as starting point for Crossplane in a GitOps pattern. Remove namespace boundary (that is a daydream at best for K8s multi-tenancy) by using vcluster, and you don’t need XRC. I’d personally throw XRC out the window and just use XR with vcluster. Makes the rest of this sort of irrelevant.

To configure Argo CD for Annotation resource tracking, edit the argocd-cm ConfigMap in the argocd Namespace (Argo CD version 2.4.8 or greater is recommended). Add application.resourceTrackingMethod: annotation to the data section as below: Continue reading →

External Secret Store is currently a beta feature of Crossplane. This feature enables us to publish connection details (Crossplane currently outputs these to a Kubernetes Secret in the Crossplane cluster) to an external vault, This then enables us to reference those secrets/connection details from a context outside of the Crossplane cluster. See this post for more on External Secret Store. But there is another interesting option when we simply need secrets from the Crossplane cluster to be available to Pods in a remote cluster. Continue reading →

Update: Upbound Cloud has been retired. So the basic premise of this post is no longer relevant. I believe it still has merit for similar use case, so I’ll leave it  active.

Disclaimer: Commercial product post. Ok, disclaimer out of the way, this topic comes up a lot in my day-to-day at work and I figured it would be helpful to provide some detail here.

Upbound Cloud is Upbound’s commercial SaaS offering backed by Crossplane. Argo CD is a popular GitOps platform that benefits greatly from  Crossplane. So why don’t they work nicely together ‘out of the box’? I have a series of previous posts that cover Crossplane and Argo CD in general. In this post, I’ll cover Upbound Cloud with Argo CD.  I’ll try to keep it short and to the point.

To follow along with this post, you’ll need an Upbound Cloud control plane and an instance of Argo CD running in a separate cluster.  You can follow the directions here for an Upbound Cloud trial. In that process, you’ll find directions to download a kubeconfig for your UBC instance. This will be used in proceeding steps. To install Argo CD, refer to Argo CD project page here. Continue reading →

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 WITHIN THE 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 →