Hetzner पर Kubernetes इस्तेमाल करके इंफ्रास्ट्रक्चर लागत में 75% की कमी

 (bilbof.com)
1 पॉइंट द्वारा GN⁺ 2024-12-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Hetzner

  • Hetzner पर माइग्रेशन का मुख्य उद्देश्य लागत कम करना था। Hetzner की कीमतें वैश्विक स्तर पर प्रतिस्पर्धी हैं।
  • Hetzner virtual machines और bare metal machines प्रदान करता है, और AWS की तुलना में सीमित होने के बावजूद कीमत से इसकी भरपाई करता है।
  • Hetzner पर माइग्रेट करने के बाद इंफ्रास्ट्रक्चर लागत में 75% से अधिक की कमी आई।

Kubernetes on Hetzner

Self-managing Kubernetes

  • DigitalOcean पर Kubernetes चलाया गया था, और Hetzner पर भी इसे self-managing तरीके से चलाया गया।
  • Hetzner managed Kubernetes control plane प्रदान नहीं करता, इसलिए इसे सीधे manage करना पड़ता है।
  • Nodes को manage और configure करने के लिए Terraform और Puppet का उपयोग किया गया।

Node roles

  • Cluster के भीतर roles को सरल रखने के लिए node naming convention का उपयोग किया गया: control-plane, worker, database.
  • Roles जोड़ना आसान है, लेकिन इससे resource usage की efficiency कम हो सकती है।

Node provisioning

  • Terraform का उपयोग करके cluster को bootstrap किया गया।
  • Hetzner managed firewall और networking प्रदान करता है, जिन्हें Terraform से आसानी से configure किया जा सकता है।
  • Servers पूरी तरह Terraform से manage किए गए, और role-आधारित modules लिखकर servers जोड़ना आसान बनाया गया।

Networking

  • Nodes के लिए management connections करने हेतु Tailscale VPN का उपयोग किया गया।
  • Tailscale NAT hole punching प्रदान करता है, जिससे ports बंद होने पर भी सुरक्षित रूप से connect किया जा सकता है।
  • Hetzner के managed firewall और Ubuntu के UFW का उपयोग करके ports को block किया गया।
  • Container Network Interface को configure करने के लिए Calico का उपयोग किया गया।

Storage

  • Hetzner nVME SSD और SSD-आधारित block storage प्रदान करता है।
  • Hetzner volumes में snapshot फीचर नहीं है, इसलिए data backups manually करने पड़ते हैं।
  • Database nodes में local volumes को pre-provision करने के लिए Local Persistence Volume Static Provisioner का उपयोग किया गया।

Backups

  • Hetzner volume backups नहीं देता, लेकिन पूरे server के backups प्रदान करता है।
  • Namespaces और PVC का backup लेने के लिए VMware का Velero उपयोग किया गया।
  • Postgres के लिए pgBackRest का उपयोग किया गया।

अतिरिक्त सुविधाएँ

  • Secrets management के लिए SealedSecrets.
  • Cluster monitoring के लिए Node Exporter, Prometheus, Grafana, Loki.
  • Slack के साथ alert integration के लिए Alertmanager.

Hetzner पर Kubernetes चलाने को लेकर विचार

  • Hetzner पर माइग्रेशन में लगभग 1 सप्ताह लगा, और अतिरिक्त testing व tuning में 4 सप्ताह लगे।
  • Hetzner की कीमतें उचित हैं, और विश्वास है कि वे अन्य providers की तुलना में कम बनी रहेंगी।
  • Hetzner में IP quality issues और customer service से जुड़ी कुछ सीमाएँ हैं।
  • Hetzner तेजी से नए features जारी करता है, लेकिन कम लाभ वाले services को जल्दी बंद भी कर सकता है।
  • Central Europe में इसके data center locations जर्मनी के Falkenstein, Nuremberg और फ़िनलैंड के Helsinki में हैं।

सारांश

  • यह बदलाव सुचारु रूप से हुआ, इंफ्रास्ट्रक्चर लागत 75% से अधिक घटी और cluster के compute resources दोगुने हो गए।
  • अगर लागत कम करना प्राथमिकता है, तो Hetzner एक बहुत फायदेमंद विकल्प है।
  • Hetzner के open source controllers load balancer management और persistent volume attachment को आसान बनाते हैं।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-12-02
