Self-Hosted Kubernetes Murah di Hetzner Cloud: Panduan Lengkap 2026

Tiga tahun lalu saya hampir menyerah menjalankan Kubernetes untuk project klien. Bukan karena teknologinya rumit — tapi karena tagihan AWS EKS yang membengkak sampai $480/bulan untuk cluster yang sebenarnya cuma jalanin tiga microservice kecil. Control plane managed memang gratis, tapi worker node m5.large di us-east-1 plus NAT Gateway plus EBS volume bikin angka di invoice terlihat seperti nomor telepon.

Waktu itu saya iseng memindahkan satu workload identik ke Hetzner Cloud, dan perbedaannya bikin saya kesal sendiri karena tidak dari dulu melakukannya. Cluster dengan tiga node CX32 (4 vCPU, 8GB RAM) di Hetzner cuma $14/bulan total. Bukan $14 per node — $14 untuk seluruh cluster. Performa I/O malah lebih kencang karena Hetzner pakai NVMe lokal, bukan network-attached storage yang di-throttle.

Artikel ini adalah catatan lengkap bagaimana saya membangun dan menjalankan cluster Kubernetes self-hosted di Hetzner untuk produksi. Bukan tutorial hello-world yang selesai di kubectl get pods. Saya akan bahas arsitektur, provisioning otomatis, CCM (Cloud Controller Manager), CSI untuk persistent volume, ingress, backup etcd, sampai monitoring. Semua angka harga per Juli 2026.

1. Kenapa Hetzner, Bukan yang Lain?

Sebelum masuk teknis, penting untuk paham kenapa Hetzner jadi pilihan rasional untuk tim kecil Indonesia. Saya sudah pakai DigitalOcean, Vultr, Linode, dan AWS. Hetzner menang di satu metrik yang paling penting: harga per performa.

Provider	Spec	Harga/bulan	Storage
Hetzner CX32	4 vCPU / 8GB	~$4.7	80GB NVMe
DigitalOcean Basic	4 vCPU / 8GB	$48	160GB SSD
AWS m5.xlarge	4 vCPU / 16GB	~$140	EBS terpisah
Vultr HF	4 vCPU / 8GB	$48	160GB NVMe

Untuk perbandingan VPS yang lebih luas, saya sudah menulis analisis mendalam AWS vs GCP vs DigitalOcean vs Vultr yang bisa jadi konteks tambahan. Tapi untuk Kubernetes spesifik, Hetzner sulit dikalahkan.

Catatan penting soal latensi: Datacenter Hetzner ada di Jerman (Falkenstein, Nuremberg) dan Finlandia (Helsinki), plus yang terbaru di US (Ashburn, Hillsboro) dan Singapore. Untuk user Indonesia, pilih region Singapore atau US-West tergantung lokasi user lo. Latensi Jakarta ke Singapore sekitar 25-35ms, masih sangat layak untuk kebanyakan aplikasi web.

2. K3s, Bukan Kubeadm

Kesalahan terbesar pemula adalah mencoba install Kubernetes "murni" pakai kubeadm di VPS kecil. Itu overkill. kubeadm butuh banyak komponen terpisah (etcd cluster terpisah, control plane terpisah), dan overhead-nya memakan resource yang seharusnya buat aplikasi lo.

Saya pakai K3s — distribusi Kubernetes ringan dari Rancher. K3s mengemas seluruh control plane ke satu binary ~70MB, pakai SQLite atau embedded etcd, dan memangkas semua driver cloud provider yang tidak perlu. Hasilnya: cluster production-ready yang bisa jalan di node 2GB RAM.

Untuk cluster produksi, saya pakai topologi 3 server (control plane) + N agent (worker). Tiga server penting supaya etcd punya quorum — kalau satu node mati, cluster tetap jalan. Ini prinsip yang sama dengan setup GitOps yang saya bahas sebelumnya: redundancy itu bukan kemewahan, itu kebutuhan.

3. Provisioning Otomatis dengan Terraform

Jangan pernah provision node Kubernetes manual lewat web console. Lo akan berakhir dengan snowflake server yang konfigurasinya cuma ada di kepala lo. Saya pakai Terraform dengan provider hetzner/hcloud untuk semua provisioning.

