🥇 kubectl کو زیادہ مؤثر طریقے سے استعمال کرنے کا طریقہ: ایک تفصیلی گائیڈ

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

ٹیم Mail.ru سے Kubernetes aaS ڈینیئل ویبل کے ایک مضمون کا ترجمہ کیا جس میں آپ کو kubectl کے ساتھ مؤثر طریقے سے کام کرنے کے لیے تجاویز اور ترکیبیں ملیں گی۔ یہ آپ کو کبرنیٹس کی گہری سمجھ حاصل کرنے میں بھی مدد کرے گا۔

مصنف کے مطابق، مضمون کا مقصد Kubernetes کے ساتھ آپ کے روزمرہ کے کام کو نہ صرف زیادہ موثر بنانا ہے، بلکہ مزید پرلطف بھی بنانا ہے!

تعارف: kubectl کیا ہے؟

اس سے پہلے کہ آپ kubectl کو زیادہ مؤثر طریقے سے استعمال کرنا سیکھ سکیں، آپ کو یہ جاننے کی ضرورت ہے کہ یہ کیا ہے اور یہ کیسے کام کرتا ہے۔

صارف کے نقطہ نظر سے، kubectl ایک کنٹرول پینل ہے جو آپ کو Kubernetes آپریشن کرنے کی اجازت دیتا ہے۔

تکنیکی طور پر، kubectl ایک Kubernetes API کلائنٹ ہے۔

Kubernetes API ایک HTTP REST API ہے۔ یہ API حقیقی Kubernetes یوزر انٹرفیس ہے، جس کے ذریعے اسے مکمل طور پر کنٹرول کیا جاتا ہے۔ اس کا مطلب ہے کہ ہر Kubernetes آپریشن API کے اختتامی نقطہ کے طور پر سامنے آتا ہے اور اس اختتامی نقطہ پر HTTP درخواست کے ساتھ کیا جا سکتا ہے۔

لہذا، kubectl کا بنیادی کام Kubernetes API کو HTTP درخواستیں کرنا ہے:

Kubernetes ایک مکمل طور پر وسائل پر مبنی نظام ہے۔ اس کا مطلب یہ ہے کہ یہ وسائل کی اندرونی حالت کو برقرار رکھتا ہے اور تمام Kubernetes آپریشنز CRUD آپریشنز ہیں۔

آپ ان وسائل کو سنبھال کر Kubernetes کے مکمل کنٹرول میں ہیں، اور Kubernetes یہ بتاتا ہے کہ وسائل کی موجودہ حالت کی بنیاد پر کیا کرنا ہے۔ اس وجہ سے، Kubernetes API حوالہ ان کے متعلقہ آپریشنز کے ساتھ وسائل کی اقسام کی فہرست کے طور پر ترتیب دیا گیا ہے۔

آئیے ایک مثال دیکھتے ہیں۔.

ہم کہتے ہیں کہ آپ ReplicaSet ریسورس بنانا چاہتے ہیں۔ ایسا کرنے کے لیے، آپ ReplicaSet کو ایک فائل میں نام سے بیان کرتے ہیں۔ replicaset.yaml، پھر کمانڈ چلائیں:

$ kubectl create -f replicaset.yaml

یہ ایک ReplicaSet وسیلہ بنائے گا۔ لیکن پردے کے پیچھے کیا ہوتا ہے؟

Kubernetes میں ReplicaSet تخلیق کا عمل ہے۔ کسی دوسرے آپریشن کی طرح، یہ ایک API اختتامی نقطہ کے طور پر سامنے آیا ہے۔ اس آپریشن کے لیے مخصوص API اختتامی نقطہ اس طرح لگتا ہے:

POST /apis/apps/v1/namespaces/{namespace}/replicasets

تمام Kubernetes آپریشنز کے لیے API کے اختتامی پوائنٹس پر مل سکتے ہیں۔ API حوالہ (سمیت مندرجہ بالا اختتامی نقطہ)۔ اختتامی نقطہ پر حقیقی درخواست کرنے کے لیے، آپ کو پہلے API سرور URL کو اختتامی نقطہ راستوں میں شامل کرنا ہوگا جو API حوالہ میں درج ہیں۔

لہذا، جب آپ مندرجہ بالا کمانڈ پر عمل کرتے ہیں، تو kubectl مندرجہ بالا API اینڈ پوائنٹ پر HTTP POST کی درخواست بھیجتا ہے۔ ReplicaSet تعریف جو آپ نے فائل میں فراہم کی ہے۔ replicaset.yaml، درخواست کے جسم میں بھیجا جاتا ہے۔

اس طرح kubectl ان تمام کمانڈز کے لیے کام کرتا ہے جو Kubernetes کلسٹر کے ساتھ تعامل کرتے ہیں۔ ان تمام صورتوں میں، kubectl مناسب Kubernetes API کے اختتامی پوائنٹس پر HTTP درخواستیں کرتا ہے۔

براہ کرم نوٹ کریں کہ آپ یوٹیلیٹی جیسے یوٹیلیٹی کا استعمال کرتے ہوئے کبرنیٹس کو مکمل طور پر منظم کرسکتے ہیں۔ curlKubernetes API کو دستی طور پر HTTP درخواستیں بھیج کر۔ Kubectl آسانی سے Kubernetes API کو استعمال کرنا آسان بناتا ہے۔

یہ بنیادی باتیں ہیں کہ کیوبیکٹل کیا ہے اور یہ کیسے کام کرتا ہے۔ لیکن Kubernetes API کے بارے میں کچھ اور ہے جو ہر kubectl صارف کو معلوم ہونا چاہیے۔ آئیے Kubernetes کی اندرونی دنیا پر ایک سرسری نظر ڈالتے ہیں۔

Kubernetes کی اندرونی دنیا

Kubernetes آزاد اجزاء کے ایک سیٹ پر مشتمل ہوتا ہے جو کلسٹر نوڈس پر الگ الگ عمل کے طور پر چلتا ہے۔ کچھ اجزاء ماسٹر نوڈس پر چلتے ہیں، دوسرے ورکر نوڈس پر، ہر جزو اپنا مخصوص کام انجام دیتا ہے۔

یہاں اہم نوڈس پر سب سے اہم اجزاء ہیں:

مخزن - ذخیرہ وسائل کی تعریف (عام طور پر یہ وغیرہ ہے).
API سرور - ایک API فراہم کرتا ہے اور اسٹوریج کا انتظام کرتا ہے۔
کنٹرولر مینیجر - اس بات کو یقینی بناتا ہے کہ وسائل کے حالات تصریحات کے مطابق ہوں۔
شیڈولر - ورکر نوڈس پر پوڈز کو شیڈول کرتا ہے۔

اور ورکر نوڈس پر ایک سب سے اہم جزو یہ ہے:

کوبیلیٹ - ورکنگ نوڈ پر کنٹینرز کے آغاز کا انتظام کرتا ہے۔

یہ سمجھنے کے لیے کہ یہ اجزاء کیسے مل کر کام کرتے ہیں، آئیے ایک مثال دیکھیں۔

آئیے فرض کریں کہ آپ نے ابھی مکمل کیا ہے۔ kubectl create -f replicaset.yaml، جس کے بعد kubectl نے HTTP POST کی درخواست کی۔ ReplicaSet API اینڈ پوائنٹ (ReplicaSet وسائل کی تعریف کو پاس کرنا)۔

کلسٹر میں کیا ہو رہا ہے؟

کرنے کے بعد kubectl create -f replicaset.yaml API سرور آپ کے ReplicaSet وسائل کی تعریف کو اسٹوریج میں محفوظ کرتا ہے:
اگلا، ReplicaSet کنٹرولر کو کنٹرولر مینیجر میں لانچ کیا جاتا ہے، جو ReplicaSet وسائل کی تخلیق، ترمیم اور حذف کرنے کا کام سنبھالتا ہے:
ReplicaSet کنٹرولر ہر ReplicaSet ریپلیکا (ReplicaSet تعریف میں پوڈ ٹیمپلیٹ کے مطابق) کے لیے پوڈ کی تعریف تیار کرتا ہے اور انہیں اسٹوریج میں محفوظ کرتا ہے:
شیڈولر لانچ کیا گیا ہے، ٹریکنگ پوڈز جو ابھی تک کسی ورکر نوڈس کو تفویض نہیں کیے گئے ہیں:
شیڈولر ہر پوڈ کے لیے ایک مناسب ورکر نوڈ کا انتخاب کرتا ہے اور اس معلومات کو اسٹور میں پوڈ کی تعریف میں شامل کرتا ہے:
ورکر نوڈ پر جس کو پوڈ تفویض کیا گیا ہے، کیوبلیٹ کو لانچ کیا جاتا ہے، یہ اس نوڈ کو تفویض کردہ پوڈز کو ٹریک کرتا ہے:
کوبیلیٹ اسٹوریج سے پوڈ کی تعریف پڑھتا ہے اور کنٹینر رن ٹائم، جیسے ڈوکر، کو نوڈ پر کنٹینرز لانچ کرنے کی ہدایت کرتا ہے:

