🥇نحوه استفاده موثرتر از کوبکتل: راهنمای دقیق

اگر با Kubernetes کار می کنید، احتمالا kubectl یکی از ابزارهایی است که بیشتر استفاده می کنید. و هر زمان که زمان زیادی را صرف کار با یک ابزار خاص می کنید، مطالعه آن و یادگیری نحوه استفاده موثر از آن مفید است.

تیم Kubernetes aaS از Mail.ru مقاله ای توسط دانیل وایبل ترجمه شده است که در آن نکات و ترفندهایی را برای کار موثر با kubectl خواهید دید. همچنین به شما کمک می کند تا درک عمیق تری از Kubernetes به دست آورید.

به گفته نویسنده، هدف مقاله این است که کار روزانه شما با Kubernetes را نه تنها کارآمدتر، بلکه لذت بخش تر کند!

مقدمه: کوبکتل چیست؟

قبل از اینکه بتوانید استفاده موثرتر از کوبکتل را یاد بگیرید، باید درک اولیه ای از چیستی و نحوه عملکرد آن به دست آورید.

از دیدگاه کاربر، kubectl یک کنترل پنل است که به شما امکان می دهد عملیات Kubernetes را انجام دهید.

از نظر فنی، kubectl یک مشتری API Kubernetes است.

Kubernetes API یک API HTTP REST است. این API رابط کاربری واقعی Kubernetes است که از طریق آن کاملاً کنترل می شود. این بدان معنی است که هر عملیات Kubernetes به عنوان یک نقطه پایانی API در معرض دید قرار می گیرد و می تواند با یک درخواست HTTP به آن نقطه پایانی انجام شود.

بنابراین، کار اصلی kubectl ایجاد درخواست های HTTP به API Kubernetes است:

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

نقاط پایانی API برای تمام عملیات Kubernetes را می توان در این آدرس یافت مرجع API (شامل نقطه پایانی بالا). برای درخواست واقعی یک نقطه پایانی، ابتدا باید URL سرور API را به مسیرهای نقطه پایانی که در مرجع API فهرست شده است اضافه کنید.

از این رو، هنگامی که دستور بالا را اجرا می کنید، kubectl یک درخواست HTTP POST را به نقطه پایانی API بالا ارسال می کند. تعریف ReplicaSet که در فایل ارائه کردید replicaset.yaml، در متن درخواست ارسال می شود.

به این ترتیب kubectl برای تمام دستوراتی که با خوشه Kubernetes تعامل دارند کار می کند. در تمام این موارد، kubectl به سادگی درخواست های HTTP را به نقاط پایانی API مناسب Kubernetes ارسال می کند.

لطفاً توجه داشته باشید که می‌توانید Kubernetes را با استفاده از ابزاری مانند curlبا ارسال دستی درخواست های HTTP به API Kubernetes. 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 یک تعریف pod ایجاد می کند (طبق قالب پاد در تعریف ReplicaSet) و آنها را در حافظه ذخیره می کند:
زمان‌بندی راه‌اندازی می‌شود، غلاف‌های ردیابی که هنوز به هیچ‌یک از گره‌های کارگری اختصاص داده نشده‌اند:
زمانبند یک گره کارگر مناسب برای هر غلاف انتخاب می کند و این اطلاعات را به تعریف غلاف در فروشگاه اضافه می کند:
در گره کارگری که غلاف به آن اختصاص داده شده است، Kubelet راه اندازی می شود، غلاف های اختصاص داده شده به این گره را ردیابی می کند:
Kubelet تعریف pod را از ذخیره‌سازی می‌خواند و به یک Container Runtime، مانند Docker دستور می‌دهد تا کانتینرها را روی گره راه‌اندازی کند:

در زیر نسخه متنی این توضیحات آمده است.

درخواست API به نقطه پایانی ایجاد ReplicaSet توسط سرور API پردازش می شود. سرور API درخواست را احراز هویت می کند و تعریف منبع ReplicaSet را در حافظه ذخیره می کند.

