ایک کنٹینر کو ڈیپلائے کرنا آسان ہے۔ دس کو ڈیپلائے کرنا قابلِ انتظام ہے۔ لیکن جب آپ درجنوں مشینوں پر سینکڑوں کنٹینرز چلا رہے ہوں، تو دستی انتظام (manual management) مشکل نہیں بلکہ ناممکن ہو جاتا ہے۔ آپ اس بات کا سراغ کھو دیتے ہیں کہ کون سا کنٹینر کہاں موجود ہے۔ ایک سرور خراب ہو جاتا ہے، اور آپ کی ایپلی کیشن تب تک غائب رہتی ہے جب تک کوئی اسے دوبارہ شروع کرنے کے لیے بیدار نہ ہو جائے۔ نئے انسٹنس (instances) شروع کرنے سے پہلے ہی ٹریفک کا دباؤ آپ کے سیٹ اپ کو مفلوج کر دیتا ہے۔ بالکل یہیں پر Kubernetes منظر میں آتا ہے۔ یہ محض ایک اور DevOps ٹول نہیں ہے۔ یہ ایک orchestration layer ہے جو کنٹینر مینجمنٹ کو اسکرپٹنگ کی مشق کے بجائے ایک کنٹرول کے مسئلے کے طور پر دیکھتی ہے۔
اسکرپٹس آخر کار کیوں ناکام ہو جاتے ہیں
زیادہ تر ٹیمیں شیل اسکرپٹس (shell scripts) یا بنیادی آٹومیشن سے آغاز کرتی ہیں۔ وہ امیجز (images) حاصل کرنے، کنٹینرز شروع کرنے، لاگز (logs) پر نظر رکھنے اور ناکام شدہ عمل (processes) کو دوبارہ شروع کرنے کے لیے کمانڈز لکھتے ہیں۔ یہ طریقہ ایک 'پروف آف کانسیپٹ' (proof of concept) کے لیے تو ٹھیک ہے، لیکن حقیقی دنیا کے بوجھ کے نیچے یہ ڈھہہ جاتا ہے۔ مائیکرو سروسز مختلف ہوسٹس پر ایک دوسرے سے بات کرتی ہیں، مخصوص انوائرمنٹ ویری ایبلز (environment variables) پر انحصار کرتی ہیں، انہیں مستقل اسٹوریج کی ضرورت ہوتی ہے جو کنٹینر ری اسٹارٹ ہونے کے بعد بھی برقرار رہے، اور وہ ورژن کے درمیان مستقل نیٹ ورکنگ کی توقع رکھتی ہیں۔ جب کوئی ورچوئل مشین غائب ہو جاتی ہے تو ایک اسکرپٹ خود بخود ورک لوڈ کو دوبارہ شیڈول نہیں کر سکتا۔ یہ کریش لوپ (crash loop) میں پھنسے ہوئے انسٹنس کو چھوڑ کر، صحت مند انسٹنسز کے درمیان نیٹ ورک ٹریفک کو تقسیم نہیں کر سکتا۔ Kubernetes اس مسئلے کو حل کرتا ہے کیونکہ یہ خود کلسٹر (cluster) کو ان فیصلوں کا ذمہ دار بنا دیتا ہے۔ آپ بیان کرتے ہیں کہ آپ کو کیا چاہیے، اور سسٹم مسلسل اس حالت (state) کو نافذ کرتا رہتا ہے۔
وہ تین چیزیں جو یہ آپ کو فراہم کرتا ہے
Kubernetes تین بنیادی صلاحیتیں فراہم کرتا ہے جو دستی آگ بجھانے (manual firefighting) کی جگہ خودکار بھروسہ مندی (automated reliability) لاتی ہیں۔
High availability کا مطلب ہے کہ آپ کی ایپلی کیشنز آن لائن رہتی ہیں، چاہے آپ کے انفراسٹرکچر کے کچھ حصے ناکام ہو جائیں۔ اگر کوئی کنٹینر کریش ہو جاتا ہے، تو Kubernetes اسے چند سیکنڈوں میں تبدیل کر دیتا ہے۔ اگر کوئی پورا ورکر نوڈ (worker node) بند ہو جاتا ہے، تو شیڈولر (scheduler) اس کی غیر موجودگی کو محسوس کرتا ہے اور متاثرہ ورک لوڈ کو کلسٹر میں موجود دوسری صحت مند مشینوں پر منتقل کر دیتا ہے۔ سسٹم آپ کے متعین کردہ مطلوبہ اسٹیٹ (desired state) پر مسلسل نظر رکھتا ہے اور انسانی مداخلت کے بغیر ان تبدیلیوں کو درست کرتا رہتا ہے۔
Scalability کا مطلب ہے کہ آپ کی ایپلی کیشنز آپ کے صارفین کے ساتھ ساتھ بڑھتی ہیں۔ صرف دو گھنٹے کے ٹریفک کے عروج سے بچنے کے لیے بیس (20) سرورز فراہم کرنے کے بجائے، آپ اہم میٹرکس (metrics) متعین کرتے ہیں، جیسے CPU کا استعمال یا ریکویسٹ لیٹنسی (request latency)، اور جب حد (threshold) عبور ہو جائے تو کلسٹر کو مزید کنٹینر انسٹنسز شامل کرنے دیتے ہیں۔ جب ڈیمانڈ کم ہوتی ہے، تو ریپلیکا کی تعداد دوبارہ کم ہو جاتی ہے۔ آپ اسی چیز کے لیے ادائیگی کرتے ہیں جس کی آپ کو ضرورت ہوتی ہے، اور جب ضرورت ہوتی ہے۔
Disaster recovery کا مطلب ہے کہ کریش کے بعد آپ کا ڈیٹا اور کنفیگریشن واپس آ جاتی ہے۔ Kubernetes پورے کلسٹر کی حالت کو ایک تقسیم شدہ کی-ویلیو اسٹور (distributed key-value store) میں محفوظ کرتا ہے۔ اگر کوئی بڑی ناکامی ورکر نوڈز یا کنٹرول پلین (control plane) کے کسی حصے کو بھی ختم کر دے، تو وہ محفوظ شدہ اسٹیٹ سسٹم کو آپ کے ورک لوڈز کو بالکل اسی طرح دوبارہ بنانے کی اجازت دیتی ہے جیسے وہ کنفیگر کیے گئے تھے۔ آپ کا ڈیٹا واپس آ جاتا ہے کیونکہ آرکیسٹریٹر (orchestrator) کو یاد ہوتا ہے کہ اسے کیسا ہونا چاہیے تھا۔
سیٹ اپ: دماغ اور طاقت (Brains and Muscle)
ایک Kubernetes کلسٹر کے دو بنیادی کردار ہیں جنہیں ڈرافٹ میں 'دماغ' اور 'طاقت' کے طور پر بیان کیا گیا ہے، اور یہ مثال عملی طور پر بالکل درست ہے۔
Master Node دماغ ہے۔ یہ آپ کی کسٹمر فیسنگ ایپلی کیشنز نہیں چلاتا۔ اس کے بجائے، یہ کنٹرول پلین کے اجزاء کی میزبانی کرتا ہے جو ٹاسک شیڈول کرتے ہیں، کلسٹر کی حالت کا انتظام کرتے ہیں، اور تبدیلیوں کا جواب دیتے ہیں۔ جب آپ کوئی کمانڈ جاری کرتے ہیں یا کنفیگریشن فائل جمع کرواتے ہیں، تو ماسٹر نوڈ فیصلہ کرتا ہے کہ ورک لوڈ کہاں ہونا چاہیے، آیا وہ صحت مند ہے، اور جب وہ صحت مند نہ ہو تو کیا کرنا چاہیے۔
Worker Nodes طاقت ہیں۔ ہر ورکر ایک ہلکا پھلکا ایجنٹ چلاتا ہے جو ماسٹر کے ساتھ رابطہ کرتا ہے اور اصل پوڈز (pods) کو چلانے کے لیے کنٹینر رن ٹائم (container runtime) کا استعمال کرتا ہے۔ یہ وہ نوڈز ہیں جہاں آپ کا ایپلی کیشن کوڈ CPU اور میموری استعمال کرتا ہے۔ مزید ورکر نوڈز شامل کریں، اور آپ کا کلسٹر خام صلاحیت (raw capacity) حاصل کر لیتا ہے۔ ریڈنڈنسی (redundancy) کے لیے کنفیگر کیے گئے مزید ماسٹر نوڈز شامل کریں، اور آپ کا کنٹرول پلین انفرادی ہارڈ ویئر کی ناکامیوں کے خلاف لچکدار بن جاتا ہے۔
Pods، Containers، اور Services
Kubernetes کے ساتھ کام کرنے کے لیے، آپ کو تین اصطلاحات کو سمجھنے کی ضرورت ہے جو یہ طے کرتی ہیں کہ سافٹ ویئر کو کیسے پیک کیا جاتا ہے اور اس تک کیسے پہنچا جاتا ہے۔
Containers وہ پیکیجز ہیں جو آپ کی ایپلی کیشن کو اس کی وابستگیوں (dependencies)، لائبریریز اور کنفیگریشن کے ساتھ یکجا کرتے ہیں۔ وہ سافٹ ویئر کو بنیادی ہوسٹ سے الگ رکھتے ہیں تاکہ یہ ڈویلپمنٹ، اسٹیجنگ اور پروڈکشن میں ایک ہی طرح سے چلے۔
Pods Kubernetes میں سب سے چھوٹی قابلِ تعیناتی (deployable) اکائی ہیں۔ ایک pod ایک یا ایک سے زیادہ کنٹینرز کو اپنے اندر ضم کرتا ہے جنہیں وسائل (resources) شیئر کرنے کی ضرورت ہوتی ہے۔ وہ ایک ہی نیٹ ورک نیم اسپیس (network namespace) شیئر کرتے ہیں اور ایک ہی لوکل اسٹوریج والیومز تک رسائی حاصل کر سکتے ہیں۔ یہ اہم ہے: آپ براہ راست ایک سادہ کنٹینر کو تعینات نہیں کرتے، بلکہ آپ ایک pod تعینات کرتے ہیں جو اسے اپنے اندر رکھتا ہے۔ Pods جان بوجھ کر عارضی (ephemeral) بنائے گئے ہیں۔ حالات بدلنے کے ساتھ ساتھ وہ تخلیق کیے جاتے ہیں، ختم کیے جاتے ہیں، اور تبدیل کیے جاتے ہیں۔ ان کی زندگی کا دورانیہ ڈیزائن کے لحاظ سے متحرک (dynamic) ہوتا ہے۔
Services اس لیے موجود ہیں کیونکہ pods عارضی (transient) ہوتے ہیں۔ ہر بار جب ایک pod ری اسٹارٹ ہوتا ہے، تو غالباً اسے ایک نیا انٹرنل IP ایڈریس ملتا ہے۔ اگر آپ کی ایپلی کیشن کے دیگر حصے براہ راست ان بدلتے ہوئے ایڈریسز سے جڑنے کی کوشش کریں گے، تو وہ مسلسل ناکام ہوں گے۔ ایک service آپ کے pods کو ایک مستقل IP ایڈریس اور DNS نام فراہم کرتی ہے۔ یہ ایک مستحکم 'فرنٹ ڈور' کے طور پر کام کرتی ہے، جو اپنے سلیکٹر (selector) سے مطابقت رکھنے والے تمام صحت مند pods پر آنے والی درخواستوں کو لوڈ بیلنس (load-balance) کرتی ہے۔ یہ آپ کے کلائنٹس کو انفرادی کنٹینرز کے لائف سائیکل کے انتشار سے الگ کر دیتی ہے۔
بڑے پیمانے پر Kubernetes: Netflix کی مثال
Netflix اپنے مواد کی ترسیل کے نیٹ ورک (content delivery network) کو مینیج کرنے کے لیے Kubernetes کا استعمال کرتا ہے۔ یہ انفراسٹرکچر دنیا بھر میں لاکھوں ناظرین کو بیک وقت ویڈیو اسٹریمز فراہم کرتا ہے۔ جب کوئی مقبول شو ریلیز ہوتا ہے اور ڈیمانڈ بڑھتی ہے، تو کلسٹر (cluster) ان کیش نوڈز (cache nodes) کو بڑھا دیتا ہے جو صارفین کے قریب ویڈیو سیگمنٹس کو اسٹور کرتے ہیں۔ اگر کوئی علاقائی نوڈ (regional node) فیل ہو جائے، تو ٹریفک خود بخود دوسرے راستے پر منتقل ہو جاتی ہے۔ اس کا نتیجہ یہ نکلتا ہے کہ کسی انجینئر کو دستی طور پر ایمرجنسی کال کیے بغیر لاکھوں لوگوں کے لیے فلمیں چلتی رہتی ہیں۔ آرکیسٹریٹر (orchestrator) پیمانے اور ناکامیوں کو سنبھال لیتا ہے تاکہ سروس بغیر کسی تعطل کے جاری رہے۔
آغاز: YAML، JSON، اور API Server
Kubernetes کے ساتھ آغاز کرنے کا مطلب ہے کہ 'imperative click-ops' کو پیچھے چھوڑ کر 'declarative configuration' کو اپنانا۔ آپ جو چاہتے ہیں اسے YAML یا JSON فائلوں میں لکھتے ہیں۔ یہ مینی فیسٹس (manifests) کنٹینر امیج سے لے کر ریپلیکا کی تعداد، ایکسپوزڈ پورٹس، انوائرمنٹ ویری ایبلز، اور اسٹوریج ماؤنٹس تک ہر چیز کی وضاحت کرتے ہیں۔ جب آپ کی فائل تیار ہو جاتی ہے، تو آپ اسے ماسٹر نوڈ پر موجود API server کو بھیج دیتے ہیں۔ کنٹرول پلین (control plane) اس ڈیکلریشن کو وصول کرتا ہے، اسے کلسٹر اسٹیٹ ڈیٹا بیس میں محفوظ کرتا ہے، اور پھر حقیقت کو آپ کی وضاحت کے مطابق بنانے کے لیے کام شروع کر دیتا ہے۔ آپ Kubernetes کو یہ نہیں بتاتے کہ اسے اپنا کام بالکل کیسے کرنا ہے۔ آپ اسے بتاتے ہیں کہ حتمی نتیجہ کیا ہونا چاہیے، اور وہ خود ہی اقدامات طے کر لیتا ہے۔
اصل حاصلِ کلام
Kubernetes کو سیکھنے کے لیے محنت درکار ہے۔ شروع میں اس کی اصطلاحات مشکل محسوس ہوتی ہیں۔ اس میں بہت سے متحرک حصے شامل ہیں، اور ایک ڈسٹریبیوٹڈ سسٹم (distributed system) کی ڈی بگنگ (debugging) کرنا ایک سنگل سرور کی ڈی بگنگ سے فطری طور پر زیادہ مشکل ہے۔ لیکن اس کا فائدہ آپریشنل سکون کی صورت میں ملتا ہے۔ آپ انفرادی مشینوں کی نگرانی کرنا چھوڑ دیتے ہیں۔ آپ رات کے 3 بجے ہونے والے آؤٹج (outage) کے دوران اپنے اسٹارٹ اپ اسکرپٹس کے کام کرنے کی دعا کرنا چھوڑ دیتے ہیں۔ آپ ڈیفالٹ کے طور پر ناکامی کے پیشِ نظر ڈیزائن کرنا شروع کر دیتے ہیں، یہ فرض کرتے ہوئے کہ نوڈز فیل ہوں گے، اور آرکیسٹریٹر پر بھروسہ کرتے ہیں کہ وہ آپ کی ایپلی کیشن کو درست حالت میں رکھے گا۔ ذہنیت میں یہ تبدیلی، کہ 'کاش کچھ نہ ٹوٹے' سے 'یہ جاننا کہ سسٹم خرابی کو سنبھال سکتا ہے'، اس محنت کو قابلِ عمل بناتی ہے۔
ماخذ: What Is Kubernetes? Kubernetes Explained in 15 Mins
اختیاری لرننگ کمیونٹی: GyaanSetu AI on Telegram