ذیل میں اس تفصیل کا متنی ورژن ہے۔

ReplicaSet تخلیق کے اختتامی نقطہ پر API کی درخواست API سرور کے ذریعہ کارروائی کی جاتی ہے۔ API سرور درخواست کی توثیق کرتا ہے اور ReplicaSet وسائل کی تعریف کو اسٹوریج میں محفوظ کرتا ہے۔

یہ واقعہ ReplicaSet کنٹرولر کو شروع کرتا ہے، جو کنٹرولر مینیجر کا ذیلی عمل ہے۔ ReplicaSet کنٹرولر سٹور میں ReplicaSet وسائل کی تخلیق، اپ ڈیٹ کرنے اور حذف کرنے کی نگرانی کرتا ہے اور ایسا ہونے پر واقعہ کی اطلاع موصول کرتا ہے۔

ReplicaSet کنٹرولر کا کام اس بات کو یقینی بنانا ہے کہ ReplicaSet pods کی مطلوبہ تعداد موجود ہو۔ ہماری مثال میں، ابھی تک کوئی پوڈ موجود نہیں ہے، لہذا ReplicaSet کنٹرولر ان پوڈ کی تعریفیں بناتا ہے (ReplicaSet تعریف میں پوڈ ٹیمپلیٹ کے مطابق) اور انہیں اسٹوریج میں محفوظ کرتا ہے۔

نئے پوڈز کی تخلیق ایک شیڈیولر کے ذریعہ شروع کی گئی ہے جو پوڈ کی تعریفوں پر نظر رکھتا ہے جو ابھی تک ورکر نوڈس کے لیے طے نہیں کی گئی ہیں۔ شیڈیولر ہر پوڈ کے لیے ایک مناسب ورکر نوڈ کا انتخاب کرتا ہے اور پوڈ کی تعریفوں کو ذخیرہ میں اپ ڈیٹ کرتا ہے۔

نوٹ کریں کہ اس وقت تک، کلسٹر میں کہیں بھی کام کا بوجھ کوڈ نہیں چل رہا تھا۔ سب کچھ جو اب تک کیا گیا ہے۔ - یہ ماسٹر نوڈ پر ریپوزٹری میں وسائل کی تخلیق اور اپ ڈیٹ ہے۔

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

اس وقت، آپ کی ReplicaSet ایپلیکیشن آخر کار چل رہی ہے!

Kubernetes API کا کردار

جیسا کہ آپ نے پچھلی مثال میں دیکھا، Kubernetes اجزاء (سوائے API سرور اور سٹوریج کے) سٹوریج میں وسائل میں تبدیلیوں کو دیکھتے ہیں اور اسٹوریج میں وسائل کے بارے میں معلومات کو تبدیل کرتے ہیں۔

بلاشبہ، یہ اجزاء اسٹوریج کے ساتھ براہ راست تعامل نہیں کرتے ہیں، بلکہ صرف Kubernetes API کے ذریعے ہوتے ہیں۔

درج ذیل مثالوں پر غور کریں۔:

ReplicaSet کنٹرولر API اینڈ پوائنٹ کا استعمال کرتا ہے۔ فہرست ReplicaSets پیرامیٹر کے ساتھ watch ReplicaSet وسائل میں تبدیلیوں کی نگرانی کے لیے۔
ReplicaSet کنٹرولر API اینڈ پوائنٹ کا استعمال کرتا ہے۔ پوڈ بنائیں (پڈ بنائیں) پھلی بنانے کے لیے۔
شیڈیولر API اینڈ پوائنٹ کا استعمال کرتا ہے۔ پیچ پھلی (پوڈ میں ترمیم کریں) منتخب کارکن نوڈ کے بارے میں معلومات کے ساتھ پوڈ کو اپ ڈیٹ کرنے کے لیے۔

جیسا کہ آپ دیکھ سکتے ہیں، یہ وہی API ہے جس تک kubectl رسائی حاصل کرتا ہے۔ اندرونی اجزاء اور بیرونی صارفین کے لیے ایک ہی API کا استعمال Kubernetes ڈیزائن میں ایک بنیادی تصور ہے۔

اب ہم خلاصہ کر سکتے ہیں کہ Kubernetes کیسے کام کرتا ہے:

سٹوریج سٹور بیان کرتے ہیں، یعنی Kubernetes وسائل۔
API سرور سٹوریج کو Kubernetes API کی شکل میں ایک انٹرفیس فراہم کرتا ہے۔
Kubernetes کے دیگر تمام اجزاء اور صارفین API کے ذریعے Kubernetes کی حالت (وسائل) کو پڑھتے، مشاہدہ کرتے اور اس میں ہیرا پھیری کرتے ہیں۔

ان تصورات کو جاننے سے آپ کو kubectl کو بہتر طور پر سمجھنے اور اس سے زیادہ سے زیادہ فائدہ اٹھانے میں مدد ملے گی۔

اب آئیے کچھ مخصوص ٹپس اور ٹرکس دیکھتے ہیں جو kubectl کے ساتھ آپ کی پیداواری صلاحیت کو بہتر بنانے میں مدد کریں گے۔

1. کمانڈ کی تکمیل کا استعمال کرتے ہوئے ان پٹ کو تیز کریں۔

kubectl کے ساتھ کارکردگی کو بہتر بنانے کے لیے سب سے زیادہ مفید، لیکن اکثر نظر انداز کی جانے والی تکنیکوں میں سے ایک کمانڈ کی تکمیل ہے۔

کمانڈ کی تکمیل آپ کو ٹیب کلید کا استعمال کرتے ہوئے kubectl کمانڈز کے حصوں کو خود بخود مکمل کرنے کی اجازت دیتی ہے۔ یہ ذیلی کمانڈز، اختیارات اور دلائل کے لیے کام کرتا ہے، جس میں وسائل کے ناموں جیسی پیچیدہ چیز بھی شامل ہے۔

دیکھیں کہ کیوبیکٹل کمانڈ کی تکمیل کیسے کام کرتی ہے:

کمانڈ کی تکمیل Bash اور Zsh شیلوں کے لیے کام کرتی ہے۔

سرکاری رہنما خودکار تکمیل کو ترتیب دینے کے لیے تفصیلی ہدایات پر مشتمل ہے، لیکن ذیل میں ہم ایک مختصر اقتباس فراہم کریں گے۔

کمانڈ کی تکمیل کیسے کام کرتی ہے۔

کمانڈ کی تکمیل ایک شیل خصوصیت ہے جو تکمیل اسکرپٹ کا استعمال کرتے ہوئے کام کرتی ہے۔ ایکسٹینشن اسکرپٹ ایک شیل اسکرپٹ ہے جو کسی مخصوص کمانڈ کے لیے ایکسٹینشن کے رویے کی وضاحت کرتی ہے۔

Kubectl درج ذیل کمانڈز کا استعمال کرتے ہوئے Bash اور Zsh کے لیے ایکسٹینشن اسکرپٹ خود بخود تیار اور آؤٹ پٹ کرتا ہے۔

$ kubectl completion bash

: Или

$ kubectl completion zsh

نظریہ میں، ان کمانڈز کے آؤٹ پٹ کو مناسب کمانڈ شیل سے جوڑنا کافی ہے تاکہ kubectl کمانڈز کی تکمیل کر سکے۔

عملی طور پر، کنکشن کا طریقہ Bash کے لیے مختلف ہے (بشمول Linux اور MacOS کے درمیان فرق) اور Zsh۔ ذیل میں ہم ان تمام اختیارات کو دیکھیں گے۔

لینکس پر باش

Bash تکمیل اسکرپٹ bash-completion پیکیج پر منحصر ہے، لہذا آپ کو اسے پہلے انسٹال کرنے کی ضرورت ہے:

$ sudo apt-get install bash-completion

: Или

$ yum install bash-completion

آپ مندرجہ ذیل کمانڈ کا استعمال کرتے ہوئے جانچ کر سکتے ہیں کہ پیکیج کامیابی سے انسٹال ہوا ہے۔

