Google เปิดเครื่องมือย้าย EKS ไป GKE ให้ AI เสนอ แต่คนยังเป็นผู้อนุมัติ

การย้ายเวิร์กโหลดจาก Amazon EKS ไป Google Kubernetes Engine (GKE) ไม่ใช่แค่เปลี่ยนชื่อฟิลด์ในไฟล์ Kubernetes แต่ต้องรักษาพฤติกรรมของระบบเดิมไว้ด้วย ทั้งสิทธิ์เข้าถึงทรัพยากร เส้นทางที่คำขอวิ่งไป และกำลังประมวลผลที่เวิร์กโหลดได้รับ แนวทางย้ายคอนเทนเนอร์ของ Google จึงเริ่มจากการสำรวจเวิร์กโหลดและความเกี่ยวข้องระหว่างระบบก่อนลงมือย้าย 19

เมื่อ 24 กันยายน 2569 Google ประกาศเปิดซอร์ส GKE agentic migration ซึ่งเป็นปลั๊กอินสำหรับเอเจนต์ AI ที่ใช้การให้เหตุผลของโมเดลภาษาขนาดใหญ่ควบคู่กับเครื่องมือและกฎตรวจสอบที่ให้ผลแน่นอน แทนการให้วิศวกรเขียนคำสั่งถาม AI แบบเฉพาะหน้าแล้วนำคำตอบไปใช้ทันที 2

จุดเสี่ยงไม่ใช่ไฟล์ผิดรูปแบบ แต่อาจเป็นพฤติกรรมที่เปลี่ยนไป

ในขั้นตอนแปลงโครงสร้างพื้นฐานที่กำหนดด้วยโค้ดและไฟล์กำหนดค่า Kubernetes จาก EKS ไป GKE ทีมงานควรถามอย่างน้อยสามเรื่อง:

• สิทธิ์ของเวิร์กโหลด: หากแปลงการระบุตัวตนฝั่ง AWS ไปเป็น Workload Identity ของ Google เวิร์กโหลดยังเข้าถึงสิ่งที่จำเป็นได้หรือไม่ และได้สิทธิ์เกินจำเป็นหรือเปล่า
• เส้นทางทราฟฟิก: หากเปลี่ยนการตั้งค่าโหลดบาลานเซอร์และ ingress ไปใช้ Gateway API คำขอยังไปถึงบริการที่ถูกต้องตามกฎเดิมหรือไม่
• การจัดสรรโหนด: การแปลงการเตรียมโหนดยังรองรับเงื่อนไขการจัดตารางทำงานและกำลังประมวลผลที่แอปต้องใช้หรือไม่

นี่คือ คำถามสำหรับตรวจทานผลการแปลง ไม่ใช่ข้อยืนยันว่าเครื่องมือรองรับทุกกรณี ไฟล์ที่ผ่านการตรวจรูปแบบแล้วก็ยังอาจเปลี่ยนสิทธิ์ เส้นทางทราฟฟิก หรือสมมติฐานเรื่องทรัพยากรได้

ให้ AI เสนอ แล้วตรวจและอนุมัติก่อนนำไปใช้

ในแนวทางที่อธิบายไว้ โมเดลทำหน้าที่เสนอวิธีแปลง ส่วนปลั๊กอินเปิดทางให้เรียกใช้เครื่องมือผ่าน Model Context Protocol (MCP) แต่การมีช่องทางเรียกเครื่องมือไม่ได้พิสูจน์ว่าผลลัพธ์ถูกต้อง ประกาศของ Google ยืนยันการผสานโมเดลกับเครื่องมือแบบกำหนดผลได้ ทว่าเนื้อหาประกาศที่มีให้ตรวจสอบไม่ได้แจกแจงการทำงานทุกขั้นหรือกฎแปลงทุกข้อ 2

การตรวจสอบแบบออฟไลน์ด้วยกฎที่แน่นอนช่วยให้ไฟล์ชุดเดียวกันถูกตรวจด้วยเกณฑ์เดียวกันก่อนนำไปใช้ ต่างจากการให้ AI ประเมินคำตอบของตัวเอง แต่ผลรับรองย่อมครอบคลุมเฉพาะสิ่งที่กฎตรวจไว้ ไม่อาจยืนยันว่าแอปจะทำงานเหมือนเดิมทุกประการหลังย้ายระบบ Google ระบุว่ามีกฎป้องกันแบบกำหนดผลได้ แต่ข้อมูลประกาศที่มีอยู่ยังไม่บอกขอบเขตการตรวจสอบออฟไลน์ทั้งหมด 2