این رویداد کنترلر ReplicaSet را که یک فرآیند فرعی از مدیریت کنترلر است، راه اندازی می کند. کنترلر ReplicaSet بر ایجاد، به روز رسانی و حذف منابع ReplicaSet در فروشگاه نظارت می کند و در صورت وقوع یک اعلان رویداد دریافت می کند.

وظیفه کنترلر ReplicaSet اطمینان از وجود تعداد مورد نیاز ReplicaSet است. در مثال ما، هنوز هیچ pod وجود ندارد، بنابراین کنترلر ReplicaSet این تعاریف پاد را ایجاد می کند (طبق قالب پاد در تعریف ReplicaSet) و آنها را در حافظه ذخیره می کند.

ایجاد غلاف های جدید توسط یک زمان بندی راه اندازی می شود که تعاریف غلاف را که هنوز برای گره های کارگر برنامه ریزی نشده اند، پیگیری می کند. زمانبند یک گره کارگر مناسب برای هر پاد انتخاب می کند و تعاریف غلاف را در مخزن به روز می کند.

توجه داشته باشید که تا این مرحله، هیچ کد بار کاری در هیچ نقطه ای از خوشه اجرا نمی شد. تمام کارهایی که تاکنون انجام شده است - این ایجاد و به روز رسانی منابع در مخزن در گره اصلی است.

آخرین رویداد Kubelets را فعال می کند، که غلاف های برنامه ریزی شده برای گره های کارگر خود را نظارت می کند. Kubelet گره کارگری که غلاف های ReplicaSet شما روی آن نصب شده اند باید به زمان اجرا کانتینر مانند Docker دستور دهد تا تصاویر کانتینر مورد نیاز را دانلود کرده و آنها را اجرا کند.

در این مرحله، برنامه ReplicaSet شما در نهایت اجرا می شود!

نقش Kubernetes API

همانطور که در مثال قبلی دیدید، اجزای Kubernetes (به جز سرور API و ذخیره سازی) تغییرات منابع موجود در ذخیره سازی را مشاهده می کنند و اطلاعات مربوط به منابع موجود در ذخیره سازی را تغییر می دهند.

البته این مؤلفه‌ها مستقیماً با فضای ذخیره‌سازی تعامل ندارند، بلکه فقط از طریق Kubernetes API تعامل دارند.

به مثال های زیر توجه کنید:

کنترلر ReplicaSet از نقطه پایانی API استفاده می کند ReplicaSets را لیست کنید با پارامتر watch برای نظارت بر تغییرات منابع ReplicaSet.
کنترلر ReplicaSet از نقطه پایانی API استفاده می کند Pod را ایجاد کنید (ایجاد غلاف) برای ایجاد غلاف.
Scheduler از نقطه پایانی API استفاده می کند پچ غلاف (ویرایش غلاف) برای به روز رسانی غلاف ها با اطلاعات مربوط به گره کارگر انتخاب شده.

همانطور که می بینید، این همان API است که kubectl به آن دسترسی دارد. استفاده از API یکسان برای اجزای داخلی و کاربران خارجی یک مفهوم اساسی در طراحی Kubernetes است.

اکنون می‌توانیم نحوه عملکرد Kubernetes را خلاصه کنیم:

فروشگاه های ذخیره سازی منابع Kubernetes را بیان می کنند.
سرور API یک رابط برای ذخیره سازی در قالب Kubernetes API فراهم می کند.
همه اجزای دیگر و کاربران Kubernetes وضعیت (منابع) Kubernetes را از طریق API می خوانند، مشاهده می کنند و دستکاری می کنند.

دانستن این مفاهیم به شما کمک می کند کوبکتل را بهتر درک کنید و بیشترین بهره را از آن ببرید.

اکنون بیایید به چند نکته و ترفند خاص نگاه کنیم که به بهبود بهره وری شما با kubectl کمک می کند.

1. سرعت ورودی را با استفاده از تکمیل دستور افزایش دهید

یکی از مفیدترین، اما اغلب نادیده گرفته شده، تکنیک ها برای بهبود عملکرد با kubectl تکمیل فرمان است.