Struktur yang saya pakai: satu module untuk network (private network + firewall), satu module untuk server nodes, satu untuk agent nodes. Semua node masuk ke private network Hetzner supaya traffic antar-node tidak kena biaya bandwidth publik dan lebih aman.

Firewall Hetzner saya set ketat: hanya port 22 (SSH, dibatasi IP tertentu), 6443 (Kubernetes API), dan 80/443 (ingress) yang terbuka ke publik. Sisanya, termasuk port etcd 2379 dan Kubelet 10250, cuma bisa diakses dari private network. Ini hardening dasar yang sering dilewatkan — dan kalau lo serius soal keamanan, baca juga panduan hardening SSH server Ubuntu yang saya tulis, karena prinsipnya sama.

4. Cloud Controller Manager & CSI Driver

Ini bagian yang bikin K3s di Hetzner terasa seperti managed Kubernetes. Hetzner menyediakan hcloud-cloud-controller-manager (CCM) dan hcloud-csi-driver resmi. CCM bikin LoadBalancer service otomatis bikin Hetzner Load Balancer, dan node otomatis ke-label dengan zone/region. CSI driver bikin PersistentVolumeClaim otomatis provision Hetzner Volume.

Tanpa CCM, service type LoadBalancer lo akan stuck di status <pending> selamanya. Tanpa CSI, lo harus manage persistent storage manual pakai hostPath — yang tidak aman dan tidak portable. Keduanya di-install sebagai Helm chart, dan saya jalankan sebagai bagian dari bootstrap cluster.

Yang perlu diingat: Hetzner Volume cuma bisa di-attach ke satu node sekaligus (ReadWriteOnce). Untuk workload yang butuh shared storage (ReadWriteMany), lo perlu solusi lain seperti Longhorn atau NFS. Saya pribadi pakai Longhorn untuk replicated storage — agak lebih berat, tapi kasih redundancy yang tidak dikasih Hetzner Volume bawaan.

5. Ingress: Traefik vs nginx-ingress

K3s datang dengan Traefik sebagai ingress controller default. Untuk kebanyakan kasus, Traefik sudah cukup dan konfigurasi otomatis-nya ramah pemula. Tapi untuk produksi dengan traffic serius, saya ganti ke ingress-nginx karena kontrol yang lebih granular soal rate limiting, custom headers, dan tuning performance.

Saya taruh Hetzner Load Balancer di depan ingress-nginx, dengan proxy protocol diaktifkan supaya IP client asli tidak hilang. SSL saya handle pakai cert-manager dengan Let's Encrypt — sama persis dengan pendekatan yang saya jelaskan di panduan TLS Let's Encrypt self-hosted. Bedanya, di Kubernetes semua sertifikat di-manage otomatis oleh cert-manager, tidak perlu cron certbot manual.

6. Backup etcd — Jangan Sampai Menyesal

Satu-satunya hal yang lebih menyakitkan dari cluster down adalah cluster yang tidak bisa di-restore karena tidak ada backup. etcd adalah otak cluster Kubernetes — semua state (deployment, secret, configmap) tersimpan di sana. Kalau etcd corrupt dan lo tidak punya backup, lo mulai dari nol.

Saya pakai k3s etcd-snapshot yang dijadwalkan otomatis setiap 6 jam, hasilnya di-upload ke S3-compatible storage (Hetzner Object Storage atau Backblaze B2). Retensi saya set 14 hari. Setiap bulan saya lakukan restore drill — benar-benar restore snapshot ke cluster staging untuk memastikan backup-nya valid. Backup yang tidak pernah di-test restore-nya bukan backup, itu harapan.

7. Monitoring: Prometheus + Grafana + Loki

Cluster tanpa monitoring adalah cluster yang lo tidak tahu kondisinya. Saya install kube-prometheus-stack via Helm — ini paket lengkap: Prometheus, Grafana, Alertmanager, node-exporter, dan kube-state-metrics. Untuk log, saya tambah Loki + Promtail supaya bisa query log terpusat.

