- แพลตฟอร์มโอเพนซอร์สที่สร้างมาเพื่อให้นักพัฒนาเดี่ยวก็ใช้งาน Kubernetes ได้ง่าย โดยมอบความสะดวกใกล้เคียงกับ Heroku
- ทำงานบนสภาพแวดล้อม Docker และ Docker Compose และติดตั้งรวมถึงรันได้ด้วยคำสั่งง่ายๆ
- พัฒนาขึ้นเพื่อแก้ปัญหา ค่าใช้จ่ายด้าน IT ที่เพิ่มขึ้นอย่างไม่คาดคิด ซึ่งเคยพบในสตาร์ตอัปเดิม
- แทนที่จะใส่ความสามารถที่ซับซ้อน กลับเลือก เปิดเผยเฉพาะองค์ประกอบหลักอย่าง Ingress, Services, Deployments, Pods, CronJobs เพื่อคงความเรียบง่าย
- สามารถ ดีพลอยแอปโอเพนซอร์สได้เกือบทั้งหมดผ่าน Helm และยัง ดาวน์โหลดการตั้งค่า YAML เพื่อออกจาก Canine ได้
- เสริม ความสามารถที่ Kubernetes ไม่มีมาให้โดยพื้นฐาน เช่น บัญชีผู้ใช้ การดีพลอย และแดชบอร์ด เพื่อมุ่งเป็นแพลตฟอร์มพัฒนาที่เหมาะกับทีมขนาดเล็ก
ภาพรวม
- Canine เป็นแพลตฟอร์มโอเพนซอร์สสำหรับการดีพลอย Kubernetes ที่ออกแบบมาให้ดีพลอยแอปได้ง่ายเหมือน Heroku
- ทำงานอยู่บน Kubernetes cluster ของตัวเอง และหากจำเป็นก็สามารถดาวน์โหลดการตั้งค่า YAML ออกไปเพื่อ ใช้งานแบบกระจายศูนย์ต่อได้
- เปิดเผยเฉพาะ resource หลักอย่าง Ingress, Services, Deployments, Pods, CronJobs ทำให้ใช้งานได้เรียบง่ายและตรงไปตรงมา
มุมมองของปัญหา: โครงสร้างซับซ้อนและต้นทุนที่พุ่งสูง
- จากประสบการณ์การดำเนินงานสตาร์ตอัปเดิม พบว่า ค่าใช้จ่ายด้าน IT เพิ่มขึ้นเร็วกว่าที่คาดไว้อย่างมาก
- ค่าใช้จ่ายมักเพิ่มขึ้นตาม ความซับซ้อนขององค์กรและจำนวนบริการที่เชื่อมต่อกัน และหลายครั้งไม่ได้เกี่ยวข้องกับปริมาณการใช้เซิร์ฟเวอร์หรือคอมพิวต์โดยตรง
- เครื่องมือจาก third-party ต่อไปนี้สะสมจนทำให้ต้นทุนด้าน IT พุ่งสูง:
- เครื่องมือด้านข้อมูล เช่น Looker, Redshift, Databricks, DBT Cloud, FiveTran
- เครื่องมือมอนิเตอร์ เช่น Datadog, New Relic, Sentry
- เครื่องมือโครงสร้างพื้นฐาน เช่น Google Maps API, AWS
- แม้บางส่วนจะสามารถแทนที่ด้วยโอเพนซอร์สได้ แต่ก็ลังเลที่จะนำมาใช้เพราะ ภาระในการจัดการโครงสร้างพื้นฐานสำหรับมอนิเตอร์, health check และการแจ้งเตือน
ศักยภาพและข้อจำกัดของ Kubernetes
- Kubernetes เป็น แพลตฟอร์มที่ขยายได้ตั้งแต่ single node ไปจนถึงหลายพัน cluster และแทบทุกคลาวด์ก็มีให้เป็นมาตรฐาน
- แต่สำหรับผู้เริ่มต้นและทีมขนาดเล็ก มันถูกมองว่าเป็น ระบบที่ซับซ้อนและพังได้ง่าย
- โดยเฉพาะความผิดพลาดอย่างการลบ CoreDNS อาจทำให้ทั้ง cluster ใช้งานไม่ได้
- เมื่อภาระด้านต้นทุนและการปฏิบัติการสะสมขึ้น PaaS แบบ abstraction เดิมกลับกลายเป็นตัวฉุดรั้ง
คุณสมบัติของ Canine
- เปิดเผยเฉพาะความสามารถขั้นต่ำที่จำเป็นของ Kubernetes เพื่อ รักษาความเรียบง่ายและความสามารถในการควบคุม
- ส่วนที่ขาดได้รับการเสริมด้วยความสามารถต่อไปนี้:
- การจัดการบัญชีผู้ใช้
- การจัดการการดีพลอย
- การรันสคริปต์ one-off แบบง่าย
- แดชบอร์ด metrics
- ด้วย แพลตฟอร์มดีพลอยที่ใช้งานเข้าใจง่าย แม้ผู้เริ่มต้นก็สามารถดีพลอยแอปพลิเคชันบนสภาพแวดล้อม Kubernetes ได้สะดวก
- หากเตรียมเพียง Docker และ Docker Compose ก็สามารถติดตั้งและรันได้ด้วยคำสั่งเพียงครั้งเดียว
- มี สภาพแวดล้อมการจัดการผ่าน UI ที่ช่วยลดภาระจากการตั้งค่าซับซ้อนและการบำรุงรักษา Kubernetes
- ด้วย การผสานรวม Helm จึงดีพลอยแอปโอเพนซอร์สอย่าง Sentry ได้ง่าย
การย้ายระบบและอิสระในการใช้งาน
- Canine ใช้งานโดยวางซ้อนอยู่บน Kubernetes เดิม จึงย้ายออกได้ง่ายเช่นกัน
- ทุกการตั้งค่าสามารถดาวน์โหลดออกมาเป็น YAML ได้ ทำให้ย้ายไปแพลตฟอร์มอื่นในภายหลังได้สะดวก
ความสำคัญและจุดแตกต่าง
- เมื่อเทียบกับเครื่องมือ Kubernetes ทั่วไป มี UI ที่ เป็นมิตรกับผู้เริ่มต้น และขั้นตอนติดตั้งที่ง่ายกว่า
- นำประสบการณ์การใช้งานแบบ Heroku เข้ามาสู่ ecosystem ของ Kubernetes ช่วยลดอุปสรรคในการเริ่มต้นได้อย่างมาก
- ด้วยพื้นฐานแบบโอเพนซอร์ส จึงมี ความยืดหยุ่นในการขยายต่อ และเปิดโอกาสให้ชุมชนมีส่วนร่วมในการพัฒนา
- คาดว่าจะเกิดประโยชน์อย่างมากเพราะแม้แต่ ทีมพัฒนาขนาดเล็ก หรือสตาร์ตอัปก็สามารถใช้ข้อดีของ Kubernetes ได้อย่างง่ายดาย
- ใช้งาน แจกจ่าย และแก้ไขได้อย่างอิสระภายใต้ Apache 2.0 License
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผมเป็นคนที่คอยมองหาโซลูชันที่ดีกว่าอยู่เสมอเพื่อให้ได้ “ประสบการณ์แบบ Heroku” บนเซิร์ฟเวอร์ของตัวเอง เลยรู้สึกยินดีมาก
เอกสารเกี่ยวกับ Kubernetes ของ Canine เข้าถึงง่ายมาก และให้ความรู้สึกว่าเป็นมิตรที่สุดเท่าที่เคยเห็นมา
พออ่านเอกสารแล้วก็เกิดคำถามขึ้น: ตอนแรกหวังว่าจะใช้ Canine บนสภาพแวดล้อม managed K8s อย่าง Digital Ocean ได้ แต่พออ่านแล้วรู้สึกเหมือนต้องดูแล K8s cluster เอง
มีคำถามอยู่ไม่กี่ข้อ
โดยทั่วไปแบบแรกเหมาะกับแอป staging/พัฒนา และแบบที่สองเหมาะกับแอป production
ในกรณีของแบบที่สอง คุณจัดการจำนวนโหนดบน Digital Ocean หรือที่อื่นเอง แล้ว Kubernetes ก็จะ reschedule workload อัตโนมัติและใช้ความสามารถ autoscale ได้
นี่น่าจะเป็นใจความของคำถาม แต่ Canine ยังไม่รองรับการสร้าง multi-node cluster บน Hetzner ด้วยตัวเองโดยตรง
มี terraform ของ Hetzner สำหรับสร้าง K8s cluster อยู่เหมือนกัน แต่ Canine ยังไม่ได้ฝังสิ่งนั้นมาให้
พอปรับปรุง UI อะไรต่าง ๆ แล้วก็สนใจจะทำอยู่
ตอนนี้คือช่วยได้ผ่านคู่มือติดตั้ง K3s บน VPS เดียว หรือใช้ในกรณีที่มี cluster เตรียมไว้แล้ว
ลิงก์อ้างอิง: terraform-hcloud-kube-hetzner
ในฐานะคนที่คิดว่าโปรเจ็กต์แบบนี้จำเป็นมาก ก็ขอเป็นกำลังใจให้
ถ้าเป็นวันนี้ผมน่าจะเลือกระหว่าง Canine กับ Dokploy (และก็คิดว่า Docker Swarm เป็นเทคโนโลยีที่คนประเมินค่าต่ำไป)
ข้อเสนอแนะ: ตอนเห็นเซกชัน “ทำไมคุณไม่ควรใช้ Canine” ตอนแรกคิดว่าจะตรงไปตรงมาและสดใหม่ แต่กลับรู้สึกว่ามีน้ำเสียงประชดนิด ๆ จนไม่ค่อยสบายใจ
อยากให้เขียนตรง ๆ ไปเลยมากกว่าว่าคุณต้องซื้อและดูแลเซิร์ฟเวอร์เอง ถ้าล่มก็ต้องรับผิดชอบเอง และนี่คือผลิตภัณฑ์ช่วงแรกจากนักพัฒนาเดี่ยว ซึ่งเป็นข้อเสียที่เป็นจริงและควรบอกให้ชัด
สงสัยว่า Docker Swarm ตอนนี้สถานะด้านการบำรุงรักษาและการรองรับเป็นอย่างไร
ขอแชร์ว่าหลายปีก่อนเหมือนทีม Docker ปัจจุบันหยุดพัฒนาไปแล้ว เลยเลิกตามต่อ
เขียนแบบนั้นเพื่อพยายามให้ต่างจาก landing page อื่น ๆ แต่ขอบคุณมากสำหรับ feedback จากผู้ใช้จริง
ตั้งใจว่าจะลองใหม่อีกครั้ง
ขอแชร์ลิสต์ที่รวบรวมแพลตฟอร์ม PaaS ต่าง ๆ ที่มีอยู่ในโลกนี้
awesome-paas
กำลังหาดูอยู่พอดีว่าจะส่งโปรเจ็กต์เข้าไปในลิสต์แบบนี้อย่างไร ขอบคุณมาก เดี๋ยวจะไปเปิด PR
dokku เป็นแพลตฟอร์ม PaaS แบบมินิมัลที่รันบน VPS ได้ และก็มี dokku-scheduler-kubernetes ด้วย
dokku-scheduler-kubernetes
แต่ไม่รองรับ Helm chart
ยังมีการสรุปโครงสร้าง cloud computing โดยรวมและลิงก์เปรียบเทียบหลายแบบไว้ด้วย
Cloud computing architecture
Cloud-computing comparison
Category:Cloud_platforms
ใน awesome-selfhosted ก็มี serverless/FaaS เหมือนกัน โดยลิงก์ไปที่ awesome-sysadmin > PaaS
awesome-selfhosted FaaS/Serverless
มีคำถามถึง OP(ผู้เขียน)
อยากรู้ว่าพื้นหลังที่ทำให้สร้างโปรเจ็กต์นี้คืออะไร
ผมเองก็มีความอยากทำอะไรซับซ้อนสักอย่างตั้งแต่ต้นจนจบเหมือนกัน แต่ที่เคยทำมีแค่การรวม API กับ React
เลยอยากรู้ว่าคุณแตกไอเดียที่ซับซ้อนออกเป็นงานย่อยที่ทำได้จริง แล้วทำให้มันเกิดขึ้นเป็นโอเพนซอร์สโปรเจ็กต์ระดับ “ทางเลือกแทน Heroku” ได้อย่างไร
ผมแทบไม่มีประสบการณ์ใช้ Heroku เลย เวลาจะหาว่า “ควรทำฟีเจอร์อะไร” ก็คงไปดูจากหน้าราคาอะไรทำนองนั้น แต่ก็กลัวว่าวิธีนี้จะไม่มีประสิทธิภาพ
แนวคิด Heroku ทางเลือกที่สร้างบน Kubernetes ฟังดูน่าสนใจ
แต่ถ้าจะใช้แล้วต้องรู้เรื่อง K8s หรือ Helm chart ด้วย สำหรับผมมันก็แทบไม่ใช่ Heroku ทางเลือก
แน่นอนว่าผมเข้าใจว่าจากมุมของผู้ดูแลระบบ มันอาจง่ายแค่ระดับ echo hello ก็ได้
แต่ถ้าผมแค่อยากเอาอะไรขึ้นระบบให้เร็วที่สุด ผมไม่อยากแม้แต่จะนึกถึงคำว่า “Kubernetes และ Helm chart”
ผู้ใช้ไม่จำเป็นต้องรู้ด้วยซ้ำว่า Kubernetes มีอยู่ และยังได้ใช้ประโยชน์จาก ecosystem ที่สุกงอมของมัน
และถ้าวันไหนต้องการความสามารถขั้นสูงขึ้น ก็ยังเปิดใช้ฟีเจอร์ระดับผู้เชี่ยวชาญอย่าง Kubernetes API ได้โดยตรงทุกเมื่อ
เป็นจุดเล็ก ๆ แต่ขอทักไว้
Kubernetes ไม่ได้รัน docker container แต่รัน container ตามมาตรฐาน Open Container Initiative(OCI)
Docker เป็นชื่อทางการค้า
อีกจุดเล็ก ๆ เช่นกัน:
ใน Canine Kubernetes Crash Course มีคำอธิบายว่า “รองรับเซิร์ฟเวอร์ 10,000 เครื่อง”
แต่เอกสารทางการระบุว่า Kubernetes รองรับได้สูงสุด 5,000 โหนด
ดูเอกสารทางการของ kubernetes
จะทำ cluster ที่ใหญ่กว่านั้นมากก็ได้ แต่ตอนนั้นต้องคัสตอมหนักมาก (เช่นเปลี่ยน API registry ทั้งชุด)
และแน่นอนว่า workload ก็มีผล
Kubernetes ยังไปไม่ถึงขั้นรองรับ cluster ขนาดใหญ่มากแบบ out-of-the-box แต่ก็ดีขึ้นทุกรีลีส
ผมไม่ชอบถ้าบอกว่าจำเป็นต้องใช้ docker
ทุกวันนี้มักรันบน podman หรือ containerd แทน docker
การทำโปรเจ็กต์นี้สนุกมากจริง ๆ และเป็นการพัฒนาที่สนุกที่สุดในชีวิตผม
ความรู้สึกที่ได้ถือ “tech stack” ทั้งหมดไว้ในมือเดียวนั้นยอดเยี่ยมมาก
ทั้ง Rails app, infra ของ Canine, เซิร์ฟเวอร์ Raspberry pi, ไปจนถึง ISP ที่ผมใช้อยู่
ขอแชร์ประสบการณ์การเอาแอปขึ้นระบบโดยที่ดูแลทุกอย่างด้วยตัวเองทั้งหมด
บนเว็บไซต์ระบุไลเซนส์เป็น 2024 MIT License
แต่บน github จริง ๆ ระบุเป็น apache license
มากกว่าประเด็นว่าปีถูกหรือไม่ ผมคิดว่าประเภทไลเซนส์ต่างหากที่เป็นความต่างสำคัญ
เลยอยากรู้ว่าไลเซนส์ที่ใช้จริงคืออะไร
ในการ self-hosting ผมอยากได้อะไรที่อยู่กึ่งกลางระหว่าง docker กับ K8s เลยเคยหาของแนวนี้เองเหมือนกัน
เคยพิจารณา Nomad ด้วย แต่ก็ยังซับซ้อนกว่า dead simple docker อยู่เล็กน้อย และ ecosystem ก็ยังไม่พร้อม
สุดท้ายเลยรัน home server ด้วย docker อย่างเดียว และยอมรับ downtime ระหว่าง deploy
ใน production เลยอยากรู้ว่า Canine ช่วย abstract K8s ไปได้แค่ไหน
จะมีจุดที่ต้องลงไปดูภายในอยู่ไหม ในฐานะคนที่ยังใหม่กับ K8s ก็ยังสงสัยว่าจุดกึ่งกลางแบบนั้นทำได้จริงหรือเปล่า
uncloud
เป้าหมายคือให้ CLI แบบ Docker และความสามารถ multi-machine/production แบบ Docker Compose โดยยังคงความเรียบง่ายและไม่ต้องมี control plane สำหรับปฏิบัติการ
ตอนนี้ยังอยู่ระหว่างพัฒนา แต่เป้าหมายคือให้เข้าใจได้ง่ายว่าเกิดอะไรขึ้นในทุกเลเยอร์ และ troubleshooting ได้ง่ายด้วย
ชอบคอนเซปต์นี้มากจริง ๆ
K8s เป็นเทคโนโลยีที่ยอดเยี่ยม แต่ความซับซ้อนของมันคืออุปสรรคในการเริ่มต้น
จากข้อมูลที่เปิดเผยออกมาดูเหมือนเข้าใจแก่นของปัญหาได้ดี
คาดว่าน่าจะมีประโยชน์มากขึ้นในสาย self-hosting ที่โซลูชันอย่าง PVE, Microcloud, Cockpit กำลังได้รับความนิยม
ผมมี N100 NUC ที่บ้านวางทิ้งไว้เครื่องหนึ่ง ตอนนี้เริ่มอยากเลิกใช้ Microcloud แล้วลองทดสอบ Canine ดู
บางครั้ง helm ก็ชวนให้ยุ่งยาก
งงว่า value ไหนใน values.yaml เปลี่ยนแล้วมีผลได้เลย กับ value ไหนที่ต้องตั้งตั้งแต่แรก
บางชุดติดตั้งผ่าน helm มี service เยอะมากจนสับสนว่าอะไรรีสตาร์ตได้เมื่อไร
ในทางกลับกัน core kubernetes ใช้งานกับ stateless job ได้ลื่นไหลมาก
ทุกวันนี้ผมไม่ค่อยเข้าใจแล้วว่าคนพูดถึง “ความซับซ้อน” ของ K8s มาจากไหน
สมัยก่อนมีเรื่องอย่างตั้ง kubespray กันสองชั่วโมง
แต่เดี๋ยวนี้ถ้าใช้เครื่องมืออย่าง rke ก็สร้าง cluster ได้ด้วยไฟล์ yaml ไฟล์เดียวกับ ssh key อันเดียว