EKS أم GKE في السعودية؟ كيف يحدد اختيار منصة الحاويات الـ Stack الإنتاجي الذي تشتريه

كثير من الفرق التقنية في السعودية تبدأ رحلة البنية التحتية من الجهة الخاطئة: تتصفح Terraform Registry، تجرب عدة وحدات، ثم تكتشف لاحقًا أن الـ terraform provider الذي بنت عليه افتراضاتها لا يتوافق مع المنصة التي تحتاجها فعليًا. النتيجة إعادة كتابة، تأخير في الإطلاق، وتكلفة لا تظهر في الفاتورة الأولى. الحل ليس اختيار الـ Stack أولًا، بل حسم قرار المنصة أولًا: EKS أم GKE؟ ثم ترك هذا القرار يحدد تكوين الـ Stack الإنتاجي بالكامل.

في هذا المقال نشرح لماذا يجب حسم قرار المنصة قبل شراء أي Stack، ونستعرض المعايير الثلاثة التي تحسم الاختيار في السياق السعودي، ثم نقارن EKS وGKE على مستوى معايير القرار لا قوائم الميزات. ننتقل بعدها إلى ما تضيفه ضوابط NCA CCC-2:2024 على حساب الـ Stack، ونوضح كيف يغيّر كل خيار من نموذج التحجيم التلقائي للعُقد، ونمط الهوية والصلاحيات، ونقاط التسجيل والمراقبة، والخدمات داخل المنطقة واعتمادياتها. ونختم بقائمة تحقق عملية قبل الشراء من Terraform Registry أو من أي provider، لتبدأ بالمنصة، ثم تشتري الـ Stack الذي يمكن نشره داخل المنطقة دون إعادة عمل.

لماذا يجب حسم قرار المنصة قبل شراء الـ Stack

الخطأ الشائع أن يبدأ الفريق من سجل وحدات Terraform: يتصفح الوحدات، تعجبه مجموعة ما، ثم يكتشف أن مزوّد Terraform أو موارده لا تطابق المنصة المتاحة داخل المنطقة، فيتحول الـ Stack من أصل إلى عبء.

الـ Stack ليس قطعة محايدة. وحدات Kubernetes وHelm ومزوّدات الهوية تختلف جذريًا بين AWS وGoogle Cloud؛ وما يُبنى لـ EKS لا يُنقل إلى GKE بتغيير متغيّر واحد، بل بإعادة كتابة الموارد والصلاحيات.

والتأخير ليس مجانيًا: إعادة العمل على وحدات الشبكة والهوية ونقاط التسجيل بعد حسم المنصة تعني إعادة بناء، لا تعديلًا بسيطًا، وتكلفتها الحقيقية تتجاوز فرق سعر أي وحدة. وهذا امتداد طبيعي لفكرة أن قرار البناء أم الشراء ليس تقنيًا، هو قرار اقتصادي.

القاعدة العملية: كل قرار منصة يفرض فورًا قرارات تابعة (التحجيم، الهوية، المراقبة، الخدمات الإقليمية) قبل كتابة أول سطر Terraform.

إفصاح: IaC Bazaar جهة تجارية تبيع وحدات وStacks جاهزة للإنتاج، بما فيها مجموعات مُجهّزة لـ AWS وEKS وGKE، وهذا المقال يقدّم إطار قرار لا توصية مبنية على مصلحة بيع. وبهذا الترتيب فقط يصبح سؤال المعايير التالية ذا معنى.

المعايير الثلاثة التي تحسم الاختيار في السياق السعودي

بعد أن ثبت أن الـ Stack قرار تابع للمنصة، يبقى تحويل هذا المبدأ إلى معايير قابلة للفحص. في السياق السعودي تحسم الاختيار ثلاثة معايير متقاطعة، لا قائمة ميزات:

• التوافر الإقليمي: لا تفترض توفر EKS أو GKE في منطقة سعودية بعينها. تحقق من صفحات المناطق والخدمات الرسمية لدى AWS وGoogle Cloud، ثم طابقها مع الخدمات التي يعتمد عليها الـ Stack فعليًا.

• زمن الاستجابة: لا توجد قياسات عامة موثوقة تُقتبس. اعتبره عاملًا يُقاس عمليًا من شبكة مستخدميك ومن مناطق العبور داخل المملكة، لا رقمًا جاهزًا من مقال.