تکمیل فرمان به شما امکان می دهد تا با استفاده از کلید Tab به طور خودکار بخش هایی از دستورات kubectl را تکمیل کنید. این برای فرمان‌های فرعی، گزینه‌ها و آرگومان‌ها، از جمله موارد پیچیده مانند نام منابع، کار می‌کند.

ببینید تکمیل دستور kubectl چگونه کار می کند:

تکمیل فرمان برای پوسته های Bash و Zsh کار می کند.

راهنمای رسمی حاوی دستورالعمل های دقیق برای تنظیم تکمیل خودکار است، اما در زیر گزیده ای کوتاه ارائه خواهیم کرد.

چگونه تکمیل دستور کار می کند

تکمیل فرمان یک ویژگی پوسته است که با استفاده از یک اسکریپت تکمیل کار می کند. اسکریپت افزونه یک اسکریپت پوسته است که رفتار یک برنامه افزودنی را برای یک دستور خاص تعریف می کند.

Kubectl به طور خودکار اسکریپت های افزونه را برای Bash و Zsh با استفاده از دستورات زیر تولید و خروجی می کند:

$ kubectl completion bash

Или:

$ kubectl completion zsh

در تئوری کافی است خروجی این دستورات را به پوسته فرمان مناسب متصل کنید تا kubectl بتواند دستورات را تکمیل کند.

در عمل، روش اتصال برای Bash (از جمله تفاوت بین Linux و MacOS) و Zsh متفاوت است. در زیر تمام این گزینه ها را بررسی خواهیم کرد.

Bash در لینوکس

اسکریپت تکمیل Bash به بسته تکمیل bash بستگی دارد، بنابراین ابتدا باید آن را نصب کنید:

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

با دستور زیر می توانید تست کنید که بسته با موفقیت نصب شده است:

$ type _init_completion

اگر این کد تابع پوسته را خروجی می دهد، bash-completion به درستی نصب می شود. اگر دستور خطای Not Found داد، باید خط زیر را به فایل خود اضافه کنید ~ / .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 کار خواهد کرد.

Bash در MacOS

در MacOS راه اندازی کمی پیچیده تر است. واقعیت این است که MacOS به طور پیش فرض از Bash نسخه 3.2 استفاده می کند و اسکریپت تکمیل خودکار kubectl به نسخه Bash حداقل 4.1 نیاز دارد و در Bash 3.2 کار نمی کند.

مشکلات مربوط به صدور مجوز مربوط به استفاده از نسخه قدیمی Bash در MacOS وجود دارد. نسخه 4 Bash تحت مجوز GPLv3 است که توسط اپل پشتیبانی نمی شود.

برای پیکربندی تکمیل خودکار kubectl در MacOS، باید نسخه جدیدتر Bash را نصب کنید. همچنین می‌توانید Bash به‌روزرسانی‌شده را به‌عنوان پوسته پیش‌فرض خود تنظیم کنید، که در آینده از بسیاری از مشکلات جلوگیری می‌کند. دشوار نیست، جزئیات در مقاله آورده شده است "به روز رسانی Bash در MacOS'.

قبل از ادامه، مطمئن شوید که از نسخه اخیر Bash استفاده می کنید (خروجی را بررسی کنید bash --version).

اسکریپت تکمیل Bash بسته به پروژه متفاوت است bash-completing، بنابراین ابتدا باید آن را نصب کنید.

با استفاده از 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 را با استفاده از Homebrew نصب کرده باشید. در این مورد، bash-completion همه اسکریپت ها را از این دایرکتوری بارگیری می کند.