Hacker News की रायें

  • कई सालों से Hetzner के dedicated servers पर ग्राहकों को Kubernetes clusters दे रहे हैं, और performance सचमुच शानदार है—आम तौर पर request time लगभग आधा हो जाता है
    Hardware सस्ता है, इसलिए हर ग्राहक के लिए dedicated DevOps engineering time भी दिया जा सकता है, लेकिन कुछ शर्तें हैं। Updates test करने के लिए staging cluster लगभग अनिवार्य है, और production updates को रविवार को अंदाज़े से धकेलना कोई नहीं चाहेगा। Application-level replication सबसे ज़रूरी है, उसके बाद block-level replication आता है, और हम OpenEBS/Mayastor इस्तेमाल कर रहे हैं। कई Postgres operators आज़माने के बाद फिलहाल StackGres सबसे बेहतर लगता है
    Ansible playbooks एक asset हैं; अगर किसी खास service के लिए उन्हें अच्छी तरह व्यवस्थित और comment कर दिया जाए, तो बाद में वही service कहीं और फिर deploy करना आसान हो जाता है। संभव हो तो servers को जोड़ने के लिए dedicated 10G network की सलाह है। 1G production traffic, image pulls और service-to-service traffic मिलाकर कम पड़ जाता है, और latency AWS जैसी availability zone के अंदर की communication की तुलना में 10 गुना बेहतर हो जाती है
    अगर network redundancy चाहिए, तो 1G port पर internal use के लिए 1G vSwitch(VLAN) बनाएं, हर server को loopback IP दें, और BGP से routes publish करें (bird)। MinIO cluster को operator के जरिए सही तरीके से चलाया जाए तो यह बहुत मुश्किल नहीं है, और local high-bandwidth, low-latency object storage देता है। शुरुआती निवेश में बिना interruption के अनुभवी engineering time करीब 2–4 महीने चाहिए, और HTTP load balancing जैसे सहायक लेकिन झंझट वाले काम अभी भी CloudFlare जैसे cloud providers को सौंपे जा सकते हैं

    • “Servers को जोड़ने के लिए dedicated 10G network” के लिए क्या Hetzner से अलग से request करनी पड़ती है, यह जानना चाहूंगा
      Public docs में 10G uplink option है, लेकिन वह external network के लिए है, और 20TB limit काफी कड़ी लगती है। अगर यह internal cluster I/O है, तो 20TB आसानी से समस्या बन सकता है
    • 1G vSwitch, loopback IP और BGP(bird) से network redundancy configure करने वाले हिस्से की example configuration साझा कर सकते हैं क्या
    • अगर 2–4 महीने का शुरुआती engineering investment चाहिए, तो https://syself.com भी देखने लायक है
      मैं उसी कंपनी में काम करता हूं, और हमने ऐसा platform बनाया है जो कुछ मिनटों में production-ready cluster देता है
    • बिना interruption के अनुभवी engineering time के 2–4 महीने किसी कंपनी या ग्राहक के लिए कितने मूल्यवान हैं, इसकी तुलना अगले 5 साल तक ज्यादा monthly bills देने से करनी होगी
      Consulting company हो तो वह काम बेचना चाहेगी, लेकिन ग्राहक के नज़रिए से, अगर monthly AWS cost करीब 10,000 डॉलर होने की उम्मीद नहीं है, तो यह बिल्कुल भी worthwhile नहीं लगता। xkcd याद आता है: https://xkcd.com/1319/

  • Hetzner dedicated servers पर Kubernetes cluster चला चुका हूं, और Aurora, S3, ECS Fargate जैसी fully या highly managed services के साथ भी काम किया है
    अनुभव के हिसाब से Hetzner का cloud bill कभी-कभी equivalent AWS के मुकाबले 20% स्तर तक कम हो सकता है, लेकिन उस cost advantage के साथ बड़े trade-offs आते हैं
    Hetzner Kubernetes में NVMe storage पर आधारित Ceph cluster, MariaDB operator, networking के लिए Cilium, और Helm chart deployment के लिए ArgoCD manage किया। Kubernetes cluster updates भी खुद संभालने पड़े, और एक बार पूरा cluster outage भी झेलना पड़ा। Kubernetes और Ceph दोनों में कई bugs मिले, जिनमें से कई GitHub issues और Ceph tracker में दर्ज थे। Manage और monitor करने वाले कामों की सूची खत्म ही नहीं होती थी, और workloads की संख्या व environment complexity के आधार पर ऐसी setup maintain करना DevOps team का full-time काम बन सकता है
    इसके उलट AWS या किसी दूसरे बड़े cloud provider का इस्तेमाल करें तो काफी कम hands-on setup संभव है। Managed services इस्तेमाल करने से maintenance effort बहुत घट जाता है और team का operational burden भी कम होता है। आखिरकार AWS DevOps workload को बहुत कम करता है, और Hetzner cloud bill को बहुत कम करता है। कौन सा विकल्प ज्यादा cost-effective है, इसके लिए Total Cost of Ownership (TCO) analysis चाहिए; Hetzner शुरुआत में सस्ता दिखे, फिर भी extra DevOps time savings को खत्म कर सकता है

    • यह काफी ChatGPT output जैसा दिखता है, और पुराने लेखन में भी “जहां X है, वहीं Y भी Z करता है। Y पहले ही X से overlap करता है” जैसी पंक्तियां बहुत हैं
      उदाहरण के तौर पर 2 vCPU, 4GB configuration और AWS की similar configuration की तुलना करें तो AWS बहुत महंगा है, इसलिए cost analysis देखना चाहूंगा। Operational burden घटाने वाले tool के रूप में https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner भी है
    • Support issues reproduce करने के लिए toy development cluster के अलावा Kubernetes cluster कभी नहीं चलाया, लेकिन एक दिन वह certificate issue से टूट गया
      Root cause पता लगाना भी आसान नहीं था, और online recovery के लिए मंत्र जैसे commands बहुत थे, लेकिन मैंने सब हटाकर cluster फिर से बना दिया। उसके बाद से हर कुछ हफ्तों में ऐसा ही करता हूं। असली Kubernetes operator के पास certificate auto-upgrade और कई दूसरे tools होंगे, लेकिन company हो तो ऐसे operator के लिए पैसे देने पड़ेंगे
    • Ceph चलाना सच में बहुत तकलीफदेह है। यह महंगा, slow और अभी ठीक से ready महसूस नहीं होता
      पता है कि कुछ जगहों पर इसका इस्तेमाल होता है, लेकिन Lustre या GPFS जैसे mature systems से तुलना करें तो यह भारी time waste बन जाता है। बेहतर है कि कई छोटे file systems को NFS से export किया जाए और block-level replication सुनिश्चित किया जाए। Single address space file system सुविधाजनक है, लेकिन बड़े scale पर इसे reliably बनाने की management cost अक्सर worth नहीं होती। Database sharding की तरह file system को भी shard करें, और Kubernetes में सही image के साथ सही storage attach हो, इसके लिए mapping logic आसानी से जोड़ा जा सकता है
    • मोटे तौर पर सहमत हूं, लेकिन यह हैरानी की बात है कि OpenShift जैसे middle-ground solution पर अक्सर विचार नहीं किया जाता
      इससे DevOps burden काफी घटता है, साथ ही bare metal की performance और flexibility दोनों मिलती हैं। Fully managed महंगी services और पूरी तरह self-built setup के बीच यह एक बढ़िया hybrid है। Cost काफी है, इसलिए startups के लिए अच्छा विकल्प नहीं हो सकता, लेकिन 72GB RAM या 36 CPU से ऊपर, यानी लगभग 9 medium-sized nodes वाले cluster के लिए OpenShift जैसी चीज़ पर जरूर विचार करना चाहिए
    • Kubernetes cluster को manually update करना बहुत बड़ा trade-off है। कुछ पैसे बचाने के लिए ऐसा करना, जब तक हालत बहुत मजबूर न हो, कल्पना करना मुश्किल है

  • Hetzner volumes production databases के लिए बहुत धीमे हैं—यह समस्या हैरानी की बात है कि आसानी से हल हो सकती है। बहुत सस्ते Hetzner bare-metal machines को nodes के रूप में इस्तेमाल कर सकते हैं
    NVMe storage वाली machines में database performance शानदार होती है और अक्सर RAM भी भरपूर होती है। Kubernetes में database चलाने के बजाय, master-replica configuration के लिए दो या उससे अधिक मजबूत bare-metal machines रखना बेहतर हो सकता है। अगर setup झंझट लगता है, तो Pigsty जैसे modern package का इस्तेमाल किया जा सकता है: https://pigsty.cc/

    • Kubernetes में local NVMe storage इस्तेमाल करते हुए database चलाने के भी कई विकल्प हैं
      Database pods को किसी specific node पर pin करके LocalPathProvisioner इस्तेमाल करें, या JuiceFS, OpenEBS जैसे distributed solutions इस्तेमाल करें
    • Bare-metal servers के local storage का इस्तेमाल करके अच्छा अनुभव रहा
      ग्राहकों के लिए लिखी गई guide यहां है: https://syself.com/docs/hetzner/apalla/how-to-guides/storage/local-storage-in-baremetal

  • 10 साल से ज्यादा समय से Hetzner को संतोषजनक तरीके से इस्तेमाल कर रहा हूं, और पहले जर्मनी data center के dedicated servers इस्तेमाल करता था, फिर US latency कम करने के लिए Cloud US VM पर चला गया
    हाल में generous 20TB free traffic घटकर 3TB हो गया और extra TB के लिए €1.19 लगने लगा—यह थोड़ा निराशाजनक है, लेकिन जिन दूसरे US cloud providers का मूल्यांकन किया, उनसे यह अब भी काफी बेहतर value-for-money लगता है
    Kubernetes को जरूरी तौर पर नहीं चुनूंगा, लेकिन मौजूदा SSH/Docker Compose deployment को GitHub Actions और kamal-deploy.org पर ले जाकर सफलतापूर्वक इस्तेमाल कर रहा हूं। Setup आसान है और remote deployment apps को monitor करने के लिए UX tools भी अच्छे हैं: https://servicestack.net/posts/kamal-deployments

    • यह US-side issue जैसा लगता है, और शायद peering partner price increase के लिए दबाव डाल रहा हो
      Germany data centers अभी भी 20TB bandwidth देते हैं: https://www.hetzner.com/cloud/
      लेकिन US में उसी price पर bandwidth एक order of magnitude से भी कम है

  • पहले पैसे बचाने और मजे के लिए car maintenance खुद करता था, लेकिन यह उम्मीद से ज्यादा complex था और समय के साथ इधर-उधर चीजें खराब या टूटती रहीं
    “दोबारा ठीक करने” में बहुत समय लगा, और कुछ वर्षों में tools पर शायद हजारों dollars खर्च हुए। सस्ते tools टूट गए या जल्दी rust हो गए तो उन्हें बदलने का खर्च भी था, और car अक्सर stands पर चढ़ी रहती थी। फिर भी बहुत अच्छे lessons मिले, जिनमें सबसे बड़ा lesson यह था कि कुछ काम खुद करने लायक नहीं होते। अगर यह livelihood से जुड़ा काम है, तो mechanic को देना या car lease करना बेहतर है
    Oil change जैसे simple काम भी खुद करने लायक बहुत कम हैं। Oil pan, filter wrench, funnel, maintenance creeper जैसे tools खरीदना, time निकालना, गंदे work clothes ढूंढना, shop जाकर नया oil और filter खरीदना, फिर घर आकर change करना, और उसी दिन या किसी और दिन waste oil लेने वाली shop पर जाना पड़ता है। जबकि workshop में oil और filter की कीमत से करीब 15 dollars ज्यादा देकर 20 मिनट में काम खत्म हो जाता है
    Kubernetes पूरी car है, और वह भी complex car। अगर इसे मजे के लिए नहीं कर रहे हैं, तो इसे खुद maintain करना सच में worth नहीं है

    • पक्का नहीं। Workshop ने brake replacement के लिए 1800 dollars मांगे, लेकिन मैंने parts 300 dollars में खरीदे और पहली बार होने के बावजूद एक दिन में पूरा कर लिया
      यह काफी अच्छा reward है और सीखने लायक skill है। पड़ोसी के पास car lift है, इससे definitely मदद मिली
    • अगर हर काम के लिए AA को बुलाना और हर बार famous workshop जाना budget का बड़ा हिस्सा खा रहा हो, तो बात अलग है
      मुद्दा यह है कि क्या खुद करना है और क्या outsource करना है, इसका balance ढूंढना पड़ता है; यह उतना आसान या साफ-सुथरा नहीं है जितना यहां कहा गया है
    • आखिरकार बात दो चीजों पर आती है: अभी और आगे इसमें आपकी कितनी interest और motivation है, और third-party dependencies लंबी अवधि में कितना अड़ंगा लगाने की संभावना रखती हैं
      Kubernetes में अक्सर शामिल रहने वाले consultant के perspective से, शुरुआती मदद और ongoing help channel रखना अच्छा है, लेकिन internal team में भी कोई genuinely interested व्यक्ति साथ-साथ सीखता रहे तो बेहतर है
      Consultants और experts शुरुआत में खराब decisions से बचा सकते हैं और कई महीनों तक दीवार से सिर टकराने जैसी स्थिति कम कर सकते हैं। Core business पर भी focus करना हो, तो technology या ecosystem के आम dark corners और traps को reasonable time में सीखना आसान नहीं है। मदद लें, लेकिन मछली पकड़ना और आग जलाना भी सीखना चाहिए

  • लेख दिलचस्प है, लेकिन cluster और उसके ऊपर चलने वाले workloads का description missing लगता है
    Nodes कितने हैं, traffic कितना मिलता है, uptime और latency requirements क्या हैं—यह जानना चाहूंगा। और absolute cost savings भी important हैं। महीने के 100,000 dollars का 75% बचाना और महीने के 100 dollars का 75% बचाना पूरी तरह अलग बात है

    • अनुभव से, अगर GPU इस्तेमाल नहीं हो रहा या already महीने के 100,000 dollars खर्च नहीं हो रहे, तो कोई ध्यान नहीं देता
      वास्तव में मुझे लगता है कि महीने के 100,000 dollars ही tipping point हैं। यानी साल के 1.2 million dollars
      Sophisticated bare-metal deployment को ठीक से support करने के लिए engineer salary में सालाना करीब 400,000 dollars लगेंगे, और data center commitments, hardware depreciation, bandwidth पर लगभग सालाना 100,000 dollars लगेंगे। ऐसे लोग आम तौर पर यह काम करते हुए business के दूसरे हिस्सों में भी बड़ी value देते हैं, इसलिए actual cost कम हो सकती है। तब सालाना 700,000 dollars बचेंगे, जो शानदार है; और equivalent cloud spend इससे जितना ज्यादा होगा, फायदा उतना ही बड़ा होता जाएगा

  • 10 साल से ज़्यादा पहले जब मैं web hosting में काम करता था, तो खराब व्यवहार की वजह से Hetzner IPs को लगातार blackhole करना पड़ता था
    दूसरे सस्ते VM providers के साथ भी यही था, और यह geo databases से कोई लेना-देना नहीं रखता था; वजह सिर्फ व्यवहार था। सस्ता होने की वजह होती है

    • कुछ साल पहले जब मैंने Mailgun free tier इस्तेमाल करने की कोशिश की थी, तब भी यही समस्या थी
      Product features पसंद आए थे, लेकिन free tier IPs की reputation बहुत खराब थी, और खासकर Hotmail या Yahoo में email लगभग स्वीकार ही नहीं होते थे। Free hosting services spammers और scammers से भर जाती हैं, और low-cost services भी कुछ कम स्तर पर वैसी ही होती हैं। कीमत जितनी ज़्यादा होती है, fraud और spam के लिए उसका इस्तेमाल उतना कम होता है
    • हालात बदलते रहते हैं, लेकिन आजकल जिन platforms से मेरी hosted sites पर सबसे ज़्यादा हमले आते हैं, वे बड़े cloud providers हैं, खासकर Azure
      AWS, Google, DigitalOcean, Linode, Contabo वगैरह भी login brute force और common vulnerability scanning attacks को काफी host करते हैं
    • AWS यह सुनिश्चित करने के लिए काफी मेहनत करता है कि public IPs block lists में न जाएँ
    • अगर मतलब बनता हो, तो backend को Hetzner पर रखा जा सकता है। उदाहरण के लिए queues या batch processors
    • hcloud पर k8s repository में blacklisted न होने वाला floating IP पाने के लिए कई IPs आज़माने पड़े

  • मैं एक consulting company में काम करता हूँ जो companies को infrastructure setup और security में मदद करती है, और हमारे कई customers Hetzner जैसे low-cost providers, regional mid-tier providers, और AWS/GCP/Azure जैसे top 3 clouds पर Kubernetes चलाते हैं
    कुछ government, finance, healthcare companies भी हैं जो public cloud पर चला नहीं सकतीं या चलाना नहीं चाहतीं, इसलिए आम तौर पर on-premises host करती हैं
    अगर Hetzner में महीने में एक बार issue या defect आता है, तो mid-tier providers में यह 2–3 महीने में एक बार और AWS जैसी जगहों में 5–6 महीने में एक बार जैसा होता है। हालांकि कीमत भी उसी observation जैसी चलती है, इसलिए हर case में सावधानी से देखना पड़ता है कि extra equipment, backups और failure scenarios जोड़ना बेहतर सौदा है या नहीं
    Basic hosting services इस्तेमाल करने का बड़ा फायदा यह है कि cost predictability कहीं बेहतर होती है। Equipment cost दें और जरूरत के हिसाब से scale करें। AWS जैसे providers की add-on services में फँसने पर unexpected बड़े bills आ सकते हैं, और उनसे निकलना भी कहीं मुश्किल हो जाता है। अगर आप छोटी company हैं, तो शुरू में आसान solutions या “free credits” के लालच में आकर ऐसे short-sighted फैसले न लें जो long-term survival को खतरे में डाल दें
    यहाँ कोई सही जवाब नहीं है, सिर्फ trade-offs हैं

  • मैंने खुद इस्तेमाल नहीं किया, लेकिन https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner Hetzner पर Kubernetes setup और manage करने के तरीके के रूप में बहुत अच्छा लगता है
    फिलहाल मैं Oracle free tier इस्तेमाल कर रहा हूँ, लेकिन Oracle से बाहर निकलने के लिए इस तरफ move करने के बारे में लगातार सोच रहा हूँ

    • इससे मैं दो clusters चला रहा हूँ, एक production के लिए और एक development के लिए
      काफी अच्छी तरह चलता है। SuSE MicroOS पर automatic security updates के लिए हर रविवार machines reboot करने का schedule भी रखा है। Workload बढ़ने पर machines scale करना भी आज़माया है। Terraform जो भी बदलाव करने जा रहा है, उन्हें ज़रूर review करना पड़ता है, लेकिन ऐसा करने पर यह काफी सुरक्षित है
      सिर्फ एक downside यह है कि सभी nodes firewall के पीछे होने पर भी public IP चाहिए, हालांकि इस पर काम चल रहा है
    • इसका इस्तेमाल करके मैंने अपने personal journaling site के लिए cluster configure किया
      एक रात में cluster चलने लगा और काफी अच्छा काम करता है। एक छोटी समस्या यह थी कि arm node पर automatic updates run नहीं हुए थे; उस समय सिर्फ single node चल रहा था और control plane taint की वजह से update pod run नहीं हो पा रहा था, इसलिए वह अटक गया
    • Cluster API और Cluster API Provider Hetzner भी इस्तेमाल कर रहा हूँ
      https://github.com/syself/cluster-api-provider-hetzner
      बहुत स्थिर तरीके से काम करता है
    • हाल ही में Oracle free tier पर k8s चलाने वाली एक post पढ़ी और try करने का सोचा था
      जानना चाहता हूँ कि क्या कोई specific परेशानी है जिसकी वजह से move करने का मन हो

  • मुझे नहीं लगता कि यह कहना सही है कि DigitalOcean, दूसरे providers की तरह free managed control plane देता है लेकिन managed cluster nodes पर आम तौर पर 100% markup लगाता है
    DigitalOcean में worker nodes की cost सामान्य Droplet जैसी ही है और कोई extra cost नहीं है। इसलिए DigitalOcean का offering काफी attractive है। free control plane जिसकी चिंता नहीं करनी पड़ती, free upgrades, और load balancers व storage जैसी extra integrations मिलती हैं। इसे खुद manage करने के बजाय न चुनने की कोई बड़ी वजह मुझे समझ नहीं आती

    • Actual nodes फिर भी DigitalOcean पर Hetzner से बहुत महंगे हैं। शायद यही मुख्य वजह है
      Hetzner का 8GB RAM shared CPU लगभग 10 डॉलर है, और DigitalOcean का equivalent 48 डॉलर है
    • czhu12 ने जो कहा उसके अलावा, DOKS का high-availability control plane के लिए extra charge लेना platform को production-grade न होने जैसा महसूस कराता है
      अगर Hetzner पर managed experience चाहिए, तो https://syself.com देख सकते हैं। मैं उसी company में काम करता हूँ