رهان Red Hat على OpenShift هو مسار ترقية، وليس اختصارًا لـ Kubernetes

ملخص

• حجة Red Hat حول OpenShift تكون أقوى عندما يُنظر إليها كمنتج دورة حياة، وليس كاختصار معبأ لـ Kubernetes. يجمع OpenShift بين Kubernetes وRed Hat Enterprise Linux CoreOS ومشغلي المجموعات وOperator Lifecycle Manager والسجلات وسياسة الدعم والتكاملات المعتمدة في نموذج تشغيل يتمثل وعده الرئيسي في أن المؤسسات يمكنها التنقل عبر الترقيات مع قدر أقل من أعمال التجميع غير المدعومة. يخلق الهيكل نفسه تبعية جديدة: بمجرد أن تقبل الفرق مسارات التحديث المختبرة من Red Hat وفهارس المشغلين وحدود الدعم، تصبح حريتها مقيدة بساعة إصدار المنصة.
• تدعم الأدلة ادعاء ضيقًا لكنه مهم: لقد بنى Red Hat آلية جادة حول توصيات الترقية والتحديثات الشرطية وإصدارات EUS وفئات دورة حياة المشغلين والنسخ المتطابق المنفصل. يمكن لهذه الآلية أن تقلل من عدم اليقين بالنسبة لفرق البيئات المنظمة والهجينة، خاصة عندما يكون البديل هو الحفاظ على Kubernetes المنبع وصور Linux والسجلات وسياسة الأمان والتوافق الإضافي بشكل منفصل. لكنها لا تلغي العمل التشغيلي. لا يزال المسؤولون يتحملون مسؤولية الاختبار قبل الإنتاج وتوافق التطبيقات واستراتيجية الموافقة على المشغلين وتوافر النسخ المتطابقة وتحديد أولويات الثغرات وحدود دعم الطرف الثالث وتخطيط التعافي.
• السؤال التجاري ليس ما إذا كان OpenShift أرخص من Kubernetes المنبع بشكل منفصل. بل هو ما إذا كان الاشتراك وعلاقة الدعم والمنصة المعتمدة تقلل من الهندسة المكررة بما يكفي لتبرير رسوم الاشتراك والتدريب والترحيل والقيود المعمارية والارتباط. يُظهر التقرير السنوي لـ IBM لعام 2025 جذبًا سوقيًا ذا معنى، حيث بلغت إيرادات السحابة الهجينة (Red Hat) 7.327 مليار دولار وإيرادات OpenShift السنوية المتكررة 1.9 مليار دولار في نهاية العام. هذه الأرقام تثبت الطلب، وليس النتائج. الدليل الحاسم للمشتري يظل تاريخ ترقيته الخاص وسجل الحوادث وقدرة الموظفين واستعداده لقبول عقد تشغيل Red Hat.

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

غالبًا ما يُوصف OpenShift بأنه منصة Kubernetes، لكن هذا الوصف واسع جدًا لشرح سبب دفع المؤسسات الكبيرة لشركة Red Hat. Kubernetes نفسه ليس نادرًا. الشيء النادر هو مسار مُدار عبر الساعات غير المتوافقة حول Kubernetes. لوحات التحكم وعقد العمل والمكونات الإضافية للشبكة ومحركات التخزين وسياسات القبول ومكونات المراقبة والمشغلون والصور الأساسية ومواصفات نشر التطبيقات لا تصبح جميعها جاهزة في وقت واحد. فريق المنصة المؤسسية لا يسأل فقط عما إذا كانت المجموعة يمكنها العمل اليوم. بل يسأل عما إذا كانت المجموعة يمكنها الانتقال من حالة مدعومة إلى حالة أخرى بينما يستمر التطبيقات والمراجعون وأصحاب الأعمال في طلب التغيير.

توثيق Red Hat الخاص بالتحديث يوضح وجهة النظر. تسمح قنوات تحديث OpenShift للمسؤولين بتحديد مسار الإصدار الثانوي الذي يعتزمون اتباعه، ويستخدم مشغل إصدار المجموعة (Cluster Version Operator) رسمًا بيانيًا للتحديث واختيار القناة ومعلومات شرطية لتقديم تحديثات موصى بها أو شرطية للمجموعة (توثيق Red Hat لتحديث مجموعات OpenShift). الآلية مهمة لأنها تحول اختيار الترقية إلى سطح تشغيل مقيد. لا يتم ببساطة تسليم مسؤول المجموعة كل بناء ويُطلب منه الاختيار. المنصة من المفترض أن تقدم مسارات مختبرة، مع مخاطر معروفة تنعكس في التوصيات المتاحة.

لهذا السبب تعد التحديثات الشرطية محورية في ادعاء قيمة OpenShift. توثق Red Hat التحديث الشرطي كهدف متاح لكنه غير موصى به بسبب خطر معروف قد ينطبق على المجموعة. يقوم مشغل إصدار المجموعة بالاستعلام بشكل دوري عن خدمة تحديث OpenShift، وتقييم المخاطر الشرطية ويمكن أن يعرض الهدف كشرطي إذا كان الخطر ينطبق أو لا يمكن تقييمه. إرشادات Red Hat متحفظة: إذا لم تكن هناك حاجة قوية للانتقال إلى هذا الهدف، فانتظر مسارًا موصى به؛ إذا كان هناك ثغرة أو سبب آخر يبرر الانتقال على أي حال، فقم بإجراء اختبار غير إنتاجي، وافحص الخلل المرتبط وأشرك الدعم إذا لزم الأمر (توثيق Red Hat حول تقييم التحديثات الشرطية).

