"ما الفرق بين Kubernetes وOpenShift؟" – يطرح هذا السؤال بثبات يحسد عليه. على الرغم من أن هذا في الواقع يشبه السؤال عن كيفية اختلاف السيارة عن المحرك. إذا واصلنا هذا التشبيه، فإن السيارة هي منتج نهائي، ويمكنك استخدامه على الفور، حرفيًا: اركب وانطلق. من ناحية أخرى، لكي يأخذك المحرك إلى مكان ما، يجب أولاً استكماله بالكثير من الأشياء الأخرى حتى تحصل في النهاية على نفس السيارة.
لذلك، فإن Kubernetes هو المحرك الذي يتم من خلاله تجميع السيارة (المنصة) ذات العلامة التجارية OpenShift، والتي تأخذك إلى هدفك.
نريد في هذه المقالة أن نذكرك ونفحص النقاط الرئيسية التالية بمزيد من التفصيل:
- Kubernetes هو قلب منصة OpenShift وهو معتمد بنسبة 100% من Kubernetes، وهو مفتوح المصدر تمامًا وبدون أدنى طبيعة ملكية. باختصار:
- واجهة برمجة تطبيقات مجموعة OpenShift هي XNUMX% من Kubernetes.
- إذا كانت الحاوية تعمل على أي نظام Kubernetes آخر، فستعمل على OpenShift دون أي تغييرات. ليست هناك حاجة لإجراء تغييرات على التطبيقات.
- لا يضيف OpenShift ميزات ووظائف مفيدة إلى Kubernetes فحسب. مثل السيارة، يعد OpenShift خارج الصندوق، ويمكن وضعه في مرحلة الإنتاج على الفور، وكما سنوضح أدناه، فهو يجعل حياة المطور أسهل كثيرًا. ولهذا السبب فإن OpenShift هو واحد من كل شخصين. إنها منصة PaaS ناجحة ومعروفة على مستوى المؤسسات من وجهة نظر المطور. وفي الوقت نفسه، فهو عبارة عن حل حاوية كخدمة فائق الموثوقية من وجهة نظر التشغيل الصناعي.
OpenShift هو Kubernetes حاصل على شهادة CNCF بنسبة 100%
يعتمد OpenShift على . لذلك، بعد التدريب المناسب، يندهش المستخدمون من قوة kubectl. وأولئك الذين تحولوا إلى OpenShift من مجموعة Kubernetes غالبًا ما يقولون كم يعجبهم حقًا، بعد إعادة توجيه kubeconfig إلى مجموعة OpenShift، تعمل جميع البرامج النصية الموجودة بشكل لا تشوبه شائبة.
من المحتمل أنك سمعت عن الأداة المساعدة لسطر أوامر OpenShift والتي تسمى OC. إنه متوافق تمامًا مع الأوامر مع kubectl، بالإضافة إلى أنه يقدم العديد من المساعدات المفيدة التي ستكون مفيدة عند تنفيذ عدد من المهام. لكن أولاً، المزيد عن توافق OC وkubectl:
أوامر كوبيكتل
فرق او سي
kubectl الحصول على القرون
احصل على القرون
kubectl الحصول على مساحات الأسماء
oc الحصول على مساحات الأسماء
kubectl create -f Publisher.yaml
oc إنشاء -f Deployment.yaml
إليك ما تبدو عليه نتائج استخدام kubectl على OpenShift API:
• kubectl get pods - إرجاع البودات كما هو متوقع.
• kubectl الحصول على مساحات الأسماء - إرجاع مساحات الأسماء كما هو متوقع.
يقوم الأمر kubectl create -f mydeployment.yaml بإنشاء موارد kubernetes تمامًا كما هو الحال في أي منصة Kubernetes أخرى، كما هو موضح في الفيديو أدناه:
بمعنى آخر، جميع واجهات برمجة تطبيقات Kubernetes متاحة بالكامل في OpenShift مع الحفاظ على التوافق بنسبة 100%. ذلك هو السبب .
يضيف OpenShift ميزات مفيدة إلى Kubernetes
تتوفر واجهات برمجة تطبيقات Kubernetes بنسبة 100% في OpenShift، ولكن من الواضح أن الأداة المساعدة Kubernetes القياسية kubectl تفتقر إلى الوظائف والراحة. ولهذا السبب أضافت Red Hat ميزات مفيدة وأدوات سطر أوامر إلى Kubernetes، مثل OC (اختصار لعميل OpenShift) وODO (OpenShift DO، هذه الأداة المساعدة تستهدف المطورين).
1. أداة OC - نسخة أكثر قوة وملاءمة من Kubectl
على سبيل المثال، على عكس kubectl، فهو يسمح لك بإنشاء مساحات أسماء جديدة وتبديل السياقات بسهولة، كما يقدم أيضًا عددًا من الأوامر المفيدة للمطورين، مثل إنشاء صور الحاوية ونشر التطبيقات مباشرة من التعليمات البرمجية المصدر أو الثنائيات (المصدر إلى الصورة، s2i).
دعونا نلقي نظرة على أمثلة لكيفية مساعدة المساعدين المضمنين والوظائف المتقدمة لأداة OC المساعدة في تبسيط العمل اليومي.
المثال الأول هو إدارة مساحة الاسم. تحتوي كل مجموعة Kubernetes دائمًا على مساحات أسماء متعددة. تُستخدم عادةً لإنشاء بيئات التطوير والإنتاج، ولكن يمكن استخدامها أيضًا، على سبيل المثال، لتزويد كل مطور بصندوق حماية شخصي. من الناحية العملية، يؤدي هذا إلى اضطرار المطور إلى التبديل بين مساحات الأسماء بشكل متكرر، حيث يعمل kubectl في سياق المساحة الحالية. لذلك، في حالة kubectl، يستخدم الأشخاص بنشاط البرامج النصية المساعدة لهذا الغرض. ولكن عند استخدام OC، للتبديل إلى المساحة المطلوبة، فقط قل "oc project namespace".
ألا تتذكر اسم مساحة الاسم التي تحتاجها؟ لا مشكلة، فقط اكتب "oc get project" لعرض القائمة الكاملة. هل تتساءل كيف سيعمل هذا إذا كان لديك فقط إمكانية الوصول إلى مجموعة فرعية محدودة من مساحات الأسماء في المجموعة؟ حسنًا، لأن kubectl لا يقوم بذلك بشكل صحيح إلا إذا سمح لك RBAC برؤية جميع المساحات الموجودة في المجموعة، وفي المجموعات الكبيرة لا يتم منح هذه الأذونات للجميع. لذلك، نجيب: بالنسبة لـ OC، هذه ليست مشكلة على الإطلاق وستنتج بسهولة قائمة كاملة في مثل هذه الحالة. هذه الأشياء الصغيرة هي التي تشكل التوجه المؤسسي لـ Openshift وقابلية التوسع الجيدة لهذه المنصة من حيث المستخدمين والتطبيقات
2. ODO - نسخة محسنة من kubectl للمطورين
مثال آخر على تحسينات Red Hat OpenShift على Kubernetes هو الأداة المساعدة لسطر أوامر ODO. إنه مصمم للمطورين ويسمح لك بنشر التعليمات البرمجية المحلية بسرعة إلى مجموعة OpenShift البعيدة. يمكنه أيضًا تبسيط العمليات الداخلية لمزامنة جميع تغييرات التعليمات البرمجية على الفور مع الحاويات الموجودة في مجموعة OpenShift البعيدة دون الحاجة إلى إعادة إنشاء الصور وتسجيلها وإعادة نشرها.
دعونا نلقي نظرة على كيفية قيام OC وODO بتسهيل العمل مع الحاويات وKubernetes.
ما عليك سوى مقارنة اثنين من مسارات العمل عندما يتم إنشاؤها على أساس kubectl، وعند استخدام OC أو ODO.
• نشر التعليمات البرمجية على OpenShift لأولئك الذين لا يتحدثون YAML:
كوبيرنيتيس/kubectl
$> استنساخ البوابة
1- قم بإنشاء ملف Dockerfile الذي يقوم ببناء الصورة من الكود
-----
من العقدة
WORKDIR /usr/src/app
نسخ الحزمة*.json ./
انسخ ملف Index.js ./
نسخ ./app ./app
تشغيل تثبيت npm
كشف 3000
CMD ["npm"، "ابدأ"] ————–
2- نبني الصورة
$>بناء بودمان...
3- الدخول إلى الريجستري
تسجيل دخول بودمان...
4- ضع الصورة في الريجستري
دفع بودمان
5- قم بإنشاء ملفات yaml لنشر التطبيق (deployment.yaml،service.yaml، ingress.yaml) - هذا هو الحد الأدنى المطلق
6- نشر ملفات البيان:
تطبيق كوبيكتل -f .
أوبن شيفت/أوك
$> oc التطبيق الجديد – اسم_التطبيق الخاص بنا
أوبن شيفت/أودو
$> استنساخ البوابة
$> قم بإنشاء مكون nodejs myapp
$>دفعة أودو
• تبديل السياق: تغيير مساحة اسم العمل أو مجموعة العمل.
كوبيرنيتيس/kubectl
1- إنشاء سياق في kubeconfig لمشروع "myproject"
2- سياق مجموعة kubectl ...
أوبن شيفت/أوك
مشروع "مشروعي"
مراقبة الجودة: "ظهرت هنا ميزة مثيرة للاهتمام، ولا تزال في إصدار ألفا. ربما يمكننا وضعه في الإنتاج؟ "
تخيل أنك تجلس في سيارة سباق ويقال لك: "لقد قمنا بتركيب نوع جديد من الفرامل، ولكي نكون صادقين، فإن موثوقيتها ليست على ما يرام بعد... ولكن لا تقلق، سوف نقوم بتحسينها بشكل فعال خلال بطولة." كيف تحب هذا الاحتمال؟ نحن في ريد هات لسنا سعداء إلى حدٍ ما. 🙂
لذلك، نحاول تأجيل إصدار إصدارات ألفا حتى تنضج بدرجة كافية ونجري اختبارات قتالية شاملة ونشعر أنها آمنة للاستخدام. عادة، يمر كل شيء بمرحلة معاينة المطورين أولاً، ثم عبرها وعندها فقط يخرج كإصدار عام (GA)، وهي مستقرة بالفعل لدرجة أنها مناسبة للإنتاج.
لماذا هذا؟ لأنه، كما هو الحال مع تطوير أي برنامج آخر، لا تصل جميع الأفكار الأولية في Kubernetes إلى الإصدار النهائي. أو يصلون إليها ويحتفظون حتى بالوظيفة المقصودة، لكن تنفيذها يختلف جذريًا عن ذلك الموجود في إصدار ألفا. مع الآلاف والآلاف من عملاء Red Hat الذين يستخدمون OpenShift لدعم أعباء العمل ذات المهام الحرجة، فإننا نركز بشكل خاص على استقرار منصتنا والدعم طويل المدى.
تلتزم Red Hat بإصدار OpenShift بشكل متكرر وتحديث إصدار Kubernetes الذي يأتي معه. على سبيل المثال، يتضمن إصدار GA الحالي من OpenShift 4.3 في وقت كتابة هذا التقرير Kubernetes 1.16، وهو وحدة واحدة فقط خلف الإصدار الرئيسي من Kubernetes رقم 1.17. وبالتالي، فإننا نحاول تزويد العميل بنظام Kubernetes على مستوى المؤسسات وتوفير تحكم إضافي في الجودة أثناء إصدار إصدارات جديدة من OpenShift.
إصلاحات البرنامج: "كان هناك ثغرة في إصدار Kubernetes الذي لدينا قيد الإنتاج. ولا يمكنك إغلاقه إلا بتحديث ثلاثة إصدارات. أم أن هناك أي خيارات؟
في مشروع Kubernetes مفتوح المصدر، عادةً ما يتم إصدار إصلاحات البرامج كجزء من الإصدار التالي، وتغطي أحيانًا إصدارًا أو إصدارين رئيسيين سابقين، مما يوفر تغطية لمدة لا تزيد عن 6 أشهر.
تفتخر شركة Red Hat بإطلاق الإصلاحات المهمة في وقت أبكر من غيرها وتوفير الدعم لفترة أطول. خذ على سبيل المثال ثغرة تصعيد امتيازات Kubernetes (): تم اكتشافه في Kubernetes 1.11، وتم إصدار إصلاحات الإصدارات السابقة فقط حتى الإصدار 1.10.11، مما ترك هذا الإصلاح في الثغرة في جميع إصدارات Kubernetes السابقة، من 1.x إلى 1.9.
في المقابل، (يوجد Kubernetes 1.2)، حيث استحوذ على تسعة إصدارات من OpenShift وأظهر بوضوح الاهتمام بالعملاء (مزيد من التفاصيل ).
كيف يعمل OpenShift وRed Hat على دفع Kubernetes للأمام
تعد Red Hat ثاني أكبر مساهم في البرامج في مشروع Kubernetes مفتوح المصدر، بعد Google فقط، مع 3 من أكثر 5 مطورين إنتاجًا يأتون من Red Hat. حقيقة أخرى غير معروفة: ظهرت العديد من الوظائف المهمة في Kubernetes على وجه التحديد بمبادرة من Red Hat، على وجه الخصوص، مثل:
- RBAC. لم يكن لدى Kubernetes وظائف RBAC (ClusterRole، ClusterRoleBinding) حتى قرر مهندسو Red Hat تنفيذها كجزء من النظام الأساسي نفسه، وليس كوظيفة OpenShift إضافية. هل تخشى Red Hat تحسين Kubernetes؟ بالطبع لا، لأن Red Hat تتبع بشكل صارم مبادئ المصادر المفتوحة ولا تلعب ألعاب Open Core. تعد التحسينات والابتكارات التي تقودها مجتمعات التطوير، بدلاً من المجتمعات المملوكة، أكثر قابلية للتطبيق ويتم اعتمادها على نطاق أوسع، وهو ما يتوافق جيدًا مع هدفنا الأساسي المتمثل في جعل البرامج مفتوحة المصدر أكثر فائدة لعملائنا.
- سياسات الأمان للقرون (سياسات أمان Pod). تم تطبيق مفهوم تشغيل التطبيقات بشكل آمن داخل البودات في الأصل في OpenShift تحت اسم SCC (قيود سياق الأمان). وكما في المثال السابق، قررت شركة Red Hat إدخال هذه التطورات في مشروع Kubernetes المفتوح حتى يتمكن الجميع من استخدامها.
يمكن الاستمرار في هذه السلسلة من الأمثلة، لكننا أردنا فقط إظهار أن Red Hat ملتزمة حقًا بتطوير Kubernetes وجعله أفضل للجميع.
من الواضح أن OpenShift هو Kubernetes. ما هي الاختلافات؟ 🙂
نأمل من خلال قراءة هذا المقال أن تكون قد أدركت أن Kubernetes هو المكون الأساسي لـ OpenShift. الشيء الرئيسي، ولكن ليس الوحيد. بمعنى آخر، لن يمنحك تثبيت Kubernetes ببساطة نظامًا أساسيًا على مستوى المؤسسات. ستحتاج إلى إضافة المصادقة والشبكات والأمان والمراقبة وإدارة السجل والمزيد. بالإضافة إلى ذلك، سيتعين عليك اتخاذ بعض الاختيارات الصعبة من بين العدد الكبير من الأدوات المتاحة (لتقدير تنوع النظام البيئي، ما عليك سوى إلقاء نظرة ) ويضمنون بطريقة أو بأخرى الاتساق والتماسك حتى يعملوا كواحد. بالإضافة إلى ذلك، ستحتاج بانتظام إلى إجراء التحديثات واختبار الانحدار كلما تم إصدار إصدار جديد لأي من المكونات التي تستخدمها. أي أنه بالإضافة إلى إنشاء المنصة نفسها وصيانتها، ستحتاج أيضًا إلى التعامل مع كل هذه البرامج. من غير المرجح أن يتبقى الكثير من الوقت لحل مشاكل العمل وتحقيق المزايا التنافسية.
ولكن في حالة OpenShift، تأخذ Red Hat كل هذه التعقيدات على عاتقها وتمنحك ببساطة منصة كاملة وظيفيًا، والتي لا تتضمن فقط Kubernetes نفسها، ولكن أيضًا المجموعة الكاملة من الأدوات مفتوحة المصدر الضرورية التي تحول Kubernetes إلى فئة مؤسساتية حقيقية. الحل الذي يمكنك إطلاقه على الفور وبهدوء تام في الإنتاج. وبالطبع، إذا كان لديك بعض مجموعات التكنولوجيا الخاصة بك، فيمكنك دمج OpenShift في الحلول الحالية.
ألقِ نظرة على الصورة أعلاه: كل ما هو خارج مستطيل Kubernetes هو المكان الذي تضيف فيه Red Hat وظائف لا يمتلكها Kubernetes، كما يقولون، حسب التصميم. والآن سننظر إلى أهم هذه المجالات.
1. نظام تشغيل قوي كقاعدة: RHEL CoreOS أو RHEL
لقد كانت Red Hat شركة رائدة في مجال توفير توزيعات Linux للتطبيقات المهمة للأعمال لأكثر من 20 عامًا. تتيح لنا خبرتنا المتراكمة والمحدثة باستمرار في هذا المجال تقديم أساس موثوق وموثوق به حقًا للتشغيل الصناعي للحاويات. يستخدم RHEL CoreOS نفس نواة RHEL، ولكن تم تحسينه بشكل أساسي لمهام مثل تشغيل الحاويات وتشغيل مجموعات Kubernetes: حجمه الصغير وثباته يجعل من السهل إعداد المجموعات، والقياس التلقائي، ونشر التصحيحات، وما إلى ذلك. كل هذه الميزات تجعله أكثر سهولة. أساس مثالي لتقديم نفس تجربة المستخدم مع OpenShift عبر مجموعة واسعة من بيئات الحوسبة، بدءًا من الأنظمة المعدنية وحتى السحابة الخاصة والعامة.
2. أتمتة عمليات تكنولوجيا المعلومات
تُعد أتمتة عمليات التثبيت وعمليات اليوم الثاني (أي العمليات اليومية) نقطة قوة OpenShift، مما يجعل من الأسهل بكثير إدارة وتحديث والحفاظ على أداء منصة الحاوية على أعلى مستوى. ويتم تحقيق ذلك من خلال دعم مشغلي Kubernetes على مستوى نواة OpenShift 4.
يعد OpenShift 4 أيضًا نظامًا بيئيًا كاملاً من الحلول المستندة إلى مشغلي Kubernetes، والتي تم تطويرها بواسطة Red Hat نفسها وشركاء خارجيين (انظر. ريد هات، أو متجر المشغل ، تم إنشاؤها بواسطة Red Hat لمطوري الطرف الثالث).
يتضمن كتالوج OpenShift 4 المتكامل أكثر من 180 مشغل Kubernetes
3. أدوات المطور
منذ عام 2011، أصبح OpenShift متاحًا كمنصة PaaS (النظام الأساسي كخدمة) التي تجعل الحياة أسهل بكثير للمطورين، وتساعدهم على التركيز على البرمجة، وتوفر دعمًا أصليًا للغات البرمجة مثل Java وNode.js وPHP وRuby وPython وGo، بالإضافة إلى التكامل المستمر لـ CI/CD وخدمات التوصيل وقواعد البيانات وما إلى ذلك. يقدم OpenShift 4 ، والتي تتضمن أكثر من 100 خدمة تعتمد على مشغلي Kubernetes التي طورتها Red Hat وشركاؤنا.
على عكس Kubernetes، يحتوي OpenShift 4 على واجهة مستخدم رسومية مخصصة ()، مما يساعد المطورين على نشر التطبيقات بسهولة من مصادر مختلفة (git، والسجلات الخارجية، وDockerfile، وما إلى ذلك) في مساحات الأسماء الخاصة بهم ويتصور بوضوح العلاقات بين مكونات التطبيق.
بالإضافة إلى ذلك، يقدم OpenShift مجموعة من أدوات تطوير Codeready، والتي تتضمن على وجه الخصوص ، بيئة تطوير متكاملة (IDE) تحتوي على حاوية كاملة مع واجهة ويب تعمل مباشرة أعلى OpenShift وتنفذ نهج بيئة تطوير متكاملة (IDE) كخدمة. من ناحية أخرى، بالنسبة لأولئك الذين يرغبون في العمل بشكل صارم في الوضع المحلي، هناك Codeready Containers، وهو إصدار كامل الوظائف من OpenShift 4 يمكن نشره على جهاز كمبيوتر محمول.
بيئة تطوير متكاملة (IDE) متكاملة كخدمة للتطوير الفعال على منصة Kubernetes/OpenShift
يوفر OpenShift نظام CI/CD كاملًا بمجرد إخراجه من الصندوق، إما استنادًا إلى Jenkins الموجود في حاوية أو مكون إضافي للعمل مع خطوط الأنابيب، أو نظام CI/CD الموجه لـ Kubernetes (حاليًا في إصدار المعاينة التقنية). يتكامل كلا الحلين بشكل كامل مع وحدة تحكم OpenShift، مما يسمح لك بتشغيل مشغلات خطوط الأنابيب وعرض عمليات النشر والسجلات والمزيد.
4. أدوات التطبيق
يسمح لك OpenShift بنشر كل من التطبيقات ذات الحالة التقليدية والحلول المستندة إلى السحابة بناءً على بنيات جديدة، مثل الخدمات الصغيرة أو بدون خادم. يأتي حل OpenShift Service Mesh فورًا مزودًا بأدوات أساسية للحفاظ على الخدمات الصغيرة، مثل Istio وKiali وJaeger. وفي المقابل، لا يشتمل حل OpenShift Serverless على Knative فحسب، بل يشمل أيضًا أدوات مثل Keda التي تم إنشاؤها كجزء من مبادرة مشتركة مع Microsoft لتوفير وظائف Azure على منصة OpenShift.
سيكون الحل المتكامل OpenShift ServiceMesh (Istio، Kiali، Jaeger) مفيدًا عند تطوير الخدمات الصغيرة
لسد الفجوة بين التطبيقات القديمة والحاويات، يسمح OpenShift الآن بترحيل الأجهزة الافتراضية إلى منصة OpenShift باستخدام Container Native Virtualization (الموجود حاليًا في TechPreview)، مما يجعل التطبيقات المختلطة حقيقة واقعة ويسهل ترحيلها بين السحابات المختلفة، الخاصة والعامة.
جهاز ظاهري Windows 2019 يعمل على OpenShift عبر Container Native Virtualization (حاليًا في إصدار المعاينة التقنية)
5. أدوات للمجموعات
يجب أن تحتوي أي منصة على مستوى المؤسسات على خدمات المراقبة والتسجيل المركزي، وآليات الأمان، والمصادقة والترخيص، وأدوات إدارة الشبكة. ويوفر OpenShift كل هذا بشكل خارج الصندوق، وهو مفتوح المصدر بنسبة 100%، بما في ذلك حلول مثل ElasticSearch وPrometheus وGrafana. تأتي كل هذه الحلول مزودة بلوحات معلومات ومقاييس وتنبيهات تم إنشاؤها وتكوينها بالفعل باستخدام خبرة Red Hat الواسعة في مراقبة المجموعة، مما يسمح لك بالتحكم في بيئة الإنتاج الخاصة بك ومراقبتها بشكل فعال منذ البداية.
يأتي OpenShift أيضًا بشكل قياسي مزودًا بأشياء مهمة لعملاء الشركات مثل المصادقة مع موفر oauth المدمج، والتكامل مع موفري بيانات الاعتماد، بما في ذلك LDAP، وActiveDirectory، وOpenID Connect، وغير ذلك الكثير.
لوحة معلومات Grafana التي تم تكوينها مسبقًا لمراقبة مجموعة OpenShift
أكثر من 150 مقياسًا وتنبيهًا من Prometheus تم تكوينها مسبقًا لمراقبة مجموعة OpenShift
أن تستمر
إن الوظائف الغنية للحل وخبرة Red Hat الواسعة في مجال Kubernetes هي الأسباب التي جعلت OpenShift تحقق مركزًا مهيمنًا في السوق، كما هو موضح في الشكل أدناه (اقرأ المزيد ).
"تتصدر شركة Red Hat السوق حاليًا بحصة تبلغ 44٪.
تجني الشركة فوائد استراتيجية المبيعات التي تركز على العملاء، حيث تقوم أولاً بالتشاور مع مطوري المؤسسات وتدريبهم ثم تنتقل إلى تحقيق الدخل عندما تبدأ المؤسسة في نشر الحاويات في الإنتاج.
(المصدر: )
نأمل أن تستمتع بهذا المقال. في المنشورات المستقبلية في هذه السلسلة، سنلقي نظرة فاحصة على مزايا OpenShift مقارنة بـ Kubernetes في كل فئة من الفئات التي تمت مناقشتها هنا.
المصدر: www.habr.com