In Episode 5, we hardcoded our RDS instance size to 20GB. If a developer asked for 50GB in their Claim, Crossplane ignored it. In this episode, we explore the Patcher, learning how to dynamically route data from the Composite Resource (XR) into the physical Managed Resources (MRs).
In Episode 4, we built an API (XRD) but it didn’t actually create any AWS infrastructure. In this final fundamental episode, we write a Composition. This is the ’translation engine’ that instructs Crossplane exactly which physical Managed Resources to create when a developer requests our custom API.
Managed Resources (MRs) are too low-level for application developers. In this episode, we learn how to define a Composite Resource Definition (XRD). This allows Platform Engineers to design a brand new, highly abstracted Custom Kubernetes API tailored exactly to their company’s needs.
A Managed Resource (MR) is the foundational building block of Crossplane. It is a 1-to-1 representation of a physical cloud object (like an S3 Bucket or an RDS Instance) stored as a Custom Resource in Kubernetes. In this episode, we provision our first AWS resource directly via kubectl.
Crossplane is useless on its own. To orchestrate AWS, Azure, or GCP, we must install Providers. In this episode, we install the official Upbound AWS Provider, configure Kubernetes Secrets to store our IAM credentials, and bind them to a ProviderConfig.
To understand Crossplane, you must first understand the Kubernetes Control Loop. In this episode, we explore the theoretical difference between CLI-driven IaC (Terraform) and Control Plane IaC (Crossplane). We will then install Crossplane into a local cluster using Helm.