اگه نصب کردی kubectl با استفاده از Homebrew، پس نیازی به انجام مرحله قبل نیست، زیرا اسکریپت تکمیل خودکار به طور خودکار در پوشه قرار می گیرد. /usr/local/etc/bash_completion.d در حین نصب در این صورت، تکمیل خودکار kubectl به محض نصب 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 - هنگامی که یک pod به یک گره اختصاص داده می شود، نام آن در فیلد نوشته می شود 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
```
این دستور نام تصاویر کانتینر را برای هر pod نمایش می دهد.

به یاد داشته باشید که یک غلاف می تواند حاوی چندین کانتینر باشد، سپس نام تصاویر در یک خط نمایش داده می شود که با کاما از هم جدا می شوند.
نمایش مناطق در دسترس بودن گره:
```
$ 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 فهرست شده باشد. در این حالت، تمام این فایل ها در زمان اجرا در یک پیکربندی مشترک ترکیب می شوند. همچنین می توانید فایل kubeconfig پیش فرض را با اجرای kubectl با پارامتر تغییر دهید --kubeconfig. نگاه کن اسناد رسمی.

فایل های kubeconfig

بیایید ببینیم فایل kubeconfig دقیقا شامل چه چیزی است:

همانطور که می بینید، فایل kubeconfig شامل مجموعه ای از زمینه ها است. متن از سه عنصر تشکیل شده است:

Cluster - URL API سرور خوشه.
کاربر - اعتبار احراز هویت کاربر در خوشه.
فضای نام - فضای نامی که هنگام پیوستن به خوشه استفاده می شود.

در عمل، آنها اغلب از یک زمینه در هر خوشه در kubeconfig خود استفاده می کنند. با این حال، می‌توانید در هر خوشه، زمینه‌های متعددی داشته باشید که بر اساس کاربر یا فضای نام متمایز می‌شوند. با این حال، این پیکربندی چند متنی غیر معمول است، بنابراین معمولاً یک نگاشت یک به یک بین خوشه‌ها و زمینه‌ها وجود دارد.

در هر زمان، یکی از زمینه ها جاری است:

وقتی kubectl یک فایل پیکربندی را می خواند، همیشه اطلاعاتی را از زمینه فعلی می گیرد. در مثال بالا، kubectl به خوشه Hare متصل می شود.

بر این اساس، برای جابجایی به یک خوشه دیگر، باید زمینه فعلی را در فایل kubeconfig تغییر دهید:

اکنون kubectl به خوشه Fox متصل می شود.

برای جابجایی به فضای نام متفاوت در همان خوشه، باید مقدار عنصر فضای نام را برای زمینه فعلی تغییر دهید:

در مثال بالا، kubectl از فضای نام Prod خوشه فاکس استفاده خواهد کرد (قبلاً فضای نام Test تنظیم شده بود).

توجه داشته باشید که kubectl گزینه هایی را نیز ارائه می دهد --cluster, --user, --namespace и --context، که به شما امکان می دهد بدون توجه به آنچه در kubeconfig تنظیم شده است، عناصر جداگانه و خود زمینه فعلی را بازنویسی کنید. نگاه کن kubectl options.

در تئوری، می توانید تنظیمات را در kubeconfig به صورت دستی تغییر دهید. اما ناخوشایند است. برای ساده کردن این عملیات، ابزارهای مختلفی وجود دارد که به شما امکان می دهد پارامترها را به طور خودکار تغییر دهید.

از kubectx استفاده کنید

یک ابزار بسیار محبوب برای جابجایی بین خوشه ها و فضاهای نام.

ابزار دستورات را ارائه می دهد kubectx и kubens به ترتیب زمینه و فضای نام فعلی را تغییر دهید.

همانطور که گفته شد، تغییر زمینه فعلی به معنای تغییر خوشه است اگر شما فقط یک زمینه در هر خوشه دارید.

در اینجا مثالی از اجرای این دستورات آورده شده است:

در اصل، این دستورات به سادگی فایل kubeconfig را همانطور که در بالا توضیح داده شد ویرایش می کنند.

برای نصب kubectx، دستورالعمل های موجود را دنبال کنید Github

هر دو دستور از تکمیل خودکار نام‌های متن و فضای نام پشتیبانی می‌کنند که نیاز به تایپ کامل آنها را از بین می‌برد. دستورالعمل های تنظیم تکمیل خودکار اینجا.