هذه ليست هندسة ساحرة، لكنها الجزء من موثوقية المنصة الذي تشعر به المؤسسات بشكل مباشر. يمكن للمجموعة التي تؤدي أداءً جيدًا في يوم الإطلاق أن تصبح عبئًا إذا ترك التصحيح التالي مشغلًا خلفه، أو كشف عن إزالة API، أو كسر سلوك التخزين، أو أجبر على استثناء متسرع. وعد Red Hat هو أن الرسم البياني للترقية يلتقط بعضًا من هذا الخطر قبل أن يتحول إلى انقطاع للعميل. الوعد ليس مطلقًا. يمكن للرسم البياني أن يعبر فقط عن ما تعرفه Red Hat، وما يمكن أن يكشفه التتبع والاختبار، وما تبلغه المجموعة، وما تجعل امتدادات العميل نفسه قابلًا للملاحظة.

النتيجة العملية هي اختبار موثوقية ذو وجهين. إذا كانت Red Hat محقة، فإن OpenShift يقلل من عدد القرارات غير المدعومة التي يجب على فرق المنصة اتخاذها أثناء الترقيات. إذا كانت Red Hat مخطئة، فإن الضوابط نفسها التي تجعل OpenShift مفيدًا تصبح احتكاكًا: مسار محظور أو شرطي، مشغل معتمد غير جاهز بعد، مرآة منفصلة لم يتم تحديثها، أو إجابة دعم تقول إن العميل خارج الإطار المختبر.

ما تملكه Red Hat بالفعل

شركة Red Hat, Inc. هي الآن جزء من IBM، لكن حدود تشغيل OpenShift لا ينبغي أن تُخلط مع محفظة IBM السحابية بأكملها. أكملت IBM استحواذ Red Hat في عام 2019، واضعة الصفقة حول السحابة الهجينة المفتوحة (بيان صحفي لـ Red Hat). يكشف تقارير IBM الآن عن Red Hat من خلال فئة السحابة الهجينة. في التقرير السنوي لعام 2025 المقدم إلى هيئة الأوراق المالية والبورصات، أبلغت IBM عن إيرادات السحابة الهجينة (Red Hat) بقيمة 7.327 مليار دولار، بزيادة 12.9 بالمائة كما ورد، وإيرادات OpenShift السنوية المتكررة بقيمة 1.9 مليار دولار في نهاية العام، بزيادة تزيد عن 30 بالمائة على أساس سنوي (التقرير السنوي لـ IBM 2025، إيداع SEC).

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

يصف الوصف العام للمنتج من Red Hat OpenShift كمنصة سحابية هجينة تركز على الأمان مع عمليات تشغيل مؤتمتة بالكامل، متاحة كخدمات سحابية مُدارة أو برنامج مُدار ذاتيًا (صفحة منتج Red Hat OpenShift). التفاصيل وراء هذه الجملة هي حدود التشغيل. Red Hat تملك توزيعة OpenShift التجارية، وتكامل RHEL CoreOS، ومشغلي المنصة التي تشحنها، وتوثيق دورة الحياة، وسياسة الدعم، والتصحيحات، وتجربة الاشتراك. إنها لا تملك Kubernetes المنبع كمشروع، ولا كل مشغل في مجموعة العميل، ولا كل مكون شريك معتمد، ولا كل وحدة تحكم مخصصة، ولا كل مواصفة نشر تطبيق، ولا كل خدمة مزود سحابي، ولا كل صفيف تخزين، ولا كل مهمة أتمتة داخلية بناها عميل.

التمييز ليس تافهًا. غالبًا ما يختار مشترو OpenShift المنصة لأنهم يريدون أسئلة تكامل أقل، لكن الأقل لا يعني صفرًا. يغطي نطاق دعم Red Hat المكونات المشحونة والاستخدام الموثق والتشخيص وتقارير الأخطاء ضمن دورة حياة المنتج ذات الصلة. يستثني أو يحد من مجالات مثل المشاريع المجتمعية كعناصر قائمة بذاتها، وميزات المعاينة التقنية، وتطوير الأكواد المخصصة، ومكونات الطرف الثالث غير المعتمدة، وبعض أعمال التصميم أو التنفيذ ما لم يتم تطبيق خدمات منفصلة (نطاق دعم الإنتاج من Red Hat). كما تفصل سياسة دعم الطرف الثالث من Red Hat مسؤولية Red Hat عن مسؤولية بائعي الطرف الثالث؛ إذا تم تضمين مكون طرف ثالث غير معتمد، يمكن أن يُطلب من العميل إعادة الإنتاج بمنتج معتمد أو مُصدق من الشريك (سياسة دعم برامج الطرف الثالث من Red Hat).

حدود الدعم هذه هي ميزة تجارية وقيود في نفس الوقت. إنها تعطي المؤسسات جهة مسؤولة عن المنصة المتكاملة. كما تخبرهم أي الخيارات يمكن أن تنقلهم خارج أقوى موقف دعم. مجموعة OpenShift المليئة بالمشغلين المخصصين وافتراضات النواة المخصصة والصور غير الرسمية وتجاوزات التكوين غير المدعومة لم تعد نفس المنتج الذي اختبرته Red Hat.

Kubernetes يحدد الوتيرة، لكن OpenShift يضيق الطريق

يرث OpenShift فيزياء Kubernetes. يحافظ المشروع المنبع على فروع إصدار لآخر ثلاثة إصدارات ثانوية ويعطي Kubernetes 1.19 والأحدث حوالي عام من دعم التصحيحات. كما تقيد سياسة انحراف الإصدار (version skew policy) مدى تباعد مكونات لوحة التحكم و kubelets والعملاء. في المجموعات عالية التوفر، يجب أن تبقى مثيلات خادم API ضمن إصدار ثانوي واحد، ويجب ألا تكون kubelets أحدث من خادم API بينما يُسمح لها فقط بالتأخر بعدد محدود من الإصدارات الثانوية (سياسة انحراف إصدار Kubernetes).

يخلق هذا الوتيرة المنبع حالة عمل لمنصة نازلة مدعومة. قد ترغب مؤسسة منظمة في الحصول على النظام البيئي الأمني والتطبيقي لـ Kubernetes، لكنها لا تريد بالضرورة ساعة الصيانة المنبع كأداة تخطيط وحيدة. سياسة دورة حياة OpenShift من Red Hat تعطي OpenShift Container Platform دورة حياة مرحلية يمكن فيها دعم إصدارات ثانوية متعددة في نفس الوقت، مع سعي Red Hat إلى وتيرة إصدار كل أربعة أشهر وإبقاء التصحيحات في متناول المشتركين النشطين عبر دورة الحياة (سياسة دورة حياة Red Hat OpenShift).

يوضح تيار الإصدار الحالي المفاضلة. تم توثيق OpenShift Container Platform 4.22 باستخدام Kubernetes 1.35 مع CRI-O، وتذكر ملاحظات الإصدار أن الإصدارات الزوجية بدءًا من 4.14 تحصل على دورة حياة EUS مدتها 24 شهرًا عبر البنى المدعومة، مع مدة EUS إضافية تمدد التوافر الإجمالي إلى 36 شهرًا عند الاشتراك (ملاحظات إصدار OpenShift 4.22). تصف سياسة دورة الحياة الأوسع لـ Red Hat أيضًا شروط حياة طويلة اختيارية يمكن أن تمدد دعم OpenShift لإصدارات EUS المؤهلة، وفقًا للاشتراك والنطاق (سياسة دورة حياة Red Hat OpenShift).

هذا ليس تصريحًا مجانيًا لتجنب التغيير. إنها طريقة لشراء وقت التخطيط. يمكن لفريق على إصدار EUS توقيت علاج التطبيق وتحديثات المشغلين وأدلة التدقيق ونوافذ التغيير بشكل أكثر تعمدًا من فريق يتبع Kubernetes المنبع وحده. لكن تكلفة وقت التخطيط هي العيش ضمن مجموعات Red Hat المدعومة. المشتري الذي يريد كل ميزة Kubernetes المنبع فورًا، أو الذي يريد مزج إصدارات مكونات عشوائية، يجب أن يعامل دورة حياة OpenShift على أنها قيد بقدر ما هي فائدة.

المشغلون ينقلون العبء إلى أعلى المكدس

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

يحاول مدير دورة حياة المشغل (Operator Lifecycle Manager) في OpenShift التحكم في هذا التعقيد. يقول توثيق Red Hat إن OLM يحل التبعيات بضمان تثبيت الإصدارات المحددة من المشغلين وتعريفات الموارد المخصصة أثناء التثبيت، باستخدام فهارس للعثور على مشغل يلبي API CRD المطلوبة (مسرد إطار عمل مشغل OpenShift). يمكن للمسؤولين اختيار قنوات التحديث واستراتيجيات الموافقة. مع الموافقة التلقائية، يبدأ OLM التحديث عند توفر إصدار جديد من المشغل في القناة المحددة؛ مع الموافقة اليدوية، يجب على المسؤول الموافقة على التحديث قبل بدء التثبيت (مهام مسؤول OpenShift للمشغلين).

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

حاولت Red Hat جعل هذا أكثر قابلية للفهم من خلال تصنيفات دورة حياة المشغل. تصف سياسة دورات حياة مشغل OpenShift تصنيفات Platform Aligned وPlatform Agnostic وRolling Stream للمشغلين المشحونين من Red Hat المستخدمة مع OpenShift، والتي تسري من OpenShift 4.14 والأحدث. تشير السياسة إلى أن المشغلين يمكن أن يكون لهم وتيرة إصدار ودورة حياة خاصة بهم، ويجب مراجعتهم في سياق دورة حياة إصدار مجموعة OpenShift (دورات حياة مشغل Red Hat OpenShift).

هذا يساعد، لكنه يكشف أيضًا عن عمق التبعية. المشتري لا يشتري دورة حياة واحدة. إنه يشتري كومة من دورات الحياة: OpenShift وRHCOS وKubernetes وCRI-O والمشغلون المشحونون من Red Hat ومنتجات Red Hat الاختيارية ومكونات الشريك وتطبيقات العميل. ميزة Red Hat هي أنها تنشر وتدعم العديد من هذه الطبقات معًا. الخطر المتبقي هو أن عبء العمل الأكثر أهمية للعميل قد يعتمد على الطبقة الوحيدة غير المتوافقة.

RHEL CoreOS هو استقرار بساعة مرفقة

