سوالات زیادی راجع به ماهیت OpenShift وجود دارد و با تغییر حاضر در نسخه‌های 3.x به Kubernetes از معماری قبلی، سوالی که بیشتر از همه تکرار می‌شود راجع به تفاوت‌های میان OpenShift و Kubernetes است. در این خبر به بررسی این تفاوت ها خواهیم پرداخت .
مفهوم Kubernetes
در CoreOS، در واقع Kubernetes را هستهی سیستم‌های توزیع شده در نظر گرفته می‌شود. یک برنامه‌ی زمانبندی کارها که به خوبی طراحی شده باشد، در چندین ماشین کار کند و قادر به هماهنگی وضعیت کارهای مدیریت شده نیز باشد، همانند تاثیری که هستهی لینوکس برای بار کاری برنامه ریزی شده بر روی یک Host دارد، به طور طبیعی همکاری را افزایش می‌دهد. با همین منطق، RedHat می‌دانست که تمایزی که کاربران میان محصولات قائل می‌شوند، بر اساس اهمیت‌شان خواهد بود.
این همان هستهی لینوکس است که در بسیاری از گوشی‌ها، لپ تاپ‌ها، سرورها و حتی Raspberry Pi اجرا می‌شود، و تفاوتشان در وجود Patchهای گوناگونی است که برای پشتیبانی از سخت افزارهایی که هسته به طور مستقیم بر روی آن‌ها استقرار دارد، منتشر می‌شوند. این مدل نیز به همان ترتیب است. به طوری که Kubernetes در توزیع‌های مختلف Kubernetes مشابه است، با این تفاوت که برای پشتیبانی از لایه‌ای که Kubernetes بر روی آن مستقر است، Patchهای مختلفی وجود دارند.
بررسی OpenShift
تیم OpenShift مفتخر است که توزیعی از Kubernetes را با هدف بهبود تجربه توسعه دهندگان نسل بعدی برنامه‌های کاربردی بومی Cloud تولید کرده است. تیم Tectonic (توزیع CoreOS از Kubernetes) بر روی تجربه مدیران و تیم‌های عملیاتی که نیاز داشتند به سرعت به مسائل مربوط به سیستم عامل و Kubernetes رسیدگی کنند، متمرکز بود. با انتشار نسخه‌ی OpenShift 4.0 که به زودی عرضه خواهد شد، برای هر دو نوع مخاطب، رابط‌های کاربری ارائه خواهد شد تا به نیازهای خاص هر دو پاسخ داده شود.
با این که همه می‌توانند لینوکس را از ابتدا با انتخاب هر قطعه و جمع آوری آن‌ها را به روش دلخواه خود بسازند، بیشتر کاربران این کار را نمی‌کنند. سطح جداسازی‌ای که اغلب کاربران انتخاب می‌کنند بدین معنی است که آن‌ها از مدیریت و یا حتی دانش در مورد تفاوت بین Util-Linux نسخه 2.31 و 2.33 بهره‌ی زیادی نمی‌برند. اگر بخواهیم یک قدم جلوتر برویم، باید گفت که کاربران به حداقل سطح عملکرد و پس از آن به لیست ویژگی‌های ارائه شده اهمیت می‌دهند. حداقل سطح عملکرد به عنوان مثال دانستن این است که کدام دستورات و یا APIها پس از کدام نسخه در دسترس هستند.
این بسیار شبیه OpenShift است. Kubernetes با ابزارهای اضافی مهم و تقاضا شده توسط کاربران تجهیز شده است. همانند CoreOS و CentOS که شامل مجموعه‌هایی مختلف از ابزارها هستند که به نیازهای کاربران مختلف پاسخ می‌دهند، توزیع‌های Kubernetes نیز به این صورت می‌باشند. در Red Hat تمرکز بر روی در دسترس قرار دادن ابزارهایی که به توسعه دهندگان و تیم‌های عملیاتی کمک می‌کند است. به عنوان مثال به همین دلیل است که تکنولوژی Istio به صورت پیش نمایش در OpenShift گنجانده شده است. Istio ابزاری است که بسیاری از کاربران ممکن است به آن تکیه کنند و بنابراین باید در توزیع پایه قرار گیرد.
OKD در مقابل Red Hat OpenShift
آیا OpenShift نرم افزاری متن باز است؟ بله! تمام اجزای موجود در OpenShift درون جامعه متن باز توسعه داده شده و می‌توان آن‌ها در GitHub مشاهده کرد. در GitHub می‌توانید تعداد زیادی Repository پیدا کنید که پاسخگوی بسیاری از نگرانی‌ها در مورد فعال نگه داشتن Clusterهای Kubernetas می‌باشند. اجزای نرم افزاری مورد نیاز برای اجرای Kubernetes درون یک پروژه بسته بندی می‌گردند. این پروژه‌ی توزیع Kubernetas که قبلا Origin خطاب می‌شد، OKDنام دارد. به این ترتیب، Kubernetes و OKD از این نظر شبیه یکدیگر هستند که هر دوی آن‌ها پروژه‌های متن باز می‌باشند و Kubernetes یکی از پروژه‌های رده‌بالاتر (Upstream (OKD است. همانطور که هستهی لینوکس، GNU Bash، GCC و سرور httpd Apache، رده‌بالاهای توزیع لینوکس Fedora می‌باشند. هنگامی‌که قرار است به بهبود یا افزودن ویژگی‌ها در OpenShift پرداخته شود، در صورتی که این کار در Kubernetes روی دهد، کار در رده‌های بالاتر انجام می‌گردد و در زمان ایجاد OpenShift با استفاده از نسخه‌های Kubernetes کار انجام می‌شود.
سپس Red Hat پروژه OKD را همراه با تعدادی از پروژه‌های دیگر مانند Maistra، اپراتورهای مختلف و دیگر منابع درون محصول Red Hat OpenShift Container Platform بسته بندی می‌کند. پس از اینکه آماده‌سازی انتشار Kubernetes به پایان می‌رسد، کار بسته بندی OKD و سپس OpenShift آغاز می‌شود.
Red Hat OpenShift بر همه‌ی این جوانب استوار است و تحت آزمایشات داخلی گسترده قرار می‌گیرد تا اطمینان حاصل گردد که تمام اجزا یکپارچه، و تیم‌ها آماده هستند تا از نیازهای مشتریانی که نرم افزار در دست تولید را اجرا می‌نمایند، پشتیبانی کنند. این توانمندسازی داخلی یکی از دلایل وجود فاصله بین انتشار رده‌های بالاتر و انتشار متعاقب نسخه‌ی آماده برای استفاده شرکتی OpenShift می‌باشد. مشتریان شرکت Red Hat می‌خواهند بر روی شانه‌های تخصص این شرکت بایستند، و می‌دانند که آن‌ها می‌توانند به صورت End to End از اجزایی که با OpenShift ارائه می‌دهند پشتیبانی نمایند.
همانطور که می‌توان لینوکس را از ابتدا ساخت، می‌توان به روش سخت‌تر پیش از نصب Kubernets بهینه‌سازی را انجام داد، اما بهتر است این کار را به افرادی با زمان، صبر و درجه ریسکی که نیازی به پشتیبانی سازمانی نخواهند داشت، واگذار نمود. برای کسانی که بر روی کارکردهای خود تمرکز دارند و می‌خواهند بر روی شانه‌های Red Hat بایستاند، انتخاب Red Hat OpenShift Platform توصیه می‌شود.