$ type _init_completion

اگر یہ شیل فنکشن کوڈ کو آؤٹ کرتا ہے، تو bash-completion صحیح طریقے سے انسٹال ہے۔ اگر کمانڈ "نہیں ملا" غلطی دیتی ہے، تو آپ کو اپنی فائل میں درج ذیل لائن شامل کرنے کی ضرورت ہے۔ ~ / .bashrc:

$ source /usr/share/bash-completion/bash_completion

کیا اس لائن کو فائل میں شامل کرنا ضروری ہے؟ ~ / .bashrc یا نہیں اس کا انحصار اس پیکیج مینیجر پر ہے جسے آپ bash-completion انسٹال کرنے کے لیے استعمال کرتے تھے۔ یہ APT کے لیے ضروری ہے، لیکن YUM کے لیے نہیں۔

bash-completion انسٹال کرنے کے بعد، آپ کو ہر چیز کو کنفیگر کرنے کی ضرورت ہے تاکہ kubectl تکمیل اسکرپٹ کو تمام شیل سیشنز میں فعال کیا جائے۔

ایسا کرنے کا ایک طریقہ درج ذیل لائن کو فائل میں شامل کرنا ہے۔ ~ / .bashrc:

source <(kubectl completion bash)

دوسرا طریقہ یہ ہے کہ ڈائرکٹری میں kubectl ایکسٹینشن اسکرپٹ شامل کریں۔ /etc/bash_completion.d (اگر یہ موجود نہیں ہے تو اسے بنائیں):

$ kubectl completion bash >/etc/bash_completion.d/kubectl

کیٹلاگ میں تمام ایڈ آن اسکرپٹس /etc/bash_completion.d خود بخود bash-completion میں شامل ہیں۔

دونوں اختیارات یکساں طور پر لاگو ہوتے ہیں۔

شیل کو دوبارہ شروع کرنے کے بعد، kubectl کمانڈ کی تکمیل کام کرے گی۔

MacOS پر باش

MacOS پر سیٹ اپ تھوڑا زیادہ پیچیدہ ہے۔ حقیقت یہ ہے کہ پہلے سے طے شدہ طور پر، MacOS Bash ورژن 3.2 استعمال کرتا ہے، اور kubectl آٹوکمپلیشن اسکرپٹ کے لیے کم از کم 4.1 کے Bash ورژن کی ضرورت ہوتی ہے اور یہ Bash 3.2 میں کام نہیں کرتا ہے۔

MacOS پر Bash کا پرانا ورژن استعمال کرنے سے متعلق لائسنسنگ کے مسائل ہیں۔ Bash ورژن 4 GPLv3 کے تحت لائسنس یافتہ ہے، جو Apple کے ذریعے تعاون یافتہ نہیں ہے۔

MacOS پر kubectl autocompletion کو کنفیگر کرنے کے لیے، آپ کو Bash کا تازہ ترین ورژن انسٹال کرنا ہوگا۔ آپ اپڈیٹ شدہ باش کو اپنے ڈیفالٹ شیل کے طور پر بھی سیٹ کر سکتے ہیں، جو آپ کو مستقبل میں بہت سی پریشانیوں سے بچائے گا۔ یہ مشکل نہیں، تفصیل مضمون میں دی گئی ہے۔MacOS پر Bash کو اپ ڈیٹ کرنا'.

جاری رکھنے سے پہلے، یقینی بنائیں کہ آپ Bash کا حالیہ ورژن استعمال کر رہے ہیں (آؤٹ پٹ چیک کریں۔ bash --version).

Bash تکمیل اسکرپٹ پروجیکٹ کے لحاظ سے مختلف ہوتی ہے۔ bash - تکمیل، لہذا آپ کو پہلے اسے انسٹال کرنے کی ضرورت ہے۔

آپ استعمال کرکے bash-completion انسٹال کرسکتے ہیں۔ ہومبرو:

$ brew install bash-completion@2

یہاں @2 bash-completion ورژن 2 کا مطلب ہے۔ kubectl آٹوکمپلیشن کے لیے bash-completion v2 کی ضرورت ہوتی ہے، اور bash-completion v2 کے لیے کم از کم Bash ورژن 4.1 کی ضرورت ہوتی ہے۔

کمانڈ آؤٹ پٹ brew-install ایک Caveats سیکشن پر مشتمل ہے، جو بتاتا ہے کہ فائل میں کیا شامل کرنے کی ضرورت ہے۔ ~/.bash_profile:

export BASH_COMPLETION_COMPAT_DIR=/usr/local/etc/bash_completion.d
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . 
"/usr/local/etc/profile.d/bash_completion.sh"

تاہم، میں ان لائنوں کو شامل نہ کرنے کی تجویز کرتا ہوں۔ ~/.bash_profileاور اندر ~/.bashrc. اس صورت میں، خودکار تکمیل نہ صرف مین میں، بلکہ چائلڈ کمانڈ شیلز میں بھی دستیاب ہوگی۔

کمانڈ شیل کو دوبارہ شروع کرنے کے بعد، آپ مندرجہ ذیل کمانڈ کا استعمال کرکے تصدیق کر سکتے ہیں کہ انسٹالیشن درست ہے:

$ type _init_completion

اگر آپ آؤٹ پٹ میں شیل فنکشن دیکھتے ہیں، تو سب کچھ صحیح طریقے سے ترتیب دیا گیا ہے.

اب ہمیں یہ یقینی بنانے کی ضرورت ہے کہ kubectl خودکار تکمیل تمام سیشنز میں فعال ہے۔

ایک طریقہ یہ ہے کہ درج ذیل لائن کو اپنے میں شامل کریں۔ ~/.bashrc:

source <(kubectl completion bash)

دوسرا طریقہ یہ ہے کہ فولڈر میں خودکار اسکرپٹ شامل کریں۔ /usr/local/etc/bash_completion.d:

$ kubectl completion bash
>/usr/local/etc/bash_completion.d/kubectl

یہ طریقہ صرف اس صورت میں کام کرے گا جب آپ ہومبریو کا استعمال کرتے ہوئے bash-completion انسٹال کریں۔ اس صورت میں، bash-completion اس ڈائریکٹری سے تمام اسکرپٹس کو لوڈ کرتا ہے۔

اگر آپ انسٹال کرتے ہیں۔ ہومبریو کا استعمال کرتے ہوئے کیوبیکٹل، پھر پچھلے مرحلے کو انجام دینے کی ضرورت نہیں ہے، کیونکہ خودکار تکمیل اسکرپٹ خود بخود فولڈر میں رکھ دی جائے گی۔ /usr/local/etc/bash_completion.d تنصیب کے دوران. اس صورت میں، kubectl autocompletion جیسے ہی آپ bash-completion انسٹال کریں گے کام کرنا شروع کر دے گا۔

نتیجے کے طور پر، یہ تمام اختیارات برابر ہیں.

زش

Zsh کے لیے خودکار تکمیل اسکرپٹ کو کسی انحصار کی ضرورت نہیں ہے۔ جب آپ کمانڈ شیل لوڈ کرتے ہیں تو آپ کو ان کو فعال کرنے کی ضرورت ہے۔

آپ اپنے میں ایک لائن شامل کرکے ایسا کرسکتے ہیں۔ ~/.zshrc فائل:

source <(kubectl completion zsh)

اگر آپ کو کوئی غلطی موصول ہوتی ہے۔ not found: compdef اپنے شیل کو دوبارہ شروع کرنے کے بعد، آپ کو بلٹ ان فنکشن کو فعال کرنے کی ضرورت ہے۔ compdef. آپ اسے اپنی فائل کے شروع میں شامل کرکے اسے فعال کرسکتے ہیں۔ ~/.zshrc مندرجہ ذیل:

autoload -Uz compinit
compinit

2. وسائل کی تفصیلات کو جلدی سے دیکھیں

جب آپ YAML وسائل کی تعریفیں بناتے ہیں، تو آپ کو ان وسائل کے لیے فیلڈز اور ان کے معنی جاننے کی ضرورت ہوتی ہے۔ اس معلومات کو تلاش کرنے کے لیے ایک جگہ API ریفرنس میں ہے، جس میں تمام وسائل کے لیے مکمل وضاحتیں شامل ہیں۔

تاہم، جب بھی آپ کو کسی چیز کی تلاش کرنے کی ضرورت ہو ویب براؤزر پر سوئچ کرنا تکلیف دہ ہے۔ لہذا kubectl کمانڈ فراہم کرتا ہے۔ kubectl explain، جو آپ کے ٹرمینل میں تمام وسائل کی وضاحتیں دکھاتا ہے۔

