"تفاوت بین Kubernetes و OpenShift چیست؟" - این سوال با ثبات رشک برانگیز پیش می آید. اگرچه در واقعیت این مانند این است که بپرسید یک ماشین با یک موتور چه تفاوتی دارد. اگر قیاس را ادامه دهیم، پس یک ماشین یک محصول تمام شده است، می توانید بلافاصله از آن استفاده کنید، به معنای واقعی کلمه: وارد شوید و بروید. از طرفی برای اینکه یک موتور شما را به جایی برساند، ابتدا باید با خیلی چیزهای دیگر تکمیل شود تا در نهایت همان ماشین را به دست آورید.
بنابراین، Kubernetes موتوری است که ماشین (پلتفرم) برند OpenShift دور آن مونتاژ شده است که شما را به هدفتان می رساند.
در این مقاله می خواهیم نکات کلیدی زیر را با کمی جزئیات بیشتر به شما یادآوری و بررسی کنیم:
- Kubernetes قلب پلتفرم OpenShift است و دارای گواهینامه Kubernetes 100%، کاملا متن باز و بدون کوچکترین ماهیت اختصاصی است. به طور خلاصه:
- API خوشه OpenShift XNUMX٪ Kubernetes است.
- اگر کانتینر روی هر سیستم دیگر Kubernetes اجرا شود، بدون هیچ تغییری روی OpenShift اجرا می‌شود. نیازی به تغییر در برنامه ها نیست.
- OpenShift نه تنها ویژگی ها و قابلیت های مفیدی را به Kubernetes اضافه می کند. مانند یک ماشین، OpenShift آماده استفاده از جعبه است، می تواند بلافاصله به تولید برسد، و همانطور که در زیر نشان خواهیم داد، زندگی یک توسعه دهنده را بسیار آسان می کند. به همین دلیل است که OpenShift از هر دو نفر یک نفر است. این پلتفرم PaaS در سطح سازمانی موفق و شناخته شده از دیدگاه یک توسعه دهنده است. و در عین حال، از نظر عملیات صنعتی یک راه حل فوق العاده قابل اعتماد Container-as-a-Service است.
OpenShift Kubernetes با گواهینامه 100٪ CNCF است
OpenShift بر اساس . بنابراین، پس از آموزش مناسب، کاربران از قدرت کوبکتل شگفت زده می شوند. و کسانی که از Kubernetes Cluster به OpenShift تغییر مکان داده‌اند، اغلب می‌گویند که پس از تغییر مسیر kubeconfig به خوشه OpenShift، چقدر دوست دارند، همه اسکریپت‌های موجود بی‌عیب و نقص کار می‌کنند.
احتمالاً در مورد ابزار خط فرمان OpenShift به نام OC شنیده اید. این به طور کامل با kubectl سازگار است، به علاوه چندین کمک کننده مفید را ارائه می دهد که هنگام انجام تعدادی کار مفید خواهند بود. اما ابتدا، کمی بیشتر در مورد سازگاری OC و kubectl:
دستورات kubectl
تیم های OC
kubectl غلاف دریافت کنید
oc دریافت غلاف
kubectl فضاهای نام را دریافت می کند
oc فضاهای نام را دریافت کنید
kubectl ایجاد -f deployment.yaml
oc ایجاد -f deployment.yaml
در اینجا نتایج استفاده از kubectl در OpenShift API به نظر می رسد:
• kubectl get pods - غلاف ها را همانطور که انتظار می رود برمی گرداند.
• kubectl getspaces – فضاهای نام را همانطور که انتظار می رود برمی گرداند.
دستور kubectl create -f mydeployment.yaml منابع kubernetes را درست مانند هر پلتفرم دیگر Kubernetes ایجاد می کند، همانطور که در ویدیوی زیر نشان داده شده است:
به عبارت دیگر، تمام API های Kubernetes به طور کامل در OpenShift در دسترس هستند و در عین حال سازگاری 100٪ را حفظ می کنند. به همین دلیل است .
OpenShift ویژگی های مفیدی را به Kubernetes اضافه می کند
APIهای Kubernetes 100% در OpenShift در دسترس هستند، اما ابزار استاندارد Kubernetes kubectl به وضوح فاقد عملکرد و راحتی است. به همین دلیل است که Red Hat ویژگی های مفید و ابزارهای خط فرمان را به Kubernetes اضافه کرده است، مانند OC (مخفف کلاینت OpenShift) و ODO (OpenShift DO، این ابزار برای توسعه دهندگان طراحی شده است).
1. ابزار OC - نسخه قدرتمندتر و راحت تر Kubectl
به عنوان مثال، بر خلاف kubectl، به شما اجازه می دهد فضاهای نام جدیدی ایجاد کنید و به راحتی زمینه ها را تغییر دهید، و همچنین تعدادی دستورات مفید را برای توسعه دهندگان ارائه می دهد، مانند ساخت تصاویر کانتینر و استقرار برنامه ها به طور مستقیم از کد منبع یا باینری ها (Source-to-Image, s2i).
بیایید به مثال‌هایی نگاه کنیم که چگونه کمک‌های داخلی و عملکرد پیشرفته ابزار OC به ساده‌سازی کار روزمره کمک می‌کنند.
اولین مثال مدیریت فضای نام است. هر خوشه Kubernetes همیشه چندین فضای نام دارد. آنها معمولاً برای ایجاد محیط های توسعه و تولید استفاده می شوند، اما همچنین می توانند به عنوان مثال برای هر توسعه دهنده یک جعبه شنی شخصی استفاده شوند. در عمل، این باعث می‌شود که توسعه‌دهنده مجبور باشد مکرراً بین فضاهای نام جابجا شود، زیرا kubectl در زمینه فضای فعلی اجرا می‌شود. بنابراین، در مورد kubectl، مردم به طور فعال از اسکریپت های کمکی برای این کار استفاده می کنند. اما هنگام استفاده از OC، برای جابجایی به فضای مورد نظر، کافیست «oc project namespace» را بگویید.
به یاد ندارید فضای نامی که نیاز دارید چه نام دارد؟ مشکلی نیست، فقط "oc get projects" را تایپ کنید تا لیست کامل نمایش داده شود. تردید دارید که اگر فقط به زیر مجموعه محدودی از فضاهای نام در خوشه دسترسی داشته باشید، این کار چگونه کار خواهد کرد؟ خوب، زیرا kubectl فقط در صورتی این کار را به درستی انجام می دهد که RBAC به شما اجازه دهد تمام فضاهای روی خوشه را ببینید، و در خوشه های بزرگ به همه چنین مجوزهایی داده نمی شود. بنابراین، ما پاسخ می دهیم: برای OC این به هیچ وجه مشکلی نیست و در چنین شرایطی به راحتی یک لیست کامل تولید می کند. همین چیزهای کوچک است که جهت گیری شرکتی Openshift و مقیاس پذیری خوب این پلت فرم را از نظر کاربران و برنامه ها تشکیل می دهد.
2. ODO - یک نسخه بهبود یافته از kubectl برای توسعه دهندگان
نمونه دیگری از بهبودهای Red Hat OpenShift نسبت به Kubernetes، ابزار خط فرمان ODO است. برای توسعه دهندگان طراحی شده است و به شما امکان می دهد کد محلی را به سرعت در یک خوشه OpenShift از راه دور مستقر کنید. همچنین می‌تواند فرآیندهای داخلی را ساده‌سازی کند تا فوراً همه تغییرات کد را با کانتینرهای یک خوشه OpenShift از راه دور بدون نیاز به ساخت مجدد، رجیستری و استقرار مجدد تصاویر همگام‌سازی کند.
بیایید ببینیم چگونه OC و ODO کار با کانتینرها و Kubernetes را آسان‌تر می‌کنند.
کافی است چند گردش کار را در زمانی که بر اساس kubectl ساخته می شوند و زمانی که از OC یا ODO استفاده می شود، مقایسه کنید.
• استقرار کد در OpenShift برای کسانی که YAML صحبت نمی کنند:
Kubernetes/kubectl
$> git clone
1- یک Dockerfile ایجاد کنید که تصویر را از روی کد بسازد
-----
از گره
WORKDIR /usr/src/app
بسته کپی*.json./
COPY index.js./
کپی ./برنامه ./برنامه
نصب npm را اجرا کنید
EXPOSE 3000
CMD ["npm"، "شروع"] ————–
2- تصویر را می سازیم
$> ساخت پادمن...
3- وارد رجیستری شوید
ورود به پادمن ...
4- تصویر را در رجیستری قرار دهید
فشار پادمن
5- فایل های yaml را برای استقرار برنامه ایجاد کنید (deployment.yaml، service.yaml، ingress.yaml) - این حداقل مطلق است.
6- فایل های مانیفست را مستقر کنید:
Kubectl application -f .
OpenShift/oc
$> oc new-app – our_application_name
OpenShift/odo
$> git clone
$> odo ایجاد مؤلفه nodejs myapp
$>odo فشار
• سوئیچ زمینه: فضای نام کار یا خوشه کاری را تغییر دهید.
Kubernetes/kubectl
1- ایجاد زمینه در kubeconfig برای پروژه "myproject"
2- کوبکتل مجموعه زمینه…
OpenShift/oc
پروژه oc "مای پروژه"
کنترل کیفیت: «یک ویژگی جالب اینجا ظاهر شده است، هنوز در نسخه آلفا. شاید بتوانیم آن را وارد تولید کنیم؟»
تصور کنید که در یک ماشین مسابقه ای نشسته اید و به شما می گویند: "ما نوع جدیدی از ترمزها را نصب کرده ایم و صادقانه بگویم، قابلیت اطمینان آنها هنوز خوب نیست... اما نگران نباشید، ما فعالانه آنها را در طول دوره بهبود خواهیم داد. از مسابقات قهرمانی.” چگونه این چشم انداز را دوست دارید؟ ما در کلاه قرمزی به نوعی خیلی خوشحال نیستیم. 🙂
بنابراین، ما سعی می‌کنیم تا زمانی که نسخه‌های آلفا به بلوغ کافی نرسند و آزمایش‌های کامل نبرد را انجام داده‌ایم و احساس کنیم استفاده از آنها بی‌خطر هستند، خودداری کنیم. معمولاً همه چیز ابتدا از مرحله پیش‌نمایش برنامه‌نویس و سپس از مرحله پیش‌نمایش می‌گذرد و تنها پس از آن به عنوان یک انتشار عمومی منتشر می شود (GA)، که در حال حاضر آنقدر پایدار است که برای تولید مناسب است.
چرا اینطور است؟ زیرا مانند توسعه هر نرم افزار دیگری، همه ایده های اولیه در Kubernetes به انتشار نهایی نمی رسند. یا به آن می رسند و حتی عملکرد مورد نظر را حفظ می کنند، اما اجرای آنها با نسخه آلفا تفاوت اساسی دارد. با هزاران هزار مشتری Red Hat که از OpenShift برای پشتیبانی از بارهای کاری حیاتی استفاده می کنند، ما تاکید ویژه ای بر پایداری پلت فرم و پشتیبانی طولانی مدت خود داریم.
Red Hat متعهد است که OpenShift را به طور مکرر منتشر کند و نسخه Kubernetes همراه با آن را به روز کند. به عنوان مثال، نسخه GA فعلی OpenShift 4.3 در زمان نگارش این مقاله شامل Kubernetes 1.16 است که تنها یک واحد از نسخه بالادستی Kubernetes با شماره 1.17 عقب تر است. بنابراین، ما در تلاش هستیم تا با ارائه نسخه‌های جدید OpenShift، Kubernetes کلاس سازمانی را به مشتری ارائه دهیم و کنترل کیفیت بیشتری را ارائه دهیم.
رفع نرم افزار: «یک حفره در نسخه Kubernetes که در حال تولید آن هستیم وجود داشت. و فقط با به‌روزرسانی سه نسخه می‌توانید آن را ببندید. یا گزینه هایی وجود دارد؟
در پروژه منبع باز Kubernetes، اصلاحات نرم افزاری معمولاً به عنوان بخشی از نسخه بعدی منتشر می شوند، گاهی اوقات یک یا دو نسخه عطف قبلی را پوشش می دهند، و حداقل 6 ماه پوشش می دهند.
Red Hat به خود می بالد که زودتر از سایرین اصلاحات مهم را منتشر کرده و برای مدت طولانی تری پشتیبانی می کند. به عنوان مثال آسیب پذیری افزایش امتیاز Kubernetes را در نظر بگیرید (): در Kubernetes 1.11 کشف شد، و اصلاحات نسخه‌های قبلی فقط تا نسخه 1.10.11 منتشر شد، و این مورد را در همه نسخه‌های قبلی Kubernetes، از 1.x تا 1.9 خالی گذاشت.
به نوبه خود، (Kubernetes 1.2 وجود دارد)، XNUMX نسخه OpenShift را ضبط کرده و به وضوح مراقبت از مشتریان را نشان می دهد (جزئیات بیشتر ).
چگونه OpenShift و Red Hat کوبرنتیس را به جلو می برند
رد هت دومین شرکت بزرگ نرم‌افزاری پروژه منبع باز Kubernetes است و تنها پس از گوگل، 3 تا از 5 توسعه‌دهنده پرکار از Red Hat هستند. یک واقعیت کمتر شناخته شده دیگر: بسیاری از عملکردهای حیاتی در Kubernetes دقیقاً به ابتکار Red Hat ظاهر شد، به ویژه، مانند:
- RBAC. Kubernetes توابع RBAC (ClusterRole، ClusterRoleBinding) را نداشت تا زمانی که مهندسان Red Hat تصمیم گرفتند آنها را به عنوان بخشی از خود پلتفرم و نه به عنوان عملکرد اضافی OpenShift پیاده سازی کنند. آیا Red Hat از بهبود Kubernetes می ترسد؟ البته نه، زیرا Red Hat به شدت از اصول متن باز پیروی می کند و بازی های Open Core را انجام نمی دهد. پیشرفت‌ها و نوآوری‌هایی که توسط جوامع توسعه هدایت می‌شوند، به‌جای جوامع اختصاصی، قابل دوام‌تر و به‌طور گسترده‌تر مورد استفاده قرار می‌گیرند، که به خوبی با هدف اصلی ما برای مفیدتر کردن نرم‌افزار متن‌باز برای مشتریان‌مان هماهنگی دارد.
- سیاست های امنیتی برای pods (Pod Security Policies). این مفهوم اجرای امن برنامه ها در داخل پادها در ابتدا در 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
رد هت بیش از 20 سال است که یک ارائه دهنده پیشرو در توزیع های لینوکس برای برنامه های کاربردی مهم تجاری بوده است. تجربه انباشته شده و دائماً به روز شده ما در این زمینه به ما این امکان را می دهد که مبنایی واقعا قابل اعتماد و قابل اعتماد برای عملیات صنعتی کانتینرها ارائه دهیم. RHEL CoreOS از همان هسته RHEL استفاده می کند، اما در درجه اول برای کارهایی مانند اجرای کانتینرها و اجرای خوشه های Kubernetes بهینه شده است: اندازه کاهش یافته و تغییرناپذیری آن باعث می شود تا تنظیم خوشه ها، مقیاس خودکار، استقرار وصله ها و غیره را آسان تر کند. همه این ویژگی ها آن را آسان می کند. پایه ای ایده آل برای ارائه همان تجربه کاربری با OpenShift در طیف گسترده ای از محیط های محاسباتی، از فلز خالی گرفته تا ابر خصوصی و عمومی.
2. اتوماسیون عملیات IT
اتوماسیون فرآیندهای نصب و عملیات روز دوم (یعنی عملیات روزانه) نقطه قوت 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-as-a-service را پیاده سازی می کند. از سوی دیگر، برای کسانی که می‌خواهند در حالت محلی کار کنند، Codeready Containers، یک نسخه کاملاً کاربردی از OpenShift 4 وجود دارد که می‌تواند روی لپ‌تاپ نصب شود.
IDE یکپارچه به عنوان یک سرویس برای توسعه کارآمد در پلتفرم Kubernetes/OpenShift
OpenShift یک سیستم کامل CI/CD را دقیقاً از جعبه ارائه می دهد، یا بر اساس جنکینز کانتینری و یک پلاگین برای کار با خطوط لوله یا سیستم CI/CD مبتنی بر Kubernetes (در حال حاضر در نسخه پیش نمایش Tech). هر دوی این راه‌حل‌ها به طور کامل با کنسول OpenShift ادغام می‌شوند و به شما امکان می‌دهند راه‌اندازهای خط لوله را اجرا کنید، استقرارها، گزارش‌ها و موارد دیگر را مشاهده کنید.
4. ابزارهای کاربردی
OpenShift به شما امکان می دهد هم برنامه های کاربردی حالت دار سنتی و هم راه حل های مبتنی بر ابر را بر اساس معماری های جدید مانند میکروسرویس ها یا بدون سرور اجرا کنید. راه حل OpenShift Service Mesh با ابزارهای کلیدی برای نگهداری میکروسرویس ها مانند Istio، Kiali و Jaeger از جعبه خارج می شود. به نوبه خود، راه حل OpenShift Serverless نه تنها شامل Knative، بلکه ابزارهایی مانند Keda است که به عنوان بخشی از یک ابتکار مشترک با مایکروسافت برای ارائه عملکردهای Azure در پلتفرم OpenShift ایجاد شده است.
راه حل یکپارچه OpenShift ServiceMesh (Istio، Kiali، Jaeger) هنگام توسعه میکروسرویس ها مفید خواهد بود.
برای پر کردن شکاف بین برنامه‌های قدیمی و کانتینرها، OpenShift اکنون امکان مهاجرت ماشین مجازی به پلتفرم OpenShift را با استفاده از Container Native Virtualization (در حال حاضر در TechPreview) می‌دهد و برنامه‌های ترکیبی را به واقعیت تبدیل می‌کند و مهاجرت آنها را بین ابرهای مختلف، خصوصی و عمومی تسهیل می‌کند.
ماشین مجازی مجازی Windows 2019 در حال اجرا بر روی OpenShift از طریق Container Native Virtualization (در حال حاضر در نسخه پیش نمایش Tech)
5. ابزار برای خوشه ها
هر پلتفرم کلاس سازمانی باید دارای خدمات نظارت و ثبت متمرکز، مکانیسم‌های امنیتی، احراز هویت و مجوز، و ابزارهای مدیریت شبکه باشد. و OpenShift همه اینها را خارج از جعبه فراهم می کند، و همه آنها 100٪ منبع باز هستند، از جمله راه حل هایی مانند ElasticSearch، Prometheus، Grafana. همه این راه حل ها دارای داشبوردها، معیارها و هشدارهایی هستند که قبلاً با استفاده از تخصص گسترده نظارت بر خوشه Red Hat ساخته و پیکربندی شده اند و به شما این امکان را می دهند که از همان ابتدا محیط تولید خود را به طور مؤثر کنترل و نظارت کنید.
OpenShift همچنین با موارد مهمی مانند احراز هویت با ارائه‌دهنده oauth داخلی، ادغام با ارائه‌دهندگان اعتبار، از جمله LDAP، ActiveDirectory، OpenID Connect، و موارد دیگر استاندارد ارائه می‌کند.
داشبورد Grafana از پیش پیکربندی شده برای نظارت بر خوشه OpenShift
بیش از 150 معیار و هشدار از پیش پیکربندی شده Prometheus برای نظارت بر خوشه OpenShift
ادامه
عملکرد غنی راه حل و تجربه گسترده Red Hat در زمینه Kubernetes دلایلی است که باعث شده است OpenShift به موقعیت غالب در بازار دست یابد، همانطور که در شکل زیر نشان داده شده است (بیشتر بخوانید ).
رد کلاه در حال حاضر با سهم 44 درصدی در بازار پیشتاز است.
این شرکت از مزایای استراتژی فروش مشتری محور خود بهره می برد، جایی که ابتدا با توسعه دهندگان سازمانی مشاوره و آموزش می دهد و سپس با شروع به کارگیری کانتینرها در تولید، به سمت کسب درآمد می رود.
(منبع: )
امیدواریم از این مقاله لذت برده باشید. در پست‌های بعدی این مجموعه، نگاهی دقیق‌تر به مزیت‌های OpenShift نسبت به Kubernetes در هر یک از دسته‌هایی که در اینجا مورد بحث قرار می‌گیرند، خواهیم داشت.
منبع: www.habr.com