Creating Test Kubernetes Clusters With Kind
I will show you how to quickly get up and running with a local development Kubernetes cluster using Kind and a hosted instance of Octopus.
Join the DZone community and get the full member experience.Join For Free
Getting started with Kubernetes can be a little overwhelming. With so many tools like Minikube, K3s, Docker Desktop, MicroK8s, and Kind, even knowing which test distribution to use is not an easy choice.
For local development, I find myself using Kind. It is quick to boot and integrates well with WSL2 allowing me to quickly switch between Windows and Linux development.
In this blog post and the associated screencast, I show you how to quickly get up and running with a local development Kubernetes cluster using Kind and a hosted instance of Octopus.
The video below demonstrates the process of deploying a web application to a development Kubernetes cluster created by Kind. The remainder of the post provides links to additional resources and copies of the scripts used in this demo:
Enable WSL2 Docker Integration
To use Kind from a WSL2 instance, Docker Desktop needs to enable WSL2 integration. This is done by selecting the Use the WSL2 based engine option:
Docker has exposed the target WSL2 instances:
Kind is a self-contained Linux executable that is downloaded and placed into the PATH for easy access. The Kind quick start docs provide instructions on installing Kind, which in my WSL2 Ubuntu instance was achieved by running:
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.8.1/
kind-linux-amd64 chmod +x ./kind sudo mv ./kind /usr/local/bin
The Kind documentation has links to the latest release, which will likely have been updated from the URL above.
Creating the Cluster
A new development cluster is created with the command:
kind create cluster
This cluster is then made accessible with the configuration stored in the
~/.kube/config file, created by Kind when the cluster was created. An example of this file is shown below:
Extracting the Certificates
The script below extracts the
client-key-data fields into a single PFX file and the
certificate-authority-data field into a plain text file.
Note that you will need the
openssl applications installed for this script to work.
Here is a similar script in PowerShell:
Installing the Octopus Worker
To connect a local development machine to an Octopus instance, a polling worker needs to be installed. A polling worker reaches out to the Octopus Server and allows communication when the target machine does not have a static IP address.
The Tentacle is installed using these instructions from the Octopus website. For my Ubuntu-based WSL2 instance, the installation was done with the commands:
The Tentacle instance is then configured with the command:
Because WSL2 doesn't support systemd, we need to run the Tentacle manually with the command:
sudo /opt/octopus/tentacle/Tentacle run --instance Tentacle
The two certificate files created from the Kind Kubernetes configuration file are uploaded into Octopus:
Creating the Target
After the certificates are uploaded, a new Kubernetes target is created using the Kind User certificate for authentication, and the Kind CA certificate to trust the HTTPS API endpoint:
Creating the Feed
The Docker image being deployed is hosted on DockerHub, which must be configured as an external feed:
Creating the Deployment
We then deploy the
nginx container with the Deploy Kubernetes containers step.
The pods created by the deployment are exposed with a service accessed on port 80:
Accessing the Service
Kind only exposes the Kubernetes API endpoint, and so the service is not accessible outside of the cluster. To open NGINX from our browser, we need to use
kubectl to forward traffic from a local port into the cluster. This is done with the command:
kubectl port-forward svc/myservice 8081:80
NGINX is then available on the URL http://localhost:8081. Here is the welcome page displayed by the default NGINX container:
The combination of Kind and WSL2 provides a convenient way to create a local development Kubernetes cluster that can be exposed to Octopus via a polling worker.
In this post and screencast, we saw how to configure a development Kubernetes cluster in WSL2, extract the certificates used by the HTTPS endpoint and user authentication, connect to the cluster via a polling Tentacle, and create a Kubernetes target that can be used to perform deployments.
Published at DZone with permission of Matthew Casperson, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.