کمانڈ فارمیٹ مندرجہ ذیل ہے:

$ kubectl explain resource[.field]...

کمانڈ درخواست کردہ وسائل یا فیلڈ کی تفصیلات کو آؤٹ پٹ کرے گی۔ ظاہر کی گئی معلومات API مینول میں موجود معلومات سے ملتی جلتی ہے۔

умолчанию По kubectl explain کھیتوں کے گھونسلے کی صرف پہلی سطح کو ظاہر کرتا ہے۔

دیکھیں کہ یہ کیسا لگتا ہے۔ یہاں ہو سکتا ہے.

اگر آپ اختیار شامل کرتے ہیں تو آپ پورے درخت کو ظاہر کرسکتے ہیں۔ --recursive:

$ kubectl explain deployment.spec --recursive

اگر آپ بالکل نہیں جانتے کہ کن وسائل کی ضرورت ہے، تو آپ ان سب کو درج ذیل کمانڈ کے ساتھ ڈسپلے کر سکتے ہیں۔

$ kubectl api-resources

یہ کمانڈ وسائل کے نام جمع شکل میں دکھاتا ہے، جیسے deployments کے بجائے deployment. یہ مختصر نام بھی دکھاتا ہے، مثال کے طور پر deployان وسائل کے لیے جن کے پاس یہ ہے۔ ان اختلافات کی فکر نہ کریں۔ نام دینے کے یہ تمام اختیارات kubectl کے برابر ہیں۔ یعنی آپ ان میں سے کسی کو بھی استعمال کر سکتے ہیں۔ kubectl explain.

درج ذیل تمام کمانڈز برابر ہیں:

$ kubectl explain deployments.spec
# или
$ kubectl explain deployment.spec
# или        
$ kubectl explain deploy.spec

3. حسب ضرورت کالم آؤٹ پٹ فارمیٹ استعمال کریں۔

ڈیفالٹ کمانڈ آؤٹ پٹ فارمیٹ kubectl get:

$ kubectl get pods
NAME                     READY    STATUS    RESTARTS  AGE
engine-544b6b6467-22qr6   1/1     Running     0       78d
engine-544b6b6467-lw5t8   1/1     Running     0       78d
engine-544b6b6467-tvgmg   1/1     Running     0       78d
web-ui-6db964458-8pdw4    1/1     Running     0       78d

یہ فارمیٹ آسان ہے، لیکن اس میں معلومات کی ایک محدود مقدار شامل ہے۔ مکمل وسائل کی تعریف کی شکل کے مقابلے میں، یہاں صرف چند فیلڈز دکھائے گئے ہیں۔

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

حسب ضرورت فارمیٹ کے استعمال کا تعین اختیارات کے ذریعے کیا جاتا ہے:

-o custom-columns=<header>:<jsonpath>[,<header>:<jsonpath>]...

آپ ہر آؤٹ پٹ کالم کو ایک جوڑے کے طور پر بیان کر سکتے ہیں۔ <header>:<jsonpath>جہاں <header> کالم کا نام ہے، اور <jsonpath> - وسائل کے میدان کی وضاحت کرنے والا ایک اظہار۔

آئیے ایک سادہ مثال دیکھیں:

$ kubectl get pods -o custom-columns='NAME:metadata.name'

NAME
engine-544b6b6467-22qr6
engine-544b6b6467-lw5t8
engine-544b6b6467-tvgmg
web-ui-6db964458-8pdw4

آؤٹ پٹ میں پوڈز کے ناموں کے ساتھ ایک کالم ہوتا ہے۔

آپشن ایکسپریشن فیلڈ سے پوڈ کے ناموں کو منتخب کرتا ہے۔ metadata.name. اس کی وجہ یہ ہے کہ پوڈ کا نام بچے کے نام کے خانے میں بیان کیا گیا ہے۔ metadata پوڈ کے وسائل کی تفصیل میں۔ مزید تفصیلات میں مل سکتی ہیں۔ API گائیڈ یا کمانڈ ٹائپ کریں۔ kubectl explain pod.metadata.name.

اب ہم کہتے ہیں کہ آپ آؤٹ پٹ میں ایک اضافی کالم شامل کرنا چاہتے ہیں، مثال کے طور پر ہر پوڈ پر چلنے والے نوڈ کو دکھانا۔ ایسا کرنے کے لیے، آپ اپنی مرضی کے کالم کے اختیار میں مناسب کالم کی تفصیلات شامل کر سکتے ہیں:

$ kubectl get pods 
  -o custom-columns='NAME:metadata.name,NODE:spec.nodeName'

NAME                       NODE
engine-544b6b6467-22qr6    ip-10-0-80-67.ec2.internal
engine-544b6b6467-lw5t8    ip-10-0-36-80.ec2.internal
engine-544b6b6467-tvgmg    ip-10-0-118-34.ec2.internal
web-ui-6db964458-8pdw4     ip-10-0-118-34.ec2.internal

اظہار نوڈ کا نام منتخب کرتا ہے۔ spec.nodeName - جب ایک پوڈ نوڈ کو تفویض کیا جاتا ہے، تو اس کا نام فیلڈ میں لکھا جاتا ہے۔ spec.nodeName پوڈ وسائل کی تفصیلات. آؤٹ پٹ میں مزید تفصیلی معلومات مل سکتی ہیں۔ kubectl explain pod.spec.nodeName.

براہ کرم نوٹ کریں کہ Kubernetes ریسورس فیلڈز کیس حساس ہیں۔

آپ کسی بھی ریسورس فیلڈ کو بطور کالم دیکھ سکتے ہیں۔ بس وسائل کی تفصیلات کا جائزہ لیں اور اپنی پسند کے کسی بھی فیلڈ کے ساتھ اسے آزمائیں۔

لیکن پہلے، آئیے فیلڈ سلیکشن ایکسپریشنز پر گہری نظر ڈالیں۔

JSONPath اظہارات

وسائل کے شعبوں کو منتخب کرنے کے اظہار پر مبنی ہیں۔ JSONPath.

JSONPath JSON دستاویزات سے ڈیٹا بازیافت کرنے کی زبان ہے۔ JSONPath کے لیے کسی ایک فیلڈ کا انتخاب کرنا سب سے آسان استعمال ہے۔ اس کے پاس بہت کچھ ہے۔ مزید امکاناتسلیکٹرز، فلٹرز وغیرہ سمیت۔

Kubectl وضاحت محدود تعداد میں JSONPath خصوصیات کی حمایت کرتا ہے۔ ان کے استعمال کے امکانات اور مثالیں ذیل میں بیان کی گئی ہیں۔

# Выбрать все элементы списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[*].image'
# Выбрать специфический элемент списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[0].image'
# Выбрать элементы списка, попадающие под фильтр
$ kubectl get pods -o custom-columns='DATA:spec.containers[?(@.image!="nginx")].image'
# Выбрать все поля по указанному пути, независимо от их имени
$ kubectl get pods -o custom-columns='DATA:metadata.*'
# Выбрать все поля с указанным именем, вне зависимости от их расположения
$ kubectl get pods -o custom-columns='DATA:..image'

آپریٹر خاص طور پر اہم ہے۔ بہت سے Kubernetes ریسورس فیلڈز کی فہرستیں ہیں، اور یہ آپریٹر آپ کو ان فہرستوں کے ممبران کو منتخب کرنے کی اجازت دیتا ہے۔ فہرست کے تمام عناصر کو منتخب کرنے کے لیے یہ اکثر وائلڈ کارڈ جیسے [*] کے ساتھ استعمال ہوتا ہے۔

درخواست کی مثالیں

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

پھلیوں کے لیے کنٹینر کی تصاویر کی نمائش:
```
$ kubectl get pods 
  -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

NAME                        IMAGES
engine-544b6b6467-22qr6     rabbitmq:3.7.8-management,nginx
engine-544b6b6467-lw5t8     rabbitmq:3.7.8-management,nginx
engine-544b6b6467-tvgmg     rabbitmq:3.7.8-management,nginx
web-ui-6db964458-8pdw4      wordpress
```
یہ کمانڈ ہر پوڈ کے لیے کنٹینر کی تصویر کے نام دکھاتا ہے۔

یاد رکھیں کہ ایک پوڈ کئی کنٹینرز پر مشتمل ہو سکتا ہے، پھر تصویر کے نام کوما سے الگ کرکے ایک لائن پر دکھائے جائیں گے۔
نوڈ کی دستیابی کے زونز کی نمائش:
```
$ kubectl get nodes 
  -o 
custom-columns='NAME:metadata.name,ZONE:metadata.labels.failure-domain.beta.kubernetes.io/zone'

NAME                          ZONE
ip-10-0-118-34.ec2.internal   us-east-1b
ip-10-0-36-80.ec2.internal    us-east-1a
ip-10-0-80-67.ec2.internal    us-east-1b
```
یہ کمانڈ مفید ہے اگر آپ کا کلسٹر عوامی کلاؤڈ میں ہوسٹ کیا گیا ہو۔ یہ ہر نوڈ کے لیے دستیابی زون دکھاتا ہے۔

دستیابی زون ایک کلاؤڈ تصور ہے جو نقل کے زون کو جغرافیائی علاقے تک محدود کرتا ہے۔

ہر نوڈ کے لیے دستیابی زونز ایک خاص لیبل کے ذریعے حاصل کیے جاتے ہیں۔ failure-domain.beta.kubernetes.io/zone. اگر کلسٹر عوامی کلاؤڈ میں چل رہا ہے، تو یہ لیبل خود بخود بن جاتا ہے اور ہر نوڈ کے لیے دستیابی زون کے ناموں سے بھر جاتا ہے۔

لیبلز Kubernetes وسائل کی تفصیلات کا حصہ نہیں ہیں، لہذا آپ کو ان کے بارے میں معلومات اس میں نہیں ملے گی۔ API گائیڈ. تاہم، اگر آپ YAML یا JSON فارمیٹ میں نوڈس کے بارے میں معلومات کی درخواست کرتے ہیں تو وہ (کسی دوسرے لیبل کی طرح) دیکھے جا سکتے ہیں:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
یہ وسائل کی تفصیلات سیکھنے کے علاوہ وسائل کے بارے میں مزید جاننے کا ایک بہترین طریقہ ہے۔

4. کلسٹرز اور نام کی جگہوں کے درمیان آسانی سے سوئچ کریں۔

جب kubectl Kubernetes API سے درخواست کرتا ہے، تو یہ سب سے پہلے kubeconfig فائل کو پڑھتا ہے تاکہ کنکشن کے لیے تمام ضروری پیرامیٹرز حاصل کیے جاسکیں۔

پہلے سے طے شدہ طور پر kubeconfig فائل ہے۔ ~/.kube/config. عام طور پر یہ فائل ایک خاص کمانڈ کے ذریعے بنائی یا اپ ڈیٹ کی جاتی ہے۔

جب آپ ایک سے زیادہ کلسٹرز کے ساتھ کام کرتے ہیں، تو آپ کی kubeconfig فائل میں ان تمام کلسٹرز سے منسلک ہونے کی ترتیبات ہوتی ہیں۔ آپ کو kubectl کمانڈ کو بتانے کا طریقہ درکار ہے کہ آپ کس کلسٹر کے ساتھ کام کر رہے ہیں۔

ایک کلسٹر کے اندر، آپ متعدد نام کی جگہیں بنا سکتے ہیں—ایک قسم کا ورچوئل کلسٹر ایک فزیکل کلسٹر کے اندر۔ Kubectl یہ بھی طے کرتا ہے کہ kubeconfig فائل کی بنیاد پر کون سی نام کی جگہ استعمال کرنی ہے۔ اس کا مطلب ہے کہ آپ کو kubectl کمانڈ کو بتانے کا طریقہ بھی درکار ہے کہ کس نام کی جگہ کے ساتھ کام کرنا ہے۔

اس باب میں ہم یہ بتائیں گے کہ یہ کیسے کام کرتا ہے اور اسے مؤثر طریقے سے کیسے کام کرنا ہے۔

نوٹ کریں کہ آپ کے پاس متعدد kubeconfig فائلیں KUBECONFIG ماحولیاتی متغیر میں درج ہو سکتی ہیں۔ اس صورت میں، ان تمام فائلوں کو رن ٹائم کے وقت ایک مشترکہ کنفیگریشن میں ملا دیا جائے گا۔ آپ پیرامیٹر کے ساتھ kubectl چلا کر ڈیفالٹ kubeconfig فائل کو بھی تبدیل کر سکتے ہیں۔ --kubeconfig. دیکھو سرکاری دستاویزات.

kubeconfig فائلیں

آئیے دیکھتے ہیں کہ kubeconfig فائل میں بالکل کیا شامل ہے:

جیسا کہ آپ دیکھ سکتے ہیں، kubeconfig فائل میں سیاق و سباق کا ایک سیٹ ہوتا ہے۔ سیاق و سباق تین عناصر پر مشتمل ہے:

کلسٹر — کلسٹر سرور کا API URL۔
صارف - کلسٹر میں صارف کی تصدیق کی اسناد۔
نام کی جگہ - کلسٹر میں شامل ہونے پر استعمال ہونے والی نام کی جگہ۔

عملی طور پر، وہ اکثر اپنے kubeconfig میں فی کلسٹر ایک سیاق و سباق استعمال کرتے ہیں۔ تاہم، آپ کے پاس فی کلسٹر متعدد سیاق و سباق ہو سکتے ہیں، صارف یا نام کی جگہ کے لحاظ سے مختلف۔ تاہم، یہ کثیر سیاق و سباق کی ترتیب غیر معمولی ہے، اس لیے عام طور پر کلسٹرز اور سیاق و سباق کے درمیان ون ٹو ون میپنگ ہوتی ہے۔

کسی بھی وقت، سیاق و سباق میں سے ایک موجودہ ہے:

جب kubectl ایک کنفیگریشن فائل پڑھتا ہے، تو یہ ہمیشہ موجودہ سیاق و سباق سے معلومات لیتا ہے۔ اوپر کی مثال میں، kubectl Hare کلسٹر سے جڑ جائے گا۔

اس کے مطابق، دوسرے کلسٹر میں جانے کے لیے، آپ کو kubeconfig فائل میں موجودہ سیاق و سباق کو تبدیل کرنے کی ضرورت ہے:

اب kubectl فاکس کلسٹر سے جڑ جائے گا۔

ایک ہی کلسٹر میں مختلف نام کی جگہ پر جانے کے لیے، آپ کو موجودہ سیاق و سباق کے لیے نام کی جگہ کے عنصر کی قدر کو تبدیل کرنے کی ضرورت ہے:

مندرجہ بالا مثال میں، kubectl فاکس کلسٹر کی پروڈ نیم اسپیس استعمال کرے گا (پہلے ٹیسٹ نام کی جگہ سیٹ کی گئی تھی)۔

نوٹ کریں کہ kubectl اختیارات بھی فراہم کرتا ہے۔ --cluster, --user, --namespace и --context، جو آپ کو انفرادی عناصر اور خود موجودہ سیاق و سباق کو اوور رائٹ کرنے کی اجازت دیتا ہے، قطع نظر اس کے کہ kubeconfig میں کیا سیٹ ہے۔ دیکھو kubectl options.

نظریہ میں، آپ kubeconfig میں ترتیبات کو دستی طور پر تبدیل کر سکتے ہیں۔ لیکن یہ تکلیف دہ ہے۔ ان کارروائیوں کو آسان بنانے کے لیے، مختلف افادیتیں ہیں جو آپ کو پیرامیٹرز کو خود بخود تبدیل کرنے کی اجازت دیتی ہیں۔

kubectx استعمال کریں۔

کلسٹرز اور نام کی جگہوں کے درمیان سوئچ کرنے کے لیے ایک بہت مقبول افادیت۔

یوٹیلیٹی کمانڈ فراہم کرتی ہے۔ kubectx и kubens موجودہ سیاق و سباق اور نام کی جگہ کو بالترتیب تبدیل کرنے کے لیے۔

جیسا کہ ذکر کیا گیا ہے، موجودہ سیاق و سباق کو تبدیل کرنے کا مطلب ہے کلسٹر کو تبدیل کرنا اگر آپ کے پاس فی کلسٹر صرف ایک سیاق و سباق ہے۔

ان کمانڈز کو چلانے کی ایک مثال یہ ہے:

بنیادی طور پر، یہ کمانڈز صرف kubeconfig فائل میں ترمیم کرتی ہیں جیسا کہ اوپر بیان کیا گیا ہے۔

نصب کرنے کے لئے kubectxپر دی گئی ہدایات پر عمل کریں۔ گیتوب.

دونوں کمانڈز سیاق و سباق اور نام کی جگہ کے ناموں کی خودکار تکمیل کی حمایت کرتے ہیں، جو انہیں مکمل طور پر ٹائپ کرنے کی ضرورت کو ختم کر دیتا ہے۔ خودکار تکمیل کو ترتیب دینے کے لیے ہدایات یہاں.

