DigitalOcean DOKS is production-grade, but at ~$24+/month minimum, it's expensive for learning and experimentation. Sometimes you want a personal Kubernetes cluster where you can break things, try experimental configurations, and learn without worrying about costs.
Hetzner Cloud offers the most cost-effective path: real cloud servers at ~$5/month for a functional K3s cluster. K3s is a lightweight Kubernetes distribution that runs on smaller instances while remaining fully Kubernetes-compatible. Your kubectl commands, Helm charts, and Dapr configurations work identically.
Before diving into setup, understand why this combination works for budget-conscious learning.
Hetzner's CPX11 instances (2 vCPU, 2GB RAM) cost approximately $5.59/month (EUR 4.99). A minimal K3s cluster (1 master + 2 workers) runs around $17/month, or a single-node setup for learning costs under $6/month.
K3s is Kubernetes, stripped down to essentials:
K3s achieves this by:
The key insight: K3s is a certified Kubernetes distribution. Your kubectl commands, Helm charts, and YAML manifests work exactly the same. You're learning real Kubernetes, not a simulation.
Before starting, verify you have:
If you don't have an SSH key:
Output:
Accept defaults. This creates ~/.ssh/id_rsa (private) and ~/.ssh/id_rsa.pub (public).
Hetzner is a German cloud provider known for competitive pricing and reliable infrastructure.
Note: Hetzner's verification process may take 24-48 hours. They manually review accounts to prevent abuse. Plan ahead if you need the cluster immediately.
After verification:
The hetzner-k3s CLI needs an API token to provision resources:
Security warning: This token has full access to create and destroy resources. Store it securely.
Add to your shell profile (~/.zshrc or ~/.bashrc) for persistence:
The hetzner-k3s CLI automates K3s cluster provisioning on Hetzner Cloud. It handles server creation, K3s installation, and kubeconfig generation.
If you have Go installed:
Output:
Verify installation:
Output:
If you don't have Go, download the binary directly:
macOS (Apple Silicon):
macOS (Intel):
Linux (AMD64):
Verify:
The hetzner-k3s CLI uses a YAML configuration file to define your cluster. Create a file named cluster.yaml:
For a learning lab, cpx11 is sufficient. Your Task API and supporting services fit comfortably in 2GB per node.
Choose the location closest to you for lower latency.
With configuration ready, provision your cluster:
Output:
This process takes 3-5 minutes. The CLI:
Set the KUBECONFIG environment variable to use your new cluster:
Verify connectivity:
Output:
All nodes show Ready status. Your K3s cluster is operational.
Check that system pods are running:
Output:
K3s includes:
When you create LoadBalancer services on Hetzner, the cluster needs the Hetzner Cloud Controller Manager (CCM) to provision Hetzner Load Balancers automatically.
The hetzner-k3s CLI can install CCM automatically. Add to your cluster.yaml:
If you already created your cluster, install CCM manually:
Output:
With CCM installed, creating a type: LoadBalancer service automatically provisions a Hetzner Load Balancer (~$6/month additional).
Verify your cluster works by deploying a simple application:
Output:
Check the deployment:
Output:
Access nginx through any node's public IP:
Output:
Clean up the test:
With the configuration in this chapter:
For a minimal single-node learning cluster:
This costs ~$5.59/month. K3s can run workloads on the control plane node.
When to choose Hetzner K3s:
When to choose DOKS:
When you're done experimenting, destroy the cluster to stop charges:
Output:
Important: This permanently destroys all servers and data. Export any important configurations first.
Now that you have a personal cloud lab, explore K3s and Hetzner further with your AI companion.
What you're learning: Understanding K3s architecture helps you make informed decisions about when lightweight Kubernetes is appropriate versus when you need full enterprise features.
What you're learning: Cloud pricing is complex. Understanding all cost components helps you budget accurately and choose providers based on your actual workload patterns.
What you're learning: Skill portability is the goal. Understanding what's K3s-specific versus universal Kubernetes ensures your learning applies to any cluster.
Hetzner servers have public IPs by default. Your cluster is internet-accessible. Before deploying sensitive workloads, implement network policies, firewall rules, and authentication. Never expose sensitive services without TLS and proper access controls.
You built a multi-cloud-deployer skill in an earlier Chapter. Test and improve it based on what you learned about Hetzner and K3s.
Does your skill produce valid cluster.yaml? Does it explain K3s versus full Kubernetes tradeoffs?
Ask yourself:
If you found gaps: