لا تتحدد سيادة المنصة السحابية الأصلية بمكان تشغيل الحمل أو تخزين بياناته فقط. فبحسب تحليل نشرته CNCF في 18 أغسطس 2026 وكتبه Chamod Perera، سفير CNCF، وSuvin Kodituwakku، مهندس برمجيات أول في WSO2، يعتمد إثبات السيادة أيضاً على مكان وجود حالة التحكم، ومسارات السجلات والبيانات الوصفية، والجهات القادرة على الوصول إلى المفاتيح وبيانات الاعتماد، وقدرة الفريق على مواصلة التشغيل إذا اختفت خدمة المورّد.
يقترح التحليل النظر إلى السيادة باعتبارها خاصية في طوبولوجيا المنصة، لا مجرد اختيار منطقة من قائمة إعدادات. ويستخدم OpenChoreo، وهو منصة داخلية مفتوحة المصدر للمطورين ومشروع في مرحلة Sandbox لدى CNCF، مثالاً قابلاً للفحص على هذا النهج، مع التأكيد أن المبادئ المعمارية لا تقتصر عليه.
أربعة أسئلة تتجاوز موقع الخوادم
ترى المادة أن فرق المنصات مطالبة، في ظل أطر مثل EU Data Act وNIS-2 وDORA وUK Data Use and Access Act، بالإجابة عن أسئلة عملية تتجاوز تحديد المنطقة الجغرافية. أولها: ما الولاية القانونية التي يعمل تحتها كل مكوّن يمكنه لمس بيانات المستأجر، بما في ذلك مستوى التحكم والسجلات؟ وثانيها: هل يمكن للفريق تشغيل الأحمال وإعادة بنائها ونقلها إذا توقفت الخدمة المستضافة لدى المورّد؟
أما السؤالان الآخران فيتعلقان بإمكانية وصول أطراف خارج الحدود إلى المفاتيح أو حالة العناقيد أو بيانات اعتماد الإدارة، وبما إذا كان تغيير المورّد أو العتاد أو الدولة يتطلب إعادة كتابة الحمل. ويخلص التحليل إلى أن هذه الأسئلة تركز أساساً على مكان وجود التحكم والحالة، ومن يملك القدرة على الوصول إليهما.
كيف تعمل البنية متعددة المستويات؟
يقسم OpenChoreo المنصة إلى عنقودات مستقلة، لكل منها دورة حياة وحدود أمنية وسلوك توسع خاص به:
- مستوى التحكم: يحتفظ بالحالة المرغوبة عبر واجهات برمجة معلنة ويشغل وحدات المصالحة، لكنه لا يشغل أحمال المستأجرين.
- مستويات البيانات: عنقودات Kubernetes متوافقة تشغل الأحمال فعلياً، ولكل منها خادم API وحالة مستقلان.
- مستويات المراقبة: تجمع السجلات والمقاييس وآثار التتبع وتخدمها.
- مستويات سير العمل: تنفذ عمليات CI وGitOps.
- مستوى التجربة: يوفر بوابة المطورين وواجهة CLI وواجهات API وMCP.
العنصر الأهم هو نموذج الاتصال. فمستويات البيانات والمراقبة وسير العمل تفتح اتصالات صادرة ومصادقاً عليها بشكل متبادل عبر mTLS إلى بوابة مستوى التحكم، بينما لا يبادر مستوى التحكم بالاتصال بها. وبذلك لا تكون خوادم API الخاصة بالعناقيد التي تستضيف أحمالاً منظمة مكشوفة للإنترنت. كما أن مستوى التحكم يحتفظ بالحالة المرغوبة، لا بحالة التشغيل الكاملة للمستأجر؛ لذلك يستطيع مستوى البيانات مواصلة خدمة الطلبات حتى عند فقدان الاتصال بمستوى التحكم.
ما الذي يتغير عملياً لفرق المنصات؟
يمكن ربط كل مستوى بيانات بولاية قانونية محددة، بحيث يصبح نموذج «ولاية واحدة، مستوى بيانات واحد» قابلاً للمراجعة والتدقيق. كما يرسل كل مستوى بيانات بياناته التشغيلية إلى مستوى مراقبة إقليمي، بدلاً من تمرير السجلات والآثار عبر مستوى التحكم. وبهذا تبقى أحمال المستأجر وقياساتها داخل الحدود الإقليمية المحددة.
وتعتمد قابلية الاستمرار بعيداً عن المورّد على كون كل مستوى بيانات عنقود Kubernetes كاملاً ومتوافقاً، لا نقطة نهاية مُدارة ومغلقة. ويشير التحليل إلى استخدام مكونات مفتوحة المصدر من منظومة CNCF والسحابة الأصلية، مثل Argo Workflows وCloud Native Buildpacks وOpenSearch وPrometheus وOpenTelemetry وFlux وcert-manager وCilium. وتسمح البنية المعيارية باستبدال مكوّن أو ربط منظومة مراقبة قائمة بواجهة الاستعلام نفسها.
أما حماية الأسرار والمفاتيح فتُترك لمخزن متوافق مع External Secrets Operator أو لخزينة تختارها الجهة المشغلة، بدلاً من فرض ملكية افتراضية للمفاتيح. كما يمكن تطبيق صلاحيات دقيقة على مستوى المساحات والمشروعات والمكونات، مع ربط المجموعات بأي مزود هوية OAuth2/OIDC، سواء كان المستدعي مطوراً أو أداة CLI أو وكيلاً للذكاء الاصطناعي.
تكامل العناقيد الافتراضية مع مستويات المنصة
لا يلغي هذا النموذج نمط عنقود المستأجر، بل يكمله. فالعنقود الافتراضي يمنح كل مستأجر مستوى تحكم افتراضياً وخادم API ومخزناً خاصين به داخل عنقود مضيف مشترك، ما يعزل حالة التحكم بين المستأجرين بكلفة أقل من عنقود مخصص لكل واحد. لكنه لا يحدد وحده الولاية التي يجب أن يستضيف فيها المستأجر، ولا مكان إرسال السجلات، ولا من يملك صلاحية ترقية الحمل بين بيئتين أو منطقتين.
هنا تضيف طبقة المنصة ضوابط التوزيع والتشغيل. إذ يمكن لمورد DataPlane حمل وسم الولاية القانونية، وربط مورد observabilityPlaneRef بمستوى مراقبة إقليمي، فيما تحدد مسارات الترقية البيئات التي يمكن للحمل الانتقال بينها. كما توفر بوابة المطورين مسارات جاهزة تقلل الحاجة إلى منح المستخدمين وصولاً مباشراً إلى العناقيد الحساسة.
لكن هذا التركيب له حد واضح: المستأجرون الموجودون على المضيف نفسه يشاركون العقدة ونواة نظام التشغيل. فإذا كان نموذج التهديد يتطلب عزلاً عتادياً لكل مستأجر، فلن يكون العنقود الافتراضي كافياً، وسيلزم مستوى بيانات فعلي مستقل.
السيادة كتكوين معلن وقابل للتدقيق
يقترح التحليل تمثيل الطوبولوجيا عبر موارد Kubernetes معلنة وحفظها في Git: أي منطقة تستخدم أي مستوى بيانات، وأي وجهة تستقبل بيانات المراقبة، وما مسارات الترقية المسموح بها. وبذلك يصبح إنشاء ولاية جديدة طلب دمج (pull request) قابلاً للمراجعة، وتصبح الإجابة عن سبب وجود بيانات مستأجر في منطقة معينة مستندة إلى سجل تغييرات، لا إلى لقطة شاشة من لوحة تحكم.
مع ذلك، لا تغير البنية متعددة المستويات الولاية القانونية للجهة التي تشغل البنية التحتية، ولا تلغي تعرضها للأنظمة القانونية التي تخضع لها. كما أنها ترسم الحدود ولا تفرض وحدها سياسات ما يحدث داخلها؛ فالتصديق على سلسلة التوريد، وSBOM، وتسجيل التدقيق، وهوية الأحمال عبر أدوات مثل SPIFFE/SPIRE، تظل ضوابط منفصلة تحتاج إلى دمج.
وتأتي الكلفة التشغيلية كقيد أخير: كل عنقود إضافي يحتاج إلى مراقبة وترقية ونسخ احتياطي. لذلك تكون البنية مبررة عندما تحمل الحدود المرسومة وزناً قانونياً أو أمنياً حقيقياً، وقد تصبح مبالغة في البيئات التي لا تحتاج ذلك. والخلاصة أن الجمع بين عناقيد المستأجرين لعزل الموارد، والبنية متعددة المستويات لتحديد ما يمكنه عبور الحدود، والتكوينات المعلنة القابلة لإدارة الإصدارات، يحول السيادة من وعد تعاقدي إلى خاصية يمكن تشغيلها ومراجعتها.