ผมไม่ได้ต้องการ Kubernetes และคุณก็คงไม่ต้องการมันเช่นกัน

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

เหตุผลที่ผมเลิกใช้ Kubernetes แล้วเลือก Google Cloud Run

ที่มาของการนำ Kubernetes มาใช้

  • บนแพลตฟอร์มแก้ไข 3D ออนไลน์ Clara.io ที่เปิดตัวในปี 2013 ได้ใช้ เซิร์ฟเวอร์แบบ bare metal เพื่อปรับแต่งโครงสร้างพื้นฐานให้เหมาะสมที่สุด แต่ต้องใช้แรงงานมากเกินไปกับการดูแลฮาร์ดแวร์และมอนิเตอร์ริง
  • ในโปรเจกต์ Threekit.com ปี 2018 ได้เลือกใช้ Kubernetes ในช่วงที่ Azure, AWS, Docker รับ Kubernetes เป็นมาตรฐานและเริ่มกลายเป็นกระแสหลัก

ข้อจำกัดของ Kubernetes

  1. ปัญหาเรื่องต้นทุน:

    • ค่าใช้จ่ายพื้นฐานในการสร้างคลัสเตอร์สูง ทั้งโหนดสำหรับการจัดการและการทำคลัสเตอร์แบบซ้ำซ้อน
    • ออโตสเกลที่ช้าทำให้ต้องจัดสรรทรัพยากรเกินความจำเป็น และเกิดค่าใช้จ่ายจากทรัพยากรที่ไม่ได้ใช้งาน

  2. ความยากในการจัดการเวิร์กโหลด:

    • การจัดตารางงานมีความซับซ้อน และทั้งตัว scheduler ในตัวกับ Argo ก็ไม่มีประสิทธิภาพเมื่อต้องจัดการงานจำนวนมาก

  3. ภาระจากความซับซ้อนที่มากเกินไป:

    • ฟีเจอร์ที่มีมากมายทำให้งานง่าย ๆ กลายเป็นเรื่องซับซ้อน
    • ต้องมีบุคลากร DevOps เฉพาะสำหรับดูแล Kubernetes ซึ่งนำไปสู่ต้นทุนที่สูงขึ้น

เปลี่ยนไปใช้ Google Cloud Run

Cloud Run เข้ามาแทนความซับซ้อนของ Kubernetes ด้วยสภาพแวดล้อมที่เรียบง่ายและคุ้มค่ากว่า

การตั้งค่าใหม่

  • โครงสร้างพื้นฐานแบบ Docker container:
    • มีทั้งคอนเทนเนอร์สำหรับ บริการที่สเกลอัตโนมัติ และ งานที่รันระยะยาว
    • Cloud Run ทำงานคอนเทนเนอร์ การดีพลอย การสเกล การจัดการ downtime และการรันงานให้โดยอัตโนมัติ

ข้อดีของ Cloud Run

  1. ความคุ้มค่าด้านต้นทุน:

    • คิดค่าบริการตามเวลาการใช้งาน CPU และหน่วยความจำ
    • ไม่มีค่าใช้จ่ายสำหรับบริการที่ไม่ได้ใช้งาน
    • ตัวอย่าง: เว็บไซต์ Web3D Survey รองรับทราฟฟิก 500,000 ครั้งต่อเดือน ได้ด้วยค่าใช้จ่ายเพียง $4/เดือน

  2. ออโตสเกลที่เร็วและเสถียร:

    • สเกลได้ภายในไม่กี่วินาที เร็วกว่า Kubernetes
    • รับมือกับความต้องการที่พุ่งสูงขึ้นได้อย่างรวดเร็ว

  3. ไม่มีภาระในการดูแล Kubernetes:

    • Cloud Run ทำงานบนพื้นฐาน Borg ของ Google จึงไม่ต้องจัดการ Kubernetes cluster

  4. งานอะซิงก์ที่เรียบง่าย:

    • ใช้ Cloud Run Tasks เพื่อรีทรายอัตโนมัติและรันงานจำนวนมากได้อย่างสะดวก

ปัญหาที่อาจเกิดจาก Kubernetes: การติดล็อกกับคลัสเตอร์

  • หากพึ่งพาฟังก์ชันของ Kubernetes มากเกินไป จะทำให้การผสานหรือขยายทรัพยากรที่อยู่นอกคลัสเตอร์ทำได้ยาก
  • กลายเป็นการผูกติดกับโครงสร้างพื้นฐานเฉพาะ ส่งผลให้การขยายระบบและการย้ายระบบซับซ้อนขึ้นและมีค่าใช้จ่ายเพิ่มขึ้น

คำถามทั่วไปเกี่ยวกับการใช้ Cloud Run