یکی دیگر از ویژگی های مفید 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 برای ارائه یک رابط جستجوی رایگان تعاملی (مانند حالت تعاملی kubectx) استفاده می‌کنند. این به این معنی است که شما نیاز دارید 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 خود وارد کنید و آنها را با به عنوان مثال قابل اجرا کنید. chmod +x. بلافاصله پس از این شما می توانید استفاده کنید kubectl ctx и kubectl ns.

5. ورودی را با autoaliases کاهش دهید

نام مستعار پوسته راه خوبی برای افزایش سرعت ورودی است. پروژه Kubectl- مستعار شامل حدود 800 میانبر برای دستورات پایه کوبکتل است.

ممکن است تعجب کنید - چگونه 800 نام مستعار را به خاطر می آورید؟ اما لازم نیست همه آنها را به خاطر بسپارید، زیرا آنها بر اساس یک طرح ساده ساخته شده اند که در زیر آورده شده است:

به عنوان مثال:

kgpooyaml - kubectl get pods oyaml
ksysgsvcw — kubectl -n kube-system دریافت svc w
ksysrmcm -kubectl -n kube-system rm cm
kgdepallsl - 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 (در حال حاضر هیچ نام مستعاری برای منبع Roles وجود ندارد).
برای دریافت داده برای یک pod خاص، می توانید از دستور استفاده کنید 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 این است که سعی می کند (هر بار که Tab را فشار می دهید) نام مستعار را تکمیل کند، نه دستوری که نام مستعار به آن اشاره می کند (مثلاً همانطور که Zsh انجام می دهد). از آنجایی که شما اسکریپت های تکمیلی برای همه 800 نام مستعار ندارید، تکمیل خودکار کار نمی کند.

پروژه نام مستعار کامل یک راه حل کلی برای این مشکل ارائه می دهد. به مکانیسم تکمیل نام مستعار متصل می شود، نام مستعار را به صورت داخلی به یک فرمان گسترش می دهد و گزینه های تکمیل را برای دستور تکمیل شده برمی گرداند. این به این معنی است که padding برای یک نام مستعار دقیقاً مانند یک فرمان کامل عمل می کند.

در ادامه، ابتدا نحوه نصب full-alias و سپس پیکربندی آن را برای فعال کردن تکمیل برای همه نام‌های مستعار kubectl توضیح خواهم داد.

در حال نصب full-alias

اول از همه، full-alias بستگی دارد bash-completing. بنابراین، قبل از نصب full-alias، باید مطمئن شوید که bash-completion نصب شده است. دستورالعمل‌های نصب قبلاً برای Linux و MacOS ارائه شده است.

نکته مهم برای کاربران MacOS: مانند اسکریپت تکمیل خودکار kubectl، full-alias با 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

پس از راه اندازی مجدد پوسته، full-alias به طور کامل نصب می شود.

فعال کردن تکمیل خودکار برای نام‌های مستعار kubectl

نام مستعار از لحاظ فنی یک تابع wrapper را ارائه می دهد _complete_alias. این تابع نام مستعار را بررسی می کند و نکات تکمیلی را برای دستور مستعار برمی گرداند.

برای مرتبط کردن یک تابع با یک نام مستعار خاص، باید از مکانیزم Bash داخلی استفاده کنید کامل، برای نصب _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.

توجه داشته باشید که می توانید از full-alias برای هر نام مستعار موجود در سیستم خود استفاده کنید.

بنابراین، برای فعال کردن تکمیل خودکار برای همه نام‌های مستعار kubectl، باید دستور بالا را برای هر یک از آنها اجرا کنید. قطعه زیر دقیقاً این کار را انجام می دهد، مشروط بر اینکه نام مستعار kubectl را تنظیم کرده باشید ~/.kubectl-aliases:

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

این قطعه کد باید در شما قرار داده شود ~/.bashrc، پوسته فرمان را مجدداً راه اندازی کنید و تکمیل خودکار برای همه 800 نام مستعار kubectl در دسترس خواهد بود.

6. گسترش kubectl با افزونه ها

شروع با نسخه 1.12، kubectl پشتیبانی می کند مکانیسم پلاگین، که به شما امکان می دهد عملکردهای آن را با دستورات اضافی گسترش دهید.

