K3d in Action: Fast-Tracking Local Kubernetes Development

If you’re a DevOps enthusiast, a beginner in Kubernetes, or a developer managing a local stack, having a Kubernetes cluster locally is highly beneficial.

There are several solutions for setting up a cluster on your computer, such as minikube, k3s and microk8s. While these options are user-friendly, they can be less efficient in terms of performance. The ideal setup would enable rapid development and testing, mirroring your production environment as closely as possible.

Here’s where k3d comes into play. It’s a streamlined version of k3s, Rancher’s lightweight Kubernetes distribution, that uses Docker instead of virtual machines, leading to significantly faster performance.

This guide will help you set up a cluster quickly. As a practical application, we’ll be deploying a WordPress site using Helm. This requires Docker, kubectl, and Helm to be installed on your system. A basic understanding of these tools will be advantageous.

First, let’s install k3d using the following command, which downloads and runs the installation script:

curl -s https://raw.githubusercontent.com/k3d-io/k3d/main/install.sh | bash

Next, create your cluster with:

k3d cluster create mycluster --api-port 6550 -p "8081:80@loadbalancer"

In this command, mycluster is the name of your cluster, which you can customize. The command also maps Kubernetes’ Ingress port 80 to your local machine’s port 8081, important for accessing services like websites later. For more details on exposing services, check out the k3d documentation here.

I was able to get my k3d cluster operational in just 15 seconds, even on a standard-spec PC running Windows 11 with Windows Subsystems for Linux. This speed is a notable improvement over other methods and can be even faster on a native Linux system.

Once you create the cluster, the current context in your kubeconfig—a file that stores your cluster access information—will automatically switch to the new cluster. To confirm that everything is functioning correctly, run the following kubectl command:

kubectl get all -A

This command will display all the resources in all namespaces in your cluster, providing a quick overview of the cluster’s status.

Now, let’s move on to Helm. I’ve set up a directory named wordpress with a templates sub-directory. Here’s how the directory structure is organized:

wordpress/
├── templates/
│   └── ingress.yaml
├── Chart.yaml
└── values.yaml

In this structure, templates contains our Kubernetes resource definitions, in this case, ingress.yaml for managing external access to our services. Chart.yaml and values.yaml are key files in defining our Helm chart. Chart.yaml is straightforward; it establishes a dependency on the bitnami/wordpress chart, which is the basis for our deployment:

apiVersion: v2
name: wordpress
description: My WordPress deployment
version: 0.1.0
appVersion: 6.1.1
dependencies:
  - name: wordpress
    version: 15.2.48
    repository: https://charts.bitnami.com/bitnami

In this file, we specify basic information about our chart and declare that it depends on a specific version of the Bitnami WordPress chart, effectively leveraging an existing, tested solution for our deployment.

In the values.yaml file, we modify several default settings:

service:
  type: ClusterIP
  ports:
    http: 80

wordpress:
  wordpressUsername: admin
  wordpressPassword: "12345678"
  wordpressEmail: admin@example.com
  wordpressBlogName: My Blog

Firstly, let’s discuss the critical configurations. I’ve set service.type to ClusterIP, which is used for internal network communication within the Kubernetes cluster. This setting is crucial for the Ingress configuration we’ll introduce shortly, allowing local connectivity through HTTP port 80.

Next, we establish default WordPress credentials. In production environments, it’s essential to use Kubernetes Secrets or other secret managers like Hashicorp Vault for security. However, for this demonstration, the credentials are in plain text for simplicity. Remember, this is just an example and should not be replicated in a real-world scenario.

For more insights into the parameters that can be customized in the Bitnami WordPress chart, I recommend reviewing the Bitnami official documentation. This resource provides a comprehensive guide on various configuration options to tailor your WordPress deployment to your specific needs.

In the templates/ingress.yaml file, we start with the default configuration suggested in the k3d documentation and modify it for our WordPress setup:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wordpress
  annotations:
    ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: wordpress
            port:
              number: 80

This configuration defines an Ingress resource, which is essential for directing HTTP traffic to our WordPress service within the Kubernetes cluster.

Next, navigate to the WordPress directory (cd wordpress) and prepare the dependencies for our chart:

helm dependency build

This command builds the charts/ directory, which includes dependencies for our WordPress chart, specifically the bitnami/wordpress dependency.

Now, we’re ready to install the chart:

helm install wordpress . -f values.yaml

This Helm command installs the WordPress chart in our cluster, using the configurations specified in values.yaml.

After initiating the installation, allow a few minutes for the pods to become operational. To effectively monitor the deployment process, use the command watch kubectl get all -A. This command continuously updates and displays the status of all resources in all namespaces in your cluster, giving you a live overview of your deployment’s progress.

Once the deployment is complete, you can access your new WordPress site at localhost:8081 in your browser. To log in, navigate to localhost:8081/admin and use the WordPress credentials you set earlier. This will give you a first-hand look at your newly deployed WordPress site.

To conveniently manage your cluster, you can utilize the following commands to start and stop it:

k3d cluster stop mycluster
k3d cluster start mycluster

These commands allow you to easily pause and resume your Kubernetes cluster, conserving resources when the cluster is not in use.

In just a few minutes, you can progress from having no setup at all to running a fully-functional WordPress site on a Kubernetes cluster on your local machine.

I hope you found this guide informative and enjoyable. Thank you for reading!