انٹرنیٹ پر بہت سارے حوالہ جات موجود ہیں، لیکن بعض اوقات آسان ترین مشورہ سب سے قیمتی ہوتا ہے۔ ٹیم ترجمہ ، جسے مضمون کے مصنف نے Kubernetes کے ساتھ کام کرنے کے ایک سال بعد جمع کیا۔ نکات کو اہمیت کے لحاظ سے ترتیب نہیں دیا جاتا ہے، لیکن ہم سمجھتے ہیں کہ ہر کوئی اپنے لیے کچھ مفید پائے گا۔
Kubernetes کے ساتھ کام کرنے کا آسان ترین حکم
کے ساتھ شروع کرنے کے لئے، شاید سب سے آسان اور سب سے زیادہ مفید کارروائی Kubernetes کے ساتھ کام کرنا۔ درج ذیل کمانڈ کمانڈ کی تکمیل کو قابل بناتی ہے۔ kubectl باش شیل میں:
echo "source <(kubectl completion bash)" >> ~/.bashrc
آٹوفل kubectl bashrc فائل میں لکھا جائے گا اور ہر بار شیل شروع ہونے پر خود بخود چالو ہوجائے گا۔ یہ لمبی کمانڈز اور پیرامیٹرز جیسے ٹائپنگ کو تیز کرتا ہے۔ all-namespaces. میں مزید پڑھیں .
نام کی جگہ میں پہلے سے طے شدہ میموری اور سی پی یو کی حدود
اگر ایپلی کیشن غلط لکھی گئی ہے، مثال کے طور پر، یہ ہر سیکنڈ میں ڈیٹابیس سے ایک نیا کنکشن کھولتا ہے لیکن اسے کبھی بند نہیں کرتا، تو کلسٹر میں میموری لیک ہو جاتی ہے۔ اور اگر ایپلی کیشن میں تعیناتی کے دوران میموری کی حد مقرر نہیں ہے، تو یہ نوڈ کی ناکامی کا باعث بن سکتا ہے۔
اسے روکنے کے لیے، Kubernetes آپ کو فی نیم اسپیس کی بنیاد پر ڈیفالٹ پابندیاں سیٹ کرنے کی اجازت دیتا ہے۔ وہ ایک مخصوص نام کی جگہ کے لیے yaml فائل میں لکھے گئے ہیں۔ یہاں ایسی فائل کی ایک مثال ہے:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
ایسا یامل بنائیں اور کسی بھی نام کی جگہ پر لاگو کریں۔ مثال کے طور پر، نام کی جگہ پر limit-example. اب اس نام کی جگہ میں تعینات کسی بھی کنٹینر کی حد 512Mi ہوگی، جب تک کہ اس کنٹینر کے لیے کوئی اور انفرادی حد مقرر نہ کی جائے۔
Kubernetes کے پرانے ورژن میں کوڑا کرکٹ جمع کرنا
کبلیٹ بطور ڈیفالٹ کوڑا اٹھانا شروع کرتا ہے جب var/lib/docker دستیاب ڈسک کی 90% جگہ پر قبضہ کرتا ہے۔ یہ بہت اچھا ہے، تاہم، Kubernetes 1.7 تک استعمال شدہ inodes کی تعداد پر کوئی طے شدہ حد نہیں تھی، جو فائل سسٹم میں فائلوں کی تعداد کے مساوی ہے۔
ممکنہ طور پر آپ کا کنٹینر var/lib/docker ڈسک کی جگہ کا صرف 50% استعمال کر سکتا ہے، لیکن انوڈس ختم ہو سکتا ہے، جو کارکنوں کے لیے پریشانی کا باعث بنے گا۔
1.4 سے 1.6 تک کیوبلیٹ کے پرانے ورژن میں آپ کو یہ جھنڈا شامل کرنا پڑے گا:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
1.7 اور بعد کے ورژن میں یہ جھنڈا بطور ڈیفالٹ سیٹ ہوتا ہے۔ تاہم، پچھلے ورژن انوڈ کی حد کی نگرانی نہیں کرتے ہیں۔
Minikube... چھوٹے لیکن طاقتور مقامی Kubernetes
Minikube مقامی Kubernetes کلسٹر کو چلانے کا سب سے آسان طریقہ ہے۔ یہ ایک سادہ کمانڈ کے ساتھ شروع کیا گیا ہے:
minikube start
اس کمانڈ کو چلانے کے نتیجے میں آپ کی مشین پر ایک حقیقی Kubernetes کلسٹر چل رہا ہے۔
چال یہ ہے کہ ایپلی کیشن کو کیسے بنایا جائے اور اسے اس کلسٹر پر مقامی طور پر چلایا جائے۔ جب تک کہ خاص طور پر ہدایت نہ کی جائے، ڈوکر امیج آپ کے کمپیوٹر پر بنائی جائے گی نہ کہ کلسٹر پر۔
ڈوکر کو امیج کو مقامی کبرنیٹس کلسٹر میں دھکیلنے پر مجبور کرنے کے لیے، ڈوکر مشین کو درج ذیل کمانڈ دی گئی ہے۔
eval $(minikube docker-env)
اب ہم مقامی Kubernetes کلسٹر پر ایپلی کیشنز بنا سکتے ہیں۔
kubectl کو ہر کسی تک رسائی نہ دیں۔
یہ واضح معلوم ہوتا ہے، لیکن اگر ایک سے زیادہ ٹیمیں اپنی ایپلی کیشنز کے لیے ایک ہی کلسٹر کا استعمال کر رہی ہیں (جس کے لیے کبرنیٹس بنایا گیا تھا)، آپ کو صرف ہر ایک کو نہیں دینا چاہیے۔ kubectl. بہتر ہے کہ کمانڈز کو الگ کر دیا جائے، ان میں سے ہر ایک کو اس کی اپنی نام کی جگہ تفویض کی جائے اور RBAC پالیسیوں کا استعمال کرتے ہوئے رسائی کو محدود کیا جائے۔
آپ ہر پوڈ تک رسائی، پڑھنے، تخلیق کرنے، حذف کرنے اور دیگر کارروائیوں کے حقوق تفویض کرکے الجھن میں پڑ سکتے ہیں۔ لیکن اہم بات رازوں تک رسائی کو محدود کرنا ہے، اس کی اجازت صرف منتظمین تک ہے۔ اس طرح ہم ان لوگوں کے درمیان فرق کریں گے جو کلسٹر کا انتظام کر سکتے ہیں اور ان لوگوں کے درمیان جو آسانی سے اس میں تعینات کر سکتے ہیں۔
پوڈ بجٹ کا نظم کریں۔
کبرنیٹس کلسٹر میں کسی ایپلیکیشن کے لیے ڈاؤن ٹائم نہ ہونے کو کیسے یقینی بنایا جائے؟ PodDisruptionBudget اور پھر PodDisruptionBudget۔
کلسٹرز کو وقتاً فوقتاً اپ ڈیٹ کیا جاتا ہے اور نوڈس کو خالی کر دیا جاتا ہے۔ کچھ بھی نہیں ٹھہرتا، یہ حقیقت ہے۔ ایک سے زیادہ مثالوں والی ہر تعیناتی میں PDB (PodDisruptionBudget) شامل ہونا چاہیے۔ یہ ایک سادہ یامل فائل میں بنایا گیا ہے جو کلسٹر پر لاگو ہوتا ہے۔ کسی خاص PDB کا کوریج ایریا لیبل سلیکٹرز کے ذریعے طے کیا جاتا ہے۔
نوٹ: PDB بجٹ کو صرف اسی صورت میں مدنظر رکھا جاتا ہے جب بجٹ کی خلاف ورزی کو تبدیل کیا جا سکتا ہے ()۔ ہارڈ ویئر کی ناکامیوں جیسے حالات میں، PDB کام نہیں کرے گا۔
مثال PDB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
دو اہم پیرامیٹرز ہیں۔ matchLabels и minAvailable. پہلا پیرامیٹر بتاتا ہے کہ بجٹ کن ایپلیکیشنز پر لاگو ہوتا ہے۔ مثال کے طور پر، اگر میرے پاس لیبل کے ساتھ تعیناتیاں ہیں۔ app: app-a и app: app-b، پھر یہ PDB صرف پہلے والے پر لاگو ہوگا۔
پیرامیٹر minAvailable نوڈ کو خالی کرتے وقت (صفائی) کو مدنظر رکھا جاتا ہے۔ مثال کے طور پر، ہماری مثال میں، خالی کرنے کے دوران، تمام مثالوں کو بے دخل کر دیا جاتا ہے۔ app: app-aسوائے دو کے۔
یہ آپ کو کنٹرول کرنے کی اجازت دیتا ہے کہ کسی بھی وقت ایپلی کیشن کے کتنے واقعات چلائے جائیں۔
ایپلی کیشن ہیلتھ مانیٹرنگ
اس طرح کی نگرانی دو طریقوں سے ممکن ہے: تیاری یا زندہ دلی کے ٹیسٹ کا استعمال۔
پہلی تحقیقات (تیار) ٹریفک وصول کرنے کے لیے کنٹینر کی تیاری کا تعین کرتی ہے۔
دوسرا (جاندار) ظاہر کرتا ہے کہ کنٹینر صحت مند ہے یا اسے دوبارہ شروع کرنے کی ضرورت ہے۔
متعلقہ کنفیگریشنز کو صرف تعیناتی کے لیے yaml میں شامل کیا جاتا ہے۔ وہاں آپ ٹائم آؤٹ، تاخیر کے اوقات اور دوبارہ ٹرائلز کی تعداد بتا سکتے ہیں۔ ان کے بارے میں مزید تفصیلات دیکھیں .
ٹیگز ہر جگہ موجود ہیں۔
لیبلز Kubernetes میں بنیادی تصورات میں سے ایک ہیں۔ وہ اشیاء کو آزادانہ طور پر ایک دوسرے کے ساتھ بات چیت کرنے کے ساتھ ساتھ لیبل کی بنیاد پر سوالات تخلیق کرنے کی اجازت دیتے ہیں۔ Kubernetes میں، آپ کلائنٹ کے پاس بھی جا سکتے ہیں اور مخصوص ٹیگز کے لیے ایونٹس دیکھ سکتے ہیں۔
آپ ٹیگز کے ساتھ تقریباً کچھ بھی کر سکتے ہیں، لیکن ایک اچھی مثال ایک ہی کلسٹر پر پروگرام چلانے کے لیے متعدد ماحول بنانا ہے۔
ہم کہتے ہیں کہ آپ ایک ہی کلسٹر کے لیے استعمال کرتے ہیں۔ dev и qa. اس کا مطلب ہے کہ آپ درخواست لے سکتے ہیں۔ app-aبیک وقت دونوں ماحول میں کام کرنا qa и dev. اس صورت میں، ہم مناسب پیرامیٹر کی وضاحت کر کے ایک مخصوص ماحول میں درخواست کی مثال تک الگ سے رسائی حاصل کر سکتے ہیں۔ environment. مثال کے طور پر app: app-a и environment: dev ایک ماحول کے لیے، اور app: app-a и environment: qa دوسرے کے لئے.
یہ آپ کو درخواست کی دونوں مثالوں تک رسائی حاصل کرنے کی اجازت دیتا ہے، مثال کے طور پر، بیک وقت جانچ کرنا۔
منظم ہو جائیں۔
Kubernetes ایک بہت طاقتور نظام ہے، لیکن کوئی بھی نظام آخر کار بہت سارے عمل کے ساتھ پھنس سکتا ہے۔ Kubelet آپ کے بتائے ہوئے تمام عمل اور جانچ پڑتال کے ساتھ ساتھ خود بھی چلاتا ہے۔
بلاشبہ، ایک یتیم سروس سسٹم کو سست نہیں کرے گی، اور Kubernetes کو زمین سے پیمانہ کرنے کے لیے ڈیزائن کیا گیا ہے۔ لیکن اگر ایک خدمت کے بجائے دس لاکھ ظاہر ہوں تو کبلیت دم گھٹنے لگتی ہے۔
اگر کسی وجہ سے آپ کسی تعیناتی (کنٹینر، تصویر، جو کچھ بھی) کو حذف کر دیتے ہیں، تو بس مکمل صفائی کو یقینی بنائیں۔
جاؤ سے ملو
ہم نے آخری مشورے کو محفوظ کر لیا۔ گو پروگرامنگ زبان سیکھیں۔
Kubernetes کو Go میں تیار کیا گیا ہے، تمام ایکسٹینشن گو میں لکھے گئے ہیں، اور کلائنٹ-گو کلائنٹ لائبریری کو بھی سرکاری طور پر تعاون حاصل ہے۔
اسے مختلف اور دلچسپ چیزوں کے لیے استعمال کیا جا سکتا ہے۔ مثال کے طور پر، اپنے ذائقہ کے مطابق Kubernetes سسٹم کو بڑھانا۔ لہذا، آپ ڈیٹا اکٹھا کرنے، ایپلیکیشنز کو تعینات کرنے، یا کنٹینرز کو صاف کرنے کے لیے اپنے پروگرام استعمال کر سکتے ہیں۔
گو پروگرامنگ کی زبان سیکھنا اور کلائنٹ گو میں مہارت حاصل کرنا شاید سب سے اہم مشورہ ہے جو آپ نئے Kubernetes صارفین کو دے سکتے ہیں۔
اور کیا پڑھنا ہے۔:
- .
- ?
- .
ماخذ: www.habr.com