Alerting saya set untuk hal-hal yang benar-benar actionable: node NotReady, Pod CrashLoopBackOff berulang, disk usage di atas 85%, dan certificate yang mau expired. Jangan alert untuk semua hal — alert fatigue bikin lo mengabaikan notifikasi yang penting. Untuk visualisasi status layanan ke user, saya juga jalankan status page self-hosted dengan Uptime Kuma yang datanya saya ambil dari Prometheus.

8. Rincian Biaya Produksi Nyata

Ini breakdown cluster produksi yang saya jalankan untuk satu klien SaaS (per Juli 2026):

Komponen	Spec	Biaya/bulan
3x server (control plane)	CX22 (2 vCPU/4GB)	~$11
3x agent (worker)	CX32 (4 vCPU/8GB)	~$14
Hetzner Load Balancer	LB11	~$5
3x Volume (50GB)	Persistent storage	~$5
Object Storage (backup)	~20GB	~$1
Total		~$36/bulan

Bandingkan dengan EKS equivalent yang bisa dengan mudah tembus $300-500/bulan setelah dihitung worker node, EBS, NAT Gateway, dan data transfer. Penghematan 85-90% ini nyata, dan saya sudah menjalankannya lebih dari setahun tanpa insiden besar.

9. Kapan Self-Hosted K8s Bukan Pilihan Tepat

Saya tidak akan menjual Kubernetes sebagai solusi untuk semua orang. Jujur saja: kalau tim lo cuma dua orang dan aplikasi lo bisa jalan di satu VPS dengan Docker Compose, Kubernetes adalah beban operasional yang tidak perlu. Saya sudah menulis soal Coolify sebagai alternatif PaaS self-hosted yang jauh lebih sederhana untuk kasus seperti itu.

Kubernetes baru masuk akal kalau: lo punya banyak microservice yang perlu scaling independen, butuh zero-downtime deployment yang serius, atau tim lo sudah familiar dengan konsep K8s. Self-hosted di Hetzner menambah satu layer tanggung jawab — lo yang patch, lo yang upgrade, lo yang jaga etcd. Tapi dengan Terraform + GitOps + monitoring yang benar, overhead itu bisa dikelola bahkan oleh tim kecil.

10. Upgrade Cluster Tanpa Downtime

Salah satu ketakutan terbesar menjalankan Kubernetes self-hosted adalah proses upgrade. Versi Kubernetes rilis tiap beberapa bulan, dan menunda upgrade terlalu lama bikin lo ketinggalan security patch. Kabar baiknya, K3s bikin upgrade relatif tidak menyakitkan kalau lo pakai pendekatan rolling yang benar.

Workflow upgrade yang saya pakai: pertama, upgrade satu server node (control plane) dulu dan pastikan sehat sebelum lanjut. Pakai systemctl stop k3s, swap binary ke versi baru, start lagi, dan tunggu sampai node Ready dan etcd quorum stabil. Ulangi untuk server node lain satu per satu — jangan pernah stop dua server sekaligus karena bisa kehilangan quorum. Setelah semua server di versi baru, baru rolling upgrade agent node dengan kubectl drain dulu supaya Pod pindah graceful, upgrade binary, lalu kubectl uncordon.

Untuk aplikasi, pastikan Pod lo punya PodDisruptionBudget supaya drain tidak mematikan semua replica sekaligus. Dan selalu baca changelog K3s sebelum upgrade major — kadang ada breaking change di versi Kubernetes yang dibawa. Saya biasanya tunggu satu-dua minggu setelah rilis patch sebelum upgrade produksi, biar bug awal ketahuan komunitas dulu. Disiplin upgrade rutin tiap kuartal jauh lebih murah daripada upgrade besar setahun sekali yang penuh kejutan.

Kesimpulan

Self-hosted Kubernetes di Hetzner Cloud adalah salah satu rasio harga-performa terbaik yang bisa lo dapat di 2026. Dengan K3s, provisioning Terraform, CCM/CSI resmi Hetzner, dan monitoring yang proper, lo dapat cluster production-ready dengan biaya seperlima managed Kubernetes di cloud besar. Kuncinya bukan di tools-nya — tapi di disiplin: backup etcd yang teruji, hardening firewall, dan alerting yang actionable. Mulai dari cluster kecil, otomasi sejak hari pertama, dan jangan pernah skip backup drill bulanan.