کنویئر سے کنویئر: CRI-O اب OpenShift کنٹینر پلیٹ فارم 4 میں ڈیفالٹ ہے۔

پلیٹ فارم ریڈ ہیٹ اوپن شیٹ کنٹینر پلیٹ فارم 4 آپ کو تخلیق کو ہموار کرنے کی اجازت دیتا ہے۔ کنٹینرز کی تعیناتی کے لیے میزبانبشمول کلاؤڈ سروس فراہم کرنے والوں کے بنیادی ڈھانچے میں، ورچوئلائزیشن پلیٹ فارمز پر یا ننگے دھاتی نظاموں میں۔ صحیح معنوں میں کلاؤڈ پر مبنی پلیٹ فارم بنانے کے لیے، ہمیں استعمال کیے گئے تمام عناصر پر سختی سے قابو رکھنا تھا اور اس طرح ایک پیچیدہ آٹومیشن کے عمل کی وشوسنییتا کو بڑھانا تھا۔

واضح حل یہ تھا کہ Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux کی ایک قسم) اور CRI-O کو معیاری کے طور پر استعمال کیا جائے، اور اس کی وجہ یہ ہے...

چونکہ کبرنیٹس اور کنٹینرز کے کام کی وضاحت کرتے وقت مشابہت تلاش کرنے کے لیے جہاز رانی کا موضوع بہت اچھا ہے، اس لیے آئیے ایک مثال کا استعمال کرتے ہوئے ان کاروباری مسائل کے بارے میں بات کرنے کی کوشش کرتے ہیں جنہیں CoreOS اور CRI-O حل کرتے ہیں۔ دھاندلی کے بلاکس کی تیاری کے لیے برونیل کی ایجادات. 1803 میں، مارک برونیل کو بڑھتی ہوئی برطانوی بحریہ کی ضروریات کے لیے 100 رگنگ بلاکس تیار کرنے کا کام سونپا گیا۔ دھاندلی کا بلاک ایک قسم کی دھاندلی ہے جو رسیوں کو بادبانوں سے جوڑنے کے لیے استعمال ہوتی ہے۔ 19ویں صدی کے بالکل آغاز تک، یہ بلاکس ہاتھ سے بنائے جاتے تھے، لیکن برونیل خودکار پیداوار میں کامیاب ہو گیا اور مشین ٹولز کا استعمال کرتے ہوئے معیاری بلاکس تیار کرنے لگا۔ اس عمل کے آٹومیشن کا مطلب یہ تھا کہ نتیجے میں آنے والے بلاکس بنیادی طور پر ایک جیسے تھے، اگر ٹوٹ جائیں تو آسانی سے تبدیل کیے جا سکتے ہیں، اور بڑی مقدار میں تیار کیے جا سکتے ہیں۔

اب تصور کریں کہ کیا برونیل کو یہ کام 20 مختلف جہازوں کے ماڈلز (Kubernetes ورژن) اور پانچ مختلف سیاروں کے لیے مکمل طور پر مختلف سمندری کرنٹ اور ہواؤں (بادل فراہم کرنے والے) کے لیے کرنا پڑا۔ اس کے علاوہ، یہ ضروری تھا کہ تمام بحری جہاز (اوپن شفٹ کلسٹرز)، قطع نظر اس کے کہ جن سیاروں پر نیویگیشن کی جاتی ہے، کپتانوں (آپریٹرز جو کلسٹرز کے آپریشن کا انتظام کرتے ہیں) کے نقطہ نظر سے ایک جیسا سلوک کریں۔ بحری مشابہت کو جاری رکھنے کے لیے جہاز کے کپتان اس بات کی بالکل بھی پرواہ نہیں کرتے کہ ان کے جہازوں پر کس قسم کے رگنگ بلاکس (CRI-O) استعمال کیے جاتے ہیں- ان کے لیے اہم بات یہ ہے کہ یہ بلاکس مضبوط اور قابل اعتماد ہیں۔