• الإقامة البياناتية: وثيقة NCA CCC-2:2024 لا تحسم التزامات البيانات الشخصية. ارجع إلى PDPL لدى SDAIA وإطار الحوسبة السحابية لدى CST، بحسب ما تشير إليه منشورات SDAIA، لتحديد ما يجب أن يبقى داخل المملكة.

• الالتزامات القائمة: الاتفاقيات والأرصدة والخصومات والشهادات وخبرة الفريق معايير قرار مشروعة، لكنها ليست دليلًا على جودة المنصة أو ملاءمتها.

• التوثيق الإلزامي: حوّل كل معيار إلى سؤال قابل للتحقق: هل تغطي الخدمة المتاحة في المنطقة الموارد التي يعتمد عليها الـ Stack؟

رتّب هذه الأسئلة قبل المقارنة عبر دليل اختيار حلول Kubernetes، فهي أساس الجدول في القسم التالي.

EKS أم GKE؟ مقارنة على مستوى معايير القرار لا قوائم الميزات

بعد أن حوّلنا المعايير إلى أسئلة قابلة للفحص، يصبح السؤال ليس "أيهما أفضل" بل "أيهما يطابق إجاباتك". لا تتوفر مصادر مستقلة كافية لمقارنة أداء EKS وGKE أو خصائصهما التفصيلية بدقة، لذا لا نبني حكمًا على قوائم ميزات. بدلًا من ذلك، ابنِ جدول قرار: الصفوف هي التوافر الإقليمي، الإقامة البياناتية، الالتزامات القائمة، نموذج التحكم بالهوية، نقاط التسجيل، والخبرة الداخلية؛ والأعمدة EKS وGKE، ثم وزن لكل معيار بحسب منشأتك.

EKS امتداد طبيعي لمن يعتمد AWS أصلًا في الهوية والشبكة وسياسات الحساب، لكن شكل الـ Stack يتوقف على مزوّد Terraform الرسمي وموارد الهوية المطلوبة. GKE خيار منطقي لمن بنى اتفاقياته وفريقه على Google Cloud، مع نمط مختلف في الترقيات وإدارة حدود العُقد والتحكم بالوصول. تجد تفصيل هذه الفروق في دليل Terraform وKubernetes لبناء Stacks جاهزة لـ EKS وGKE.

النتيجة العملية: أي منصة تختار تغيّر موارد الـ Stack التي تتبنّاها أو تشتريها. هذا لبّ القرار، لا الشعار التسويقي.

ما الذي يضيفه NCA CCC-2:2024 على حساب الـ Stack

أيا كانت المنصة التي تستقر عليها، يبقى سؤال الالتزام قائمًا بذاته. ضوابط CCC-2:2024 توسّع ضوابط ECC وتكملها، وتصوغ المتطلبات من منظور مزوّدي الخدمة والمشتركين على كافة خدمات الحوسبة السحابية، أي أن الالتزام يلحق بالنشر بغض النظر عن EKS أو GKE.

استشهد بتسمية الإصدار CCC-2:2024 ولا تعتمد على تاريخ النشر الظاهر على صفحة الهيئة (02/06/2022)، فهو لا يعكس الإصدار الحالي.

الصفحة الرسمية تربط دليلين منفصلين للتنفيذ بصيغة PDF، أحدهما لمزوّدي الخدمة والآخر للمشتركين. اقرأ دليل المشترك مباشرة قبل الجزم بأي متطلب تكوين. وأي ادعاء عمّا يجب تفعيله في التسجيل أو إدارة الهوية أو إدارة المفاتيح داخل الـ Stack يبقى غير مدعوم حتى تُقرأ الوثيقة الرسمية.

عمليًا، اجعل التحقق من متطلبات CCC-2:2024 بند فحص في قائمة ما قبل الشراء، لا استنتاجًا جاهزًا يُنسخ في المخططات. ويُستحسن أن تراجع أيضًا ما الذي يجعل الـ Cloud Stack جاهزاً للإنتاج فعلاً؟ قبل تثبيت الوحدات، لأن جاهزية الـ Stack للعمل تتحدد مع الامتثال لا بعده.

كيف يغيّر كل خيار تكوين الـ Stack الإنتاجي الذي تشتريه