ایک اور مفید خصوصیت kubectx ہے انٹرایکٹو موڈ. یہ افادیت کے ساتھ مل کر کام کرتا ہے۔ FZF، جو الگ سے انسٹال ہونا ضروری ہے۔ fzf انسٹال کرنے سے خود بخود انٹرایکٹو موڈ دستیاب ہوجاتا ہے۔ kubectx. انٹرایکٹو طور پر، آپ fzf کے فراہم کردہ انٹرایکٹو فری سرچ انٹرفیس کے ذریعے سیاق و سباق اور نام کی جگہ کا انتخاب کر سکتے ہیں۔

شیل عرفی ناموں کا استعمال

موجودہ سیاق و سباق اور نام کی جگہ کو تبدیل کرنے کے لیے آپ کو علیحدہ ٹولز کی ضرورت نہیں ہے کیونکہ kubectl اس کے لیے کمانڈ بھی فراہم کرتا ہے۔ جی ہاں، ٹیم kubectl config kubeconfig فائلوں میں ترمیم کے لیے ذیلی کمانڈ فراہم کرتا ہے۔

یہاں ان میں سے کچھ یہ ہیں:

kubectl config get-contexts: تمام سیاق و سباق کو ظاہر کریں؛
kubectl config current-context: موجودہ سیاق و سباق حاصل کریں؛
kubectl config use-context: موجودہ سیاق و سباق کو تبدیل کریں؛
kubectl config set-context: سیاق و سباق کے عنصر کو تبدیل کریں۔

تاہم، ان کمانڈز کو براہ راست استعمال کرنا زیادہ آسان نہیں ہے کیونکہ وہ طویل ہیں۔ آپ ان کے لیے شیل عرفی نام بنا سکتے ہیں جن پر عمل کرنا آسان ہے۔

میں نے ان کمانڈز کی بنیاد پر عرفی ناموں کا ایک سیٹ بنایا ہے جو kubectx جیسی فعالیت فراہم کرتے ہیں۔ یہاں آپ انہیں کارروائی میں دیکھ سکتے ہیں:

نوٹ کریں کہ عرفی متعامل فری تلاش انٹرفیس (جیسے kubectx کا انٹرایکٹو موڈ) فراہم کرنے کے لیے fzf کا استعمال کرتے ہیں۔ اس کا مطلب ہے کہ آپ کو ضرورت ہے۔ fzf انسٹال کریں۔ان عرفی ناموں کو استعمال کرنے کے لیے۔

خود عرفی کی تعریفیں یہ ہیں:

# Получить текущий контекст
alias krc='kubectl config current-context'
# Список всех контекстов
alias klc='kubectl config get-contexts -o name | sed "s/^/  /;|^  $(krc)$|s/ /*/"'
# Изменить текущий контекст
alias kcc='kubectl config use-context "$(klc | fzf -e | sed "s/^..//")"'

# Получить текущее пространство имен
alias krn='kubectl config get-contexts --no-headers "$(krc)" | awk "{print $5}" | sed "s/^$/default/"'
# Список всех пространств имен
alias kln='kubectl get -o name ns | sed "s|^.*/|  |;|^  $(krn)$|s/ /*/"'
# Изменить текущее пространство имен
alias kcn='kubectl config set-context --current --namespace "$(kln | fzf -e | sed "s/^..//")"'

ان عرفی ناموں کو سیٹ کرنے کے لیے آپ کو اپنی فائل میں مندرجہ بالا تعریفیں شامل کرنے کی ضرورت ہے۔ ~/.bashrc یا ~/.zshrc اور اپنے شیل کو دوبارہ شروع کریں۔

پلگ ان کا استعمال

Kubectl آپ کو ایسے پلگ ان لوڈ کرنے کی اجازت دیتا ہے جو بنیادی کمانڈز کی طرح عمل میں آتے ہیں۔ آپ، مثال کے طور پر، kubectl-foo پلگ ان انسٹال کر سکتے ہیں اور کمانڈ پر عمل کر کے اسے چلا سکتے ہیں۔ kubectl foo.

اس طرح سیاق و سباق اور نام کی جگہ کو تبدیل کرنا آسان ہوگا، مثال کے طور پر چلا کر kubectl ctx سیاق و سباق کو تبدیل کرنے اور kubectl ns نام کی جگہ کو تبدیل کرنے کے لیے۔

میں نے دو پلگ ان لکھے ہیں جو ایسا کرتے ہیں:

پلگ ان کا کام پچھلے حصے کے عرفی ناموں پر مبنی ہے۔

یہاں یہ ہے کہ وہ کیسے کام کرتے ہیں:

نوٹ کریں کہ پلگ ان ایک انٹرایکٹو فری سرچ انٹرفیس (جیسے kubectx کا انٹرایکٹو موڈ) فراہم کرنے کے لیے fzf کا استعمال کرتے ہیں۔ اس کا مطلب ہے کہ آپ کو ضرورت ہے۔ fzf انسٹال کریں۔ان عرفی ناموں کو استعمال کرنے کے لیے۔

پلگ ان انسٹال کرنے کے لیے، آپ کو شیل اسکرپٹس کو ڈاؤن لوڈ کرنے کی ضرورت ہے۔ kubectl-ctx и kubectl-ns اپنے PATH متغیر میں کسی بھی ڈائرکٹری میں اور ان کو قابل عمل بنائیں جیسے chmod +x. اس کے فوراً بعد آپ استعمال کر سکیں گے۔ kubectl ctx и kubectl ns.

5. autoaliases کے ساتھ ان پٹ کو کم کریں۔

شیل عرفی نام ٹائپنگ کو تیز کرنے کا ایک اچھا طریقہ ہے۔ پروجیکٹ kubectl-عرف بنیادی kubectl کمانڈز کے لیے تقریباً 800 شارٹ کٹس پر مشتمل ہے۔

آپ سوچ رہے ہوں گے - آپ کو 800 عرفی نام کیسے یاد ہیں؟ لیکن آپ کو ان سب کو یاد رکھنے کی ضرورت نہیں ہے، کیونکہ وہ ایک سادہ اسکیم کے مطابق بنائے گئے ہیں، جو ذیل میں دی گئی ہے۔

مثال کے طور پر:

kgpooyaml - kubectl get pods oyaml
ksysgsvcw — kubectl -n kube-system get svc w
ksysrmcm -kubectl -n kube-system rm cm
kgdepalsl - kubectl حاصل کریں تعیناتی تمام sl

جیسا کہ آپ دیکھ سکتے ہیں، عرفی نام اجزاء پر مشتمل ہوتے ہیں، جن میں سے ہر ایک kubectl کمانڈ کے مخصوص عنصر کی نمائندگی کرتا ہے۔ ہر عرف میں بیس کمانڈ، آپریشن، اور وسائل کے لیے ایک جزو اور پیرامیٹرز کے لیے متعدد اجزاء ہوسکتے ہیں۔ اوپر دیے گئے خاکے کے مطابق آپ ان اجزاء کو بائیں سے دائیں آسانی سے "آباد" کرتے ہیں۔

موجودہ تفصیلی خاکہ پر ہے۔ GitHub کے. وہاں آپ بھی ڈھونڈ سکتے ہیں۔ عرفی ناموں کی مکمل فہرست.

مثال کے طور پر، عرف kgpooyamlall کمانڈ کے برابر ہے۔ kubectl get pods -o yaml --all-namespaces.

اختیارات کا رشتہ دار ترتیب اہم نہیں ہے: کمانڈ kgpooyamlall حکم کے برابر ہے۔ kgpoalloyaml.

آپ کو تمام اجزاء کو عرف کے طور پر استعمال کرنے کی ضرورت نہیں ہے۔ مثال کے طور پر k, kg, klo, ksys, kgpo بھی استعمال کیا جا سکتا ہے. مزید یہ کہ، آپ کمانڈ لائن پر عرفی نام اور باقاعدہ کمانڈز یا اختیارات کو یکجا کر سکتے ہیں:

مثال کے طور پر:

اس کے بجائے kubectl proxy تم لکھ سکتے ہو k proxy.
اس کے بجائے kubectl get roles تم لکھ سکتے ہو kg roles (رولز ریسورس کے لیے فی الحال کوئی عرف نہیں ہے)۔
کسی مخصوص پوڈ کے لیے ڈیٹا حاصل کرنے کے لیے، آپ کمانڈ استعمال کر سکتے ہیں۔ kgpo my-pod — kubectl get pod my-pod.