OpenShift 4، ایک کلاؤڈ پلیٹ فارم کے طور پر، ایک بالکل اسی طرح کے کاروباری چیلنج کا سامنا ہے۔ کلسٹر بنانے کے وقت، نوڈس میں سے کسی ایک میں ناکامی کی صورت میں، یا کلسٹر کو اسکیل کرتے وقت نئے نوڈس بنائے جانے چاہئیں۔ جب ایک نیا نوڈ بنایا جاتا ہے اور شروع کیا جاتا ہے، اہم میزبان اجزاء، بشمول CRI-O، کو اس کے مطابق ترتیب دیا جانا چاہیے۔ کسی بھی دوسری پیداوار کی طرح، "خام مال" کو شروع میں فراہم کیا جانا چاہیے۔ بحری جہاز کے معاملے میں، خام مال دھات اور لکڑی ہیں. تاہم، OpenShift 4 کلسٹر میں کنٹینرز کی تعیناتی کے لیے میزبان بنانے کی صورت میں، آپ کے پاس کنفیگریشن فائلز اور API فراہم کردہ سرورز بطور ان پٹ ہونے چاہئیں۔ اس کے بعد OpenShift پورے لائف سائیکل میں آٹومیشن کی مطلوبہ سطح فراہم کرے گا، اختتامی صارفین کے لیے ضروری پروڈکٹ سپورٹ پیش کرے گا اور اس طرح پلیٹ فارم میں سرمایہ کاری کو دوبارہ حاصل کرے گا۔

OpenShift 4 کو اس طرح بنایا گیا تھا کہ تمام بڑے کلاؤڈ کمپیوٹنگ فراہم کنندگان، ورچوئلائزیشن پلیٹ فارمز اور یہاں تک کہ ننگے میٹل سسٹمز کے لیے پلیٹ فارم کے پورے لائف سائیکل (ورژن 4.X کے لیے) میں آسانی سے سسٹم کو اپ ڈیٹ کرنے کی صلاحیت فراہم کی جائے۔ ایسا کرنے کے لیے، قابل تبادلہ عناصر کی بنیاد پر نوڈس بنائے جائیں۔ جب کسی کلسٹر کو Kubernetes کے نئے ورژن کی ضرورت ہوتی ہے، تو اسے CoreOS پر CRI-O کا متعلقہ ورژن بھی ملتا ہے۔ چونکہ CRI-O ورژن براہ راست Kubernetes سے جڑا ہوا ہے، اس لیے یہ جانچ، ٹربل شوٹنگ، یا سپورٹ کے مقاصد کے لیے کسی بھی ترتیب کو بہت آسان بنا دیتا ہے۔ اس کے علاوہ، یہ نقطہ نظر اختتامی صارفین اور Red Hat کے لیے اخراجات کو کم کرتا ہے۔

یہ Kubernetes کلسٹرز کے بارے میں سوچنے کا بنیادی طور پر نیا طریقہ ہے اور کچھ بہت مفید اور زبردست نئی خصوصیات کی منصوبہ بندی کی بنیاد رکھتا ہے۔ CRI-O (کنٹینر رن ٹائم انٹرفیس - اوپن کنٹینر انیشی ایٹو، مختصراً CRI-OCI) نوڈس کی بڑے پیمانے پر تخلیق کے لیے سب سے کامیاب انتخاب نکلا جو OpenShift کے ساتھ کام کرنے کے لیے ضروری ہے۔ CRI-O پہلے استعمال شدہ Docker انجن کی جگہ لے گا، جو OpenShift صارفین کو پیش کرتا ہے۔ اقتصادی، مستحکم، سادہ اور بورنگ - ہاں، آپ نے صحیح سنا - ایک بورنگ کنٹینر انجن خاص طور پر Kubernetes کے ساتھ کام کرنے کے لیے بنایا گیا ہے۔

کھلے کنٹینرز کی دنیا

دنیا ایک عرصے سے کھلے کنٹینرز کی طرف بڑھ رہی ہے۔ چاہے Kubernetes میں ہو، یا نچلی سطح پر، کنٹینر کے معیار کی ترقی ہر سطح پر جدت کے ایک ماحولیاتی نظام کے نتیجے میں۔

یہ سب اوپن کنٹینرز انیشی ایٹو کی تخلیق کے ساتھ شروع ہوا۔ جون 2015 میں. کام کے اس ابتدائی مرحلے میں، کنٹینر کی وضاحتیں تشکیل دی گئیں۔ تصویر и رن ٹائم ماحول. اس نے اس بات کو یقینی بنایا کہ ٹولز ایک ہی معیار کا استعمال کر سکتے ہیں۔ کنٹینر کی تصاویر اور ان کے ساتھ کام کرنے کے لیے ایک متحد فارمیٹ۔ وضاحتیں بعد میں شامل کی گئیں۔ تقسیم، صارفین کو آسانی سے اشتراک کرنے کی اجازت دیتا ہے۔ کنٹینر کی تصاویر.

Kubernetes کمیونٹی نے پھر پلگ ایبل انٹرفیس کے لیے ایک واحد معیار تیار کیا، جسے کہا جاتا ہے۔ کنٹینر رن ٹائم انٹرفیس (CRI). اس کی بدولت، Kubernetes کے صارفین Docker کے علاوہ کنٹینرز کے ساتھ کام کرنے کے لیے مختلف انجنوں کو جوڑنے کے قابل ہو گئے۔

Red Hat اور Google کے انجینئرز نے مارکیٹ میں ایک کنٹینر انجن کی ضرورت دیکھی جو CRI پروٹوکول پر Kubelet کی درخواستوں کو قبول کر سکے اور ایسے کنٹینرز متعارف کرائے جو اوپر ذکر کی گئی OCI وضاحتوں کے ساتھ مطابقت رکھتے تھے۔ تو OCID ظاہر ہوا۔. لیکن معاف کیجئے گا، کیا ہم نے یہ نہیں کہا کہ یہ مواد CRI-O کے لیے وقف کیا جائے گا؟ اصل میں یہ ہے، صرف رہائی کے ساتھ ورژن 1.0 پروجیکٹ کا نام CRI-O رکھ دیا گیا۔

انجیر 1۔

CRI-O اور CoreOS کے ساتھ اختراع

OpenShift 4 پلیٹ فارم کے آغاز کے ساتھ، یہ تبدیل کر دیا گیا تھا کنٹینر انجن، پلیٹ فارم میں بطور ڈیفالٹ استعمال کیا جاتا ہے، اور Docker کی جگہ CRI-O نے لے لی تھی، جو کہ Kubernetes کے متوازی طور پر تیار ہونے والے کنٹینر کو چلانے کے لیے ایک سرمایہ کاری مؤثر، مستحکم، سادہ اور بورنگ ماحول پیش کرتا ہے۔ یہ کلسٹر سپورٹ اور کنفیگریشن کو بہت آسان بناتا ہے۔ کنٹینر انجن اور میزبان کی ترتیب، نیز ان کا انتظام، OpenShift 4 کے اندر خودکار ہو جاتا ہے۔

رکو، یہ کیسا ہے؟

یہ ٹھیک ہے، OpenShift 4 کی آمد کے ساتھ، اب انفرادی میزبانوں سے جڑنے اور کنٹینر انجن کو انسٹال کرنے، اسٹوریج کو ترتیب دینے، سرچ سرورز کو ترتیب دینے یا نیٹ ورک کو ترتیب دینے کی ضرورت نہیں ہے۔ OpenShift 4 پلیٹ فارم کو استعمال کرنے کے لیے مکمل طور پر دوبارہ ڈیزائن کیا گیا ہے۔ آپریٹر فریم ورک نہ صرف اینڈ یوزر ایپلی کیشنز کے لحاظ سے، بلکہ پلیٹ فارم کی سطح کے بنیادی آپریشنز جیسے کہ تصاویر کی تعیناتی، سسٹم کو کنفیگر کرنا، یا اپ ڈیٹس انسٹال کرنا۔

Kubernetes نے ہمیشہ صارفین کو مطلوبہ حالت کی وضاحت کرکے اور استعمال کرکے ایپلیکیشنز کا نظم کرنے کی اجازت دی ہے۔ کنٹرولرز, اس بات کو یقینی بنانے کے لیے کہ اصل حالت ہدف کی حالت سے جتنا ممکن ہو مماثل ہو۔ یہ ہدف ریاست اور اصل ریاستی نقطہ نظر ترقی اور آپریشن دونوں کے نقطہ نظر سے عظیم مواقع کھولتا ہے۔ ڈویلپر مطلوبہ حالت کی وضاحت کر سکتے ہیں۔ اسے آگے بڑھائیں آپریٹر کو YAML یا JSON فائل کی شکل میں، اور پھر آپریٹر پروڈکشن ماحول میں مطلوبہ ایپلیکیشن مثال بنا سکتا ہے، اور اس مثال کی آپریٹنگ حالت مکمل طور پر متعین کردہ کے مطابق ہوگی۔

