ลดค่าใช้จ่ายโครงสร้างพื้นฐาน 75% ด้วยการใช้ Kubernetes บน Hetzner

 (bilbof.com)
1 คะแนน โดย GN⁺ 2024-12-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

Hetzner

  • การย้ายไปใช้ Hetzner มีเป้าหมายหลักเพื่อประหยัดค่าใช้จ่าย โดยราคาของ Hetzner สามารถแข่งขันได้ในระดับโลก
  • Hetzner ให้บริการทั้งเครื่องเสมือนและเครื่อง bare metal แม้จะมีข้อจำกัดมากกว่า AWS แต่ก็ชดเชยด้วยราคา
  • หลังย้ายไปใช้ Hetzner สามารถลดค่าใช้จ่ายด้านโครงสร้างพื้นฐานได้มากกว่า 75%

Kubernetes บน Hetzner

Kubernetes แบบจัดการเอง

  • เคยรัน Kubernetes บน DigitalOcean และบน Hetzner ก็ใช้งานในรูปแบบจัดการเองเช่นกัน
  • Hetzner ไม่มี managed Kubernetes control plane ให้ จึงต้องดูแลเองโดยตรง
  • ใช้ Terraform และ Puppet ในการจัดการและตั้งค่าโหนด

บทบาทของโหนด

  • ใช้กฎการตั้งชื่อโหนดเพื่อให้บทบาทในคลัสเตอร์เรียบง่าย: control-plane, worker, database
  • การเพิ่มบทบาททำได้ง่าย แต่ก็อาจลดประสิทธิภาพในการใช้ทรัพยากร

การสร้างโหนด

  • ใช้ Terraform ในการ bootstrap คลัสเตอร์
  • Hetzner มีไฟร์วอลล์และระบบเครือข่ายแบบจัดการให้ ซึ่งสามารถตั้งค่าผ่าน Terraform ได้ง่าย
  • เซิร์ฟเวอร์ทั้งหมดถูกจัดการด้วย Terraform โดยเขียนโมดูลแยกตามบทบาทเพื่อให้เพิ่มเซิร์ฟเวอร์ได้ง่าย

เครือข่าย

  • ใช้ Tailscale VPN สำหรับการเชื่อมต่อเพื่อจัดการโหนด
  • Tailscale รองรับ NAT hole punching ทำให้เชื่อมต่อได้อย่างปลอดภัยแม้จะปิดพอร์ตไว้
  • ใช้ทั้งไฟร์วอลล์แบบจัดการของ Hetzner และ UFW ของ Ubuntu เพื่อบล็อกพอร์ต
  • ใช้ Calico ในการตั้งค่า container networking interface

สตอเรจ

  • Hetzner ให้บริการทั้ง nVME SSD และ block storage ที่ใช้ SSD
  • โวลุ่มของ Hetzner ไม่มีฟังก์ชัน snapshot ดังนั้นจึงต้องสำรองข้อมูลด้วยตนเอง
  • สำหรับโหนดฐานข้อมูล ใช้ Local Persistence Volume Static Provisioner เพื่อ pre-provision โวลุ่มภายในเครื่อง

การสำรองข้อมูล

  • Hetzner ไม่มีการสำรองข้อมูลระดับโวลุ่ม แต่มีการสำรองทั้งเซิร์ฟเวอร์
  • ใช้ Velero ของ VMware เพื่อสำรอง namespace และ PVC
  • สำหรับ Postgres ใช้ pgBackRest

ฟีเจอร์เพิ่มเติม

  • ใช้ SealedSecrets สำหรับจัดการข้อมูลลับ
  • ใช้ Node Exporter, Prometheus, Grafana, Loki สำหรับมอนิเตอร์คลัสเตอร์
  • ใช้ Alertmanager เพื่อเชื่อมต่อการแจ้งเตือนกับ Slack

ความเห็นต่อการรัน Kubernetes บน Hetzner

  • การย้ายไป Hetzner ใช้เวลาประมาณ 1 สัปดาห์ และใช้เวลาอีก 4 สัปดาห์สำหรับการทดสอบและปรับแต่งเพิ่มเติม
  • ราคาของ Hetzner สมเหตุสมผล และเชื่อว่าจะยังคงต่ำกว่าผู้ให้บริการรายอื่น
  • Hetzner มีข้อจำกัดเรื่องคุณภาพ IP และการบริการลูกค้า
  • Hetzner ออกฟีเจอร์ใหม่ค่อนข้างเร็ว แต่บริการที่ทำกำไรได้น้อยก็อาจถูกยุติอย่างรวดเร็วเช่นกัน
  • ศูนย์ข้อมูลในยุโรปกลางตั้งอยู่ที่ Falkenstein, Nuremberg ในเยอรมนี และ Helsinki ในฟินแลนด์