اگر آشنایی دارید مکانیسم های پلاگین Git، سپس پلاگین های kubectl بر اساس همان اصل ساخته شده اند.

در این فصل، نحوه نصب افزونه ها، مکان یافتن آنها و نحوه ایجاد پلاگین های خود را توضیح خواهیم داد.

نصب پلاگین

پلاگین های Kubectl به صورت فایل های اجرایی ساده با نامی مانند توزیع می شوند kubectl-x. پیشوند kubectl- مورد نیاز است و به دنبال آن یک دستور فرعی جدید kubectl به شما امکان می دهد افزونه را فراخوانی کنید.

به عنوان مثال، افزونه hello به صورت فایلی به نام توزیع می شود kubectl-hello.

برای نصب افزونه باید فایل را کپی کنید kubectl-x به هر دایرکتوری در PATH خود بروید و آن را قابل اجرا کنید، به عنوان مثال با chmod +x. بلافاصله پس از این می توانید با افزونه تماس بگیرید kubectl x.

می توانید از دستور زیر برای لیست کردن تمام افزونه هایی که در حال حاضر روی سیستم شما نصب شده اند استفاده کنید:

$ kubectl plugin list

در صورتی که چندین افزونه با نام یکسان داشته باشید یا فایل افزونه ای وجود داشته باشد که قابل اجرا نیست، این دستور اخطارها را نیز نمایش می دهد.

پیدا کردن و نصب افزونه ها با استفاده از Krew

پلاگین های Kubectl را می توان مانند بسته های نرم افزاری به اشتراک گذاشت یا دوباره استفاده کرد. اما کجا می توانید افزونه هایی را که دیگران به اشتراک گذاشته اند پیدا کنید؟

پروژه کرو هدف آن ارائه یک راه حل یکپارچه برای اشتراک گذاری، جستجو، نصب و مدیریت افزونه های kubectl است. این پروژه خود را "مدیر بسته برای پلاگین های kubectl" می نامد (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 پیدا کنید.

توصیه می کنم به بخش GitHub مراجعه کنید پلاگین های kubectl. در آنجا ده ها پلاگین موجود را خواهید یافت که ارزش بررسی را دارند.

نوشتن افزونه های خود

خودت میتونی پلاگین ایجاد کنید - سخت نیست. شما باید یک فایل اجرایی بسازید که آنچه شما نیاز دارید را انجام دهد، آن را مانند نامگذاری کنید kubectl-x و طبق توضیحات بالا نصب کنید.

این فایل می تواند یک اسکریپت bash، یک اسکریپت پایتون یا یک برنامه GO کامپایل شده باشد - مهم نیست. تنها شرط این است که بتوان آن را مستقیماً در سیستم عامل اجرا کرد.

بیایید همین حالا یک نمونه پلاگین ایجاد کنیم. در قسمت قبل از دستور kubectl برای فهرست کردن کانتینرهای هر pod استفاده کردید. تبدیل این دستور به یک افزونه آسان است که می توانید با آن تماس بگیرید. 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-runtime، که به طور خاص برای نوشتن افزونه های kubectl وجود دارد.

چگونه پلاگین های خود را به اشتراک بگذارید

اگر فکر می‌کنید افزونه‌های شما می‌تواند برای دیگران مفید باشد، آن را در GitHub به اشتراک بگذارید. حتما آنها را به موضوع اضافه کنید پلاگین های kubectl.

همچنین می توانید درخواست کنید که افزونه شما به آن اضافه شود لیست کرو. دستورالعمل نحوه انجام این کار در مخازن GitHub.

تکمیل فرمان

افزونه ها در حال حاضر از تکمیل خودکار پشتیبانی نمی کنند. یعنی باید نام کامل افزونه و نام کامل آرگومان ها را وارد کنید.

مخزن GitHub kubectl برای این تابع است درخواست باز. بنابراین این امکان وجود دارد که این ویژگی در آینده اجرا شود.

موفق باشید

چه چیز دیگری در مورد موضوع بخوانید:

منبع: www.habr.com

نحوه استفاده موثرتر از kubectl: راهنمای دقیق