TL;DR: Repo = https://github.com/n8sOrganization/cp-aws-irsa

The previous three posts were overviews of the six types of patches available to Crossplane Compositions. In this post, I’ll walk through a configuration that uses all of them. I’ll also touch on transforms when they come up. While the configuration is for EKS IRSA, explaining IRSA is not the intent of this post. In a nutshell, IRSA enables a K8s Role to attain the privileges of an AWS Role. In the case of this config, we are using IRSA so that the EBS CSI containers have appropriate privileges to provision EBS volumes.

The config consists of four XRs: XCluster, XK8s, XNetwork, and XChart. XCluster exposes a claim that accepts basic input of spec.id, spec.cloud, spec.parameters.nodes.size, and spec.parameters.nodes.count. XCluster selects a Composition that has XK8s and XNetwork nested. XNetwork provisions the VPC and all of the networking required for our EKS cluster. XK8s provisions the EKS cluster, IAM Roles, creates a ProviderConfig for provider-helm, and creates an instance of XChart to deploy the AWS EBS CSI helm chart. The XChart also configures IAM resources for IRSA. Continue reading →

In the previous two posts, I covered FromCompositeFieldPath and ToCompositeFieldPath. In this post, I’ll cover CombineFromComposite and CombineToComposite.

The Combine patches enable us to include multiple string values into a single patch. For this example, I’ll focus on CombineFromComposite, you can infer the CombineToComposite  patch from the previous ToCompositeFieldPath post. Continue reading →

By the end of this post, combined with my previous Crossplane intro posts, you should be capable of implementing a fairly robust Crossplane configuration. There is a lot more to be familiar with, but you can get a long way just knowing what I’ve covered so far.

Continuing with the series on Crossplane Composition patches, Im covering ToCompositeFieldPath here. As the name implies, this is the inverse of FromCompositeFieldPath. It’s used when we need a value created in one resource template (Managed Resource) supplied to another resource template or nested XR. We can even use combinations of ToCompositeFieldPath and FromCompositeFieldPath to pass values from one nested XR to another,

Continue reading →

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 →