สรุป

  • การเปลี่ยนผ่านครั้งนี้เป็นไปอย่างราบรื่น ลดค่าใช้จ่ายโครงสร้างพื้นฐานได้มากกว่า 75% และเพิ่มทรัพยากรคอมพิวต์ของคลัสเตอร์เป็นสองเท่า
  • Hetzner เป็นตัวเลือกที่คุ้มค่ามากหากต้องการลดต้นทุน
  • คอนโทรลเลอร์โอเพนซอร์สของ Hetzner ช่วยให้การจัดการ load balancer และการเชื่อมต่อ persistent volume ทำได้ง่ายขึ้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-12-02
ความคิดเห็นจาก Hacker News

  • ผมให้บริการคลัสเตอร์ Kubernetes แก่ลูกค้าด้วย เซิร์ฟเวอร์แบบ dedicated ของ Hetzner มาหลายปีแล้ว และประสิทธิภาพก็ดูยอดเยี่ยมจริง ๆ โดยปกติเวลาตอบสนองของ request ลดลงประมาณครึ่งหนึ่ง
    ฮาร์ดแวร์ราคาถูก จึงสามารถจัดเวลา DevOps engineer แบบ dedicated ให้ลูกค้าแต่ละรายได้ด้วย แต่ก็มีข้อสมมติฐานบางอย่าง คลัสเตอร์ staging สำหรับทดสอบอัปเดตแทบจะเป็นสิ่งจำเป็น และไม่มีใครอยากดันอัปเดต production ในวันอาทิตย์แบบเดาสุ่ม การ replication ระดับแอปพลิเคชันสำคัญที่สุด ถัดมาคือการ replication ระดับบล็อก และตอนนี้ใช้ OpenEBS/Mayastor อยู่ หลังจากลองใช้ Postgres operator หลายตัว ตอนนี้มองว่า StackGres ดีที่สุด
    Ansible playbook เป็นสินทรัพย์ ถ้าจัดระเบียบและใส่คอมเมนต์ไว้ดีสำหรับบริการเฉพาะ ก็จะทำให้ภายหลัง deploy บริการเดียวกันไปที่อื่นได้ง่ายขึ้น ถ้าเป็นไปได้ แนะนำ เครือข่าย 10G เฉพาะสำหรับเชื่อมต่อเซิร์ฟเวอร์ 1G ไม่พอเมื่อรวม production traffic, image pull และ traffic ระหว่าง service เข้าด้วยกัน และ latency ดีขึ้น 10 เท่าเมื่อเทียบกับการสื่อสารภายใน availability zone แบบ AWS
    ถ้าต้องการ network redundancy ก็สร้าง 1G vSwitch (VLAN) สำหรับภายในบนพอร์ต 1G ให้ loopback IP แก่แต่ละเซิร์ฟเวอร์ แล้วกระจาย route ด้วย BGP (bird) ได้ คลัสเตอร์ MinIO ถ้ารันตามแนวทางมาตรฐานผ่าน operator ก็ไม่ได้ยากนัก และให้ object storage ในเครื่องที่ bandwidth สูงและ latency ต่ำ การลงทุนช่วงเริ่มต้นต้องใช้เวลาวิศวกรรมจากคนมีประสบการณ์แบบไม่ถูกรบกวนราว 2–4 เดือน และงานประกอบที่จุกจิกอย่าง HTTP load balancing ก็ยังโยนให้ cloud provider อย่าง CloudFlare ได้

    • สงสัยว่า “เครือข่าย 10G เฉพาะสำหรับเชื่อมต่อเซิร์ฟเวอร์” ต้องร้องขอจาก Hetzner แยกต่างหากหรือไม่
      ในเอกสารสาธารณะมีตัวเลือก 10G uplink แต่เป็นสำหรับเครือข่ายภายนอก และข้อจำกัด 20TB ดูค่อนข้างเข้มงวด ถ้าเป็น I/O ภายในคลัสเตอร์ 20TB อาจกลายเป็นปัญหาได้ง่าย
    • สงสัยว่าจะแชร์ ตัวอย่างการตั้งค่า ส่วนที่ทำ network redundancy ด้วย 1G vSwitch, loopback IP และ BGP (bird) ได้ไหม
    • ถ้าต้องลงทุนด้านวิศวกรรมช่วงเริ่มต้น 2–4 เดือน ก็น่าลองดู https://syself.com
      ผมเป็นพนักงานของบริษัทนั้น และเราสร้างแพลตฟอร์มที่ให้คลัสเตอร์พร้อมสำหรับ production ได้ภายในไม่กี่นาที
    • ต้องเทียบว่าระยะเวลาวิศวกรรมจากคนมีประสบการณ์แบบไม่ถูกรบกวน 2–4 เดือน มีมูลค่าเท่าไรต่อบริษัทหรือลูกค้า เมื่อเทียบกับการจ่ายบิลรายเดือนที่สูงกว่าในอีก 5 ปีข้างหน้า
      ถ้าเป็นบริษัท consulting ก็คงอยากขายงานนั้น แต่จากมุมลูกค้า ถ้าไม่ได้คาดว่าค่า AWS รายเดือนจะอยู่ราว 10,000 ดอลลาร์ ก็ดูไม่น่าคุ้มเลย นึกถึง xkcd: https://xkcd.com/1319/

  • เคยรันคลัสเตอร์ Kubernetes บนเซิร์ฟเวอร์ dedicated ของ Hetzner และเคยจัดการบริการแบบ fully managed หรือ managed ขั้นสูงอย่าง Aurora, S3, ECS Fargate ด้วย
    จากประสบการณ์ บิล cloud ของ Hetzner บางครั้งลดลงเหลือแค่ ประมาณ 20% เมื่อเทียบกับ AWS ที่เทียบเท่ากัน แต่ข้อได้เปรียบด้านต้นทุนนั้นมาพร้อมการแลกเปลี่ยนครั้งใหญ่
    บน Hetzner Kubernetes ผมเคยดูแลคลัสเตอร์ Ceph ที่ใช้ NVMe storage, MariaDB operator, Cilium สำหรับ networking และ ArgoCD สำหรับ deploy Helm chart ต้องจัดการอัปเดตคลัสเตอร์ Kubernetes เองด้วย และครั้งหนึ่งเคยเจอเหตุขัดข้องทั้งคลัสเตอร์ พบ bug หลายตัวทั้งใน Kubernetes และ Ceph ซึ่งหลายรายการถูกบันทึกไว้ใน GitHub issue และ Ceph tracker แล้ว รายการงานที่ต้องจัดการและเฝ้าระวังไม่มีที่สิ้นสุด และขึ้นกับจำนวน workload กับความซับซ้อนของ environment การดูแล configuration แบบนี้อาจกลายเป็นงานเต็มเวลาของทีม DevOps ได้
    ในทางกลับกัน ถ้าใช้ AWS หรือ cloud provider รายใหญ่รายอื่น จะจัด configuration ที่ต้องลงมือน้อยกว่ามากได้ การใช้ managed service ช่วยลดความพยายามด้าน maintenance อย่างมาก และลดภาระ operation ของทีม สรุปคือ AWS ลด workload ของ DevOps ได้มาก ส่วน Hetzner ลดบิล cloud ได้มาก การตัดสินว่าฝั่งไหนคุ้มกว่าต้องวิเคราะห์ ต้นทุนรวมในการเป็นเจ้าของ (TCO) และถึง Hetzner จะดูถูกกว่าในตอนแรก เวลา DevOps เพิ่มเติมก็อาจหักล้างเงินที่ประหยัดได้

    • อันนี้ดูเหมือน output จาก ChatGPT พอสมควร และประวัติการเขียนก่อนหน้าก็มีประโยคทำนอง “ในขณะที่ X แต่ Y ก็ทำ Z เช่นกัน Y ซ้อนทับกับ X อยู่แล้ว” เยอะ
      ยกตัวอย่าง ถ้าเทียบ configuration 2 vCPU, 4GB กับ configuration คล้ายกันบน AWS แล้ว AWS แพงกว่ามาก อยากเห็นการวิเคราะห์ต้นทุน นอกจากนี้ยังมี https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner เป็นเครื่องมือช่วยลดภาระ operation
    • นอกจากคลัสเตอร์ development ของเล่นสำหรับ reproduce issue support แล้ว ผมไม่เคยรันคลัสเตอร์ Kubernetes จริงจัง แต่วันหนึ่งมันพังเพราะ ปัญหา certificate
      แม้แต่จะหาสาเหตุรากก็ไม่ง่าย และออนไลน์มีคำสั่งเหมือนมนตร์คาถาสำหรับกู้คืนเต็มไปหมด แต่ผมก็ลบทิ้งแล้วสร้างคลัสเตอร์ใหม่ไปเลย หลังจากนั้นก็ทำแบบนั้นทุกสองสามสัปดาห์ ผู้ดูแล Kubernetes ตัวจริงน่าจะมีการอัปเกรด certificate อัตโนมัติและเครื่องมืออื่น ๆ อีกหลายอย่าง แต่ถ้าเป็นบริษัทก็คงต้องจ่ายเงินให้ผู้ดูแลแบบนั้น
    • การดูแล Ceph ลำบากจริง ๆ แพง ช้า และยังไม่รู้สึกว่าพร้อมดีพอ
      รู้ว่ามีที่ใช้งานอยู่ แต่เมื่อเทียบกับระบบที่ mature แล้วอย่าง Lustre หรือ GPFS มันเสียเวลามหาศาล เอา file system เล็ก ๆ หลายตัว export ผ่าน NFS แล้วรับประกันการ replication ระดับบล็อกยังดีกว่า file system แบบ address space เดียวสะดวกก็จริง แต่หลายครั้งไม่คุ้มกับค่าใช้จ่ายด้านการจัดการเพื่อทำให้เสถียรในระดับใหญ่ เหมือน database sharding ก็ควร shard file system ด้วย และใน Kubernetes สามารถเพิ่ม mapping logic ได้ง่ายเพื่อให้ storage ที่ถูกต้องไปผูกกับ image ที่ถูกต้อง
    • โดยรวมเห็นด้วย แต่แปลกใจที่ไม่ค่อยพิจารณา ทางสายกลาง อย่าง OpenShift กันบ่อยนัก
      มันลดภาระ DevOps ได้มาก พร้อมทั้งได้ทั้งประสิทธิภาพและความยืดหยุ่นของ bare metal เป็น hybrid ที่ยอดเยี่ยมระหว่างบริการแพงแบบ fully managed กับการสร้างเองทั้งหมด ค่าใช้จ่ายค่อนข้างสูง จึงอาจไม่ใช่ตัวเลือกที่ดีสำหรับ startup แต่ถ้าเป็นคลัสเตอร์ที่มี RAM 72GB หรือ CPU 36 ขึ้นไป ประมาณโหนดขนาดกลางสัก 9 โหนด ก็ควรพิจารณาอะไรอย่าง OpenShift อย่างแน่นอน
    • การอัปเดตคลัสเตอร์ Kubernetes ด้วยมือ เป็นการแลกเปลี่ยนที่หนักมาก นึกไม่ออกว่าจะทำแบบนั้นเพื่อประหยัดเงินเล็กน้อย เว้นแต่จะอยู่ในสถานการณ์จนตรอกจริง ๆ

  • ปัญหาที่ว่าโวลุ่มของ Hetzner ช้าเกินไปสำหรับฐานข้อมูลโปรดักชัน แก้ได้ง่ายกว่าที่คิดมาก แค่ใช้เครื่องแบร์เมทัลของ Hetzner ที่ราคาถูกมากเป็นโหนดก็พอ
    เครื่องที่มีสตอเรจ NVMe มักให้ประสิทธิภาพฐานข้อมูลยอดเยี่ยมและมี RAM เหลือเฟือด้วยซ้ำ บางทีการมี เครื่องแบร์เมทัล แข็งแรงอย่างน้อยสองเครื่องไว้ทำคอนฟิกแบบมาสเตอร์-รีพลิกา อาจดีกว่าการรันฐานข้อมูลบน Kubernetes ด้วยซ้ำ ถ้าไม่อยากตั้งค่าให้ยุ่งยาก ก็ใช้แพ็กเกจสมัยใหม่อย่าง Pigsty ได้: https://pigsty.cc/

    • มีตัวเลือกมากมายสำหรับรันฐานข้อมูลโดยใช้ สตอเรจ NVMe ภายในเครื่อง บน Kubernetes
      ทำได้โดยตรึงพอดฐานข้อมูลไว้กับโหนดเฉพาะแล้วใช้ LocalPathProvisioner หรือใช้โซลูชันแบบกระจายอย่าง JuiceFS, OpenEBS
    • เคยมีประสบการณ์ที่ดีจากการใช้ สตอเรจภายในเครื่อง ของเซิร์ฟเวอร์แบร์เมทัล
      คู่มือที่เขียนไว้ให้ลูกค้าอยู่ที่นี่: https://syself.com/docs/hetzner/apalla/how-to-guides/storage/local-storage-in-baremetal

  • ใช้ Hetzner มาอย่างพอใจนานกว่า 10 ปีแล้ว เดิมใช้ dedicated server ในดาต้าเซ็นเตอร์เยอรมนี ก่อนย้ายมาใช้ Cloud US VM เพื่อลด latency ไปยังสหรัฐฯ
    ช่วงหลังค่อนข้างผิดหวังเล็กน้อยที่ ทราฟฟิกฟรี 20TB ซึ่งเคยให้มาอย่างใจกว้างถูกลดเหลือ 3TB และคิดเพิ่ม €1.19 ต่อ TB แต่ก็ยังดูคุ้มค่ากว่าผู้ให้บริการคลาวด์ในสหรัฐฯ รายอื่น ๆ ที่ลองประเมินมาอยู่มาก
    คงไม่เลือก Kubernetes โดยไม่จำเป็น แต่ย้ายการ deploy แบบเดิมที่ใช้ SSH/Docker Compose ไปใช้ GitHub Actions กับ kamal-deploy.org ได้สำเร็จแล้ว ตั้งค่าง่าย และเครื่องมือ UX สำหรับมอนิเตอร์แอปที่ deploy แบบรีโมตก็ดีด้วย: https://servicestack.net/posts/kamal-deployments

    • ดูเหมือนจะเป็นปัญหาฝั่งสหรัฐฯ และอาจเป็นเพราะพาร์ตเนอร์ peering กดดันให้ขึ้นราคา
      ดาต้าเซ็นเตอร์เยอรมนียังให้ แบนด์วิดท์ 20TB อยู่: https://www.hetzner.com/cloud/
      แต่ฝั่งสหรัฐฯ ให้น้อยกว่ามากในราคาเดียวกัน

  • เมื่อก่อนซ่อมรถเองเพราะอยากประหยัดเงินและสนุกดี แต่จริง ๆ แล้วซับซ้อนกว่าที่คิด และเมื่อเวลาผ่านไปก็มีโน่นนี่พังหรือแตกเสียหาย
    ใช้เวลาไปมากกับการ “ซ่อมซ้ำ” และน่าจะหมดเงินหลายพันดอลลาร์กับเครื่องมือในช่วงหลายปีนั้น ยังมีค่าเปลี่ยนเครื่องมือราคาถูกที่พังหรือขึ้นสนิมเร็วอีก และรถก็มักถูกยกค้างอยู่บนขาตั้งบ่อย ๆ ถึงอย่างนั้นก็ได้บทเรียนดี ๆ มากมาย บทเรียนที่ใหญ่ที่สุดคือ บางอย่างไม่คุ้มที่จะทำเอง ถ้ามันเป็นเรื่องที่กระทบปากท้อง ก็ควรให้ช่างจัดการหรือเช่ารถแบบลีสไปเลยดีกว่า
    แม้แต่งานง่าย ๆ อย่างเปลี่ยนน้ำมันเครื่อง ก็แทบไม่คุ้มที่จะทำเอง ต้องซื้อเครื่องมืออย่างถาดรองน้ำมัน ประแจถอดไส้กรอง กรวย แผ่นรองนอนซ่อมรถ ต้องเคลียร์เวลา หาเสื้อผ้าทำงานที่เลอะได้ ไปที่ร้านเพื่อซื้อน้ำมันเครื่องและไส้กรองใหม่ กลับมาบ้านเพื่อเปลี่ยน แล้ววันนั้นหรือวันอื่นก็ต้องไปร้านที่รับน้ำมันเก่าอีก ขณะที่อู่ซ่อมรถคิดเพิ่มจากค่าน้ำมันและไส้กรองราว 15 ดอลลาร์ และเสร็จใน 20 นาที
    Kubernetes คือรถทั้งคัน แถมยังเป็นรถที่ซับซ้อนด้วย ถ้าไม่ได้ทำเพื่อความสนุก ก็แทบไม่คุ้มที่จะดูแลรักษาเองจริง ๆ

    • ไม่แน่ใจเหมือนกัน อู่เรียกค่าเปลี่ยนเบรก 1800 ดอลลาร์ แต่ซื้ออะไหล่มา 300 ดอลลาร์ และแม้จะทำครั้งแรกก็เสร็จภายในวันเดียว
      ผลตอบแทนค่อนข้างดี และเป็นทักษะที่ควรเรียนไว้ การที่เพื่อนบ้านมีลิฟต์ยกรถช่วยได้มากจริง ๆ
    • ถ้าค่าเรียก AA ทุกเรื่องและการไปอู่ดังทุกครั้งกลายเป็นสัดส่วนใหญ่ของงบประมาณ เรื่องก็เปลี่ยนไป
      ประเด็นคือการหาสมดุลระหว่างสิ่งที่ควรทำเองกับสิ่งที่ควรจ้างข้างนอก และมันไม่ได้ง่ายหรือเรียบร้อยอย่างที่พูดกันตรงนี้
    • สุดท้ายขึ้นอยู่กับสองอย่าง คือ ตอนนี้และต่อจากนี้คุณมีความสนใจและแรงจูงใจแค่ไหน และ การพึ่งพาบุคคลที่สาม มีโอกาสจะกลายเป็นตัวถ่วงในระยะยาวมากเพียงใด
      จากมุมมองของคอนซัลแตนต์ที่เกี่ยวข้องกับ Kubernetes บ่อย ๆ ควรมีช่องทางขอความช่วยเหลือทั้งช่วงเริ่มต้นและต่อเนื่อง แต่ในองค์กรเองก็ควรมีคนที่สนใจพอจะเรียนไปด้วยกัน
      คอนซัลแตนต์และผู้เชี่ยวชาญช่วยให้หลีกเลี่ยงการตัดสินใจแย่ ๆ ในช่วงแรก และลดการเอาหัวชนกำแพงเป็นเดือน ๆ ได้ ขณะที่ยังต้องโฟกัสธุรกิจหลัก การเรียนรู้มุมมืดและกับดักที่พบบ่อยของเทคโนโลยีหรืออีโคซิสเต็มให้ทันในเวลาสมเหตุสมผลไม่ใช่เรื่องง่าย รับความช่วยเหลือได้ แต่ก็ควรเรียนวิธีจับปลาและวิธีก่อไฟด้วย

  • เป็นบทความที่น่าสนใจ แต่รู้สึกว่ายังขาด คำอธิบายเวิร์กโหลด ของคลัสเตอร์และสิ่งที่รันอยู่บนนั้น
    อยากรู้ว่ามีกี่โหนด รับทราฟฟิกเท่าไร มีข้อกำหนดเรื่อง uptime และ latency อย่างไรบ้าง และยอดเงินที่ประหยัดได้แบบ absolute ก็สำคัญเช่นกัน ประหยัด 75% จากเดือนละ 100,000 ดอลลาร์ กับประหยัด 75% จากเดือนละ 100 ดอลลาร์ เป็นคนละเรื่องกันโดยสิ้นเชิง

    • จากประสบการณ์ ถ้าไม่ได้ใช้ GPU หรือไม่ได้จ่ายเดือนละ 100,000 ดอลลาร์อยู่แล้ว ก็ไม่มีใครสนใจ
      จริง ๆ มองว่า 100,000 ดอลลาร์ต่อเดือน คือจุดเปลี่ยนพอดี เท่ากับ 1.2 ล้านดอลลาร์ต่อปี
      หากจะซัพพอร์ตการ deploy แบร์เมทัลที่ซับซ้อนให้ดี ต้องมีค่าเงินเดือนวิศวกรราว 400,000 ดอลลาร์ต่อปี และมีค่า commitment ดาต้าเซ็นเตอร์ ค่าเสื่อมฮาร์ดแวร์ และแบนด์วิดท์รวม ๆ ราว 100,000 ดอลลาร์ต่อปี คนกลุ่มนี้มักสร้างคุณค่าใหญ่ให้ส่วนอื่นของธุรกิจไปพร้อมกันด้วย ดังนั้นต้นทุนจริงอาจต่ำกว่านั้น เมื่อเป็นเช่นนี้ก็ประหยัดได้ปีละ 700,000 ดอลลาร์ ถือว่ายอดเยี่ยม และยิ่งค่าใช้จ่ายคลาวด์เทียบเท่าสูงกว่านั้น ประโยชน์ก็ยิ่งมากขึ้นไปอีก

  • เมื่อกว่า 10 ปีก่อน ตอนที่ผมทำงานอยู่ในวงการเว็บโฮสติ้ง เรามักจะ blackhole IP ของ Hetzner อยู่เรื่อย ๆ เพราะพฤติกรรมที่ไม่ดี
    ผู้ให้บริการ VM ราคาถูกรายอื่น ๆ ก็เช่นกัน และไม่ได้เกี่ยวกับฐานข้อมูลภูมิศาสตร์เลย แต่เป็นเพราะพฤติกรรมล้วน ๆ ของถูกย่อมมีเหตุผลของมัน

    • เมื่อหลายปีก่อน ตอนที่พยายามใช้ฟรีเทียร์ของ Mailgun ก็เจอปัญหาเดียวกัน
      ผมชอบฟีเจอร์ของผลิตภัณฑ์ แต่ชื่อเสียงของ IP ในฟรีเทียร์แย่มาก โดยเฉพาะกับ Hotmail หรือ Yahoo แทบไม่มีอีเมลไหนถูกยอมรับเลย บริการโฮสติ้งฟรีมักถูกสแปมเมอร์และมิจฉาชีพครอบงำ ส่วนบริการราคาถูกก็คล้ายกัน เพียงแต่เบากว่า ยิ่งราคาแพง ก็ยิ่งถูกใช้กับการฉ้อโกงและสแปมน้อยลง
    • สถานการณ์เปลี่ยนไปเรื่อย ๆ แต่ทุกวันนี้แพลตฟอร์มที่โจมตีไซต์ที่ผมโฮสต์มากที่สุดคือผู้ให้บริการคลาวด์รายใหญ่ โดยเฉพาะ Azure
      AWS, Google, DigitalOcean, Linode, Contabo ฯลฯ ก็โฮสต์การโจมตีแบบ brute force ล็อกอินและการสแกนหาช่องโหว่ทั่วไปจำนวนมากเช่นกัน
    • AWS บริหารจัดการอย่างจริงจังไม่ให้ IP สาธารณะของตนติด blocklist
    • ถ้ามีความเหมาะสม ก็สามารถวางแบ็กเอนด์ไว้บน Hetzner ได้ เช่น คิวหรือ batch processor
    • บน hcloud ต้องลองหลายตัวกว่าจะได้ floating IP ที่ไม่ติดแบล็กลิสต์ในคลังของ k8s

  • ผมทำงานในบริษัทที่ปรึกษาซึ่งช่วยบริษัทต่าง ๆ สร้างอินฟราและดูแลความปลอดภัย และมีลูกค้าจำนวนมากที่รัน Kubernetes บนผู้ให้บริการราคาถูกอย่าง Hetzner, ผู้ให้บริการระดับกลางในท้องถิ่น และคลาวด์สามรายใหญ่อย่าง AWS/GCP/Azure
    ยังมีหน่วยงานรัฐ บริษัทการเงิน และบริษัทด้านการแพทย์ที่ไม่สามารถหรือไม่ต้องการรันบน public cloud จึงมักโฮสต์แบบ on-premise
    ถ้า Hetzner มีปัญหาหรือข้อบกพร่องเดือนละครั้ง ผู้ให้บริการระดับกลางก็ราว ๆ ทุก 2–3 เดือน ส่วนอย่าง AWS ก็ประมาณทุก 5–6 เดือน อย่างไรก็ตาม ราคาก็เคลื่อนไหวสอดคล้องกับข้อสังเกตนี้ด้วย ดังนั้นต้องพิจารณาเป็นรายกรณีอย่างระมัดระวังว่า การเพิ่มอุปกรณ์และแบ็กอัป รวมถึง scenario ความขัดข้องเพิ่มเติม จะคุ้มค่ากว่าหรือไม่
    ข้อดีใหญ่ของการใช้บริการโฮสติ้งพื้นฐานคือ คาดการณ์ราคาได้ สูงกว่ามาก แค่จ่ายค่าเครื่องและขยายตามที่ต้องการก็พอ หากถูกผูกกับบริการเสริมของผู้ให้บริการอย่าง AWS อาจเจอบิลก้อนใหญ่ที่ไม่คาดคิด และการย้ายออกก็ยากกว่ามาก ถ้าเป็นบริษัทเล็ก ช่วงแรกไม่ควรหลงกับโซลูชันที่ง่ายหรือ “เครดิตฟรี” จนตัดสินใจแบบสายตาสั้นที่คุกคามความอยู่รอดระยะยาว
    เรื่องนี้ไม่มีคำตอบที่ถูกต้อง มีแต่ trade-off

  • ยังไม่เคยใช้เอง แต่ https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner ดูเป็นวิธีที่ยอดเยี่ยมในการตั้งค่าและจัดการ Kubernetes บน Hetzner
    ตอนนี้ใช้ฟรีเทียร์ของ Oracle อยู่ แต่ก็คิดอยู่เรื่อย ๆ ว่าจะย้ายมาทางนี้เพื่อออกจาก Oracle

    • ผมรันคลัสเตอร์สองชุดด้วยตัวนี้อยู่ ชุดหนึ่งเป็น production อีกชุดเป็น dev
      ทำงานได้ค่อนข้างดี มี schedule ให้รีบูตเครื่องทุกวันอาทิตย์เพื่ออัปเดตความปลอดภัยอัตโนมัติบน SuSE MicroOS ด้วย เคยลองขยายเครื่องตาม workload ที่เพิ่มขึ้นแล้วด้วย ต้องตรวจสอบทุกการเปลี่ยนแปลงที่ Terraform ตั้งใจจะทำเสมอ แต่ถ้าทำแบบนั้นก็ค่อนข้างปลอดภัย
      ข้อเสียเดียวคือทุก node ต้องมี IP สาธารณะ แม้จะอยู่หลัง firewall ทั้งหมด ซึ่งส่วนนี้กำลังอยู่ระหว่างการแก้ไข
    • ผมใช้ตัวนี้ตั้งค่าคลัสเตอร์สำหรับไซต์ journaling ที่ใช้เอง
      ภายในคืนเดียวคลัสเตอร์ก็ทำงานได้ และทำงานค่อนข้างดี ปัญหาเล็กอย่างหนึ่งคือ automatic update ไม่ได้รันบน node แบบ arm ตอนนั้นรันอยู่แค่ node เดียว และเพราะ taint ของ control plane ทำให้ update pod รันไม่ได้จึงค้างอยู่
    • ผมใช้ Cluster API และ Cluster API Provider Hetzner อยู่ด้วย
      https://github.com/syself/cluster-api-provider-hetzner
      ทำงานได้เสถียรมาก
    • เมื่อเร็ว ๆ นี้อ่านบทความเกี่ยวกับการรัน k8s บนฟรีเทียร์ของ Oracle แล้วตั้งใจจะลองดู
      อยากรู้ว่ามีความไม่สะดวกเฉพาะอะไรที่ทำให้อยากย้ายหรือไม่

  • ผมไม่คิดว่าคำกล่าวที่ว่า DigitalOcean เหมือนผู้ให้บริการรายอื่นที่ให้ managed control plane ฟรี แต่คิด markup ปกติ 100% กับ node ของ managed cluster นั้นถูกต้อง
    บน DigitalOcean ค่า worker node เท่ากับ Droplet ปกติ และไม่มีค่าใช้จ่ายเพิ่ม ดังนั้นแนวทางของ DigitalOcean จึงค่อนข้างน่าสนใจ มี control plane ฟรี ที่ไม่ต้องกังวล, upgrade ฟรี, และ integration เพิ่มเติมอย่าง load balancer กับ storage ผมนึกเหตุผลไม่ค่อยออกว่าทำไมถึงจะไม่เลือกสิ่งนี้แทนการจัดการเอง

    • node จริง ๆ ของ DigitalOcean ก็ยังแพงกว่า Hetzner มาก นั่นน่าจะเป็นเหตุผลหลัก
      shared CPU RAM 8GB ของ Hetzner อยู่ที่ประมาณ 10 ดอลลาร์ ส่วนระดับเทียบเท่าของ DigitalOcean อยู่ที่ 48 ดอลลาร์
    • นอกจากที่ czhu12 พูดแล้ว การที่ DOKS คิดค่าบริการเพิ่มสำหรับ high-availability control plane ทำให้แพลตฟอร์มดูเหมือนไม่ใช่ระดับ production
      ถ้าต้องการประสบการณ์แบบ managed บน Hetzner ลองดู https://syself.com ได้ ผมเป็นพนักงานของบริษัทนั้น