پلیٹ فارم میں آپریٹرز کا استعمال کرتے ہوئے، OpenShift 4 RHEL CoreOS اور CRI-O کے نظم و نسق میں یہ نیا نمونہ (سیٹ اور اصل حالت کے تصور کا استعمال کرتے ہوئے) لاتا ہے۔ آپریٹنگ سسٹم اور کنٹینر انجن کے ورژن کو ترتیب دینے اور ان کا انتظام کرنے کے کام نام نہاد کا استعمال کرتے ہوئے خودکار ہوتے ہیں۔ مشین کنفیگ آپریٹر (MCO). ایم سی او کلسٹر ایڈمنسٹریٹر کے کام کو بہت آسان بناتا ہے، بنیادی طور پر انسٹالیشن کے آخری مراحل کو خودکار کرتا ہے، اور ساتھ ہی بعد میں انسٹالیشن کے بعد کے آپریشنز (دن دو آپریشن)۔ یہ سب OpenShift 4 کو ایک حقیقی کلاؤڈ پلیٹ فارم بناتا ہے۔ ہم تھوڑی دیر بعد اس میں داخل ہوں گے۔

کنٹینرز چل رہے ہیں۔

صارفین کو اوپن شفٹ پلیٹ فارم میں CRI-O انجن کو ٹیک پیش نظارہ کی حیثیت میں ورژن 3.7 سے اور عام طور پر دستیاب حالت میں ورژن 3.9 سے (فی الحال تعاون یافتہ) استعمال کرنے کا موقع ملا ہے۔ اس کے علاوہ، Red Hat بڑے پیمانے پر استعمال کرتا ہے پیداواری کام کے بوجھ کو چلانے کے لیے CRI-O ورژن 3.10 سے OpenShift آن لائن میں۔ اس سب نے CRI-O پر کام کرنے والی ٹیم کو کبرنیٹس کے بڑے کلسٹرز پر بڑے پیمانے پر کنٹینرز لانچ کرنے کا وسیع تجربہ حاصل کرنے کی اجازت دی۔ Kubernetes CRI-O کو کس طرح استعمال کرتا ہے اس کی بنیادی تفہیم حاصل کرنے کے لیے، آئیے مندرجہ ذیل مثال کو دیکھتے ہیں، جو ظاہر کرتا ہے کہ فن تعمیر کیسے کام کرتا ہے۔

چاول۔ 2. کبرنیٹس کلسٹر میں کنٹینرز کیسے کام کرتے ہیں۔

CRI-O نئے نوڈس شروع کرتے وقت، اور OpenShift پلیٹ فارم کے نئے ورژن جاری کرتے وقت پورے ٹاپ لیول کو سنکرونائز کرکے نئے کنٹینر ہوسٹس کی تخلیق کو آسان بناتا ہے۔ پورے پلیٹ فارم کی نظر ثانی ٹرانزیکشنل اپ ڈیٹس/رول بیکس کی اجازت دیتی ہے، اور کنٹینر ٹیل کور، کنٹینر انجن، نوڈس (کوبیلیٹس) اور کبرنیٹس ماسٹر نوڈ کے درمیان انحصار میں تعطل کو بھی روکتا ہے۔ پلیٹ فارم کے تمام اجزاء کو مرکزی طور پر منظم کرنے سے، کنٹرول اور ورژننگ کے ساتھ، ریاست A سے ریاست B تک ہمیشہ ایک واضح راستہ ہوتا ہے۔ یہ اپ ڈیٹ کے عمل کو آسان بناتا ہے، سیکیورٹی کو بہتر بناتا ہے، کارکردگی کی رپورٹنگ کو بہتر بناتا ہے، اور نئے ورژن کی اپ ڈیٹس اور تنصیبات کی لاگت کو کم کرنے میں مدد کرتا ہے۔ .

متبادل عناصر کی طاقت کا مظاہرہ کرنا

جیسا کہ پہلے ذکر کیا گیا ہے، OpenShift 4 میں کنٹینر ہوسٹ اور کنٹینر انجن کا انتظام کرنے کے لیے مشین کنفیگ آپریٹر کا استعمال آٹومیشن کی ایک نئی سطح فراہم کرتا ہے جو پہلے Kubernetes پلیٹ فارم پر ممکن نہیں تھا۔ نئی خصوصیات کو ظاہر کرنے کے لیے، ہم دکھائیں گے کہ آپ کس طرح crio.conf فائل میں تبدیلیاں کر سکتے ہیں۔ اصطلاحات سے الجھنے سے بچنے کے لیے، نتائج پر توجہ مرکوز کرنے کی کوشش کریں۔