براہ کرم نوٹ کریں کہ کچھ عرفی ناموں کے لیے کمانڈ لائن دلیل کی ضرورت ہوتی ہے۔ مثال کے طور پر عرف kgpol کا مطلب ہے کہ kubectl get pods -l. آپشن -l ایک دلیل کی ضرورت ہے - ایک لیبل کی تفصیلات۔ اگر آپ ایک عرف استعمال کرتے ہیں تو ایسا نظر آئے گا۔ kgpol app=ui.

چونکہ کچھ عرفی ناموں کے لیے دلائل کی ضرورت ہوتی ہے، عرف a، f، اور l کو آخری استعمال کرنا چاہیے۔

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

تنصیب۔

kubectl-aliases کو انسٹال کرنے کے لیے، آپ کو فائل ڈاؤن لوڈ کرنے کی ضرورت ہے۔ .kubectl_aliases GitHub سے اور اسے فائل میں شامل کریں۔ ~/.bashrc یا ~/.zshrc:

source ~/.kubectl_aliases

خودکار تکمیل

جیسا کہ ہم نے پہلے کہا، آپ اکثر کمانڈ لائن پر کسی عرف میں اضافی الفاظ شامل کرتے ہیں۔ مثال کے طور پر:

$ kgpooyaml test-pod-d4b77b989

اگر آپ kubectl کمانڈ کی تکمیل کا استعمال کرتے ہیں، تو آپ نے ممکنہ طور پر وسائل کے ناموں جیسی چیزوں کے لیے خودکار تکمیل کا استعمال کیا ہے۔ لیکن جب عرفی نام استعمال کیے جائیں تو کیا ایسا کیا جا سکتا ہے؟

یہ ایک بہت اہم سوال ہے کیونکہ اگر خودکار تکمیل کام نہیں کرتی ہے، تو آپ عرفی نام کے کچھ فوائد سے محروم ہو جائیں گے۔

جواب اس بات پر منحصر ہے کہ آپ کون سا شیل استعمال کر رہے ہیں:

Zsh کے لیے، عرف کی تکمیل باکس سے باہر کام کرتی ہے۔
Bash کے لیے، بدقسمتی سے، کام کرنے کے لیے خودکار تکمیل حاصل کرنے کے لیے کچھ کام درکار ہے۔

Bash میں عرف کے لیے خودکار تکمیل کو فعال کرنا

Bash کے ساتھ مسئلہ یہ ہے کہ یہ عرف کو مکمل کرنے کی کوشش کرتا ہے (ہر بار جب آپ ٹیب کو دباتے ہیں)، نہ کہ وہ کمانڈ جس کا عرف سے مراد ہوتا ہے (جیسا کہ Zsh کرتا ہے، مثال کے طور پر)۔ چونکہ آپ کے پاس تمام 800 عرفی ناموں کے لیے تکمیلی اسکرپٹ نہیں ہیں، اس لیے خودکار تکمیل کام نہیں کرتی ہے۔

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

مندرجہ ذیل میں، میں پہلے وضاحت کروں گا کہ مکمل عرف کو کیسے انسٹال کیا جائے اور پھر اسے تمام kubectl عرفوں کی تکمیل کو فعال کرنے کے لیے کس طرح ترتیب دیا جائے۔

مکمل عرف انسٹال کرنا

سب سے پہلے، مکمل عرف پر منحصر ہے۔ bash - تکمیل. لہذا، مکمل عرف کو انسٹال کرنے سے پہلے، آپ کو یہ یقینی بنانا ہوگا کہ bash-completion انسٹال ہے۔ لینکس اور میک او ایس کے لیے انسٹالیشن کی ہدایات پہلے فراہم کی جا چکی ہیں۔

MacOS صارفین کے لیے اہم نوٹ: kubectl autocompletion اسکرپٹ کی طرح، مکمل عرف Bash 3.2 کے ساتھ کام نہیں کرتا، جو کہ MacOS پر ڈیفالٹ ہے۔ خاص طور پر، مکمل عرف کا انحصار bash-completion v2 پر ہوتا ہے (brew install bash-completion@2)، جس میں کم از کم Bash 4.1 کی ضرورت ہوتی ہے۔ اس کا مطلب ہے کہ MacOS پر مکمل عرف استعمال کرنے کے لیے آپ کو Bash کا نیا ورژن انسٹال کرنا ہوگا۔

آپ کو اسکرپٹ ڈاؤن لوڈ کرنے کی ضرورت ہے۔ bash_completion.sh کی GitHub ذخیرہ اور اسے اپنی فائل میں شامل کریں۔ ~/.bashrc:

source ~/bash_completion.sh

شیل کو ریبوٹ کرنے کے بعد، مکمل عرف مکمل طور پر انسٹال ہو جائے گا۔

kubectl عرف کے لیے خودکار تکمیل کو فعال کرنا

تکنیکی طور پر مکمل عرف ایک ریپر فنکشن فراہم کرتا ہے۔ _complete_alias. یہ فنکشن عرف کو چیک کرتا ہے اور عرف کمانڈ کے لیے تکمیل کے اشارے دیتا ہے۔

کسی فنکشن کو مخصوص عرف کے ساتھ منسلک کرنے کے لیے، آپ کو بلٹ ان باش میکانزم استعمال کرنے کی ضرورت ہے۔ مکمل، نصب کرنے کے لئے _complete_alias بطور عرف تکمیل فنکشن۔

مثال کے طور پر، عرف k لیتے ہیں، جس کا مطلب kubectl کمانڈ ہے۔ نصب کرنے کے لئے _complete_alias اس عرف کے لیے ایک تکمیلی فنکشن کے طور پر، آپ کو درج ذیل کمانڈ کو چلانا چاہیے:

$ complete -F _complete_alias k

اس کا نتیجہ یہ ہے کہ جب بھی آپ کسی عرف k کو خود بخود مکمل کرتے ہیں تو فنکشن کہا جاتا ہے۔ _complete_alias، جو عرف کو چیک کرتا ہے اور کمانڈ کے لئے تکمیل کے اشارے دیتا ہے۔ kubectl.

دوسری مثال کے طور پر، عرف کو لیتے ہیں۔ kg، جس کی نشاندہی کرتا ہے۔ kubectl get:

$ complete -F _complete_alias kg

بالکل پچھلی مثال کی طرح، جب آپ کلوگرام خودکار تکمیل کرتے ہیں، تو آپ کو تکمیل کے وہی اشارے ملتے ہیں جو آپ کو حاصل ہوں گے۔ kubectl get.

نوٹ کریں کہ آپ اپنے سسٹم پر کسی بھی عرف کے لیے مکمل عرف استعمال کر سکتے ہیں۔

لہذا، تمام kubectl عرفی ناموں کے لیے خودکار تکمیل کو فعال کرنے کے لیے، آپ کو ان میں سے ہر ایک کے لیے مندرجہ بالا کمانڈ چلانے کی ضرورت ہے۔ مندرجہ ذیل ٹکڑا بالکل ایسا ہی کرتا ہے، بشرطیکہ آپ نے kubectl-aliases کو سیٹ کیا ہو۔ ~/.kubectl-aliases:

for _a in $(sed '/^alias /!d;s/^alias //;s/=.*$//' ~/.kubectl_aliases); 
do
  complete -F _complete_alias "$_a"
done

کوڈ کا یہ ٹکڑا آپ کے میں رکھنے کی ضرورت ہے۔ ~/.bashrc، کمانڈ شیل کو دوبارہ شروع کریں اور خودکار تکمیل تمام 800 kubectl عرفوں کے لیے دستیاب ہو جائے گی۔

6. پلگ ان کے ساتھ کیوبیکٹل کو بڑھانا

سے شروع ورژن 1.12، kubectl کی حمایت کرتا ہے۔ پلگ ان میکانزم، جو آپ کو اضافی کمانڈز کے ساتھ اس کے افعال کو بڑھانے کی اجازت دیتا ہے۔

اگر آپ واقف ہیں۔ گٹ پلگ ان میکانزم، پھر kubectl پلگ ان اسی اصول پر بنائے گئے ہیں۔

اس باب میں، ہم اس بات کا احاطہ کریں گے کہ کس طرح پلگ ان انسٹال کرنا ہے، انہیں کہاں تلاش کرنا ہے، اور اپنے پلگ ان کیسے بنانا ہے۔

پلگ ان انسٹال کرنا