بعد التحقق من متطلبات CCC-2:2024، ينتقل الأثر إلى وحدات الـ Stack نفسها. اختيار EKS أو GKE يترجم مباشرة إلى أسماء موارد ومزوّد Terraform مختلف، وطرق مصادقة (AWS IAM مقابل Google Cloud IAM)، وسياسات شبكة، ونقاط تصدير للسجلات والقياس. لا يوجد Stack واحد يعمل على المنصتين دون طبقة تجريد مكلفة وصيانتها ثقيلة على المدى الطويل. التفاصيل هنا تخضع لتوثيق AWS EKS وGKE ولمزوّدي Terraform الرسميين؛ راجع الوثائق وTerraform Registry قبل الاعتماد على أي اسم مورد أو إصدار. قبل الشراء، طابق وحدات الـ Stack مع هذه الفروق، لأن إعادة التكوين بعد النشر أغلى بكثير من التحقق قبله. يمكن أن تساعدك مجموعات Production-Ready Stacks for AWS, EKS, and GKE في مقارنة التكوين، لكن التحقق النهائي يبقى على بيئتك.

نموذج التحجيم التلقائي للعُقد

بعد أن اتضح أن فروق المنصات تبدأ من أسماء الموارد وطرق المصادقة، يبرز أثرها العملي في التحجيم التلقائي. في EKS يرتبط التحجيم ببنية مجموعات العُقد وأدوات AWS، ويستلزم ضبط وحدات الشبكة والسياسات مثل VPC CNI وأدوار IAM ووسوم الاكتشاف قبل إضافة طبقة التحجيم نفسها وفق توثيق EKS. في GKE يكون التوفير المعتمد على Kubernetes متأصلًا في المنصة، لكن حدود العُقد وأنماط التحجيم تختلف في التكوين والتسمية والمتغيّرات وفق توثيق GKE. السؤال الحاسم: هل وحدات التحجيم المكتوبة لـ EKS صالحة لـ GKE؟ عمليًا لا، فهي تحتاج إعادة كتابة كاملة لا تعديل وسوم. لذلك لا تعتمد على أرقام تحجيم عامة من مقالات؛ استخرج معاييرك من resource requests وقيود الجدولة في حملك الفعلي، وتحقق من الوثائق الرسمية لكل منصة. وعند تقييم الـ Stack، راجع Production-Ready Stacks for AWS, EKS, and GKE كخيارات جاهزة تخضع لمعاييرك نفسها.

نمط الهوية والصلاحيات

بعد أن يحسم التحجيم شكله، ينتقل العبء إلى الهوية: من يملك أي صلاحية داخل العنقود؟ في EKS تعتمد الهوية على AWS، وربط أدوار Kubernetes بأدوار السحابة نمط محدد يتطلب وحدات مخصّصة وحذرًا في التطبيق. أما GKE فيعتمد على هوية Google Cloud وربط حسابات الخدمة بأنماط وصول مختلفة، ما يعني وحدات مختلفة بالكامل. الـ Stack الذي تشتريه يجب أن يعرّف بوضوح مالك كل صلاحية، وإلا تحوّل التدقيق والمراجعة الأمنية إلى عبء مستمر. تحقق من دعم الـ Stack لمبدأ أقل صلاحية ممكنة، واربط ذلك بمتطلبات CCC-2:2024 بعد قراءة دليل المشترك الرسمي. وإذا كان قرارك AWS، فراجع حزمة منصة حاويات AWS (EKS) للتأكد من تضمين وحدات الهوية المناسبة قبل الشراء.

نقاط التسجيل والمراقبة

بعد حسم الهوية، تصبح وجهة السجلات هي السؤال التالي. نقاط النهاية المستهدفة للتسجيل والقياس تختلف بين EKS وGKE، وكذلك تسميات الموارد والسياسات المرتبطة بها. الخطأ هنا لا يظهر عند التطبيق: إما تُشحن السجلات إلى خارج المنطقة، أو يُفوَّت متطلب تدقيق مطلوب، وكلاهما يُكتشف في مراجعة الامتثال الدورية لا في يوم النشر. لذا تحقق من أن وحدات الـ Stack توجّه سجلات التحكم والتدقيق إلى وجهة داخل المنطقة، وأن سياسات الاحتفاظ والتشفير موثّقة لا مفترضة. الـ Stack الجاهز للإنتاج يجب أن يشرح أين تذهب سجلات مستوى التحكم والتدقيق، لا أن يعتمد على الافتراضيات الهادئة. وتذكّر أن توقيع cosign يثبت سلامة الوحدة لا صحة إعدادات التسجيل فيها، كما يناقش السجل المفتوح ووهم الثقة: الأرقام التي لا تكذب.