طبقة نظام التشغيل في OpenShift هي جزء كبير من عرض القيمة. تصف سياسة دعم الحاويات من Red Hat OpenShift كتوزيعة كاملة للمؤسسات من Kubernetes وLinux تم تسليمها كحل، مع تضمين RHEL CoreOS كمكون مدار بالكامل داخل مجموعة Kubernetes (سياسة دعم حاويات Red Hat). هذا ادعاء أقوى من مجرد القول إن Kubernetes يعمل على Linux. يعني أن Red Hat تقوم بدمج نظام تشغيل العقدة في دورة حياة المجموعة.

يظهر توثيق OpenShift الحالي مدى وضوح هذا الاقتران. تقول مقالة Red Hat حول إصدارات RHEL المستخدمة بواسطة RHEL CoreOS وOpenShift إن OpenShift 4 يتضمن نظام تشغيل عقدة مُدار بالكامل وأن تحديثات المجموعة تحدث RHCOS، وأحيانًا تتضمن نقل إصدار ثانوي لـ RHEL. تدرج المقالة OpenShift 4.22 على أنه يستخدم RHEL 9.8، و4.21 حتى 4.19 على أنها تستخدم RHEL 9.6، و4.18 و4.16 على أنها تستخدم RHEL 9.4، و4.14 على أنها تستخدم RHEL 9.2 و4.12 على أنها تستخدم RHEL 8.6 (إصدارات RHEL المستخدمة بواسطة RHCOS وOpenShift). تكرر ملاحظات إصدار 4.22 أن RHCOS يستخدم حزم RHEL 9.8 في هذا الإصدار (ملاحظات إصدار OpenShift 4.22).

بالنسبة للمؤسسة، هذا قيم لأنه يقلل من انحراف مستوى العقدة. فريق المنصة لا يضطر إلى معاملة كل عقدة كمضيف Linux منسق بشكل منفصل. يمكنه نقل طبقة نظام التشغيل عبر تحديثات المجموعة وتصحيحات Red Hat. لكن هذا يعني أيضًا أنه يجب التعامل مع تخصيص العقدة بحذر. كلما زاد اعتماد العميل على وحدات نواة غير عادية أو افتراضات على مستوى المضيف أو وكلاء خارجيين لم تختبرهم Red Hat في دورة حياة OpenShift، كلما أصبح مسار الترقية مفاوضة بين المتطلبات المحلية والمنصة المدعومة.

RHEL نفسه له دورة حياة أطول بكثير من Kubernetes. توثق Red Hat دورة حياة مدتها عشر سنوات لـ RHEL 8 و9 و10 عبر الدعم الكامل ودعم الصيانة ومراحل الحياة الممتدة، مع خيارات ممتدة للإصدارات الثانوية المؤهلة (دورة حياة Red Hat Enterprise Linux). ساعة Linux الطويلة هذه هي أحد أسباب مصداقية Red Hat مع مشتري البنية التحتية المحافظين. OpenShift، مع ذلك، لا يمكنه ببساطة أن يرث دورة حياة RHEL بأكملها كما هي، لأن Kubernetes والمشغلين يتقدمون أسرع. التحدي المنتج هو الجمع بين قابلية توقع Linux المؤسسي مع التغيير السحابي الأصلي دون التظاهر بأن هذه الساعات هي نفسها.

البيئات المنفصلة تحول دورة الحياة إلى لوجستيات

تصبح مشكلة دورة الحياة أكثر واقعية في البيئات المنفصلة أو المقيدة. قد لا يسمح البنك أو الوكالة الحكومية أو مشغل الاتصالات أو الموقع الصناعي لكل مجموعة بالوصول إلى الإنترنت العام. في هذه الإعدادات، تعتمد موثوقية التحديث ليس فقط على رسم بياني لـ Red Hat ولكن أيضًا على ما إذا كان العميل قد عكس الصور والبيانات الوصفية وفهارس المشغلين الصحيحة في سجل يمكن لكل مجموعة الوصول إليه.

توثيق التحديث المنفصل من Red Hat مباشر: للتحديث في بيئة منفصلة، يجب أن يكون لدى المجموعة إمكانية الوصول إلى سجل مرآة مع الصور والموارد اللازمة للتحديث المستهدف. كما يلاحظ أن البيئة يمكن أن تكون منفصلة لأن العقد لا يمكنها الوصول إلى الإنترنت أو لأن المؤسسة تريد إدارة التوصيات وصور الإصدار محليًا لأسباب السياسة أو الأداء (توثيق التحديث المنفصل من OpenShift).

توثيق النسخ المتطابق يوسع الالتزام. يجب على مسؤولي OpenShift عكس صور الحاويات المطلوبة قبل تثبيت وتوفير مجموعة منفصلة، ويتم وصف المكون الإضافي oc-mirror كالأداة الواحدة المفضلة لعكس إصدارات OpenShift والمشغلين ومخططات Helm والصور الأخرى. يقول نفس التوثيق إن oc-mirror يحافظ على مسارات التحديث لـ OpenShift والمشغلين، ويقوم بالنسخ المتطابق المتزايد، ويستخدم تكوين مجموعة صور تصريحي حتى يتمكن المسؤولون من تضمين الإصدارات والمشغلين التي تحتاجها المجموعة. كما يحذر من أن سجل المرآة يجب أن يكون قابلاً للوصول من قبل كل آلة في المجموعات الموفرة ويجب أن يتوافق مع توفر مجموعات OpenShift الإنتاجية لأن التثبيت والتحديث والعمليات العادية يمكن أن تفشل إذا كان السجل غير قابل للوصول (توثيق النسخ المتطابق لـ OpenShift).

