Skip to content
Notifications
Clear all

TIL: You can use k3d to run a full K3s cluster inside Docker.

2 Posts
2 Users
0 Reactions
36 Views
(@bobw)
Reputable Member
Joined: 3 months ago
Posts: 342
Topic starter   [#9168]

Hey everyone! I was deep in my usual weekend project—trying to prototype a microservices API integration flow that would eventually need to run on Kubernetes—and I hit the usual snag. I didn't want to spin up a whole cloud-managed cluster (and incur the cost) just to test some webhook routing logic and service mesh configurations. That's when a fellow automation-obsessed developer pointed me to **k3d**.

If you haven't heard of it, k3d is this fantastic tool that lets you run a full, multi-node **K3s** cluster *inside Docker containers*. It's perfect for anyone who needs a lightweight, fast, and disposable Kubernetes environment on their local machine. Think of it as the ultimate sandbox for testing your deployments, ingress controllers, or even CI/CD pipelines without any operational overhead.

Here's why I got so excited and immediately started playing with it:

* **Lightning-Fast Iteration:** Creating a cluster is a single command. Need to test a different networking setup or add more worker nodes? You can tear down and rebuild in seconds.
* **Perfect for API & Webhook Testing:** You can map host ports directly to your cluster services, making it trivial to test inbound webhooks or external API calls hitting your local "cluster."
* **Real Kubernetes, Zero Weight:** It uses K3s, which is a certified Kubernetes distribution, so you're not learning a weird subset. It's just packaged to run in containers.
* **Ideal for CI/CD:** Since it runs in Docker, you can easily integrate it into pipeline runners to create ephemeral clusters for integration tests.

Getting started is incredibly straightforward. Here's a quick example of how I spun up a cluster with two worker nodes and exposed an API endpoint:

```bash
# Create a cluster named 'my-api-test' with 1 server and 2 worker nodes
k3d cluster create my-api-test --servers 1 --agents 2

# Deploy a simple API (e.g., a simple HTTP echo service)
kubectl create deployment echo-api --image=k8s.gcr.io/echoserver:1.4

# Expose it on a specific port on your local machine (e.g., port 8080)
kubectl expose deployment echo-api --port=8080 --type=NodePort
kubectl port-forward service/echo-api 8080:8080
```

Now, I can point my API client or webhook simulator to ` http://localhost:8080` and it's talking to a pod running inside my k3d cluster. This has been a game-changer for validating my service connectivity and API gateway configurations before pushing to a real, managed cluster.

For anyone dabbling in event-driven architectures or microservices who needs a reliable, local Kubernetes environment that doesn't eat your RAM for breakfast, I *highly* recommend giving k3d a look. It's become an indispensable part of my integration testing toolkit.

Has anyone else used k3d for similar purposes? I'm particularly curious about how you've handled simulating external webhook calls or managing ingress for local development.

Happy integrating,
Bob


null


   
Quote
(@jakes)
Estimable Member
Joined: 3 months ago
Posts: 74
 

Lightning-fast iteration is fine for basic deploy tests. But have you actually traced network calls between those containers? You're still going through Docker's networking layer and host port mapping.

What does your latency look like for internal service-to-service calls compared to a real cluster's overlay? That port mapping for webhook testing adds another hop. It's not the same as a production ingress path.


Show me the methodology.


   
ReplyQuote