Category: PaaS and containers
Kubernetes on Hetzner, set up and run for production
A cluster on Hetzner with the control plane the provider does not give you, built as code, with backups, GitOps and version upgrades that someone does for you.
- Where it runs
- In your account, in your name
- Backups
- With tested restores
- Updates
- Planned and documented
In short
Kubernetes on Hetzner is a Kubernetes cluster built on Hetzner Cloud servers, as Hetzner does not offer managed Kubernetes. We set up the cluster with k3s, Talos or kubeadm, integrate it with Hetzner load balancers, private network and volumes, configure Velero backups and GitOps deployments, and take care of upgrades. It is a European and cheaper alternative to EKS or GKE.
What changes when there is no managed Kubernetes?
On EKS, GKE or AKS the provider maintains the control plane: the API, etcd and upgrades of the core components. On Hetzner that service does not exist, so the control plane is just another server that someone has to set up, back up and upgrade. That is the part we take charge of:
Control plane
Three nodes with etcd, regular etcd backups and certificates that renew themselves.
Hetzner integration
CCM for load balancers and nodes; CSI for volumes; location labels on every node.
Network
Private network between nodes, a CNI with network policies and the provider’s firewalls.
GitOps
Argo CD or Flux: what is in the cluster is what is in the repository.
Backups
Velero with the manifests and the volumes, to Object Storage.
Observability
Metrics, logs and alerts for the cluster and the applications.
Which distribution do we choose?
| Option | When we use it | What you need to know |
|---|---|---|
| k3s | Small or medium teams that want something lightweight and easy to maintain | Single binary; embedded etcd in high availability with three servers |
| Talos Linux | When node security matters: immutable system, no SSH | Managed only through its API; it takes some getting used to |
| kubeadm | When you want unmodified Kubernetes and full control | More pieces to maintain by hand |
| Cluster API with the Hetzner provider | Several clusters, or clusters that are created and destroyed often | More complex to get started, more convenient at scale |
In every case, the nodes talk to each other over the Hetzner private network, incoming traffic arrives through a Hetzner Load Balancer created by the CCM itself and persistent volumes are requested from the CSI driver.
Which problems do we find in Hetzner clusters?
- A single control plane node: if that server goes down or etcd gets corrupted, the cluster is left without a brain.
- No etcd backup: the contents of the volumes are backed up, but not the state of the cluster.
- Volumes that do not move: a pod with a volume cannot start on a node in another location.
- API exposed to the internet: the API port open to anyone, with no firewall.
- Unsupported version: Kubernetes releases minor versions frequently and the cluster falls behind.
- Cluster built by hand: nobody knows how to recreate it because it is not in code.
How do we handle backups, upgrades and security?
We back up etcd every few hours outside the cluster and, with Velero, the manifests and volumes to Hetzner Object Storage or another provider’s. We regularly restore into a test cluster to confirm that the applications start with their data. For important databases we prefer to keep them off the cluster volumes or with their own backup system, as we explain in managed PostgreSQL.
Kubernetes upgrades go one minor version at a time, first the control plane and then node by node, draining each one beforehand. Before that we review the APIs that are going away. For security we apply Kubernetes hardening: network policies, pod admission, least-privilege RBAC and secrets kept out of the repository.
How do we migrate from EKS, GKE or AKS?
First we take an inventory of what depends on the provider: load balancers, storage classes, IAM identities, secrets and managed databases. We set up the Hetzner cluster in parallel, translate those dependencies, deploy through GitOps and move traffic service by service with DNS. We calculate the savings beforehand with your real bill; we explain more in cloud migrations and costs. If you would rather not have your own control plane, the comparison table on managed Kubernetes compares a self-managed cluster like this one with the managed Kubernetes offerings.
Using another provider? What we do on EKS, GKE, AKS and the rest is in managed Kubernetes.
Where do we set it up?
In your account, with the provider you already use or the one that fits best. If the data has to stay in the EU, Hetzner and OVHcloud are the European options.
Providers we set it up on
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Own server
| Provider | How we set it up | Things to bear in mind |
|---|---|---|
| Hetzner | Control plane and nodes on cloud servers, set up by us. Hetzner Load Balancers, Networks, Volumes and Firewalls integrated with the official CCM and CSI. | No managed Kubernetes: etcd, versions and control plane high availability are our responsibility. |
| AWS | EKS, with managed nodes or Karpenter, AWS load balancers and EBS volumes. | AWS provides the control plane; deep integration with IAM. More expensive, especially in egress traffic. |
| Google Cloud | GKE in Standard or Autopilot mode. | Very mature; cluster upgrades can be automatic. |
| Azure | AKS with node pools and Azure Disk or Azure Files for volumes. | A good fit if identity already runs through Microsoft Entra ID. |
| DigitalOcean | DOKS, with DigitalOcean load balancers and volumes. | Managed and simple; fewer networking options than the big providers. |
| OVH | OVHcloud Managed Kubernetes Service. | |
| Own server | k3s or Talos on your servers or in Proxmox virtual machines, with MetalLB or your own load balancer. | No provider volumes: persistent storage has to be solved separately. |
What is included
- Kubernetes cluster in your Hetzner account, defined as code (Terraform or OpenTofu) in your repository.
- Distribution chosen to suit the case: k3s, Talos Linux, kubeadm or Cluster API.
- Hetzner cloud controller for load balancers and nodes, and CSI driver for volumes.
- Private network between nodes, Hetzner firewalls and the cluster API not exposed to the whole internet.
- Ingress, automatic certificates and external DNS.
- Backups of the cluster and volumes with Velero to Object Storage, with a test restore.
- GitOps deployments with Argo CD or Flux.
- Version upgrades of Kubernetes and of the node operating system, one minor version at a time.
Frequently asked questions
Is it safe to use k3s on Hetzner for production?
Yes, if it is set up as production: three control plane nodes, etcd with backups, a private network, firewalls and up-to-date versions. k3s is certified Kubernetes; what makes it fragile is not k3s, but a single-node cluster with no backups.
How much do we save compared with EKS or GKE?
It depends on the load, but Hetzner servers and traffic usually work out considerably cheaper. In return, the control plane is not maintained by the provider, and someone has to do that work. We make the comparison with your numbers before deciding, without list-price figures.
How do you migrate from EKS to Hetzner?
We set up the new cluster in parallel, adapt whatever depended on AWS (load balancers, volumes, IAM, secrets), restore the applications with Velero or deploy them through GitOps, and switch DNS service by service. Managed databases such as RDS are migrated separately, with replication.
What happens if a Hetzner data centre goes down?
If the cluster is spread across several locations in the same network zone, it keeps running on the remaining nodes. Hetzner volumes, on the other hand, live in a single location: critical data goes with application-level replication or with backups that can be restored in another location.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Official documentation consulted
The technical details on this page are based on:
- Hetzner Cloud: Kubernetes Cloud Controller Manager (official repository)
- Hetzner Cloud: Container Storage Interface driver (official repository)
Reviewed on