هنا تصبح الحالة الاقتصادية لـ OpenShift أكثر واقعية. يمكن لـ Red Hat تقليل عدد الخيارات وتوفير أدوات مدعومة، لكنه لا يمكنه إلغاء العبء التشغيلي للعميل. لا يزال العقار المنفصل لـ OpenShift بحاجة إلى سعة سجل وتوفر عالٍ وتحكم في الوصول وتخطيط تخزين واختيار صور وإجراءات نقل وسجلات موافقة وتحديثات متكررة. الفريق الذي لا يحافظ على مرآته لم يشترِ مناعة من الترقيات؛ لقد نقل نقطة الفشل من خدمة التحديث العامة إلى عملية السجل الخاصة به.

يمكن أن يكون العائد كبيرًا مع ذلك. قد تفضل مؤسسة منظمة هذا العبء على بديل سحب كل فريق تطبيق لصور عشوائية واختراع كل فريق بنية تحتية لعملية تحديث منفصلة. ميزة OpenShift هي التوحيد القياسي. ضعفه هو أن التوحيد القياسي يجب أن يُدار.

حدود الدعم جزء من البنية

كل منصة مؤسسية تصبح في النهاية محادثة دعم. قد يبدأ الحادث مع pod، لكنه يمكن أن يشمل صورة أساسية ونواة ومحرك تخزين وخطاف قبول ومشغل وموازن تحميل سحابي وسلطة شهادات وشبكة خدمة وبرنامج نصي للعميل. السؤال ليس فقط "ماذا فشل؟" بل "أي مكون مدعوم فشل، وتحت أي تكوين؟"

مواد دعم Red Hat توضح أن الدعم مقيد. يشمل نطاق الإنتاج التثبيت والاستخدام والتكوين والتشخيص وتقارير الأخطاء وإصلاحات الأخطاء المرتبطة بسياسة دورة الحياة، لكنه يستثني أو يحد من مجالات مثل الحزم المعدلة والأجهزة أو برامج التحكم غير المعتمدة والمشاريع المجتمعية التي تستند إليها إصدارات المؤسسات وتطوير الأكواد وميزات المعاينة التقنية (نطاق دعم الإنتاج من Red Hat). تقول سياسة دعم الطرف الثالث إن Red Hat وبائعي الطرف الثالث يدعمون منتجاتهم الخاصة، وإذا تم تحديد مكون طرف ثالث غير معتمد كجزء من مشكلة، يمكن لـ Red Hat أن تطلب من العميل إعادة الإنتاج باستخدام منتج معتمد أو مُصدق من الشريك (سياسة دعم برامج الطرف الثالث من Red Hat).

هذا ليس عيبًا فريدًا في Red Hat. كل بائع برامج مؤسسية له نطاق. السبب في أهميته بالنسبة لـ OpenShift هو أن Kubernetes يدعو إلى التوسع. نفس آلية API التي تجعل OpenShift مرنًا تجعل أيضًا من السهل تثبيت وحدات التحكم وCRDs وخطافات الويب المعدلة والمكونات الإضافية للتخزين وشبكات الخدمة ومصدري الشهادات ومحركات السياسة. يمكن للمؤسسة أن تنشئ بسرعة مجموعة يكون سطح الدعم الفعلي فيها أوسع مما يمكن لأي بائع واحد أن يملكه.

لذا فإن نموذج التشغيل الأفضل لـ OpenShift ليس "قم بتثبيت أي شيء". إنه "قم بالتثبيت ضمن إطار قابل للدعم، واجعل الاستثناءات متعمدة". النظام البيئي المعتمد من Red Hat وOperatorHub ومصادقة الشركاء وفئات دورة حياة المشغل هي طرق لرسم هذا الإطار. نموذج حوكمة المشتري يجب أن يفرضه. بدون هذه الحوكمة، يدفع الاشتراك ثمن منصة يحولها العميل ببطء إلى توزيعة مخصصة.

الخدمات المُدارة تجعل الحدود أكثر حدة. سياسة دعم Azure Red Hat OpenShift من Microsoft، على سبيل المثال، تقول إن بعض تغييرات المجموعة تؤثر على قابلية الدعم وتدرج تكوينات غير مدعومة، بما في ذلك تعديل بعض المكونات الداخلية وضبط تجاوزات تكوين غير مدعومة (سياسة دعم Microsoft Azure Red Hat OpenShift). هذا مثال خدمة سحابية، ليس عقد OpenShift المُدار ذاتيًا، لكنه يظهر نفس المبدأ: كلما كانت المنصة مُدارة أكثر، كانت الحدود أكثر وضوحًا.

الاقتصاديات تدور حول التجميع، وليس الحسابات الترخيصية

أضعف طريقة لتقييم OpenShift هي مقارنة بند الاشتراك مقابل التكلفة الاسمية لـ Kubernetes المنبع. Kubernetes المنبع مجاني للتنزيل. تشغيل منصة تطبيقات إنتاجية عليه مجاني. المقارنة ذات الصلة تشمل وقت هندسة المنصة وهندسة الإصدار وصيانة نظام التشغيل وعمليات السجل وفحص الأمان واختيار المشغل والاستجابة للحوادث وأدلة الامتثال وتدريبات الترقية والتدريب والتوثيق وتكلفة الأخطاء.