سب سے پہلے، آئیے اسے بنائیں جسے کنٹینر رن ٹائم کنفیگریشن کہتے ہیں - کنٹینر رن ٹائم کنفیگریشن۔ اسے ایک Kubernetes وسائل کے طور پر سوچیں جو CRI-O کے لیے کنفیگریشن کی نمائندگی کرتا ہے۔ حقیقت میں، یہ MachineConfig نامی کسی چیز کا ایک خصوصی ورژن ہے، جو کہ کوئی بھی کنفیگریشن ہے جو اوپن شفٹ کلسٹر کے حصے کے طور پر RHEL CoreOS مشین میں تعینات کی جاتی ہے۔

یہ حسب ضرورت وسیلہ، جسے ContainerRuntimeConfig کہا جاتا ہے، کلسٹر منتظمین کے لیے CRI-O کو ترتیب دینا آسان بنانے کے لیے بنایا گیا تھا۔ یہ ٹول اتنا طاقتور ہے کہ اسے مشین کنفیگ پول سیٹنگز کے لحاظ سے صرف مخصوص نوڈس پر لاگو کیا جا سکتا ہے۔ اسے مشینوں کے ایک گروپ کے طور پر سوچیں جو ایک ہی مقصد کو پورا کرتی ہیں۔

آخری دو لائنوں پر غور کریں جنہیں ہم /etc/crio/crio.conf فائل میں تبدیل کرنے جا رہے ہیں۔ یہ دونوں لائنیں crio.conf فائل کی لائنوں سے بہت ملتی جلتی ہیں، وہ یہ ہیں:

vi ContainerRuntimeConfig.yaml

: اختتام

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: set-log-and-pid
spec:
 machineConfigPoolSelector:
   matchLabels:
     debug-crio: config-log-and-pid
 containerRuntimeConfig:
   pidsLimit: 2048
   logLevel: debug

اب آئیے اس فائل کو Kubernetes کلسٹر میں دھکیلتے ہیں اور چیک کرتے ہیں کہ یہ اصل میں بنائی گئی تھی۔ براہ کرم نوٹ کریں کہ آپریشن بالکل ویسا ہی ہے جیسا کہ کسی دوسرے Kubernetes وسائل کے ساتھ ہے:

oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig

: اختتام

NAME              AGE
set-log-and-pid   22h

ایک بار جب ہم نے ContainerRuntimeConfig بنا لیا، ہمیں کبرنیٹس کو یہ اشارہ دینے کے لیے MachineConfigPools میں سے ایک میں ترمیم کرنے کی ضرورت ہے کہ ہم اس ترتیب کو کلسٹر میں مشینوں کے مخصوص گروپ پر لاگو کرنا چاہتے ہیں۔ اس صورت میں ہم MachineConfigPool کو ماسٹر نوڈس کے لیے تبدیل کریں گے:

oc edit MachineConfigPool/master

نتیجہ (وضاحت کے لیے، اہم جوہر باقی ہے):

...
metadata:
 creationTimestamp: 2019-04-10T23:42:28Z
 generation: 1
 labels:
   debug-crio: config-log-and-pid
   operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...

اس وقت، MCO کلسٹر کے لیے ایک نئی crio.conf فائل بنانا شروع کرتا ہے۔ اس صورت میں، مکمل طور پر تیار کنفیگریشن فائل کوبرنیٹس API کا استعمال کرتے ہوئے دیکھا جا سکتا ہے۔ یاد رکھیں، ContainerRuntimeConfig MachineConfig کا صرف ایک خصوصی ورژن ہے، لہذا ہم MachineConfigs میں متعلقہ لائنوں کو دیکھ کر نتیجہ دیکھ سکتے ہیں:

oc get MachineConfigs | grep rendered

: اختتام

rendered-master-c923f24f01a0e38c77a05acfd631910b                  4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626                  4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62                  4.0.22-201904011459-dirty 2.2.0 16h

