Kuberian: บริการค้นหาซอร์สโค้ด Kubernetes ด้วยภาษาธรรมชาติโดยใช้ LLM
(kuberian.pages.dev)[แนะนำ]
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 ความคิดเห็น
เป็นโปรเจ็กต์ที่เจ๋งมากเลยครับ! นอกจาก GeekNews แล้ว ลองไปโปรโมตที่อื่นด้วยเป็นอย่างไรบ้าง?
แล้วผมก็อยากฟังความเห็นเกี่ยวกับ CloudRun เพิ่มเติมเหมือนกันครับ
ผมได้ฝากความเห็นเกี่ยวกับ CloudRun ไว้ในคอมเมนต์ด้านล่างแล้วครับ :-)
ได้เปิดเผยบน Hacker News ล่วงหน้าเพื่อทดลองดูรูปแบบการใช้งานของผู้ใช้ครับ ฮ่าๆ
(กำลังใช้งาน Google Analytics อยู่ครับ)
มีคอมมูนิตี้อื่นที่อยากแนะนำไหมครับ? สำหรับผมเองก็ยังนึกที่อื่นออกไม่ค่อยมากนัก
โอ้ เป็นโปรเจกต์ที่น่าสนใจมากเลยครับ!
มีจุดไหนบ้างที่ทำให้ Google Cloud Run น่าพอใจกว่า AWS Lambda? ผมเองก็เคยใช้แต่ Lambda เลยอยากรู้เหมือนกันครับ
ตั้งใจว่าจะอธิบายรายละเอียดทีหลังในรูปแบบโพสต์บล็อกหรืออะไรทำนองนั้น แต่ถ้าหยิบมาเฉพาะไม่กี่ประเด็นแบบสั้น ๆ โดยจำกัดอยู่ที่สภาพแวดล้อม 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