หากนำการเปลี่ยนแปลงที่สร้างขึ้นเข้ากระบวนการ pull request แทนการแก้คลัสเตอร์ที่ใช้งานจริงโดยตรง วิศวกรจะตรวจความต่างของไฟล์และให้ระบบ CI/CD รันทดสอบ ตรวจนโยบาย และรอการอนุมัติได้ แนวทางนี้สอดคล้องกับเอกสาร GKE เรื่องการใช้ระบบควบคุมเวอร์ชันและ CI/CD แต่เนื้อหาประกาศที่มีให้ตรวจสอบยังไม่ยืนยันรายละเอียดทุกขั้นของกระบวนการ pull request สำหรับเครื่องมือนี้ 172

Rahul Shrivastava ผู้บริหารระดับ EVP ของ Persistent เรียกแนวทางนี้ว่า “provable, compiler-grade migration factory” ในประกาศของ Google คำเปรียบดังกล่าวสื่อถึงการสร้างและตรวจชิ้นงานสำหรับย้ายระบบ ไม่ใช่หลักฐานว่าความปลอดภัยของการย้ายทั้งระบบได้รับการพิสูจน์ทางคณิตศาสตร์แล้ว ทีมงานยังต้องทดสอบการทำงานจริง สิทธิ์ ประสิทธิภาพ ระบบที่เกี่ยวข้อง และช่วงสลับไปใช้ระบบใหม่ 2

แล้ว Intrinsic Core เกี่ยวข้องอย่างไร

สองวันก่อนประกาศเรื่อง GKE บริษัท Intrinsic เปิดตัว Intrinsic Core ที่งาน ROSCon 2026 ในโทรอนโต โดยเปิดซอร์สส่วนพื้นฐานของซอฟต์แวร์หุ่นยนต์อุตสาหกรรมที่เข้ากันได้กับ ROS ภายใต้สัญญาอนุญาต Apache 2.0 ความสามารถที่รายงานระบุมีทั้งการควบคุม การวางแผนการเคลื่อนที่และการจับวัตถุ การจำลอง และการประเมินท่าทางของวัตถุ; Intrinsic ยังอธิบายถึงกรอบควบคุมแบบเรียลไทม์ที่ไม่ผูกกับฮาร์ดแวร์และความสามารถด้านดิจิทัลทวิน 403337

ความเชื่อมโยงของสองข่าวนี้อยู่ที่ แนวทางลดอุปสรรคในการเริ่มใช้เทคโนโลยี มากกว่าการใช้ระบบร่วมกัน: เครื่องมือ GKE อาจช่วยให้ประเมินงานย้ายคลาวด์ได้ง่ายขึ้น ส่วน Intrinsic Core เปิดชิ้นส่วนพื้นฐานให้ผู้พัฒนาหุ่นยนต์นำไปต่อยอด สื่อบางแห่งเปรียบแนวทางหลังกับการสร้างระบบนิเวศแบบ Android อย่างไรก็ดี การเปิดซอร์สทั้งสองโครงการยังไม่ใช่หลักฐานว่าลูกค้า AWS จะย้ายคลาวด์ หรือผู้พัฒนาหุ่นยนต์จะซื้อบริการ AI ของ Google 230

ข้อสรุปสำหรับทีมที่กำลังพิจารณาย้ายระบบ: คุณค่าของแนวทางนี้คือทำให้ข้อเสนอจาก AI เข้าสู่กระบวนการตรวจสอบที่ทีมคุ้นเคย โดยไม่ให้ AI เป็นผู้ตัดสินใจนำขึ้นระบบเอง แต่แหล่งข้อมูลที่มีอยู่ยังไม่มีตัวเลขยืนยันว่าช่วยลดความล้มเหลวหรือค่าใช้จ่ายในการย้ายระบบได้เท่าไร 219