Hetzner
- Migrasi ke Hetzner terutama dilakukan untuk penghematan biaya. Harga Hetzner kompetitif secara global.
- Hetzner menyediakan virtual machine dan bare metal machine; fiturnya lebih terbatas dibanding AWS, tetapi dikompensasi oleh harganya.
- Setelah pindah ke Hetzner, biaya infrastruktur berkurang lebih dari 75%.
Kubernetes on Hetzner
Kubernetes yang dikelola sendiri
- Kubernetes dijalankan di DigitalOcean, dan di Hetzner juga dijalankan dengan pendekatan self-managing.
- Hetzner tidak menyediakan managed Kubernetes control plane, sehingga harus dikelola langsung.
- Node dikelola dan dikonfigurasi menggunakan Terraform dan Puppet.
Peran node
- Aturan penamaan node digunakan untuk menjaga peran di dalam cluster tetap sederhana:
control-plane,worker,database. - Menambahkan peran itu mudah, tetapi dapat mengurangi efisiensi penggunaan resource.
Pembangunan node
- Cluster di-bootstrap menggunakan Terraform.
- Hetzner menyediakan managed firewall dan networking, yang mudah dikonfigurasi dengan Terraform.
- Server dikelola sepenuhnya dengan Terraform, dan module per peran dibuat agar penambahan server menjadi sederhana.
Networking
- Koneksi administrasi ke node dilakukan menggunakan Tailscale VPN.
- Tailscale menyediakan NAT hole punching sehingga koneksi tetap aman meski port ditutup.
- Port diblokir menggunakan managed firewall dari Hetzner dan UFW di Ubuntu.
- Calico digunakan untuk mengonfigurasi container networking interface.
Storage
- Hetzner menyediakan nVME SSD dan block storage berbasis SSD.
- Volume Hetzner tidak memiliki fitur snapshot, sehingga backup data harus dilakukan secara manual.
- Pada node database, Local Persistence Volume Static Provisioner digunakan untuk melakukan pra-provisioning volume lokal.
Backup
- Hetzner tidak menyediakan backup volume, tetapi menyediakan backup untuk seluruh server.
- Namespace dan PVC dibackup menggunakan Velero dari VMware.
- Untuk Postgres, digunakan pgBackRest.
Fitur tambahan
- SealedSecrets digunakan untuk mengelola secret.
- Node Exporter, Prometheus, Grafana, dan Loki digunakan untuk memantau cluster.
- Alertmanager digunakan untuk integrasi notifikasi dengan Slack.
Pemikiran tentang menjalankan Kubernetes di Hetzner
- Migrasi ke Hetzner memakan waktu sekitar 1 minggu, dengan tambahan 4 minggu untuk pengujian dan tuning.
- Harga Hetzner masuk akal, dan diyakini akan tetap lebih rendah dibanding penyedia lain.
- Ada keterbatasan terkait masalah kualitas IP dan layanan pelanggan Hetzner.
- Hetzner cepat meluncurkan fitur baru, tetapi juga dapat cepat menghentikan layanan yang kurang menguntungkan.
- Lokasi data center di Eropa Tengah berada di Falkenstein dan Nuremberg di Jerman, serta Helsinki di Finlandia.
Ringkasan
- Transisi ini berjalan lancar, memangkas biaya infrastruktur lebih dari 75% dan menggandakan resource komputasi cluster.
- Hetzner adalah pilihan yang sangat menguntungkan jika perlu menekan biaya.
- Controller open source Hetzner memudahkan pengelolaan load balancer dan pemasangan volume persisten secara berkelanjutan.
1 komentar
Pendapat di Hacker News
Selama beberapa tahun, kami telah menyediakan klaster Kubernetes kepada pelanggan dengan server dedicated dari Hetzner, dan performanya memang sangat baik; biasanya waktu request berkurang sekitar separuh
Karena hardwarenya murah, kami juga bisa menyediakan waktu engineering DevOps khusus untuk setiap pelanggan, tetapi ada beberapa prasyarat. Klaster staging untuk menguji update pada dasarnya wajib, dan tidak ada yang mau mendorong update produksi pada hari Minggu hanya bermodal intuisi. Replikasi di level aplikasi adalah yang paling penting, lalu replikasi di level blok; kami menggunakan OpenEBS/Mayastor. Setelah mencoba beberapa operator Postgres, saat ini kami menganggap StackGres yang paling baik
Playbook Ansible adalah aset; jika disusun rapi dan diberi komentar untuk layanan tertentu, nantinya akan lebih mudah men-deploy layanan yang sama di tempat lain. Jika memungkinkan, saya merekomendasikan jaringan 10G dedicated untuk koneksi antarpeladen. 1G tidak cukup ketika traffic produksi, image pull, dan traffic antarlayanan digabungkan, dan latensinya 10 kali lebih baik dibanding komunikasi internal availability zone seperti di AWS
Jika membutuhkan redundansi jaringan, buat 1G vSwitch (VLAN) internal pada port 1G, beri setiap server IP loopback, lalu distribusikan route dengan BGP (bird). Klaster MinIO tidak terlalu sulit jika dijalankan sesuai praktik standar lewat operator, dan menyediakan object storage lokal dengan bandwidth tinggi dan latensi rendah. Investasi awal membutuhkan sekitar 2–4 bulan waktu engineering berpengalaman tanpa gangguan, dan pekerjaan pendukung yang merepotkan seperti load balancing HTTP masih bisa dialihkan ke penyedia cloud seperti CloudFlare
Di dokumentasi publik ada opsi uplink 10G, tetapi itu untuk jaringan eksternal, dan batas 20TB tampaknya cukup ketat. Jika ini I/O internal klaster, 20TB bisa dengan mudah menjadi masalah
Saya bekerja di perusahaan itu, dan kami membuat platform yang menyediakan klaster siap produksi dalam hitungan menit
Kalau perusahaan konsultan, mereka tentu ingin menjual pekerjaan itu, tetapi dari sisi pelanggan, kecuali biaya AWS bulanan diperkirakan sekitar 10 ribu dolar, ini sama sekali tidak terlihat bernilai. Saya teringat xkcd: https://xkcd.com/1319/
Saya pernah mengoperasikan klaster Kubernetes di server dedicated Hetzner, dan juga pernah menangani layanan yang sepenuhnya atau sangat terkelola seperti Aurora, S3, dan ECS Fargate
Berdasarkan pengalaman, tagihan cloud Hetzner kadang bisa turun hingga sekitar 20% dibanding AWS yang setara, tetapi keunggulan biaya itu datang dengan trade-off besar
Di Kubernetes Hetzner, saya mengelola klaster Ceph berbasis penyimpanan NVMe, operator MariaDB, Cilium untuk networking, dan ArgoCD untuk deployment Helm chart. Update klaster Kubernetes juga harus ditangani sendiri, dan pernah satu kali mengalami kegagalan seluruh klaster. Saya menemukan beberapa bug baik di Kubernetes maupun Ceph, banyak di antaranya tercatat di issue GitHub dan tracker Ceph. Daftar pekerjaan yang harus dikelola dan dipantau tidak ada habisnya, dan tergantung jumlah workload serta kompleksitas lingkungan, mempertahankan konfigurasi seperti ini bisa menjadi pekerjaan penuh waktu bagi tim DevOps
Sebaliknya, memakai AWS atau penyedia cloud besar lain memungkinkan konfigurasi yang jauh lebih minim sentuhan. Dengan layanan terkelola, upaya pemeliharaan berkurang besar sehingga beban operasional tim juga turun. Pada akhirnya, AWS sangat mengurangi beban kerja DevOps, sedangkan Hetzner sangat menurunkan tagihan cloud. Mana yang lebih hemat biaya memerlukan analisis total biaya kepemilikan (TCO), dan meski Hetzner tampak murah di awal, tambahan waktu DevOps bisa mengimbangi penghematannya
Sebagai contoh, jika membandingkan konfigurasi 2 vCPU, 4GB dengan konfigurasi AWS yang mirip, AWS jauh lebih mahal; saya ingin melihat analisis biayanya. Ada juga alat untuk mengurangi beban operasional: https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner
Mencari akar masalahnya pun tidak mudah, dan di internet ada banyak perintah seperti mantra yang diperlukan untuk pemulihan, tetapi saya akhirnya menghapus semuanya dan membuat ulang klaster. Setelah itu saya melakukannya setiap beberapa minggu. Operator Kubernetes sungguhan mungkin punya upgrade sertifikat otomatis dan berbagai alat lain, tetapi kalau perusahaan, rasanya harus membayar operator seperti itu
Saya tahu ada tempat yang memakainya, tetapi dibanding sistem matang seperti Lustre atau GPFS, ini menjadi pemborosan waktu yang luar biasa. Lebih baik mengekspor beberapa filesystem kecil lewat NFS dan menjamin replikasi level blok. Filesystem dengan satu address space memang nyaman, tetapi sering kali biaya manajemen untuk membuatnya stabil pada skala besar tidak sepadan. Seperti sharding database, filesystem juga bisa di-shard, dan di Kubernetes cukup mudah menambahkan logika pemetaan agar storage yang tepat terpasang pada image yang tepat
Beban DevOps bisa jauh berkurang sekaligus tetap mendapatkan performa dan fleksibilitas bare metal. Ini hibrida yang sangat baik antara layanan mahal yang sepenuhnya terkelola dan membangun sepenuhnya sendiri. Biayanya lumayan, jadi mungkin bukan pilihan bagus untuk startup, tetapi untuk klaster dengan 72GB RAM atau 36 CPU ke atas, kira-kira sekitar 9 node ukuran menengah, sesuatu seperti OpenShift jelas layak dipertimbangkan
Masalah bahwa volume Hetzner terlalu lambat untuk database produksi ternyata bisa diatasi dengan cukup mudah. Cukup gunakan mesin bare metal Hetzner yang sangat murah sebagai node
Mesin dengan penyimpanan NVMe punya performa database yang sangat baik dan sering kali RAM-nya juga lega. Alih-alih menjalankan database di Kubernetes, bahkan bisa lebih baik menyiapkan setidaknya dua mesin bare metal yang tangguh untuk konfigurasi master-replica. Kalau konfigurasi terasa merepotkan, bisa memakai paket modern seperti Pigsty: https://pigsty.cc/
Bisa dengan mengikat pod database ke node tertentu dan memakai LocalPathProvisioner, atau memakai solusi terdistribusi seperti JuiceFS atau OpenEBS
Panduan yang saya tulis untuk pelanggan ada di sini: https://syself.com/docs/hetzner/apalla/how-to-guides/storage/local-storage-in-baremetal
Saya sudah memakai Hetzner dengan puas selama lebih dari 10 tahun; dulu memakai server dedicated di data center Jerman, lalu pindah ke Cloud US VM untuk mengurangi latensi AS
Agak mengecewakan bahwa trafik gratis 20 TB yang dulu lapang baru-baru ini dikurangi menjadi 3 TB dan tambahan tiap TB menjadi €1,19, tetapi tetap terlihat jauh lebih hemat biaya dibanding penyedia cloud AS lain yang saya evaluasi
Saya tidak akan memilih Kubernetes kalau tidak perlu, tetapi saya berhasil memindahkan deployment SSH/Docker Compose lama ke GitHub Actions dan kamal-deploy.org. Konfigurasinya mudah dan tool UX untuk memantau aplikasi yang dideploy secara remote juga bagus: https://servicestack.net/posts/kamal-deployments
Data center Jerman masih menyediakan bandwidth 20 TB: https://www.hetzner.com/cloud/
Namun di AS, untuk harga yang sama, jumlahnya lebih kecil lebih dari satu digit
Dulu saya memperbaiki mobil sendiri karena ingin berhemat dan juga menyenangkan, tetapi ternyata lebih rumit dari yang saya kira, dan seiring waktu banyak bagian rusak atau patah di sana-sini
Saya menghabiskan banyak waktu untuk “memperbaiki ulang”, dan selama beberapa tahun mungkin menghabiskan ribuan dolar untuk perkakas. Ada juga biaya mengganti perkakas murah yang patah atau cepat berkarat, dan mobil sering kali berada di atas jack stand. Meski begitu saya mendapat banyak pelajaran bagus, dan pelajaran terbesar adalah: ada hal-hal yang tidak layak dikerjakan sendiri. Kalau itu menyangkut mata pencaharian, lebih baik serahkan ke mekanik atau sewa mobil lewat leasing
Bahkan pekerjaan sederhana seperti ganti oli pun tidak terlalu layak dikerjakan sendiri. Harus membeli alat seperti wadah oli bekas, kunci filter, corong, creeper board untuk perawatan, meluangkan waktu, mencari pakaian kerja yang boleh kotor, pergi ke toko membeli oli dan filter baru, pulang untuk menggantinya, lalu pada hari itu atau hari lain pergi ke toko yang menerima oli bekas. Sebaliknya, di bengkel Anda membayar sekitar 15 dolar lebih mahal dari biaya oli dan filter, dan selesai dalam 20 menit
Kubernetes itu satu mobil utuh, dan mobilnya pun rumit. Kalau bukan untuk bersenang-senang, benar-benar tidak layak memeliharanya sendiri
Imbalannya cukup bagus dan itu keterampilan yang layak dipelajari. Tetangga punya lift mobil, jadi itu jelas membantu
Intinya adalah menemukan keseimbangan antara pekerjaan yang dikerjakan sendiri dan yang di-outsource, dan itu tidak semudah atau sebersih yang digambarkan di sini
Dari sudut pandang konsultan yang sering terlibat dengan Kubernetes, sebaiknya amankan jalur bantuan awal dan berkelanjutan, tetapi juga pastikan ada orang internal yang cukup berminat untuk ikut belajar
Konsultan dan spesialis bisa membantu menghindari keputusan buruk di awal dan mengurangi berbulan-bulan membenturkan kepala ke tembok. Saat Anda juga harus fokus pada bisnis inti, tidak mudah mempelajari sudut-sudut gelap dan jebakan umum suatu teknologi atau ekosistem dalam waktu yang masuk akal. Terima bantuan, tetapi pelajari juga cara menangkap ikan dan menyalakan api
Artikel yang menarik, tetapi rasanya kurang ada penjelasan tentang cluster dan workload yang berjalan di atasnya
Saya penasaran ada berapa node, seberapa besar trafik yang diterima, serta apa kebutuhan uptime dan latensinya. Dan nominal penghematan absolut juga penting. Penghematan 75% dari 100 ribu dolar per bulan dan 75% dari 100 dolar per bulan itu benar-benar berbeda
Menurut saya, 100 ribu dolar per bulan adalah titik baliknya. Itu 1,2 juta dolar per tahun
Untuk mendukung deployment bare metal yang canggih dengan benar, dibutuhkan sekitar 400 ribu dolar per tahun untuk gaji engineer, dan sekitar 100 ribu dolar per tahun untuk komitmen data center, depresiasi hardware, serta bandwidth. Orang seperti ini biasanya, sambil mengerjakan hal tersebut, juga memberi nilai besar pada bagian lain bisnis, sehingga biaya sebenarnya bisa lebih rendah. Maka Anda menghemat 700 ribu dolar per tahun, itu bagus sekali, dan semakin besar pengeluaran cloud ekuivalennya, manfaatnya menjadi jauh lebih besar
Lebih dari 10 tahun lalu, saat bekerja di web hosting, kami sering mem-blackhole IP Hetzner karena perilaku buruk
Penyedia VM murah lainnya juga sama, dan itu semata-mata karena perilaku, bukan karena basis data geografis. Ada alasan kenapa harganya murah
Saya suka fitur produknya, tetapi reputasi IP tier gratisnya mengerikan, dan email hampir tidak diterima terutama di Hotmail atau Yahoo. Layanan hosting gratis dibanjiri spammer dan penipu; layanan murah juga mirip, hanya tingkatnya lebih rendah. Semakin mahal harganya, semakin jarang dipakai untuk penipuan dan spam
AWS, Google, DigitalOcean, Linode, Contabo, dan lainnya juga banyak menjadi host untuk brute force login dan pemindaian kerentanan umum
Saya bekerja di perusahaan konsultan yang membantu perusahaan membangun dan mengamankan infrastruktur, dan kami punya banyak klien yang menjalankan Kubernetes di penyedia murah seperti Hetzner, penyedia regional kelas menengah, serta tiga cloud teratas seperti AWS/GCP/Azure
Ada juga perusahaan pemerintah, keuangan, dan kesehatan yang tidak bisa atau tidak ingin berjalan di public cloud, sehingga biasanya di-host on-premise
Jika Hetzner mengalami isu atau cacat sebulan sekali, penyedia kelas menengah kira-kira sekali setiap 2–3 bulan, dan tempat seperti AWS kira-kira sekali setiap 5–6 bulan. Namun, harga juga bergerak mirip dengan pengamatan itu, jadi perlu dipertimbangkan dengan cermat per kasus apakah menambahkan perangkat tambahan, backup, dan skenario kegagalan merupakan transaksi yang lebih baik
Keuntungan besar memakai layanan hosting dasar adalah prediktabilitas harga yang jauh lebih tinggi. Anda tinggal membayar biaya perangkat dan melakukan scaling sesuai kebutuhan. Jika terikat pada layanan tambahan dari penyedia seperti AWS, Anda bisa mendapat tagihan besar yang tak terduga, dan jauh lebih sulit untuk keluar. Jika perusahaan kecil, sebaiknya jangan tergoda solusi mudah di awal atau “kredit gratis” lalu membuat keputusan rabun dekat yang mengancam kelangsungan jangka panjang
Tidak ada jawaban benar di sini, hanya kompromi
Saya belum pernah memakainya langsung, tetapi https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner tampak sebagai cara yang bagus untuk menyiapkan dan mengelola Kubernetes di Hetzner
Saat ini saya memakai tier gratis Oracle, tetapi terus mempertimbangkan untuk pindah ke ini agar bisa lepas dari Oracle
Berjalan cukup baik. Saya juga menjadwalkan mesin reboot setiap Minggu untuk update keamanan otomatis di SuSE MicroOS. Saya juga pernah melakukan scaling mesin seiring bertambahnya workload. Semua perubahan yang akan dilakukan Terraform memang harus selalu ditinjau, tetapi jika dilakukan begitu, cukup aman
Satu-satunya kekurangan adalah semua node membutuhkan IP publik meskipun berada di balik firewall, dan bagian ini sedang dikerjakan
Dalam semalam cluster sudah berjalan dan bekerja cukup baik. Satu masalah kecil adalah update otomatis tidak berjalan di node arm; saat itu hanya ada satu node yang berjalan, dan karena taint control plane, pod update tidak bisa berjalan sehingga macet
https://github.com/syself/cluster-api-provider-hetzner
Berjalan sangat stabil
Saya penasaran apakah ada ketidaknyamanan spesifik yang membuat Anda ingin pindah
Saya rasa tidak tepat mengatakan bahwa DigitalOcean, seperti penyedia lain, menyediakan managed control plane gratis tetapi biasanya memberi markup 100% pada node managed cluster
Di DigitalOcean, biaya worker node sama dengan Droplet biasa dan tidak ada biaya tambahan. Jadi penawaran DigitalOcean cukup menarik: control plane gratis yang tidak perlu dikhawatirkan, upgrade gratis, serta integrasi tambahan seperti load balancer dan storage. Sulit bagi saya membayangkan alasan untuk tidak memilih ini dibanding mengelolanya sendiri
CPU bersama Hetzner dengan RAM 8GB sekitar 10 dolar, sedangkan yang setara di DigitalOcean 48 dolar
Jika Anda menginginkan pengalaman managed di Hetzner, Anda bisa melihat https://syself.com. Saya karyawan perusahaan tersebut