رسالة هندسة المنصة من Red Hat مبنية حول مشكلة التجميع هذه. تضع OpenShift والأدوات ذات الصلة كطريقة لتوفير نشر وإدارة موثوقين عبر البيئات، مع الخدمة الذاتية للمطورين والحوكمة (Red Hat OpenShift لهندسة المنصة). يضيف Red Hat OpenShift Platform Plus Advanced Cluster Management وAdvanced Cluster Security وOpenShift Data Foundation Essentials وQuay، مما يوسع العرض من منصة مجموعة إلى حوكمة متعددة المجموعات والأمان وخدمات البيانات وتوزيع السجلات (Red Hat OpenShift Platform Plus).

السؤال الاقتصادي هو ما إذا كانت هذه الإمكانيات المجمعة تحل محل عمل حقيقي أم تضيف طبقة أخرى فقط. في فريق صغير مع بصمة سحابية بسيطة ومهارات قوية في Kubernetes، قد تكون خدمة Kubernetes سحابية مُدارة بالإضافة إلى مجموعة ضيقة من الإضافات أرخص وأسرع. في مؤسسة عالمية مع مجموعات محلية وسحابات متعددة ومواقع منفصلة وأعباء عمل افتراضية واحتياجات تدقيق صارمة ومهارات منصة غير متساوية، يمكن أن يكون OpenShift أرخص بالمعنى الوحيد الذي يهم: عدد أقل من عمليات التكامل المتكررة وعدد أقل من القرارات الحدودية غير المدعومة.

لكن يجب على المشترين أن يكونوا صادقين بشأن التكاليف الجديدة التي يقدمها OpenShift. الترحيل ليس تافهًا. يجب على فرق التطبيق تعلم اصطلاحات OpenShift وقيود سياق الأمان والمسارات وسير عمل المشغل وسياسة الصور والقيود الخاصة بالمجموعة. يجب على فرق المنصة تعلم قنوات دعم Red Hat وصفحات دورة الحياة وملاحظات الإصدار وسلوك الرسم البياني للتحديث وتكوين oc-mirror وموافقات المشغل وممارسات النسخ الاحتياطي. يجب على المشتريات فهم مقاييس الاشتراك. يجب على المهندسين المعماريين تحديد إلى أي مدى يتبنون محفظة Red Hat الأوسع. لا شيء من ذلك مجاني.

الارتباط (Lock-in) حقيقي أيضًا، حتى عندما تكون المنصة مبنية على المصدر المفتوح. ارتباط Red Hat ليس بشكل أساسي فخ API ملكي؛ يظل Kubernetes محوريًا، والعديد من أعباء العمل يمكن نقلها. الارتباط تشغيلي. بمجرد أن توحد الشركة على مسارات التحديث المدعومة من Red Hat والمشغلين المعتمدين والوضع الأمني الخاص بـ OpenShift ونسخ Quay المتطابق وسياسة Advanced Cluster Management وإجراءات دعم Red Hat، فإن الانتقال بعيدًا يعني إعادة بناء نموذج تشغيل، وليس مجرد نقل ملفات YAML.

إشارات العملاء والشركاء تشير إلى احتياجات الحوكمة

يجب قراءة أدلة العملاء العامة حول OpenShift بحذر لأن الكثير منها يأتي من Red Hat أو شركائها، وليس من سجلات ما بعد الحادث المحايدة. مع ذلك، فهي مفيدة لأنها تظهر لماذا تشتري المؤسسات المنصة.

تسلط صفحة Advanced Cluster Management من Red Hat الضوء على Telefonica Spain باستخدام المنتج لإدارة وأتمتة التكوين والتثبيت والصيانة عبر بيئة متعددة السحابات، مع أتمتة من نمط GitOps للتغييرات والتحقق (صفحة Red Hat Advanced Cluster Management). الاقتباس هو إشارة عميل مستضافة من البائع، لذا لا ينبغي معاملته كدليل مستقل على الأداء. إنه يظهر أن مشكلة المشتري هي حوكمة متعددة المجموعات بدلاً من ميزة Kubernetes واحدة.

يصف دليل بنية Azure من Microsoft للخدمات المالية Azure Red Hat OpenShift كطريقة لتشغيل مجموعات OpenShift 4.x مدعومة في بيئات هجينة لأعباء عمل آمنة ومرنة ومتوافقة. يقول إن Microsoft وRed Hat يشرفان على مجموعات Azure Red Hat OpenShift ويديرانها بشكل مشترك، مع تحديثات آلية وتصحيحات وإدارة دورة حياة في سياق الخدمة المُدارة (إرشادات بنية Microsoft لـ Azure Red Hat OpenShift في الخدمات المالية). هذا المصدر ليس دليلاً على أن كل عبء عمل مالي يجب أن يستخدم ARO. إنه دليل على أن شركاء hyperscaler يرون OpenShift كمنصة لأنماط بنية منظمة حيث يكون الدعم ودورة الحياة جزءًا من البيع.

