Guest post originally published on CloudReach’s blog by Brad Campbell, Chief Technologist, Platform Development at CloudReach
In the first of two blogs covering the use of Kubernetes as a cloud services provisioner, Brad Campbell answers the question: What are Custom Resource Definitions?
In a world where cloud and automating the lifecycle of “all the things” are top-of-mind for many IT practitioners, conversations about Terraform, CloudFormation (and are now beginning to regularly include the AWS CDK and Pulumi) are relatively common. As Kubernetes has grown in adoption, though, so has its ability to show up in conversations outside of those strictly relegated to where best to run one’s containers.
In fact, the theme of this conversation is exactly what we started out with: automating the lifecycle of cloud-based objects and services. Where this conversation will be much different than most in that space, though, is that it will focus on how to do that via Kubernetes. In order to connect the dots of how we can accomplish that (and why it makes sense to do so in certain scenarios), we first discuss a few concepts that are important parts of the overall process.
Custom Resource Definitions
So what exactly are Custom Resource Definitions (or, CRD)? From Kubernetes’ docs:
A custom resource is an extension of the Kubernetes API that is not necessarily available in a default Kubernetes installation. It represents a customization of a particular Kubernetes installation. However, many core Kubernetes functions are now built using custom resources, making Kubernetes more modular.
From this definition, we see that CRDs are a mechanism that Kubernetes has for purposes of extensibility.
Custom Resource Definition Implementers
CRDs may seem like some sort of exotic feature that doesn’t get used often in the real-world. In reality, though, CRDs are everywhere. If you’ve ever heard of Calico, then you’ve heard of a project that uses CRDs. Other popular projects like kubeflow use them. Operatorhub is an open market of applications and components that implement the Operator pattern, each of which is usually composed of multiple CRDs.
Returning to the opening themes, in this post we are going to use a CRD from a company called Crossplane. Crossplane has an awesome set of CRDs that allow a developer or cluster operator who can deploy apps to a cluster to provision cloud resources straight from the cluster. Using Crossplane CRDs, cloud resources are managed declaratively via YAML files, just like a Pod or a Deployment; you can also create resources imperatively on the CLI using kubectl as well.
A Self-Contained App from the Ground Up Using Crossplane for AWS
Got Cluster?
If you plan on following along, you’ll need a cluster. For this post, I’ll be using a cluster created by Minikube, running on my MacBook Pro (feel free to use a cluster provisioned in any way you like, though). So, time to fire up my cluster.
➜ ~ minikube start 😄 minikube v1.14.2 on Darwin 10.15.7 ✨ Using the docker driver based on existing profile 👍 Starting control plane node minikube in cluster minikube 🔄 Restarting existing docker container for "minikube" ... 🐳 Preparing Kubernetes v1.19.2 on Docker 19.03.8 ... 🔎 Verifying Kubernetes components... 🌟 Enabled addons: default-storageclass, storage-provisioner 🏄 Done! kubectl is now configured to use "minikube" by default
The Extra Bits
Based on our previous discussion, we know that CRDs are extensions to core Kubernetes. These extensions are powered by additional software that needs to be installed to your cluster. I’m not going to cover the installation of Crossplane’s AWS CRDs right here, as I have a script to install all the relevant components as part of the deployment of the app to the cluster, but it’s worth mentioning that these extensions don’t ship with a standard cluster distribution and, regardless of the context, usually require additional software installation and configuration for everything to work. In this example, we’re starting from a freshly-installed local cluster from Minikube.
Crossplane’s AWS CRD ships in an alpha and beta version. While the beta is more stable, we’re using the alpha version in this post, as it implements the type of resource (SNS Topic) that our app uses. If you decide to use one of Crossplane’s AWS CRDs for your project, check the resources page and figure out which version of the installer you need to use to make sure your resource type(s) are implemented.
What’s Next?
In this post, we took a look at CRDs and what makes them useful. As we look at Crossplane’s offering for provisioning AWS resources, we set the stage to dive into our app and how we’ll deploy into our cluster in the next post.
Explore How Kubernetes Can Help Your Business Modernize
Our Kubernetes Launchpad is a high-impact solution that helps enterprise teams quickly experience the benefits of cloud-native application development by rapidly deploying a DevOps platform and re-platforming an application on your chosen Cloud platform: AWS, GCP or Azure.