“ไม่กังวลเรื่องการผูกติดกับ GCP เหรอ?”

  • ด้วยการตั้งค่าที่อิง Docker จึงสามารถย้ายไปคลาวด์อื่นอย่าง AWS ได้ภายในราว 1 สัปดาห์
  • ในความเป็นจริง นอกจากเหตุผลทางการเมืองแล้ว กรณีที่ต้องเปลี่ยนผู้ให้บริการคลาวด์เกิดขึ้นไม่บ่อยนัก

“สุดท้ายแล้ว Cloud Run ก็คือ Managed Kubernetes ไม่ใช่เหรอ?”

  • แม้ Cloud Run จะใช้อินเทอร์เฟซ Knative แต่ทำงานอยู่บน Borg ของ Google ไม่ใช่บน Kubernetes
  • จึงตัดความซับซ้อนของ Kubernetes ออกไปและมอบอินเทอร์เฟซที่เรียบง่ายกว่า

ข้อเสียของเวิร์กโฟลว์ปัจจุบัน

  1. การจัดการชื่อบริการไม่สะดวก:

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

  2. ขาดการจำลอง Cloud Run Task:

    • ยังไม่มีสภาพแวดล้อมจำลองง่าย ๆ สำหรับพัฒนางานบนเครื่องโลคัล รวมถึงการจับและติดตาม log output

สรุป

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

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

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

 
blurblah 2024-12-01

คงไม่มี silver bullet อะไรแบบนั้นหรอกครับ ถ้าใช้ให้เหมาะกับสถานการณ์ก็น่าจะพอแล้ว
ถ้าหยิบ kubernetes มาใช้แบบไม่วิจารณญาณเพียงเพราะมันเป็นของที่กำลังฮิต ก็อาจจะทำให้ลำบากขึ้นได้ แต่ผมก็ยังคิดว่าสำหรับสภาพแวดล้อมที่มีขนาดค่อนข้างใหญ่ มันเป็นเครื่องมือที่ใช้ได้ดี
ต่อให้ตัดสินใจนำมาใช้ ถ้าแค่นำมาใช้แล้วจบ ก็อาจจะใช้งานมันได้ไม่เต็มที่
แล้วก็เหมือนกับเครื่องมืออื่น ๆ ไม่มีอะไรที่ตอบโจทย์ความต้องการของนักพัฒนาหรือผู้ใช้ได้ 100% ดังนั้นการทำระบบอัตโนมัติในระดับที่เหมาะสมจึงน่าจะเป็นสิ่งจำเป็นครับ
 
bungker 2024-11-29

แค่ตั้งค่า Kubernetes เสร็จก็เหลือแต่งานสบาย ๆ ... ฮือ ๆ
 
riki3 2024-11-29

Kubernetes คืออาชีพการงานของผม และก็เคยมีช่วงหนึ่งที่ผมเชื่อว่านี่คือคำตอบ แต่เมื่อเวลาผ่านไป ผมก็พบว่าตัวเองต้องเจอกับปัญหามากมายและเสียเวลาไปโดยเปล่าประโยชน์

ผมยังแนะนำ k8s ให้คนอื่นอยู่ แต่คงจะไม่ใช้กับบริการของตัวเองแล้วครับ จะว่าไปไม่ใช่แค่ k8s อย่างเดียว ผมเริ่มเหนื่อยกับคอนเทนเนอร์ไปทั้งหมดแล้ว
 
joon14 2024-11-28

ถ้าใช้งาน AWS อยู่ ก็ควรมองว่าใกล้เคียงกับ ECS ได้ไหม?
 
tujuc 2024-11-29

ใช่ครับ/ค่ะ ถ้าจะให้พูดก็คือประมาณนั้น :)
 
eclipsense 2024-11-28

การใช้ Kubernetes ไม่เป็นต่างหากที่เป็นปัญหา จะให้บอกว่า Kubernetes ไม่ค่อยดีนักก็คงไม่ถูกเท่าไร
 
tujuc 2024-11-28

ผมก็คิดคล้ายกับผู้เขียนครับ
ตอนนี้บริษัทก็ยังไม่ได้มีขนาดถึงขั้นต้องใช้ kube ด้วย

ผมเคยคิดไปเองว่านักพัฒนาทุกคนคงจะจัดการด้วย Kube ได้
แต่เอาเข้าจริง การมีแนวทางที่ช่วยให้สามารถวางโครงสร้างพื้นฐานและแก้ปัญหาได้ แม้จะทำได้ไม่ถึงระดับเฉลี่ยของนักพัฒนาในบริษัท กลับดีกว่า...
 
doolayer 2024-11-28