ترشد إرشادات الشريك من AWS لـ Red Hat Advanced Cluster Management خلال استيراد مجموعات EKS وOpenShift وROSA إلى ACM، ونشر تطبيق عبر المجموعات وتوجيه حركة المرور للتوفر العالي (مدونة شبكة شركاء AWS). مرة أخرى، هو عرض توضيحي من شريك، وليس معيار إنتاج. صلته معمارية: عرض قيمة Red Hat يمتد إلى إدارة عقارات Kubernetes المختلطة، وليس فقط مجموعات OpenShift البحتة.

نشرت Red Hat أيضًا دراسة حالة لشركة تكنولوجيا كبيرة مجهولة تضم أكثر من 100 قسم يستخدمون بيئات مختلفة. اختارت الشركة خدمات Red Hat وIBM Consulting لتوجيه الترحيل إلى OpenShift، مع التدريب ومديري الحسابات الفنيين وإثباتات المفاهيم ومسارات التبني المخصصة لمجموعات مختلفة (دراسة حالة شركة تكنولوجيا مجهولة من Red Hat). عدم الكشف عن الهوية يحد من الوزن الإثباتي، ودراسات حالة البائع تختار بشكل طبيعي نتائج مواتية. لكن التفاصيل التشغيلية موثوقة: تبني OpenShift على هذا النطاق هو مشروع أشخاص وعملية، وليس تثبيت برنامج.

النمط عبر هذه الإشارات متسق. لا تشتري المؤسسات OpenShift ببساطة لأن Kubernetes صعب. إنها تشتريه لأن Kubernetes اللامركزي يصبح عمل حوكمة. القرار يدور حول من يحدد دورة الحياة، ومن يتحقق من المكونات، ومن يدرب الفرق، ومن يوفر التصعيد، وكم التباين الذي يمكن للمؤسسة تحمله.

أين يمكن أن يفشل OpenShift مع المشتري

أنماط فشل OpenShift ليست افتراضية. إنها تتبع مباشرة نفس الآليات التي تخلق القيمة.

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

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

يمكن أن يصبح ترحيل CRD الترقية الحقيقية. سياسة هجر Kubernetes الخاصة تشرح أن APIs تتطور، وأن APIs التجريبية يمكن إزالتها بعد فترات محددة، وأن التمثيلات المخزنة وقواعد التحويل مهمة (سياسة هجر Kubernetes). في الممارسة العملية، هذا يعني أن فرق التطبيق يجب أن تعرف إصدارات API التي تستخدمها ومتى تتوقف هذه الإصدارات عن العمل. OpenShift يمكنه توثيق والتحذير، لكنه لا يمكنه إعادة كتابة كل تبعية تطبيق بأمان دون مشاركة المالك.

يمكن أن تنحرف المرآة المنفصلة. توثيق oc-mirror صريح بأن المسؤولين يجب أن يكرروا خطوات النسخ المتطابق لتحديث السجل المستهدف وأن توفر المرآة مهم للتثبيت والتحديثات والعمليات الروتينية (توثيق النسخ المتطابق لـ OpenShift). إذا كانت المرآة قديمة أو غير كاملة أو غير متاحة، فقد يكون المسار المدعوم للمجموعة موجودًا في نظام Red Hat البيئي ولكن ليس في بيئة العميل.

يمكن أن يتباطأ تصعيد الدعم بسبب الغموض. إذا لمس حادث مشغل طرف ثالث أو حد مزود سحابي أو أتمتة مخصصة أو ميزة غير مدعومة أو صورة تطبيق مبنية على حزم غير عادية ومكون Red Hat، فإن المهمة الأولى هي التشخيص وتخطيط المسؤولية. قد لا يزال Red Hat ذا قيمة في هذا السيناريو، لكن القيمة ليست سحرية. إنها القدرة على تضييق المشكلة وتحديد ما إذا كانت المنصة ضمن الإطار المدعوم.

يمكن أن يقدم التصحيح الأمني أيضًا خطر تراجع. تحافظ Red Hat وKubernetes على سياسات حول الإصدارات المدعومة والتصحيحات، لكن كل إصلاح عاجل لا يزال يهبط في بيئة حية. منصة عالية الجودة تقلل المفاجأة؛ إنها لا تجعل مخاطر التغيير تختفي. الوضع التشغيلي الصحيح هو التدريبات والمراقبة والنسخ الاحتياطي وتخطيط التراجع المناسب لعبء العمل، وليس الثقة العمياء في تحديث البائع.

اختبار المشتري يجب أن يكون محليًا

يبدأ التقييم الصحيح لـ OpenShift بتاريخ تشغيل المشتري نفسه. احسب عدد مجموعات Kubernetes والإصدارات وصور العقد ووحدات تحكم الدخول ومحركات التخزين ومحركات السياسة والسجلات ومسارات الشهادات والمشغلين المستخدمة بالفعل. احسب الأشخاص الذين يمكنهم ترقيتها بأمان. احسب فرق التطبيق التي تفهم APIs التي تم هجرها. احسب المجموعات ذات الاتصال المنفصل أو المقيد. احسب النتائج الأمنية التي تتطلب تحديثات منسقة للصورة الأساسية والعقدة والمنصة. احسب عدد المرات التي تأخرت فيها الترقية لأنه لا أحد يعرف ما إذا كانت التبعية مدعومة.

إذا كانت هذه الأعداد منخفضة، فقد يكون OpenShift وسيلة مكلفة لشراء المراسم. فريق قادر يستخدم خدمة Kubernetes مُدارة ومجموعة إضافات ضيقة وأتمتة قوية قد يكون لديه احتكاك أقل بدون OpenShift. لا يزال منصة Red Hat منطقية إذا كانت الشركة تقدر الدعم أو الاتساق الهجين، لكن يجب إثبات حالة العمل بدلاً من افتراضها.