Kubectl پلگ ان کو سادہ ایگزیکیوٹیبل فائلوں کے بطور نام کے ساتھ تقسیم کیا جاتا ہے۔ kubectl-x. سابقہ kubectl- کی ضرورت ہے، اس کے بعد ایک نیا kubectl ذیلی کمانڈ جو آپ کو پلگ ان کو کال کرنے کی اجازت دیتا ہے۔

مثال کے طور پر، ہیلو پلگ ان کو ایک فائل کے طور پر تقسیم کیا جائے گا جسے کہا جاتا ہے kubectl-hello.

پلگ ان انسٹال کرنے کے لیے، آپ کو فائل کاپی کرنے کی ضرورت ہے۔ kubectl-x اپنے PATH میں کسی بھی ڈائرکٹری میں اور اسے قابل عمل بنائیں، مثال کے طور پر کے ساتھ chmod +x. اس کے فوراً بعد آپ پلگ ان کو کال کر سکتے ہیں۔ kubectl x.

آپ ان تمام پلگ ان کی فہرست بنانے کے لیے درج ذیل کمانڈ کا استعمال کر سکتے ہیں جو فی الحال آپ کے سسٹم پر انسٹال ہیں:

$ kubectl plugin list

یہ کمانڈ انتباہات کو بھی ظاہر کرے گا اگر آپ کے پاس ایک ہی نام کے متعدد پلگ ان ہیں، یا اگر کوئی پلگ ان فائل ہے جو قابل عمل نہیں ہے۔

کریو کا استعمال کرتے ہوئے پلگ ان تلاش کرنا اور انسٹال کرنا

Kubectl پلگ ان کو سافٹ ویئر پیکجز کی طرح شیئر یا دوبارہ استعمال کیا جا سکتا ہے۔ لیکن آپ کو پلگ ان کہاں سے مل سکتے ہیں جو دوسروں نے شیئر کیے ہیں؟

پروجیکٹ کریو kubectl پلگ ان کو شیئر کرنے، تلاش کرنے، انسٹال کرنے اور ان کا انتظام کرنے کے لیے ایک متحد حل فراہم کرنا ہے۔ پروجیکٹ خود کو "کیوبیکٹل پلگ ان کے لئے پیکیج مینیجر" کہتا ہے (کریو اس سے ملتا جلتا ہے مرکب).

Krew kubectl پلگ ان کی ایک فہرست ہے جسے آپ منتخب اور انسٹال کر سکتے ہیں۔ ایک ہی وقت میں، Krew بھی kubectl کے لیے ایک پلگ ان ہے۔

اس کا مطلب ہے کہ Krew کو انسٹال کرنا بنیادی طور پر کسی دوسرے kubectl پلگ ان کو انسٹال کرنے کی طرح کام کرتا ہے۔ آپ کو تفصیلی ہدایات پر مل سکتی ہیں۔ GitHub صفحہ.

سب سے اہم کریو کمانڈز ہیں:

# Поиск в списке плагинов
$ kubectl krew search [<query>]
# Посмотреть информацию о плагине
$ kubectl krew info <plugin>
# Установить плагин
$ kubectl krew install <plugin>
# Обновить все плагины до последней версии
$ kubectl krew upgrade
# Посмотреть все плагины, установленные через Krew
$ kubectl krew list
# Деинсталлировать плагин
$ kubectl krew remove <plugin>

براہ کرم نوٹ کریں کہ Krew کا استعمال کرتے ہوئے پلگ ان انسٹال کرنا اوپر بیان کردہ معیاری طریقہ استعمال کرتے ہوئے پلگ ان انسٹال کرنے میں مداخلت نہیں کرتا ہے۔

براہ کرم نوٹ کریں کہ کمانڈ kubectl krew list صرف پلگ ان دکھاتا ہے جو کریو کا استعمال کرتے ہوئے انسٹال کیے گئے تھے، جبکہ کمانڈ kubectl plugin list تمام پلگ انز کی فہرست بناتا ہے، یعنی وہ جو کریو کا استعمال کرتے ہوئے انسٹال ہوتے ہیں اور جو دوسرے طریقوں سے انسٹال ہوتے ہیں۔

کہیں اور پلگ ان تلاش کرنا

کریو ایک نوجوان پروجیکٹ ہے، جو اس وقت جاری ہے۔ فہرست صرف تقریباً 30 پلگ ان۔ اگر آپ اپنی ضرورت کی چیز نہیں ڈھونڈ سکتے ہیں، تو آپ کہیں اور پلگ ان تلاش کر سکتے ہیں، جیسے کہ GitHub۔

میں گٹ ہب سیکشن کو دیکھنے کی سفارش کرتا ہوں۔ kubectl-plugins. وہاں آپ کو درجنوں دستیاب پلگ ان ملیں گے جو دیکھنے کے قابل ہیں۔

اپنے پلگ ان لکھنا

آپ خود کر سکتے ہیں پلگ ان بنائیں - یہ مشکل نہیں ہے. آپ کو ایک ایگزیکیوٹیبل بنانے کی ضرورت ہے جو آپ کی ضرورت کے مطابق کرے، اسے نام دیں۔ kubectl-x اور اوپر بیان کے مطابق انسٹال کریں۔

فائل ایک bash اسکرپٹ، ایک python اسکرپٹ، یا ایک مرتب شدہ GO ایپلیکیشن ہوسکتی ہے - اس سے کوئی فرق نہیں پڑتا ہے۔ شرط صرف یہ ہے کہ اسے آپریٹنگ سسٹم میں براہ راست عمل میں لایا جا سکتا ہے۔

آئیے ابھی ایک مثال پلگ ان بنائیں۔ پچھلے حصے میں، آپ نے ہر پوڈ کے لیے کنٹینرز کی فہرست بنانے کے لیے kubectl کمانڈ کا استعمال کیا۔ اس کمانڈ کو پلگ ان میں تبدیل کرنا آسان ہے جسے آپ کال کر سکتے ہیں جیسے kubectl img.

ایک فائل بنائیں kubectl-img مندرجہ ذیل مواد:

#!/bin/bash
kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

اب اس کے ساتھ فائل کو قابل عمل بنائیں chmod +x kubectl-img اور اسے اپنے PATH میں کسی بھی ڈائرکٹری میں منتقل کریں۔ اس کے فوراً بعد آپ پلگ ان استعمال کر سکتے ہیں۔ kubectl img.

جیسا کہ ذکر کیا گیا ہے، kubectl پلگ ان کسی بھی پروگرامنگ یا اسکرپٹنگ زبان میں لکھے جا سکتے ہیں۔ اگر آپ شیل اسکرپٹ استعمال کر رہے ہیں تو پلگ ان کے اندر سے آسانی سے kubectl کو کال کرنے کے قابل ہونے کا فائدہ۔ تاہم، آپ حقیقی پروگرامنگ زبانوں کا استعمال کرتے ہوئے زیادہ پیچیدہ پلگ ان لکھ سکتے ہیں۔ Kubernetes کلائنٹ لائبریری. اگر آپ Go استعمال کر رہے ہیں تو آپ بھی استعمال کر سکتے ہیں۔ cli-رن ٹائم لائبریری، جو خاص طور پر kubectl پلگ ان لکھنے کے لیے موجود ہے۔

اپنے پلگ ان کا اشتراک کیسے کریں۔

اگر آپ کو لگتا ہے کہ آپ کے پلگ ان دوسروں کے لیے کارآمد ہو سکتے ہیں، تو بلا جھجھک اسے GitHub پر شیئر کریں۔ انہیں موضوع میں ضرور شامل کریں۔ kubectl-plugins.

آپ یہ بھی درخواست کر سکتے ہیں کہ آپ کا پلگ ان شامل کیا جائے۔ کریو کی فہرست. ایسا کرنے کے طریقے کے بارے میں ہدایات میں موجود ہیں۔ GitHub ذخیرے.

کمانڈ کی تکمیل

پلگ انز فی الحال خودکار تکمیل کو سپورٹ نہیں کرتے ہیں۔ یعنی آپ کو پلگ ان کا پورا نام اور دلائل کے مکمل نام درج کرنے چاہئیں۔

اس فنکشن کے لیے GitHub kubectl ذخیرہ ہے۔ کھلی درخواست. لہذا یہ ممکن ہے کہ یہ خصوصیت مستقبل میں کسی وقت نافذ ہو جائے۔

اچھی قسمت!!!

موضوع پر اور کیا پڑھنا ہے۔:

ماخذ: www.habr.com

kubectl کو زیادہ مؤثر طریقے سے استعمال کرنے کا طریقہ: ایک تفصیلی گائیڈ