17 คะแนน โดย kuber 2023-08-04 | 4 ความคิดเห็น | แชร์ทาง WhatsApp

[แนะนำ]
Kuberian = Kubernetes + Librarian
เป็นโปรเจกต์เล่น ๆ ที่พัฒนาขึ้นด้วยความรู้สึกประมาณว่าเป็น “บรรณารักษ์ของ Kubernetes”

[การใช้งาน]
มีเป้าหมายเพื่อให้ค้นหาฟังก์ชันที่ทำหน้าที่ตามที่ต้องการได้อย่างรวดเร็ว จากฟังก์ชันกว่า 40,000 ตัวที่มีอยู่ใน Kubernetes Repository

[วิธีใช้]
หากเขียนประโยคภาษาอังกฤษที่เหมาะจะขึ้นต้นด้วย that ระบบจะค้นหาฟังก์ชันที่คล้ายที่สุดให้

[ตัวอย่างการค้นหา]

  • makes scaling decision link
    • คิวรีที่ใช้เพื่อดูว่าตัดสินใจเรื่องออโตสเกลจากเกณฑ์อะไร
  • checks if the system supports IPVS link
    • คิวรีที่ใช้ตอนต้องการหาฟังก์ชันที่ตรวจสอบว่าระบบรองรับ IPVS หรือไม่
  • make requests for checking readiness of the container link
    • คิวรีที่ใช้ตอนต้องการหาฟังก์ชันที่ส่งคำขอ Readiness Probe

โดยคร่าว ๆ คือแค่โยนประโยคในรูปอนุประโยคหลัง that เข้าไป ระบบก็จะหาฟังก์ชันที่ใกล้เคียงที่สุดให้พอเหมาะ

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

[เทคโนโลยีที่ใช้]

  • Llama 2
  • Rust
  • eui (Elasticsearch UI)
  • Knative w/ Google Cloud Run

[ความเห็นหลังใช้งาน]
พอได้ใช้ Google Cloud Run แล้ว ก็รู้สึกว่าวันเวลาที่เคยกังวลกับ AWS Lambda ดูเสียเวลาไปเลย เหมือนเป็นเทคโนโลยีคลาวด์ที่ถูกประเมินค่าต่ำเกินไป แถมราคาก็ถูกจนน่าทึ่ง ลองใช้กันดูครับ!

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

 
roxie 2023-08-06

เป็นโปรเจ็กต์ที่เจ๋งมากเลยครับ! นอกจาก GeekNews แล้ว ลองไปโปรโมตที่อื่นด้วยเป็นอย่างไรบ้าง?

แล้วผมก็อยากฟังความเห็นเกี่ยวกับ CloudRun เพิ่มเติมเหมือนกันครับ

 
kuber 2023-08-07

ผมได้ฝากความเห็นเกี่ยวกับ CloudRun ไว้ในคอมเมนต์ด้านล่างแล้วครับ :-)

ได้เปิดเผยบน Hacker News ล่วงหน้าเพื่อทดลองดูรูปแบบการใช้งานของผู้ใช้ครับ ฮ่าๆ
(กำลังใช้งาน Google Analytics อยู่ครับ)

มีคอมมูนิตี้อื่นที่อยากแนะนำไหมครับ? สำหรับผมเองก็ยังนึกที่อื่นออกไม่ค่อยมากนัก

 
jwseo 2023-08-06

โอ้ เป็นโปรเจกต์ที่น่าสนใจมากเลยครับ!
มีจุดไหนบ้างที่ทำให้ Google Cloud Run น่าพอใจกว่า AWS Lambda? ผมเองก็เคยใช้แต่ Lambda เลยอยากรู้เหมือนกันครับ

 
kuber 2023-08-07

ตั้งใจว่าจะอธิบายรายละเอียดทีหลังในรูปแบบโพสต์บล็อกหรืออะไรทำนองนั้น แต่ถ้าหยิบมาเฉพาะไม่กี่ประเด็นแบบสั้น ๆ โดยจำกัดอยู่ที่สภาพแวดล้อม HTTP API ก็จะมีประมาณนี้

HTTP
Lambda: ต้องเขียนลอจิกเพื่อรับ RPC call จาก APIGateway และประมวลผลคำขอ
Cloud Run: สื่อสารผ่าน HTTP ทั่วไป / ใช้ไลบรารีหรือเฟรมเวิร์กที่อิง HTTP ได้ตามปกติ

Concurrency
Lambda: 1 อินสแตนซ์จะประมวลผลได้เพียง 1 คำขอในเวลาเดียวกันเท่านั้นเสมอ (ถ้ามีคำขอเข้ามา 100 คำขอพร้อมกัน ก็ต้องรัน 100 อินสแตนซ์)
Cloud Run: 1 อินสแตนซ์สามารถประมวลผลพร้อมกันได้จนถึงขีดจำกัดที่ผู้ใช้กำหนด
คำอธิบายเพิ่มเติม: ถ้าเทียบเป็นรายชั่วโมง Cloud Run แพงกว่า Lambda ประมาณ 1.5 เท่า แต่ถ้า 1 อินสแตนซ์รองรับ Concurrency ได้ 100 ก็จะถูกลงประมาณ 1.5/100

Cold / Warm / Hot
Lambda: นอกจาก Cold และ Hot แล้วยังมีสถานะ Warm ที่ไม่ให้ทรัพยากร CPU ทำให้ส่งข้อมูลอย่างพวก APM ได้ยากมาก (เพราะถ้าทำให้ความเร็วในการตอบสนองช้าลงเพื่อส่งข้อมูล APM ก็มักจะไม่คุ้ม...) พวก DB Connection เองก็อาจถูกตัดตอนอยู่ในสถานะ Warm หรือไม่ก็ปล่อยทรัพยากรได้ไม่สมบูรณ์ จนสุดท้ายใช้ DB Connection Pool หมดทั้งก้อน
Cloud Run: มีแค่ Cold กับ Hot เท่านั้น ถึงอย่างนั้นถ้าเทียบแบบ AWS ก็คิดค่าบริการเพียงเท่ากับความเร็วตอบสนองของ API Gateway และตอนจะปิดก็ให้โอกาสจัดการทรัพยากรได้อย่างเหมาะสม

สภาพแวดล้อมการพัฒนา
Lambda: ตั้งค่าสภาพแวดล้อมพัฒนาบนเครื่องโลคัลได้ค่อนข้างยาก หรือมีข้อจำกัดด้าน ecosystem ของภาษา / สถาปัตยกรรม CPU สูงมาก
Cloud Run: เหมือนกับสภาพแวดล้อมการพัฒนาทั่วไป

ความสามารถในการย้ายระบบ
Lambda: โค้ดที่เขียนสำหรับ Lambda จะผูกกับ Lambda ทำให้ย้ายไปแพลตฟอร์มอื่นได้ยาก
Cloud Run: ย้ายไปสภาพแวดล้อม Kubernetes ได้โดยไม่ต้องแก้โค้ด

ยังมีอีกหลายอย่างนอกจากนี้ แต่ผมคัดมาแค่ไม่กี่ข้อที่คิดว่าน่าจะเป็นสิ่งที่หลายคนน่าจะเห็นด้วยกันครับ 555