إذا كانت هذه الأعداد عالية، يصبح OpenShift أكثر إقناعًا. قيمة الرسم البياني للتحديث المختبر ودورة الحياة المنشورة وتكامل RHCOS وتصنيفات المشغل والنسخ المتطابق المنفصل ونطاق الدعم والنظام البيئي للشريك تنمو مع التعقيد التنظيمي. يصبح الاشتراك وسيلة لشراء عقد تشغيل مشترك. يجب على المشتري مع ذلك التفاوض بقوة على التكلفة والتدريب وتوقعات الدعم، لكن البديل ليس مجانيًا. إنه صيانة منصة داخلية على نطاق المؤسسة.

أهم دليل ليس جرد ميزات. إنها تدريب ترقية. يجب على المشتري الجاد اختبار مجموعة تمثيلية مع مشغلين حقيقيين وتطبيقات تمثيلية وسياسة أمان ومراقبة وقيود سجل ونافذة تغيير واقعية. يجب عليه تسجيل عدد التحذيرات التي تظهر، وعدد مالكي التطبيقات الذين يجب أن يتصرفوا، وكم من الوقت يستغرق تحديث المرآة، وماذا يقول الدعم حول مكونات الطرف الثالث، وكم من العمل تزيله أدوات Red Hat بالفعل. هذا الاختبار سيقول أكثر من رقم قياسي.

ما الذي سيغير الحكم

ستتعزز حالة Red Hat إذا أظهرت الأدلة العامة المزيد من نتائج الترقية الإنتاجية المستقلة: معدلات انتقال الإصدار الثانوي الناجح، وتكرار التحديثات الشرطية حسب القناة، ومتوسط الوقت لإزالة المخاطر المعروفة، وتأخر استعداد المشغل، ووقت حل الدعم لمعوقات الترقية، وانخفاض الحوادث المرئية للعميل بعد تبني OpenShift. معظم هذه البيانات غير متاحة للجمهور بطريقة تدعم الادعاءات الواسعة.

ستضعف الحالة إذا وجد العملاء مرارًا أن عمليات التكامل المعتمدة تتأخر كثيرًا عن إصدارات OpenShift، وأن التحديثات الشرطية تصبح معوقات شائعة، وأن سير العمل المنفصل ثقيل الصيانة، وأن نطاق الدعم يدفع العديد من الحوادث إلى طرف ثالث، أو أن خدمات Kubernetes المُدارة تغطي ما يكفي من عمل دورة الحياة بتكلفة أقل. ستضعف أيضًا إذا جعلت الممارسات الخاصة بـ OpenShift قابلية نقل التطبيق أكثر نظرية من واقعية.

الأدلة الحالية تقع في المنتصف. Red Hat لديه آلية تقنية موثوقة لإدارة دورة الحياة، وتقارير IBM تظهر زخمًا تجاريًا قويًا. التوثيق العام ناضج بما يكفي لإظهار كل من الوعد والتحذيرات. أدلة العملاء تشير إلى الحوكمة والتدريب وعمل الترحيل، وليس التحول السهل. هذه نتيجة رصينة لكنها مفيدة.

الخلاصة

من الأفضل فهم OpenShift من Red Hat كعقد دورة حياة مؤسسية حول Kubernetes وLinux والمشغلين. موثوقية المنتج لا تثبت بإنشاء المجموعة. إنها تثبت بالترقية التي لا تعلق أعباء العمل، ومسار المشغل الذي لا يفاجئ المسؤولين، والمرآة التي تحتوي على المحتوى المطلوب، وحدود الدعم التي تبقى واضحة أثناء الحوادث، وفرق التطبيق التي يمكنها التحرك قبل أن تصبح APIs المهملة انقطاعات.

بالنسبة للمشتري المناسب، يمكن أن يكون هذا العقد أكثر قيمة من تكاليف الاشتراك لأنه يستبدل تجميع المنصة المتناثر بمسار مختبر وبائع مسؤول. بالنسبة للمشتري الخطأ، يمكن أن يضيف تكلفة وعملية وتبعية حيث كانت خدمة Kubernetes مُدارة أبسط كافية. تحدي Red Hat هو إبقاء المسار المدعوم واسعًا بما يكفي لتطبيقات المؤسسات الحقيقية مع إبقائه صارمًا بما يكفي ليعني شيئًا.

الحكم إذن مشروط. OpenShift هو إجابة قوية للمؤسسات التي تكون مشكلة Kubernetes الخاصة بها هي حوكمة دورة الحياة عبر بيئات هجينة أو منظمة أو متعددة السحابات. إنه إجابة أضعف للفرق التي تكون حاجتها الرئيسية مكانًا منخفض الاحتكاك لتشغيل الحاويات. الرسم البياني للترقية هو الاختبار الصادق: إذا استطاع Red Hat إبقاء المجموعات والمشغلين وتبعيات RHEL تتحرك عبر مسارات معروفة أسرع وأكثر أمانًا مما يمكن للعميل فعله بمفرده، فإن OpenShift يستحق مكانه. إذا لم يكن الأمر كذلك، فإن المشتري يدفع ثمن خريطة لا يمكنه اتباعها.