lesson-01
Forward¶
Thank you for taking the time to start reading this educational material.
I hope this hands-on, interactive lesson can reduce the startup cost in your journey to learning CrossPlane.
The Web Terminal¶
If you want to take advantage of the interactive, hands-on nature of these labs, you'll need to either already have a web terminal connection available or fire one up yourself.
Instructions for that can be found here.
Lesson 01¶
This lesson will cover the following exercises:
- Initialize a local Kubernetes cluster using kind
- Install CrossPlane on a local cluster using helm
- Connect the installation to an AWS account
What is Kubernetes?¶
Kubernetes is a microservices architecture (MSA) platform for automating deployment, operations and scaling of containerized applications.
It can run anywhere where Linux runs and supports on-premise, hybrid and public cloud deployments.
What is CrossPlane?¶
- CrossPlane is a free, open-source Kubernetes add-on that transforms your cluster into a universal control plane
- Was created by Upbound, and was first released in December of 2018
- It was accepted as an incubating project by the CNCF (Cloud Native Computing Foundation) in 2020
CrossPlane Features¶
From the website:
- CrossPlane enables platform teams to assemble infrastructure from multiple vendors, and expose higher level self-service APIs for application teams to consume, without having to write any code.
- CrossPlane extends your Kubernetes cluster to support orchestrating any infrastructure or managed services
- Can be installed into any Kubernetes cluster to get started
- Supports most major cloud providers and covers typical service deployments
As such, it offers an alternative to Terraform, CDK, and Pulumi
Why is this approach to infrastructure management significant?¶
I mentioned self-service in the previous slide. That's the key here.
- From a deployment standpoint, Kubernetes already breaks down barriers to entry for Developers
- To get an app deployed, developers need only describe their workloads using Kubernetes API Documents, which are expressed in yaml syntax
- CrossPlane extends this self-service approach a layer above that -- to the infrastructure itself
- It helps Developers claim cloud resources through expression of Kubernetes API Documents in the same way they do for their workloads
- The infrastructure is defined declaratively without writing any code and without revealing the underlying infrastructure of the specific vendor
- Because CrossPlane exposes administration of higher-level infrastructure in a Kubernetes-native manner, it allows us to easily design, manage, distribute, and consume these infrastructure abstractions within the existing ecosystem of Kubernetes add-ons, plugins, and integrations
Let's put what I just said into practice
Exercise 1 - Create a local Kubernetes cluster¶
Since CrossPlane is a Kubernets add-on, we'll need a Kubernetes cluster on which to install it.
For the purposes of this introduction, we'll utilize kind to initialize our demo cluster.
For those of you not familiar with the tool, it's used for running local Kubernetes clusters using Docker containers as worker nodes.
I've already installed version v0.14.0 of the tool: kind version
The syntax for creating a Kubernetes cluster using the kind command is quite simple.
We can run kind create cluster --help
to get more info, but you can create a cluster by just running kind create cluster
.
For our demonstration, we'll create a Kubernetes cluster named crossplane-demo with some customizations
echo -e """ kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane extraPortMappings: - containerPort: 30001 hostPort: 30001 - containerPort: 30002 hostPort: 30002 - role: worker """ | kind create cluster --name crossplane-demo --config=-
Next, we'll initialize our Kubernetes config and context.
You can retrieve your cluster's kubeconfig via the command kind --name crossplane-demo get kubeconfig
We'll pipe that to our kubeconfig file using the tee command:
kind --name crossplane-demo get kubeconfig | tee ~/.kube/crossplane.yaml
We'll then set our KUBECONFIG environmental variable: export KUBECONFIG=$(ls ~/.kube/*.yaml | tr '\n' ':')
and finally set our active Kubernetes context: kubectl config use-context kind-crossplane-demo
Next, we install CrossPlane.
Exercise 2 - Install CrossPlane¶
- Create the crossplane namespace:
kubectl create namespace crossplane-system
- We'll install its components using helm:
- First, add the crossplane helm repo:
helm repo add crossplane-stable https://charts.crossplane.io/stable
- Sync our local helm repos with their upstream
helm repo update
- We install crossplane:
helm install crossplane --namespace crossplane-system crossplane-stable/crossplane
- Lastly, we check the components are up and healthy:
kubectl get all -n crossplane-system
- First, add the crossplane helm repo:
Now that we have CrossPlane installed, let's connect it to our AWS infrastructure.
Exercise 3 - Install the AWS Provider¶
For CrossPlane to manage our AWS Infrastructure, we must first install the AWS Provider.
A CrossPlane provider ships with CRDs ( Custom Resources Definitions ) required to create resources on the AWS cloud.
- Create the provider Kubernetes API Document:
echo -e """apiVersion: pkg.crossplane.io/v1 kind: Provider metadata: name: aws-provider spec: package: crossplane/provider-aws:alpha""" > provider.yaml
- Apply the document:
kubectl apply -f provider.yaml
- Wait for the Provider to become healthy:
kubectl get provider.pkg --watch
Now that the Provider is in a healthy state, we're ready to connect CrossPlane to our AWS infrastructure.
Exercise 4 - Connect CrossPlane to your AWS Infrastructure¶
To connect CrossPlane to your AWS Infrastructure, you must create a ProviderConfig definition.
- I've already configured my AWS credentials using
aws configure
beforehand, so I'll now generate the Provider configuration file with my AWS Credentials, as follows:
echo -e """ [default] aws_access_key_id = $(aws configure get aws_access_key_id --profile default) aws_secret_access_key = $(aws configure get aws_secret_access_key --profile default) """ > creds.conf
- Next, we create a Kubernetes secret with the configuration file we just generated:
kubectl create secret generic aws-secret-creds -n crossplane-system --from-file=creds=./creds.conf
- We then create the Provider config for our AWS account:
echo -e """apiVersion: aws.crossplane.io/v1beta1 kind: ProviderConfig metadata: name: awsconfig spec: credentials: source: Secret secretRef: namespace: crossplane-system name: aws-secret-creds key: creds""" > provider-config.yaml
- Now apply our provider config:
kubectl apply -f provider-config.yaml
- Because we're ultimately working with Kubernetes-native resources,
we can verify the provider's pod instance:
kubectl -n crossplane-system get pods -l pkg.crossplane.io/provider=provider-aws
Everything looks good so far
With CrossPlane installed and connected to our AWS infrastructure, we're ready to launch some nukes.
Let's move onto lesson 02.