الخدمات داخل المنطقة والاعتماديات

بعد تثبيت وجهات السجلات، تبقى الاعتماديات الخفية: هل خدمات الشبكة وقواعد البيانات والتخزين التي يستدعيها الـ Stack متاحة فعلًا في المنطقة السعودية التي ستنشر فيها؟ تحقّق من ذلك لكل مورد قبل الشراء، لا بعده.

اعتماد مورد غير متاح إقليميًا يعطّل النشر أو يفرض نقل البيانات خارج المملكة، وهو ما يتطلب مسارًا نظاميًا وتقييمًا موثقًا بموجب PDPL (دليل حماية البيانات الشخصية)، أي عكس هدف الإقامة البياناتية.

راجع مزوّد Terraform المطلوب وإصداراته في Terraform Registry، وتأكد من دعمه للمورد والمنطقة، لا لمجرد وجوده. وثّق قائمة الاعتماديات كاملة: الشبكة، قواعد البيانات، التخزين، الهوية، ونقاط النهاية. هذه أرخص خطوة وقائية وأكثرها تجاهلًا.

قائمة تحقق قبل الشراء من Terraform Registry أو Provider

بعد توثيق الاعتماديات، يأتي الفحص النهائي قبل شراء أي وحدة أو Stack. رتّب خطواتك على هذا النحو:

1. احسم المنصة أولًا. اكتب قرارك بين EKS وGKE مع مبرراته الثلاثة (التوافر الإقليمي، الإقامة، الالتزامات القائمة) في وثيقة واحدة، ولا تفتح أي سجل وحدات أو تقارن حزمًا قبل ذلك.

2. تحقّق من مزوّد Terraform. راجع ناشره وإصداره في Terraform Registry، وتأكد أن المزوّد يدعم المورد والمنطقة التي ستنشر فيهما فعليًا، لا مجرد ورود المورد في الوثائق.

3. اقرأ دليل المشترك في CCC-2:2024. استخرج متطلبات التسجيل والهوية وإدارة المفاتيح قبل تبنّي أي وحدة، ولا تفترض أن مزوّد السحابة يغطيها نيابة عنك.

4. طابق الوحدات مع الخصائص الأربع: التحجيم، الهوية والصلاحيات، نقاط التسجيل، والخدمات الإقليمية. وحدة تغطي ثلاثًا منها ستجبرك على وحدات مساعدة إضافية.

5. فضّل الوحدات المتحقَّق منها أمنيًا. تعرض IaC Bazaar وحدات Terraform وOpenTofu وAnsible توصف بأنها متحقَّق منها ثابتًا ومفحوصة أمنيًا وموقّعة بـ cosign، بتحميل فوري لكل وحدة يبدأ من 29 دولارًا وبدون اشتراك، مع Vizier ومجموعات Stacks جاهزة للإنتاج لـ AWS وEKS وGKE.

6. افصح داخل فريقك بأن ما ورد في البند الخامس ادعاءات مورّد وليست نتائج مستقلة، ووازنها دائمًا بمعاييرك أنت.

الخلاصة: ابدأ بالمنصة، ثم اشترِ الـ Stack

بعد استكمال قائمة التحقق، يصبح القرار واضحًا: احسم المنصة أولًا وفق توافر إقليمي متحقَّق منه، ومتطلبات إقامة بياناتية محددة، والتزاماتك القائمة. لا تعتمد على أرقام زمن استجابة منشورة بلا قياس؛ قِسها من بيئتك الفعلية ومن مسارات شبكة مستخدميك داخل المملكة. وعند الاستشهاد بالضوابط، استخدم تسمية CCC-2:2024 وارجع مباشرة إلى دليل المشترك الرسمي للتحقق من متطلبات التسجيل والهوية والمفاتيح. بعدها فقط قارن أي Stack بوحداته الأربع: التحجيم، الهوية والصلاحيات، التسجيل، والخدمات الإقليمية. فإن لم تطابق منصتك وموقعك المختار، فهي إعادة بناء لا تعديل.

ويمكن اعتبار IaC Bazaar مصدرًا محتملًا للوحدات والمجموعات الجاهزة لـ AWS وEKS وGKE إن طابقت مواصفاتها قرارك، مع إفصاح واضح أن هذه ادعاءات مورّد وليست نتائج مستقلة، وأن المقال يقدم إطار قرار لا توصية بمنصة بعينها.