الهجرة من EKS إلى GKE: الذكاء الاصطناعي يقترح، والمهندسون يراجعون

قد ينتج نموذج لغوي ملف إعداد يبدو صحيحًا، ثم يتبيّن بعد النشر أنه وسّع صلاحيات خدمة أو غيّر مسار الطلبات. هذه هي فجوة الثقة التي تسعى Google إلى تضييقها بأداتها مفتوحة المصدر للهجرة من Amazon EKS إلى Google Kubernetes Engine (GKE): بدل مطالبة النموذج بكتابة إعدادات بديلة واتباعها مباشرة، تصف الشركة إضافةً لوكيل تجمع استدلال النماذج اللغوية بأدوات حتمية وضوابط للتحقق. 2

ما الذي ينبغي الحفاظ عليه أثناء الهجرة؟

EKS وGKE خدمتان مُدارتان لتشغيل Kubernetes لدى AWS وGoogle على الترتيب. والانتقال بينهما ليس تبديل أسماء حقول في ملفات التعريف أو «البنية التحتية بوصفها شيفرة»؛ بل محاولة للحفاظ على سلوك النظام: من يحق له الوصول إلى الموارد، وكيف تصل الطلبات إلى الخدمات، وأين تُشغَّل أحمال العمل. لذلك تبدأ إرشادات Google العامة للهجرة بجرد الأحمال والبيانات وتحديد خصائصها واعتمادياتها قبل تنفيذ النقل. 19

في سير العمل المطروح، يمكن لواجهة Model Context Protocol (MCP) أن تتيح أدوات للوكيل، فيما يساعد النموذج اللغوي على اقتراح تحويلات الإعداد. لكن إتاحة الأداة لا تعني أن اقتراحها صحيح. ويؤكد إعلان Google الجمع بين استدلال النموذج والأدوات الحتمية، من دون أن يوضح المقتطف المتاح كل عمليات الإضافة أو قواعد التحويل التي تطبقها. 2

وتستحق ثلاثة أنواع من التغييرات تدقيقًا خاصًا:

• الهوية والصلاحيات: عند نقل ربط هوية أحمال العمل من AWS إلى آلية Google المقابلة، هل بقي الوصول المطلوب متاحًا من دون منح صلاحيات إضافية؟
• توجيه الطلبات: عند تحويل إعدادات الدخول عبر موازن التحميل إلى Gateway API، هل تصل الطلبات إلى الخدمات الصحيحة وفق القواعد المتوقعة؟
• توفير العُقد: هل ما زالت الأحمال تجد سعة التشغيل وظروف الجدولة التي تحتاجها؟

هذه أسئلة مراجعة للتحويلات المذكورة في وصف سير الهجرة، وليست ضمانًا مستقلًا بأن الأداة تعالج جميع الحالات. فقد يكون ملف Kubernetes صالحًا من حيث البنية، لكنه يغيّر سلوك النظام.

التحقق قبل النشر، لا بعده

تتيح الفحوص الحتمية غير المتصلة اختبار الملفات المقترحة بالقواعد نفسها في كل مرة، بدل الاعتماد على تفسير النموذج لجودة ما أنتجه. لكنها لا تثبت إلا ما تغطيه قواعد الفحص فعلًا؛ ولا يمكنها وحدها تأكيد تطابق أداء التطبيق وصلاحياته وسلوكه بعد الانتقال. تصف Google إصدارها بأنه محمي بضوابط حتمية، لكن مقتطف الإعلان المتاح لا يحدد النطاق الكامل للتحقق غير المتصل. 2

أما مسار طلبات دمج التغييرات في سير العمل الموصوف، فيضع الملفات أمام المهندسين وبوابات التكامل والنشر المستمرين، بدل تعديل عنقود الإنتاج مباشرة. وبذلك يمكن فحص الفروق واشتراط الاختبارات والسياسات والموافقات قبل النشر. يتسق هذا مع إرشادات Google بشأن إدارة الشيفرة والنشر إلى GKE، وإن كان مقتطف الإعلان لا يؤكد بصورة مستقلة كل خطوة من خطوات هذا المسار في الأداة نفسها. 172

وصف راهول شريفاستافا، نائب الرئيس التنفيذي في Persistent، النهج في إعلان Google بأنه «مصنع هجرة قابل للإثبات وبمستوى صرامة المُصرِّفات البرمجية». التشبيه يعبّر عن توليد مخرجات قابلة للفحص، لا عن برهان رياضي على سلامة الهجرة بالكامل؛ إذ تبقى اختبارات التشغيل والاعتماديات والأداء وخطة الانتقال الفعلي ضرورية. 2

صلة أوسع بإطلاق Intrinsic Core

قبل إعلان GKE بيومين، كشفت Intrinsic عن Intrinsic Core خلال مؤتمر ROSCon 2026 في تورونتو. يوفر المشروع المفتوح المصدر قدرات متوافقة مع منظومة ROS للروبوتات، تشمل التحكم وتخطيط الحركة والإمساك والمحاكاة وتقدير الوضعية؛ وتشير التغطية إلى طرحه بترخيص Apache 2.0. وتصف Intrinsic أيضًا إطار تحكم آنيًا لا يعتمد على عتاد بعينه وقدرات «التوأم الرقمي». 403337

الصلة بين الإطلاقين استراتيجية لا تقنية مباشرة: قد تخفف أداة GKE عبء الانتقال إلى سحابة Google، بينما تخفف Intrinsic Core عبء بناء تطبيقات الروبوتات الصناعية. وقد شبّهت تغطيات صحفية النهج الثاني بفكرة «أندرويد للروبوتات»: إتاحة أساس واسع للمطورين لبناء منظومة حوله. لكن لا يثبت أي من الإطلاقين، بمفرده، أن عملاء AWS سينتقلون إلى Google أو أن مطوري الروبوتات سيشترون خدماتها المدفوعة. 230

الخلاصة: قيمة نهج GKE هي الفصل بين اقتراح الذكاء الاصطناعي وقرار اعتماد التغيير ونشره. قد يجعل ذلك الهجرة أسهل مراجعةً ضمن إجراءات الفرق القائمة، لكنه لا يغني عن اختبار كل حمل عمل؛ ولا تقدم المصادر المتاحة قياسًا لانخفاض إخفاقات الهجرة أو تكلفتها. 219