1 คะแนน โดย GN⁺ 2025-08-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Edka ช่วยให้ผู้ใช้สร้างและจัดการคลัสเตอร์ Kubernetes ได้โดยตรงอย่างง่ายดายใน บัญชี Hetzner ของตนเอง
  • มอบ ความง่ายระดับ PaaS โดยไม่สูญเสียความยืดหยุ่น
  • รวมฟีเจอร์หลากหลาย เช่น เวิร์กโฟลว์แบบ GitOps, การติดตั้งแอดออนแบบคลิกเดียว และ ความสามารถด้านการมอนิเตอร์ในตัว
  • สามารถ ลดความซับซ้อน ของกระบวนการปฏิบัติการ Kubernetes แบบเดิมได้
  • มอบประสบการณ์ การจัดการแพลตฟอร์มด้วยตนเอง ให้กับสตาร์ทอัพและผู้เชี่ยวชาญด้านไอที

ภาพรวมของ Edka

  • Edka เป็นแพลตฟอร์มที่ช่วยให้ผู้ใช้สร้าง ขยาย และจัดการคลัสเตอร์ Kubernetes ภายใน บัญชี Hetzner ของตนเองได้
  • แทนที่จะต้องตั้งค่าโครงสร้างพื้นฐานที่ซับซ้อน ผู้ใช้สามารถทำให้งานจัดการโครงสร้างพื้นฐานเป็นอัตโนมัติได้ผ่าน เวิร์กโฟลว์ GitOps
  • ยังคงรักษา ความเรียบง่ายระดับ PaaS (Platform as a Service) เอาไว้ พร้อมมอบทั้งความสามารถในการขยายระบบและความยืดหยุ่นในการตั้งค่า

คุณสมบัติหลัก

  • แอดออนแบบคลิกเดียว: ติดตั้งและใช้งาน Kubernetes แอดออนหลากหลายแบบได้ด้วยคลิกเดียว
  • การมอนิเตอร์ในตัว: ตรวจสอบสถานะคลัสเตอร์และการใช้ทรัพยากรได้ทันทีโดยไม่ต้องใช้เครื่องมือแยกต่างหาก
  • การขยายและการจัดการ: ปรับขนาดคลัสเตอร์และจัดการได้อย่างสะดวกตามความต้องการ

ข้อดีและกลุ่มเป้าหมาย

  • ตัดความซับซ้อนของการปฏิบัติการ Kubernetes แบบดั้งเดิม ทำให้แม้แต่ นักพัฒนามือใหม่ ก็จัดการโครงสร้างพื้นฐานได้ง่าย
  • เป็น บริการบนบัญชีของตนเอง ที่ช่วยควบคุมค่าใช้จ่ายได้โดยตรง จึงลดความกังวลเรื่อง vendor lock-in
  • มอบสภาพแวดล้อมให้สตาร์ทอัพและผู้เชี่ยวชาญด้านไอทีสามารถ จัดการคลัสเตอร์ด้วยตนเอง และสร้างเวิร์กโฟลว์ DevOps ได้อย่างอิสระ

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

 
GN⁺ 2025-08-16
ความคิดเห็นจาก Hacker News
  • โชคดีแบบไม่คาดคิดจริง ๆ ได้รับฟีดแบ็กบน HN ด้วย แล้วก็ไปติด rate limit บน GitHub (อันนี้แก้ได้เร็ว) หลังจากนั้น Hetzner ก็มีปัญหาขัดข้องบางส่วน ทำให้สร้างคลัสเตอร์ใหม่ได้ไม่สมบูรณ์ ขอบคุณมากที่หลายคนให้ความสนใจ นี่เป็นโปรเจกต์ข้างที่ผมทำไว้ แต่ไม่เคยคาดเลยว่าจะออกมาเป็นแบบนี้ จากนี้ก็จะปรับปรุงแพลตฟอร์มต่อและนำฟีดแบ็กมาปรับใช้
  • สงสัยว่ามันต่างจากเครื่องมือที่รองรับ Hetzner อย่าง kops ที่รู้จักกันอยู่แล้ว (https://github.com/kubernetes/kops) อย่างไร
    • ตอนนี้เครื่องมือที่ง่ายที่สุดน่าจะเป็น https://github.com/vitobotta/hetzner-k3s มีตัวเลือกหลายแบบ และก็ขึ้นอยู่กับว่าคุณอยากควบคุมในระดับ low-level แค่ไหน โปรเจกต์ Hetzner terraform เป็นตัวเลือกที่ซับซ้อนและครบถ้วนที่สุด แต่ใช้เวลาตั้งค่ามาก ประเด็นหลักคือมุ่งทำให้การ deploy ไม่ใช่แค่ Kubernetes บน Hetzner แต่รวมถึงแอปที่จำเป็นต่อการขยายความสามารถของ Kubernetes เช่น ingress controller, prometheus, elasticsearch, ฐานข้อมูล ฯลฯ ทำได้ง่ายขึ้น
    • ยังมี Talos ด้วย รองรับ Hetzner และค่อนข้าง streamlined ไม่ได้เป็นไอเดียเดียวกันเป๊ะ ๆ แต่ใกล้เคียงมาก https://www.talos.dev/v1.10/talos-guides/install/cloud-platforms/hetzner
    • อยากรู้ว่ามันต่างจากการใช้ https://github.com/vitobotta/hetzner-k3s อย่างไร
    • คาดว่าความต่างคือ UI และการซัพพอร์ตเชิงพาณิชย์
  • ดูเหมือนเป็นวิธี deploy คลัสเตอร์ k8s ที่ใช้งานง่ายมาก แต่โซลูชันนี้ทำงานบนบริการคลาวด์ของ Hetzner ซึ่งตอนที่เรารันจริง ฝั่งคลาวด์เคยมีประสบการณ์ที่น่ากังวลอยู่บ้าง ลูกค้าของเรา deploy บนไลน์อัป bare metal ของ Hetzner ซึ่งฝั่งนั้นเสถียรมาก เหตุการณ์ร้ายแรงที่สุดคือมีการรีสตาร์ตเราเตอร์เป็นครั้งคราว ซึ่งแก้ได้ด้วยการ deploy แบบ multi-AZ ถ้าคลัสเตอร์ไม่ได้ใหญ่เกินระดับหนึ่ง การทำ custom bare metal deployment ก็อาจไม่คุ้มทั้งต้นทุนและแรงที่ลงไป ดังนั้นจะคอยติดตามโปรเจกต์นี้ต่อ
  • มีโปรเจกต์สำหรับ deploy k3s บน Hetzner ด้วย Terraform อยู่เหมือนกัน https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner ถึงจะไม่ใช่ประสบการณ์ที่ลื่นไหลที่สุด แต่ทุกอย่างโฮสต์เองทั้งหมด และปัญหาส่วนใหญ่ก็แก้ได้ด้วย Terraform หรือ SSH ดีใจที่ได้เห็น managed Kubernetes บน Hetzner
  • ยังไม่เคยเห็นไกด์ที่ทำ automation ให้ k8s บน bare metal instance อันทรงพลังของ Hetzner เลย โดยอุดมคติแล้วอยากได้แนวทางแบบ cattle แต่ถ้าใช้ bare metal ที่ CPU กับหน่วยความจำดีมากได้ด้วยก็น่าจะยอดเยี่ยม ดังนั้นคลัสเตอร์ของผมจึงมีทั้งโหนดคลาวด์และ bare metal เมื่อก่อนใช้ Hetzner virtual switch เพื่อทำ L2 network ระหว่างโหนดคลาวด์กับ bare metal แต่เดี๋ยวนี้ใช้ tailscale อย่างเดียวแล้ว เครื่องมือส่วนใหญ่ เช่น Terraform จะเพิ่มหรือลบโหนดผ่าน API แต่ถ้ามีฟีเจอร์ที่ทำให้ node class บางประเภทสร้างใหม่ไม่ได้ แต่สามารถ wipe/rebuild ได้ ก็น่าจะเป็นอุดมคติมาก
  • อาจจะนอกเรื่องนิดหน่อย แต่ตอนนี้ Raku ก็รองรับ Hetzner API แล้ว https://raku.land/zef:wayland/WWW::CloudHosting::Hetzner ตอนนี้เลยสามารถเขียนสคริปต์ automation สำหรับ deployment ด้วย Raku ได้แล้ว
  • เผื่อใครสนใจ ผมทำคอร์สแนวลงมือปฏิบัติที่อิงกับ Kube-Hetzner (https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner, 3k stars) ใกล้เสร็จแล้ว ครอบคลุมทั้งวิธีการทำงานด้วยสคริปต์ต่าง ๆ การสำรอง/กู้คืน และการฝึกเคสปัญหาที่เจอบ่อย ออกแบบมาให้ได้จับของจริงโดยไม่มี abstraction เพื่อให้เข้าใจหลักการ เพราะถ้าไม่เข้าใจ สักวันก็ต้องติดปัญหา Waiting list: https://shipacademy.dev
  • ผมดูไม่ออกเลยว่าบริษัทนี้ตั้งอยู่ที่ไหน หรือเป็นสแกมหรือเปล่า บนหน้าเว็บไม่มี imprint, ข้อมูลติดต่อ หรือที่อยู่จริง ใน privacy policy มีอีเมลอยู่ตัวหนึ่งแต่ก็ถูก cloudflare ซ่อนไว้ ระบุชื่อบริษัทว่า Edka Digital S.L. แต่ก็ไม่รู้ว่าจดทะเบียนอยู่ประเทศไหน ดูเหมือนจะเป็น EU VAT แต่ก็ไม่แน่ใจ เลยรู้สึกไม่ค่อยสบายใจ
    • สวัสดีครับ โปรเจกต์นี้เป็น side project ที่ผมทำคนเดียวในฐานะฟรีแลนซ์ส่วนตัว และผมเป็นฟรีแลนซ์ที่จดทะเบียนในสเปน หมายเลข VAT คือ ESY1848661G ตอนนี้ยังอยู่ในช่วงเก็บฟีดแบ็ก เลยยอมรับตามตรงว่าไม่คิดว่าจะได้รับความสนใจขนาดนี้ ผมจะปรับแก้ทั้ง privacy policy/terms of service ใหม่ทั้งหมด เดิมทีอยากเปลี่ยนเป็นบริษัทในภายหลัง แต่ตอนนี้ยังเป็นรูปแบบฟรีแลนซ์ธรรมดาอยู่ ฟีดแบ็กแบบนี้ช่วยให้แก้ไขให้ถูกต้องได้
  • ปัญหาใหญ่ที่สุดของการตั้งค่า k8s บน Hetzner คือ ไม่มีวิธีขยายจาก bare metal ขนาดเล็ก (1 โหนด) ไปสู่ขนาดกลาง (10~100 โหนด) ได้อย่างเหมาะสม ผมต่อ ingress node ด้วย Gateway API โดยปรับ Envoy จนสำเร็จแล้ว แต่ปัญหาคือ storage: Ceph Rook หนักเกินไปสำหรับรันบนเครื่องเดียว และยังหา wrapper ที่ช่วยย้ายจากการจัดการ local volume ไปเป็น distributed volume ได้ง่าย ๆ ไม่เจอ ถ้าให้ดีจริง ๆ ควรมี PV daemon ที่ทำงานได้เบาบนเครื่องเดี่ยว ย้าย PV อัตโนมัติได้ และเมื่อภายหลังย้ายไปใช้ Ceph หรืออย่างอื่น พร็อกซีก็ควรถอนตัวเองออกได้เอง
  • อยากรู้ว่าตอนสร้าง instance บน Hetzner ใช้ cloud-init หรือเปล่า ผมกำลังใช้สคริปต์ที่เขียนเองเพื่อเพิ่ม Ubuntu instance เข้าไปเป็น Docker Swarm node และถ้ามีโซลูชันแบบนี้ในเวอร์ชันสำหรับ Docker Swarm ด้วยก็คงดีมาก