???: ผมไม่ได้ต้องการ AI และพวกคุณก็คงไม่ได้ต้องการมันเช่นกัน
 
ilbanin00 2024-11-28

ไม่ว่าผลิตภัณฑ์ไหนก็มักจะมีส่วนที่ต้องแลกเปลี่ยนกันอยู่
 
bbulbum 2024-11-28

พอใช้บริการแบบ managed ก็ไม่ได้รู้สึกว่าจัดการยากเป็นพิเศษ,,
ไม่ว่าเครื่องมือไหน ถ้าใช้ให้พอเหมาะก็มีประโยชน์ทั้งนั้น แต่รู้สึกว่า Kubernetes กลับถูกวิจารณ์อยู่บ่อย ๆ โดยเฉพาะเรื่องที่ว่า 'ตั้งค่าที่ซับซ้อนได้'
 
tujuc 2024-11-28

เพราะเป็นเทคโนโลยีที่ทำเกือบทุกอย่างได้ตามที่ฉันต้องการ... :) เลยคิดว่าน่าจะเป็นเพราะหลายคนมักใช้งานมันแบบซับซ้อนเกินไป 5555...
 
GN⁺ 2024-11-28
ความเห็นจาก Hacker News

  • แสดงความคิดเห็นไม่พอใจต่อ "เทคโนโลยีคลาวด์" โดยระบุว่าเมื่อใช้ Kubernetes จะต้องเสียเวลาไปมากกับการแก้ไขไฟล์ YAML และแก้ปัญหาข้อผิดพลาด อีกทั้งยังอยากหลีกเลี่ยงการผสานรวมกับคลาวด์และตั้งค่าเซิร์ฟเวอร์เอง

  • Kubernetes มีต้นทุนโครงสร้างพื้นฐานค่อนข้างสูง นอกเหนือจากงานด้าน DevOps และเวลาที่ใช้ดูแลจัดการ พร้อมเสนอว่าการใช้ Kubernetes แบบ managed ของผู้ให้บริการคลาวด์จะมีประสิทธิภาพมากกว่า

  • Kubernetes ไม่ใช่เครื่องมือ orchestration สำหรับคอนเทนเนอร์ แต่เป็นเครื่องมือสำหรับสร้างคลัสเตอร์คอมพิวเตอร์ ดังนั้นหากไม่ต้องการคลัสเตอร์ก็ไม่จำเป็นต้องใช้ Kubernetes

  • การลงทุนกับ DevOps มากเกินไปกำลังลดลง และมีการแชร์มุมมองเชิงวิพากษ์ต่อ Kubernetes พร้อมย้ำว่าสำหรับสตาร์ทอัพขนาดเล็ก เซิร์ฟเวอร์เพียงเครื่องเดียวก็อาจเพียงพอ

  • กล่าวถึงข้อควรระวังในการใช้ Cloud Run เช่น ข้อจำกัดของการเชื่อมต่อ TCP การเลือกสภาพแวดล้อมรันไทม์ และการตั้งค่า autoscaling

  • Cloud Run เหมาะกับสตาร์ทอัพขนาดเล็ก แต่ชี้ให้เห็นว่ายังขาดการควบคุมไฟร์วอลล์ซึ่งเป็นองค์ประกอบพื้นฐานของสถาปัตยกรรมความปลอดภัย และสุดท้ายก็จะจำเป็นต้องใช้ VPC

  • ระบุว่าการเปรียบเทียบ Google Cloud Run กับ Kubernetes นั้นไม่ยุติธรรม พร้อมอธิบายข้อดีข้อเสียของแต่ละแบบ และเน้นว่า Kubernetes เหมาะกับงานที่ซับซ้อน

  • อธิบายว่า Kubernetes มีเส้นโค้งการเรียนรู้ที่ชัน แต่ถ้าใช้อย่างเหมาะสมก็เป็นเครื่องมือที่ทรงพลัง

  • ไม่เห็นด้วยกับคำวิจารณ์ต่อ Kubernetes และเน้นว่าเมื่อต้อง deploy แอปที่ซับซ้อน อาจจำเป็นต้องใช้ Kubernetes API

  • อธิบายว่าความซับซ้อนของ Kubernetes ส่วนใหญ่มาจากงานด้านการดูแลระบบ ขณะที่ตัว Kubernetes เองมีความเสถียร

  • ชี้ว่า IaC และ CM ควรช่วยลดจำนวนการตั้งค่าและทำให้ดูแลง่ายขึ้น แต่ในความเป็นจริงกลับต้องใช้ความพยายามมากขึ้น หลายกรณีไม่จำเป็นต้องใช้ Kubernetes และผู้ดูแลระบบที่เก่งมีความสำคัญมากกว่า