TL;DR
Kubernetes on Hetzner Cloud isn't a managed service – yet countless teams run production clusters there. The official open-source integrations make this possible: The hcloud-cloud-controller-manager (HCCM) connects the cluster to the Hetzner Cloud and Robot APIs, the CSI driver provides volumes for persistent storage, and Private Networks and Load Balancers complete the cluster architecture. Building on these integrations, the community has developed tools like terraform-hcloud-kube-hetzner, hetzner-k3s, and Talos-based Terraform modules that let you set up a production-ready cluster in just a few steps.
Why Kubernetes? Who uses it and what for?
Kubernetes is an open-source platform that automates the deployment, scaling, and management of containerized applications. Originally developed at Google and released in 2014, it has become the de facto standard for container orchestration. Its core benefits can be summarized in three points:
- Automatic scaling: During traffic spikes, the cluster automatically spins up additional instances and scales them back down when demand decreases. Even data-intensive organizations like CERN use Kubernetes to scale their systems quickly in response to sudden spikes in demand.
- Self-healing: If a container or even an entire node fails, Kubernetes automatically restarts the affected workloads or moves them to other nodes. The application remains available without anyone having to get up in the middle of the night.
- Consistent operations: Whether it's a microservices architecture, a traditional web application, or a CI/CD pipeline, everything uses the same declarative configurations and runs consistently, regardless of the underlying infrastructure.
Kubernetes users are just as diverse: Teams running SaaS applications or microservices that need to handle fluctuating workloads, DevOps teams looking to automate their deployments, and organizations that want to consolidate multiple applications on shared infrastructure and manage them consistently.
A look at the ecosystem shows just how diverse Kubernetes use cases are on Hetzner Cloud. With 5.7k stars, the most popular community project on the topic is, somewhat surprisingly, the guide "Kubernetes clusters for the hobbyist", while tools like hetzner-k3s explicitly promise "production-ready" clusters. From weekend projects to production systems, the ecosystem covers it all.
If you're running a single VM with Docker Compose for a small, static setup, you don't necessarily need Kubernetes. It becomes interesting when availability, scaling, and automation start to matter. And that's exactly when the question arises: How do you set up Kubernetes properly on Hetzner Cloud?
Kubernetes on Hetzner Cloud: Run it yourself without building everything from scratch
Running Kubernetes on Hetzner Cloud is a deliberate choice: full control over your own cluster instead of relying on a managed service. What may sound like a lot of manual work at first is actually supported by a well-developed ecosystem. The GitHub topic "hetzner-cloud" currently lists 383 public repositories – and almost all of the most popular ones are Kubernetes tools. terraform-hcloud-kube-hetzner (3.9k stars) and (3.7k stars) alone have over 7,500 stars combined.
Hetzner's own official open-source integrations provide the foundation: the Cloud Controller Manager, the CSI driver, the Terraform provider and the hcloud CLI. They map Kubernetes resources such as nodes, services, and volumes directly to Hetzner Cloud resources. Let's take a closer look at each component.
The Cloud Controller Manager: The bridge to the API
The (HCCM) connects a Kubernetes cluster to the Hetzner Cloud and Robot APIs. It implements the interfaces defined by Kubernetes in the upstream package k8s.io/cloud-provider – the mechanism that allows each cloud provider to integrate its own logic into a common set of controllers. In HCCM, four controllers handle this work:
- Node Controller: Initializes each Kubernetes node and adds metadata such as the instance type and provider ID. This ID corresponds to the server ID in Hetzner Cloud or Robot, prefixed with hcloud:// or hrobot:// – providing an immutable link between the Kubernetes node and the server.
- Node Lifecycle Controller: Monitors nodes that are no longer "ready", checks whether the associated server still exists or has been shut down, and cleans up node objects whose servers no longer exist.
- Routes Controller: Creates a route in the Private Network for each node, mapping its Pod CIDR to its private IP address. This allows traffic destined for pods on a node to travel directly over the Private Network, without the overhead of an overlay network such as VXLAN.
- Service Controller: Automatically creates and configures a Hetzner Cloud Load Balancer for each Kubernetes Service of type LoadBalancer.
The latest round of optimizations shows just how actively this component is being developed: A shared cache for the node controllers and event-driven route reconciliation instead of periodic reconciliation reduce requests to the Hetzner Cloud API by around 76% during scale-up and by 94% in steady state. The change to the Routes Controller wasn't limited to HCCM. It was also contributed directly to upstream Kubernetes as KEP-5237 – an example of how work on the Hetzner integration benefits the upstream project. You can find all the details in our blog article "How we reduced API requests in the Hetzner Cloud Controller Manager". All improvements are included in HCCM v1.33 and later.
The CSI driver: Persistent storage for stateful workloads
Databases, message queues, monitoring – hardly any production cluster can do without persistent storage. The official csi-driver is a Container Storage Interface driver for Hetzner Cloud that supports ReadWriteOnce volumes in Kubernetes and other container orchestrators.
For users, the process follows standard Kubernetes workflows: You create a PersistentVolumeClaim using the StorageClass hcloud-volumes and assign it to a pod. Kubernetes then automatically provisions a PersistentVolume through the CSI driver. To do this, the driver creates a Hetzner Cloud Volume, attaches it to the appropriate node, and makes the storage available to the pod.
Networking and load balancing: How traffic flows
Two additional Hetzner Cloud products complete the picture:
Private Networks allow you to connect cluster nodes through a private network. How you set up the pod network within the cluster depends on your chosen networking solution. One option is the HCCM Routes Controller, which creates routes that make each node's pod network accessible through its private IP address.
Load Balancers provide the external entry point. The HCCM Service Controller manages them automatically: All you need is a Service of type LoadBalancer in your cluster, and Kubernetes creates and configures the corresponding Hetzner Cloud Load Balancer. In typical setups, it receives traffic from the internet and forwards it over the Private Network to an Ingress Controller such as Traefik running on the worker nodes.
A remarkably active community ecosystem has developed around these official components. The following projects stand out:
(3.9k stars) promises "optimized and maintenance-free Kubernetes on Hetzner Cloud in one command". It combines Terraform with k3s, a lightweight Kubernetes distribution.
(3.7k stars) takes a similar approach as a standalone CLI. According to its own description, it offers the easiest and fastest way to deploy production-ready Kubernetes clusters on Hetzner Cloud, also using k3s.
Talos-based setups take a different approach to the operating system: Talos is a minimal, API-driven OS built exclusively for Kubernetes. In addition to the Terraform module terraform-hcloud-talos (349 stars), the hcloud-k8s Kubernetes module provides an approach used in the official community tutorial for private clusters.
cluster-api-provider-hetzner (1.1k stars) lets you create and manage Kubernetes clusters declaratively on Hetzner Cloud and bare metal servers. The project builds on Kubernetes Cluster API and primarily targets experienced users who want to automate their cluster operations.
Then there are the official Hetzner integrations that run behind the scenes in almost all these setups: the Terraform provider (728 stars), the (1.8k stars) – and, of course, HCCM and the CSI driver themselves. You can find an overview of more Kubernetes projects on Hetzner Cloud in the Kubernetes section of our awesome-hcloud list.
A reference architecture for production environments
What does a production-ready cluster actually look like? The community tutorial "Private Kubernetes cluster via Terraform and Talos" presents an architecture that brings all the components together:
- Three control plane nodes for a highly available control plane (etcd, kube-apiserver, kube-scheduler)
- Worker nodes without public IP addresses, distributed across Placement Groups to ensure the VMs run on different physical hardware
- A Private Network (e.g. 10.21.0.0/16) as the backbone of the cluster
- An egress VM acting as a NAT gateway, allowing private nodes to access the internet and providing SSH access to run kubectl and talosctl
- A Hetzner Load Balancer, managed by Kubernetes, as the entry point for ingress-nginx
- Longhorn for distributed persistent storage and cert-manager for TLS certificates
- Cluster Autoscaler, which provisions additional worker nodes when needed
For automatic scaling on Hetzner Cloud, there is an official cloud provider integration for the Kubernetes Cluster Autoscaler. It allows you to automatically provision additional Cloud Servers as worker nodes when needed. When you no longer need them, the Autoscaler can remove them again. This allows your infrastructure to adapt to the resource requirements of your applications.
For even greater high availability, you can distribute worker nodes and load balancers across multiple locations and add redundant egress VMs. The tutorial explains both options step by step.
Which approach is right for your project?
Choosing the right approach depends less on the size of your cluster than on your specific requirements:
- Get a working cluster up and running quickly: If you want to get started with minimal effort, hetzner-k3s or terraform-hcloud-kube-hetzner are good choices. Both let you deploy a cluster with the official integrations in a short time.
- Infrastructure as Code with maximum hardening: Talos-based Terraform setups are particularly well suited if you want an immutable, fully API-driven operating system and a completely private cluster – as shown in the reference architecture above.
- Full control over every component: If you build your cluster manually or with your own automation tools, you can install HCCM and the CSI driver directly and decide on every detail yourself – from network topology to storage strategy.
- Declarative cluster management: If you want to automate the creation, management, and updating of Kubernetes clusters, the Cluster API Provider Hetzner offers a Kubernetes-native solution for cloud and bare metal environments.
All four approaches share the same foundation: Cloud Controller Manager, CSI driver, Private Networks, and Load Balancers. Once you understand how these components work together, you can make informed decisions about which tools to use – and troubleshoot issues more effectively when something goes wrong.
Conclusion
Kubernetes on Hetzner Cloud combines official open-source integrations with an active community ecosystem. HCCM translates Kubernetes concepts into cloud resources, the CSI driver provides persistent storage, and Private Networks and Load Balancers form the networking foundation. Projects like kube-hetzner, hetzner-k3s, and the Talos modules build on these components to create production-ready clusters in a short time. If you want to explore further, you can find the source code for all these projects on GitHub and over 350 tutorials in the Hetzner Community – from your first cluster to a highly available multi-location architecture.
Engineering
Maximilian Feix
Apprentice, Software Development konsoleH