براہ کرم نوٹ کریں کہ ماسٹر نوڈس کے نتیجے میں کنفیگریشن فائل اصل کنفیگریشنز کے مقابلے میں ایک نیا ورژن تھا۔ اسے دیکھنے کے لیے درج ذیل کمانڈ کو چلائیں۔ گزرتے ہوئے، ہم نوٹ کرتے ہیں کہ یہ شاید کبرنیٹس کی تاریخ کے بہترین ون لائنرز میں سے ایک ہے:

python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid

: اختتام

pids_limit = 2048

اب اس بات کو یقینی بناتے ہیں کہ کنفیگریشن تمام ماسٹر نوڈس پر لاگو ہو چکی ہے۔ پہلے ہمیں کلسٹر میں نوڈس کی فہرست ملتی ہے:

oc get node | grep master

Output:

ip-10-0-135-153.us-east-2.compute.internal   Ready master 23h v1.12.4+509916ce1

ip-10-0-154-0.us-east-2.compute.internal     Ready master 23h v1.12.4+509916ce1

ip-10-0-166-79.us-east-2.compute.internal    Ready master 23h v1.12.4+509916ce1

اب آئیے انسٹال شدہ فائل کو دیکھتے ہیں۔ آپ دیکھیں گے کہ فائل کو pid اور ڈیبگ ڈائریکٹیو کے لیے نئی قدروں کے ساتھ اپ ڈیٹ کر دیا گیا ہے جو ہم نے ContainerRuntimeConfig وسائل میں بیان کی ہیں۔ خوبصورتی خود:

oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’

: اختتام

...
pids_limit = 2048
...
log_level = "debug"
...

کلسٹر میں یہ تمام تبدیلیاں SSH چلائے بغیر کی گئی تھیں۔ تمام کام Kuberentes ماسٹر نوڈ تک رسائی حاصل کرکے کیا گیا تھا۔ یعنی یہ نئے پیرامیٹرز کو صرف ماسٹر نوڈس پر ترتیب دیا گیا تھا۔ ورکر نوڈس تبدیل نہیں ہوئے، جو کنٹینر ہوسٹس اور کنٹینر انجنوں کے ساتھ قابل تبادلہ عناصر کے سلسلے میں مخصوص اور حقیقی حالتوں کو استعمال کرنے کے Kubernetes طریقہ کار کے فوائد کو ظاہر کرتا ہے۔

اوپر دی گئی مثال تین پروڈکشن نوڈس کے ساتھ ایک چھوٹے OpenShift کنٹینر پلیٹ فارم 4 کلسٹر یا 3000 نوڈس کے ساتھ ایک بہت بڑا پروڈکشن کلسٹر میں تبدیلیاں کرنے کی صلاحیت کو ظاہر کرتی ہے۔ کسی بھی صورت میں، کام کی مقدار ایک جیسی ہوگی - اور بہت کم - صرف ContainerRuntimeConfig فائل کو ترتیب دیں، اور MachineConfigPool میں ایک لیبل تبدیل کریں۔ اور آپ یہ اوپن شیفٹ کنٹینر پلیٹ فارم 4.X کے کسی بھی ورژن کے ساتھ کر سکتے ہیں جو اپنی زندگی بھر Kubernetes کو چلا رہا ہے۔

اکثر ٹیکنالوجی کمپنیاں اتنی تیزی سے تیار ہوتی ہیں کہ ہم یہ بتانے سے قاصر ہوتے ہیں کہ ہم بنیادی اجزاء کے لیے مخصوص ٹیکنالوجیز کا انتخاب کیوں کرتے ہیں۔ کنٹینر انجن تاریخی طور پر وہ جزو رہے ہیں جس کے ساتھ صارفین براہ راست بات چیت کرتے ہیں۔ چونکہ کنٹینرز کی مقبولیت قدرتی طور پر کنٹینر انجنوں کی آمد کے ساتھ شروع ہوئی، صارفین اکثر ان میں دلچسپی ظاہر کرتے ہیں۔ یہ ایک اور وجہ ہے کہ Red Hat نے CRI-O کا انتخاب کیا۔ اب آرکیسٹریشن پر توجہ مرکوز کرنے کے ساتھ کنٹینرز تیار ہو رہے ہیں، اور ہم نے پایا ہے کہ OpenShift 4 کے ساتھ کام کرتے وقت CRI-O بہترین تجربہ فراہم کرتا ہے۔

ماخذ: www.habr.com