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 →

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 →

In this next series of posts, I’m going to cover Crossplane in increasing detail.

The most basic/simplified description I can think of for Crossplane is: A platform that leverages the Kubernetes api/controller model to deliver continuously reconciled infrastructure as code. It is really much more than that, but let’s start there for the sake of simplicity.

Some K8s principles upfront. By now, most in our industry know what Kubernetes is; and minimally, that it orchestrates containers. But K8s offers much more than just container orchestration these days, Continue reading →

The K8s Deployment resource enables us to manage ReplicaSet resources at a higher level. The Deployment controller tracks image update history (versioning) and manages the sequence of Pod replacement during updates. This enables us to rollback to previous versions and control how many ‘new’ members of a ReplicaSet are deployed at a time. However, the Deployment controller hasn’t proven to deliver real-world safe and intelligent updates. Continue reading →

In this demonstration, I’ve configured OPA policy at the K8s cluster, allowing only the Spinnaker service account to create a deployment via the kube-api server. Additionally, I’ve defined a policy within the pipeline via the Armory Policy Engine, requiring all images be specified with a tag other than ‘latest’. This demonstrates centralization and consolidation of admission policy for K8s.

Safe Continuous Deployment/Delivery is a key focus for Armory. Establishing policy-driven governance as a first-class citizen in CD pipelines is one way Armory enhances this goal. Through policy, elements of a CD pipeline are controlled at a much finer grain than RBAC alone. Continue reading →