پرو هوسٽر > بلاگ > انتظاميه > ڪبيڪٽل کي وڌيڪ مؤثر طريقي سان ڪيئن استعمال ڪجي: هڪ تفصيلي گائيڊ
ڪبيڪٽل کي وڌيڪ مؤثر طريقي سان ڪيئن استعمال ڪجي: هڪ تفصيلي گائيڊ
جيڪڏهن توهان ڪبرنيٽس سان ڪم ڪريو ٿا، ته پوءِ ڪبيڪٽل شايد انهن مان هڪ آهي جيڪا توهان استعمال ڪندا آهيو. ۽ جڏهن به توهان هڪ خاص اوزار سان ڪم ڪرڻ ۾ گهڻو وقت گذاريو ٿا، اهو ان کي سٺي نموني پڙهڻ ۽ ان کي مؤثر طريقي سان استعمال ڪرڻ سکو.
ٽيم Mail.ru کان Kubernetes aaS ڊينيل ويبل پاران هڪ آرٽيڪل ترجمو ڪيو جنهن ۾ توهان کي ڪبيڪٽل سان مؤثر طريقي سان ڪم ڪرڻ لاءِ صلاحون ۽ ترڪيبون ملنديون. اهو پڻ توهان جي مدد ڪندو Kubernetes جي گهڻي ڄاڻ حاصل ڪرڻ ۾.
ليکڪ جي مطابق، آرٽيڪل جو مقصد اهو آهي ته توهان جي روزاني ڪم کي ڪبرنيٽس سان گڏ نه رڳو وڌيڪ موثر، پر وڌيڪ خوشگوار پڻ!
تعارف: kubectl ڇا آهي
ان کان اڳ جو توھان سکي سگھو kubectl کي وڌيڪ مؤثر طريقي سان استعمال ڪرڻ، توھان کي بنيادي سمجھڻ جي ضرورت آھي اھو ڇا آھي ۽ اھو ڪيئن ڪم ڪري ٿو.
صارف جي نقطه نظر کان، kubectl هڪ ڪنٽرول پينل آهي جيڪو توهان کي Kubernetes آپريشن ڪرڻ جي اجازت ڏئي ٿو.
ٽيڪنالاجي ڳالهائڻ، kubectl هڪ Kubernetes API ڪلائنٽ آهي.
Kubernetes API هڪ HTTP REST API آهي. هي API سچو Kubernetes يوزر انٽرفيس آهي، جنهن ذريعي اهو مڪمل طور تي ڪنٽرول ٿيل آهي. هن جو مطلب اهو آهي ته هر ڪبرنيٽس آپريشن کي API جي آخري پوائنٽ جي طور تي بي نقاب ڪيو ويو آهي ۽ انهي جي آخري پوائنٽ ڏانهن HTTP درخواست سان ڪري سگهجي ٿو.
تنهن ڪري، kubectl جو مکيه ڪم ڪرڻ آهي HTTP درخواستون Kubernetes API ڏانهن:
Kubernetes هڪ مڪمل طور تي وسيلن تي مبني نظام آهي. هن جو مطلب اهو آهي ته اهو وسيلن جي اندروني حالت کي برقرار رکي ٿو ۽ سڀ ڪبرنيٽس آپريشنز CRUD آپريشن آهن.
توھان انھن وسيلن کي منظم ڪرڻ سان ڪبرنيٽس جي مڪمل ڪنٽرول ۾ آھيو، ۽ ڪبرنيٽس ڄاڻائي ٿو ته وسيلن جي موجوده حالت جي بنياد تي ڇا ڪجي. انهي سبب لاء، Kubernetes API ريفرنس منظم ڪيل وسيلن جي قسمن جي فهرست جي طور تي انهن سان لاڳاپيل عملن سان.
هي هڪ ReplicaSet وسيلو ٺاهيندو. پر پردي پٺيان ڇا ٿيندو آهي؟
Kubernetes وٽ ReplicaSet ٺاھڻ جو عمل آھي. ڪنهن ٻئي آپريشن وانگر، اهو ظاهر ڪيو ويو آهي API جي آخر پوائنٽ جي طور تي. هن آپريشن لاءِ مخصوص API آخري پوائنٽ هن طرح نظر اچي ٿو:
POST /apis/apps/v1/namespaces/{namespace}/replicasets
سڀ ڪبرنيٽس آپريشنز لاءِ API جي آخري پوائنٽس تي ڳولهي سگهجن ٿا API حوالو (شامل آهن مٿين نقطي). هڪ آخري نقطي تي حقيقي درخواست ڪرڻ لاء، توهان کي پهريان API سرور URL کي شامل ڪرڻ گهرجي آخري پوائنٽ جي رستن تي جيڪي API ريفرنس ۾ درج ٿيل آهن.
انهيء ڪري، جڏهن توهان مٿي ڏنل حڪم تي عمل ڪيو ٿا، kubectl موڪلي ٿو HTTP پوسٽ درخواست مٿين API جي آخر پوائنٽ ڏانهن. ReplicaSet تعريف جيڪا توهان فائل ۾ مهيا ڪئي آهي replicaset.yaml، درخواست جي جسم ۾ موڪليو ويو آهي.
اهو ڪيئن آهي kubectl سڀني حڪمن لاءِ ڪم ڪري ٿو جيڪي ڪبرنيٽس ڪلستر سان لهه وچڙ ۾ آهن. انهن سڀني صورتن ۾، kubectl صرف HTTP درخواستن کي مناسب Kubernetes API جي آخري پوائنٽن کي ڏئي ٿو.
مهرباني ڪري نوٽ ڪريو ته توهان مڪمل طور تي منظم ڪري سگهو ٿا Kubernetes استعمال ڪندي يوٽيليٽي جهڙوڪ curlدستي طور تي HTTP درخواستون موڪلڻ سان Kubernetes API ڏانهن. Kubectl آسان بڻائي ٿو Kubernetes API استعمال ڪرڻ.
هي بنياديات آهي ته ڪبيڪٽل ڇا آهي ۽ اهو ڪيئن ڪم ڪري ٿو. پر Kubernetes API جي باري ۾ ٻيو ڪجهه آهي جيڪو هر kubectl استعمال ڪندڙ کي ڄاڻڻ گهرجي. اچو ته ڪبرنيٽس جي اندروني دنيا تي تڪڙو نظر رکون.
ڪبرنيٽس جي اندروني دنيا
Kubernetes آزاد حصن جي ھڪڙي سيٽ تي مشتمل آھي جيڪي ڪلستر نوڊس تي الڳ عملن جي طور تي ھلندا آھن. ڪجهه جزا ماسٽر نوڊس تي هلن ٿا، ٻيا ڪم ڪندڙ نوڊس تي، هر جزو پنهنجي مخصوص ڪم کي انجام ڏئي ٿو.
اچو ته فرض ڪريو ته توهان مڪمل ڪيو آهي kubectl create -f replicaset.yaml، جنهن کان پوءِ kubectl هڪ HTTP پوسٽ جي درخواست ڪئي ReplicaSet API آخري پوائنٽ (ReplicaSet وسيلن جي تعريف کي پاس ڪرڻ).
ڪلستر ۾ ڇا ٿي رهيو آهي؟
ڪرڻ کان پوءِ kubectl create -f replicaset.yaml API سرور اسٽوريج ۾ توهان جي ReplicaSet وسيلن جي تعريف کي ذخيرو ڪري ٿو:
اڳيون، ReplicaSet سنڀاليندڙ ڪنٽرولر مينيجر ۾ شروع ڪيو ويو آهي، جيڪو ReplicaSet وسيلن جي تخليق، ترميم ۽ حذف ڪرڻ کي سنڀاليندو آهي:
ReplicaSet ڪنٽرولر هر ReplicaSet ريپليڪا لاءِ پوڊ جي تعريف ٺاهي ٿو (ريپليڪا سيٽ جي تعريف ۾ پوڊ ٽيمپليٽ جي مطابق) ۽ انهن کي اسٽوريج ۾ محفوظ ڪري ٿو:
شيڊيولر شروع ڪيو ويو آهي، ٽريڪنگ پوڊ جيڪي اڃا تائين ڪنهن به ڪم ڪندڙ نوڊس کي مقرر نه ڪيا ويا آهن:
شيڊيولر هر پوڊ لاءِ مناسب ورڪر نوڊ چونڊي ٿو ۽ هن معلومات کي اسٽور ۾ پوڊ جي تعريف ۾ شامل ڪري ٿو:
ڪم ڪندڙ نوڊ تي جنهن تي پوڊ مقرر ڪيو ويو آهي، ڪوبيليٽ شروع ڪيو ويو آهي، اهو هن نوڊ تي مقرر ڪيل پوڊس کي ٽريڪ ڪري ٿو:
ڪوبيليٽ اسٽوريج مان پوڊ جي تعريف پڙهي ٿو ۽ ڪنٽينر رن ٽائم کي هدايت ڪري ٿو، جهڙوڪ ڊڪر، نوڊ تي ڪنٽينرز کي لانچ ڪرڻ لاءِ:
هيٺ ڏنل بيان جو هڪ متن نسخو آهي.
API جي درخواست ReplicaSet ٺاھڻ جي آخري پوائنٽ تي API سرور پاران عمل ڪيو ويندو آھي. API سرور درخواست جي تصديق ڪري ٿو ۽ اسٽوريج ۾ ReplicaSet وسيلن جي تعريف کي ذخيرو ڪري ٿو.
اهو واقعو ReplicaSet ڪنٽرولر شروع ٿئي ٿو، جيڪو ڪنٽرولر مينيجر جو هڪ ذيلي پروسيس آهي. ReplicaSet ڪنٽرولر اسٽور ۾ ReplicaSet وسيلن جي تخليق، تازه ڪاري، ۽ حذف ڪرڻ جي نگراني ڪندو آهي ۽ هڪ واقعي جي نوٽيفڪيشن حاصل ڪري ٿو جڏهن اهو ٿئي ٿو.
ReplicaSet ڪنٽرولر جي نوڪري کي يقيني بڻائڻ آهي ته ReplicaSet پوڊ جي گهربل تعداد موجود آهي. اسان جي مثال ۾، اڃا تائين ڪو به پوڊ موجود ناهي، تنهن ڪري ريپليڪا سيٽ ڪنٽرولر انهن پوڊ جي تعريف ٺاهي ٿو (ريپليڪا سيٽ جي تعريف ۾ پوڊ ٽيمپليٽ جي مطابق) ۽ انهن کي اسٽوريج ۾ محفوظ ڪري ٿو.
نون پوڊز جي پيدائش ھڪڙي شيڊولر جي ذريعي شروع ڪئي وئي آھي جيڪو پوڊ جي تعريفن جي ٽريڪ رکي ٿو جيڪي اڃا تائين ورڪر نوڊس لاءِ شيڊول نه آھن. شيڊولر هر پوڊ لاءِ هڪ مناسب ڪم ڪندڙ نوڊ چونڊيندو آهي ۽ مخزن ۾ پوڊ جي وصفن کي اپڊيٽ ڪندو آهي.
نوٽ ڪريو ته هن نقطي تائين، ڪو به ڪم لوڊ ڪوڊ ڪلستر ۾ ڪٿي به نه هلندو هو. اهو سڀ ڪجهه جيڪو هن وقت تائين ڪيو ويو آهي - هي ماسٽر نوڊ تي مخزن ۾ وسيلن جي تخليق ۽ تازه ڪاري آهي.
آخري واقعو ڪبيليٽس کي متحرڪ ڪري ٿو، جيڪي انهن جي ڪم ڪندڙ نوڊس لاء مقرر ڪيل پوڊ جي نگراني ڪن ٿا. ورڪر نوڊ جو ڪوبيليٽ جنهن تي توهان جا ReplicaSet پوڊس انسٽال ٿيل آهن، لازمي ڪنٽينر جي رن ٽائم کي هدايت ڏين، جهڙوڪ ڊڪر، گهربل ڪنٽينر جون تصويرون ڊائون لوڊ ڪرڻ ۽ انهن کي هلائڻ لاءِ.
هن نقطي تي، توهان جي ReplicaSet ايپليڪيشن آخرڪار هلندي آهي!
ڪبرنيٽس API جو ڪردار
جيئن توهان اڳئين مثال ۾ ڏٺو، ڪبرنيٽس جزا (سواءِ API سرور ۽ اسٽوريج) اسٽوريج ۾ وسيلن ۾ تبديلين لاءِ ڏسندا آهن ۽ اسٽوريج ۾ وسيلن بابت معلومات تبديل ڪندا آهن.
يقينن، اهي حصا سڌو سنئون اسٽوريج سان لهه وچڙ نٿا ڪن، پر صرف ڪبرنيٽس API ذريعي.
هيٺ ڏنل مثالن تي غور ڪريو:
ReplicaSet ڪنٽرولر استعمال ڪري ٿو API آخري پوائنٽ فهرست ReplicaSets پيرا ميٽر سان watch ReplicaSet وسيلن ۾ تبديلين جي نگراني ڪرڻ لاء.
ReplicaSet ڪنٽرولر استعمال ڪري ٿو API آخري پوائنٽ پوڊ ٺاهيو (پڊ ٺاهيو) پوڊ ٺاهڻ لاء.
شيڊيولر استعمال ڪري ٿو API آخري پوائنٽ پيچ پوڊ (پڊ ايڊٽ ڪريو) چونڊيل ورڪر نوڊ بابت معلومات سان گڏ پوڊ کي اپڊيٽ ڪرڻ لاءِ.
جئين توهان ڏسي سگهو ٿا، اهو ساڳيو API آهي جيڪو kubectl تائين رسائي ٿو. اندروني اجزاء ۽ بيروني استعمال ڪندڙن لاءِ ساڳيو API استعمال ڪرڻ Kubernetes ڊيزائن ۾ بنيادي تصور آهي.
تنهن هوندي، آئون انهن لائينن کي شامل ڪرڻ جي صلاح نه ڪريان ~/.bash_profile، ۽ ۾ ~/.bashrc. انهي صورت ۾، خودڪار مڪمل ٿيڻ نه رڳو مکيه ۾، پر ٻارن جي حڪم جي شيل ۾ پڻ موجود هوندي.
ڪمانڊ شيل کي ٻيهر شروع ڪرڻ کان پوء، توهان تصديق ڪري سگهو ٿا تنصيب صحيح آهي هيٺ ڏنل حڪم استعمال ڪندي:
$ type _init_completion
جيڪڏھن توھان ڏسندا آھيو شيل فنڪشن ٻاھر ۾، پوء سڀ ڪجھ صحيح ترتيب ڏنل آھي.
هاڻي اسان کي پڪ ڪرڻ جي ضرورت آهي ته kubectl autocompletion سڀني سيشن ۾ فعال آهي.
ھڪڙو طريقو آھي توھان جي ھيٺين لائن کي شامل ڪرڻ لاء ~/.bashrc:
اهو طريقو صرف ڪم ڪندو جيڪڏهن توهان نصب ڪيو bash-completion Homebrew استعمال ڪندي. ھن حالت ۾، bash-completion ھن ڊاريڪٽري مان سڀ اسڪرپٽ لوڊ ڪري ٿو.
جيڪڏهن توهان انسٽال ڪيو kubectl استعمال ڪندي Homebrew، پوءِ پوئين قدم کي انجام ڏيڻ جي ڪا ضرورت ناهي، ڇاڪاڻ ته خودڪار مڪمل ٿيڻ واري اسڪرپٽ خودڪار طريقي سان فولڊر ۾ رکي ويندي. /usr/local/etc/bash_completion.d انسٽاليشن دوران. ان صورت ۾، kubectl autocompletion ڪم ڪرڻ شروع ڪندو جيئن ئي توهان bash-completion انسٽال ڪندا.
نتيجي طور، اهي سڀئي اختيار برابر آهن.
Zsh
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 ڏيکاري ٿو صرف پهرين سطح جي nesting جي فيلڊ.
جيڪڏهن توهان اختيار شامل ڪيو ته توهان سڄو وڻ ڏيکاري سگهو ٿا --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
هي فارميٽ آسان آهي، پر ان ۾ معلومات جي محدود مقدار شامل آهي. مڪمل وسيلن جي تعريف واري فارميٽ جي مقابلي ۾، صرف چند شعبا هتي ڏيکاريا ويا آهن.
انهي حالت ۾، توهان استعمال ڪري سگهو ٿا هڪ ڪسٽم ڪالمن آئوٽ فارميٽ. اهو توهان کي اهو طئي ڪرڻ جي اجازت ڏئي ٿو ته ڪهڙي ڊيٽا کي آئوٽ ڪجي. توهان ڪنهن به وسيلن جي فيلڊ کي الڳ ڪالم طور ڏيکاري سگهو ٿا.
ڪسٽم فارميٽ جو استعمال اختيارن کي استعمال ڪندي طئي ڪيو ويو آهي:
توھان وضاحت ڪري سگھو ٿا ھر ٻاھر ڪڍڻ واري ڪالمن کي ھڪڙي جوڙي جي طور تي <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.
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 اهو به طئي ڪري ٿو ته ڪبوب ڪنفگ فائل جي بنياد تي ڪهڙي نالي جي جاءِ استعمال ڪجي. ان جو مطلب اهو آهي ته توهان کي هڪ طريقي جي ضرورت آهي kubectl حڪم کي ٻڌائڻ لاءِ ڪهڙي نالي جي جاءِ سان ڪم ڪجي.
هن باب ۾ اسين وضاحت ڪنداسين ته اهو ڪيئن ڪم ڪري ٿو ۽ ڪيئن ان کي مؤثر طريقي سان ڪم ڪرڻ.
نوٽ ڪريو ته توھان وٽ ٿي سگھي ٿو گھڻا kubeconfig فائلون درج ٿيل KUBECONFIG ماحوليات ۾. انهي حالت ۾، اهي سڀئي فائلون گڏ ڪيون وينديون هڪ عام ترتيب ۾ رن ٽائم تي. توھان پڻ تبديل ڪري سگھو ٿا ڊفالٽ kubeconfig فائل کي هلائڻ سان kubectl کي پيٽرول سان --kubeconfig. ڏس سرڪاري دستاويز.
kubeconfig فائلون
اچو ته ڏسون ته kubeconfig فائل ۾ ڇا شامل آهي:
جئين توهان ڏسي سگهو ٿا، kubeconfig فائل ۾ سيٽن جو هڪ سيٽ شامل آهي. حوالو ٽن عنصرن تي مشتمل آهي:
ڪلستر - ڪلستر سرور جو API URL.
استعمال ڪندڙ - ڪلستر ۾ صارف جي تصديق جي سند.
Namespace - نالو اسپيس استعمال ڪيو ويو جڏهن ڪلستر ۾ شامل ٿيڻ.
عملي طور تي، اهي اڪثر ڪري استعمال ڪندا آهن هڪ حوالي سان هر ڪلستر کي انهن جي ڪبيبن ۾. تنهن هوندي، توهان وٽ هر ڪلستر ۾ ڪيترائي حوالا هوندا، صارف يا نالي جي جڳهه طرفان مختلف. بهرحال، هي گهڻ-سبب جي ترتيب غير معمولي آهي، تنهن ڪري عام طور تي ڪلستر ۽ حوالن جي وچ ۾ هڪ کان هڪ ميپنگ آهي.
ڪنهن به وقت، انهن مان هڪ حوالو موجوده آهي:
جڏهن kubectl هڪ ترتيب واري فائيل کي پڙهي ٿو، اهو هميشه موجوده حوالي سان معلومات وٺندو آهي. مٿين مثال ۾، kubectl هاري ڪلستر سان ڳنڍيندو.
انهي جي مطابق، ٻئي ڪلستر کي تبديل ڪرڻ لاء، توهان کي تبديل ڪرڻ جي ضرورت آهي موجوده حوالي سان kubeconfig فائل ۾:
هاڻي kubectl فاکس ڪلستر سان ڳنڍيندو.
ساڳئي ڪلستر ۾ مختلف نالن جي جڳھ کي تبديل ڪرڻ لاء، توھان کي تبديل ڪرڻو پوندو نالو اسپيس عنصر جو قدر موجوده حوالي لاءِ:
مٿين مثال ۾، kubectl استعمال ڪندو Fox cluster's Prod namespace (اڳ ۾ Test namespace مقرر ڪيو ويو هو).
نوٽ ڪريو ته 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 وانگر. هتي توهان انهن کي عمل ۾ ڏسي سگهو ٿا:
نوٽ ڪريو ته عرف 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 نالي جي جڳھ کي تبديل ڪرڻ لاء.
نوٽ ڪريو ته پلگ ان استعمال ڪندا آهن fzf هڪ انٽرايڪٽو مفت سرچ انٽرفيس مهيا ڪرڻ لاءِ (جهڙوڪ kubectx جي انٽرايڪٽو موڊ). هن جو مطلب آهي ته توهان کي ضرورت آهي fzf انسٽال ڪريواهي نالا استعمال ڪرڻ لاءِ.
پلگ ان انسٽال ڪرڻ لاءِ، توھان کي ڊائون لوڊ ڪرڻو پوندو شيل اسڪرپٽ نالي kubectl-ctx и kubectl-ns توهان جي PATH variable ۾ ڪنهن به ڊاريڪٽري ڏانهن وڃو ۽ انهن کي قابل عمل ٺاهيو مثال طور. chmod +x. هن کان پوء فوري طور تي توهان کي استعمال ڪرڻ جي قابل ٿي ويندي kubectl ctx и kubectl ns.
5. autoaliases سان ان پٽ کي گھٽايو
شيل عرف ان پٽ کي تيز ڪرڻ جو سٺو طريقو آهي. پروجيڪٽ kubectl-aliases بنيادي kubectl حڪمن لاءِ اٽڪل 800 شارٽ ڪٽ شامل آهن.
توهان شايد حيران ٿي رهيا آهيو - توهان کي 800 عرف ڪيئن ياد آهي؟ پر توهان کي انهن سڀني کي ياد ڪرڻ جي ضرورت ناهي، ڇاڪاڻ ته اهي هڪ سادي اسڪيم جي مطابق ٺهيل آهن، جيڪي هيٺ ڏنل آهن:
مثال طور
kgpooyaml - kubectl get pods oyaml
ksysgsvcw - kubectl -n kube-system حاصل svc w
ksysrmcm -kubectl -n kube-سسٽم rm cm
kgdepallsl - kubectl حاصل ڪريو ڊيپلائيمينٽ سڀ sl
جئين توهان ڏسي سگهو ٿا، aliases حصن مان ٺهيل آهن، جن مان هر هڪ kubectl حڪم جي مخصوص عنصر جي نمائندگي ڪري ٿو. هر عرف ۾ بنيادي ڪمانڊ، آپريشن، ۽ وسيلا، ۽ پيرا ميٽرز لاءِ گھڻن اجزاء لاءِ ھڪڙو حصو ٿي سگھي ٿو. توهان صرف انهن حصن کي کاٻي کان ساڄي طرف "آباد" ڪريو مٿي ڏنل ڊراگرام مطابق.
مثال طور، عرف 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.
ڇاڪاڻ ته ڪجهه عرفن کي دليلن جي ضرورت آهي، عرف الف، ف، ۽ ايل آخري استعمال ٿيڻ گهرجي.
عام طور تي، هڪ دفعو توهان هن اسڪيم جي پٺڀرائي حاصل ڪري سگهو ٿا، توهان آسانيءَ سان انهن حڪمن مان عرف حاصل ڪري سگهو ٿا جن تي توهان عمل ڪرڻ چاهيو ٿا ۽ ٽائپنگ جو گهڻو وقت بچائي سگهو ٿا.
تنصيب
kubectl-aliases انسٽال ڪرڻ لاءِ، توھان کي فائل ڊائون لوڊ ڪرڻ جي ضرورت آھي .kubectl_aliases GitHub مان ۽ ان کي فائل ۾ شامل ڪريو ~/.bashrc يا ~/.zshrc:
source ~/.kubectl_aliases
خودڪشي
جيئن اسان اڳ ۾ چيو آهي، توهان اڪثر ڪري اضافي لفظ شامل ڪندا آهيو عرف ۾ ڪمانڊ لائن تي. مثال طور:
$ kgpooyaml test-pod-d4b77b989
جيڪڏهن توهان استعمال ڪيو آهي kubectl ڪمانڊ مڪمل ٿيڻ، توهان شايد استعمال ڪيو آهي خودڪار مڪمل ٿيڻ شين لاءِ وسيلن جا نالا. پر ڇا اهو ٿي سگهي ٿو جڏهن عرف استعمال ڪيو وڃي؟
هي هڪ تمام اهم سوال آهي ڇو ته جيڪڏهن خودڪار مڪمل ٿيڻ ڪم نه ڪندو آهي، ته توهان عرف جا ڪجهه فائدا وڃائي ويهندا.
جواب تي منحصر آهي ته توهان ڪهڙي شيل استعمال ڪري رهيا آهيو:
بش سان مسئلو اهو آهي ته اهو مڪمل ڪرڻ جي ڪوشش ڪري ٿو (هر ڀيري توهان ٽيب کي دٻايو) عرف، نه ته اهو حڪم جيڪو عرف ڏانهن اشارو ڪري ٿو (جيئن Zsh ڪندو آهي، مثال طور). جيئن ته توهان وٽ سڀني 800 عرفن لاءِ مڪمل اسڪرپٽس نه آهن، خودڪار مڪمل ڪرڻ ڪم نٿو ڪري.
پروجيڪٽ مڪمل عرف هن مسئلي لاء هڪ عام حل مهيا ڪري. اهو عرف جي مڪمل ٿيڻ واري ميڪانيزم سان ڳنڍيندو آهي، اندروني طور تي عرف کي ڪمانڊ ڏانهن وڌائيندو آهي، ۽ مڪمل ڪيل ڪمانڊ لاءِ مڪمل ڪرڻ جا اختيار واپس ڪندو آهي. هن جو مطلب اهو آهي ته هڪ عرف لاء padding بلڪل ساڳيو ڪم ڪري ٿو جيئن مڪمل حڪم لاء.
ھيٺين ۾، مان پھريائين بيان ڪندس ته ڪيئن انسٽال ڪجي مڪمل-عرف ۽ پوءِ ان کي ڪھڙي طرح ترتيب ڏجي ته جيئن سڀني ڪبيڪٽل عرف مڪمل ڪرڻ کي چالو ڪيو وڃي.
انسٽال ڪرڻ مڪمل-عرف
سڀ کان پهريان، مڪمل-عرف تي منحصر آهي bash- مڪمل ٿيڻ. تنهن ڪري، مڪمل عرف انسٽال ڪرڻ کان اڳ، توهان کي پڪ ڪرڻ جي ضرورت آهي ته bash-completion انسٽال ٿيل آهي. لينڪس ۽ MacOS لاءِ انسٽاليشن جون هدايتون اڳ ۾ مهيا ڪيون ويون آهن.
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.
نوٽ ڪريو ته توھان پنھنجي سسٽم تي ڪنھن به عرف لاءِ مڪمل-عرف استعمال ڪري سگھو ٿا.
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 سپورٽ ڪري ٿو پلگ ان ميڪانيزم، جيڪو توهان کي اضافي حڪمن سان ان جي افعال کي وڌائڻ جي اجازت ڏئي ٿو.
جيڪڏهن توهان کان واقف آهيو Git پلگ ان ميڪانيزم، پوءِ kubectl پلگ ان ساڳئي اصول تي ٺهيل آهن.
هن باب ۾، اسان ڍڪينداسين ته ڪيئن پلگ ان کي انسٽال ڪجي، انهن کي ڪٿي ڳولهجي، ۽ پنهنجون پلگ ان ڪيئن ٺاهيون.
انسٽاليشن پلگ ان
Kubectl پلگ ان کي ورهايو ويو آهي سادي عمل ڪندڙ فائلن جي نالي سان kubectl-x. اڳڀرائي kubectl- جي ضرورت آهي، هڪ نئين kubectl ذيلي ڪمانڊ جي پٺيان جيڪا توهان کي پلگ ان کي ڪال ڪرڻ جي اجازت ڏئي ٿي.
مثال طور، هيلو پلگ ان کي ورهايو ويندو فائل جي نالي سان kubectl-hello.
پلگ ان کي انسٽال ڪرڻ لاءِ، توھان کي فائل کي نقل ڪرڻو پوندو kubectl-x توهان جي PATH ۾ ڪنهن به ڊاريڪٽري ڏانهن وڃو ۽ ان کي قابل عمل بڻايو، مثال طور chmod +x. ان کان پوء فوري طور تي توهان پلگ ان سان سڏي سگهو ٿا kubectl x.
توھان ھيٺ ڏنل حڪم استعمال ڪري سگھوٿا انھن سڀني پلگ ان کي لسٽ ڪرڻ لاءِ جيڪي ھن وقت توھانجي سسٽم تي نصب ٿيل آھن.
$ kubectl plugin list
هي حڪم پڻ ڊيڄاريندڙ ڏيکاريندو جيڪڏهن توهان وٽ هڪ ئي نالي سان ڪيترائي پلگ ان آهن، يا جيڪڏهن هڪ پلگ ان فائل آهي جيڪا قابل عمل نه آهي.
Krew استعمال ڪندي پلگ ان ڳولڻ ۽ انسٽال ڪرڻ
Kubectl پلگ ان شيئر ڪري سگھجن ٿا يا سافٽ ويئر پيڪيجز وانگر ٻيهر استعمال ڪري سگھجن ٿا. پر توهان ڪٿي ڳولي سگهو ٿا پلگ ان جيڪي ٻين شيئر ڪيا آهن؟
پروجيڪٽ Krew kubectl plugins کي شيئر ڪرڻ، ڳولڻ، انسٽال ڪرڻ ۽ انتظام ڪرڻ لاءِ هڪ متحد حل مهيا ڪرڻ جو مقصد آهي. پروجيڪٽ پاڻ کي سڏي ٿو "پيڪيج مئنيجر for kubectl plugins" (Krew ساڳيو آهي شراب).
Krew kubectl پلگ ان جي ھڪڙي فهرست آھي جنھن کي توھان منتخب ۽ انسٽال ڪري سگھو ٿا. ساڳئي وقت، Krew پڻ هڪ پلگ ان آهي kubectl لاءِ.
ان جو مطلب اهو آهي ته انسٽال ڪرڻ Krew بنيادي طور تي ڪم ڪري ٿو جهڙوڪ ڪنهن ٻئي kubectl پلگ ان کي انسٽال ڪرڻ. توھان ڳولي سگھوٿا تفصيلي هدايتون تي GitHub صفحو.
سڀ کان اهم Krew حڪم آهن:
# Поиск в списке плагинов
$ 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 صرف پلگ ان ڏيکاري ٿو جيڪي Krew استعمال ڪندي انسٽال ڪيا ويا، جڏهن ته حڪم kubectl plugin list سڀني پلگ ان کي لسٽ ڪري ٿو، اهو آهي، جيڪي Krew استعمال ڪندي انسٽال ٿيل آهن ۽ جيڪي ٻين طريقن سان نصب ٿيل آهن.
ٻئي هنڌ پلگ ان ڳولڻ
Krew هڪ نوجوان منصوبو آهي، هن وقت ان ۾ آهي فهرست صرف اٽڪل 30 پلگ ان. جيڪڏهن توهان نه ڳولي سگهو ٿا جيڪو توهان کي گهربل آهي، توهان ڳولي سگهو ٿا پلگ ان ٻئي هنڌ، جهڙوڪ GitHub.
مان گيٽ هب سيڪشن کي ڏسڻ جي صلاح ڏيان ٿو kubectl-plugins. اتي توهان کي درجن جي دستياب پلگ ان ملندا جيڪي چيڪ ڪرڻ جي قابل آهن.
توهان جي پنهنجي پلگ ان لکڻ
توهان پاڻ ڪري سگهو ٿا پلگ ان ٺاهيو - اهو ڏکيو نه آهي. توهان کي هڪ قابل عمل ٺاهڻ جي ضرورت آهي جيڪا توهان کي گهربل هجي، ان کي نالو ڏيو kubectl-x ۽ انسٽال ڪريو جيئن مٿي بيان ڪيو ويو آهي.
فائل ٿي سگهي ٿي هڪ بش اسڪرپٽ، هڪ پٿون اسڪرپٽ، يا هڪ مرتب ڪيل 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 plugins ڪنهن به پروگرامنگ يا اسڪرپٽنگ ٻولي ۾ لکي سگهجي ٿو. جيڪڏھن توھان استعمال ڪري رھيا آھيو شيل اسڪرپٽ، ان جو فائدو آھي آسانيءَ سان ڪال ڪرڻ جي قابل ٿي پلگ ان جي اندر کان. بهرحال، توهان استعمال ڪندي حقيقي پروگرامنگ ٻولين ۾ وڌيڪ پيچيده پلگ ان لکي سگهو ٿا Kubernetes ڪلائنٽ لائبريري. جيڪڏهن توهان Go استعمال ڪري رهيا آهيو، توهان پڻ استعمال ڪري سگهو ٿا cli-runtime لائبريري، جيڪو خاص طور تي kubectl plugins لکڻ لاءِ موجود آهي.
توهان جي پلگ ان کي ڪيئن حصيداري ڪجي
جيڪڏهن توهان سوچيو ته توهان جا پلگ ان ٻين لاءِ ڪارآمد ٿي سگهن ٿا، ان کي شيئر ڪرڻ لاءِ آزاد محسوس ڪريو GitHub. انھن کي موضوع ۾ شامل ڪرڻ جي پڪ ڪريو kubectl-plugins.
توھان پڻ درخواست ڪري سگھو ٿا ته توھان جو پلگ ان شامل ڪيو وڃي ڪرو فهرست. هن کي ڪيئن ڪرڻ لاء هدايتون ۾ آهن GitHub مخزن.
حڪم جي مڪمل ٿيڻ
پلگ ان في الحال خودڪار مڪمل ٿيڻ جي حمايت نٿا ڪن. اهو آهي، توهان کي پلگ ان جو پورو نالو ۽ دليلن جا پورا نالا داخل ڪرڻ گهرجن.