فصل ۴ — دستورات رایج kubectl

ابزار خط فرمان kubectl قدرتمند است و در فصل‌های بعد از آن برای ساخت objectها و تعامل با API Kubernetes استفاده می‌کنید. اما قبل از آن منطقی است دستورات پایهٔ kubectl که به همهٔ objectهای Kubernetes اعمال می‌شوند را مرور کنیم.

Namespaceها

Kubernetes از namespace برای سازمان‌دهی objectها در کلاستر استفاده می‌کند. می‌توانید هر namespace را مثل پوشه‌ای تصور کنید که مجموعه‌ای از objectها را نگه می‌دارد. به‌طور پیش‌فرض ابزار خط فرمان kubectl با namespace پیش‌فرض تعامل می‌کند. اگر می‌خواهید namespace دیگری استفاده کنید، پرچم --namespace را به kubectl بدهید. مثلاً kubectl --namespace=mystuff به objectهای namespace mystuff اشاره می‌کند. اگر می‌خواهید با همهٔ namespaceها تعامل کنید — مثلاً فهرست همهٔ Podهای کلاستر — پرچم --all-namespaces را بدهید.

Contextها

اگر می‌خواهید namespace پیش‌فرض را دائمی‌تر تغییر دهید، می‌توانید از context استفاده کنید. این در فایل پیکربندی kubectl ثبت می‌شود که معمولاً در $HOME/.kube/config است. این فایل پیکربندی همچنین نحوهٔ یافتن و احراز هویت به کلاستر را ذخیره می‌کند. مثلاً می‌توانید context با namespace پیش‌فرض متفاوت برای دستورات kubectl بسازید:

$ kubectl config set-context my-context --namespace=mystuff

این context جدید می‌سازد، اما هنوز از آن استفاده نمی‌کند. برای استفاده از context تازه‌ساخته:

$ kubectl config use-context my-context

contextها همچنین برای مدیریت کلاسترهای مختلف یا کاربران مختلف برای احراز هویت به آن کلاسترها با پرچم‌های --users یا --clusters در دستور set-context به‌کار می‌روند.

مشاهدهٔ objectهای API Kubernetes

همه‌چیز در Kubernetes با یک منبع RESTful نمایش داده می‌شود. در این کتاب به این منابع objectهای Kubernetes می‌گوییم. هر object Kubernetes در یک مسیر HTTP یکتا وجود دارد؛ مثلاً https://your-k8s.com/api/v1/namespaces/default/pods/my-pod به نمایش یک Pod در namespace پیش‌فرض به نام my-pod می‌رسد. دستور kubectl درخواست‌های HTTP به این URLها می‌زند تا به objectهای Kubernetes در این مسیرها دسترسی پیدا کند.

پایه‌ای‌ترین دستور برای مشاهدهٔ objectهای Kubernetes از طریق kubectl دستور get است. اگر kubectl get <resource-name> اجرا کنید فهرستی از همهٔ منابع در namespace فعلی می‌گیرید. برای گرفتن منبع خاص: kubectl get <resource-name> <obj-name>.

به‌طور پیش‌فرض kubectl از printer قابل‌خواندن برای انسان برای نمایش پاسخ‌های سرور API استفاده می‌کند، اما این printer بسیاری از جزئیات objectها را حذف می‌کند تا هر object در یک خط ترمینال جا شود. یکی از راه‌های گرفتن کمی اطلاعات بیشتر افزودن پرچم -o wide است که جزئیات بیشتری در خط طولانی‌تر می‌دهد. اگر می‌خواهید object کامل را ببینید، می‌توانید objectها را به‌صورت JSON یا YAML خام با پرچم‌های -o json یا -o yaml ببینید.

گزینهٔ رایج برای دستکاری خروجی kubectl حذف headerهاست که اغلب وقتی kubectl را با pipeهای Unix ترکیب می‌کنید (مثلاً kubectl ... | awk ...) مفید است. با پرچم --no-headers، kubectl headerهای بالای جدول قابل‌خواندن برای انسان را رد می‌کند.

کار رایج دیگر استخراج فیلدهای خاص از object است. kubectl از زبان پرس‌وجوی JSONPath برای انتخاب فیلدها در object برگشتی استفاده می‌کند. جزئیات کامل JSONPath خارج از محدودهٔ این فصل است، اما به‌عنوان مثال این دستور آدرس IP Pod مشخص‌شده را استخراج و چاپ می‌کند:

$ kubectl get pods my-pod -o jsonpath --template={.status.podIP}

اگر به اطلاعات دقیق‌تر دربارهٔ object خاصی علاقه‌مندید، از دستور describe استفاده کنید:

$ kubectl describe <resource-name> <obj-name>

این توضیح چندخطی غنی و قابل‌خواندن برای انسان از object و هر object و event مرتبط دیگر در کلاستر Kubernetes را می‌دهد.

ساخت، به‌روزرسانی و حذف objectهای Kubernetes

objectها در API Kubernetes به‌صورت فایل‌های JSON یا YAML نمایش داده می‌شوند. این فایل‌ها یا در پاسخ به پرس‌وجو از سرور برمی‌گردند یا به‌عنوان بخشی از درخواست API به سرور ارسال می‌شوند. می‌توانید از این فایل‌های YAML یا JSON برای ساخت، به‌روزرسانی یا حذف objectها روی سرور Kubernetes استفاده کنید.

فرض کنید object ساده‌ای در obj.yaml دارید. با kubectl می‌توانید این object را در Kubernetes بسازید:

$ kubectl apply -f obj.yaml

توجه کنید نیازی به مشخص کردن نوع منبع object نیست؛ از خود فایل object گرفته می‌شود.

به‌همین‌ترتیب، پس از تغییر object دوباره از دستور apply برای به‌روزرسانی استفاده کنید:

$ kubectl apply -f obj.yaml

ابزار apply فقط objectهایی را تغییر می‌دهد که با objectهای فعلی کلاستر متفاوت باشند. اگر objectهایی که می‌سازید از قبل در کلاستر باشند، بدون تغییر با موفقیت خارج می‌شود. این آن را برای حلقه‌هایی مفید می‌کند که می‌خواهید وضعیت کلاستر با وضعیت filesystem مطابقت داشته باشد. می‌توانید مکرراً از apply برای هم‌راستا کردن وضعیت استفاده کنید.

اگر می‌خواهید ببینید دستور apply چه می‌کند بدون اعمال واقعی تغییرات، پرچم --dry-run را بزنید تا objectها در ترمینال چاپ شوند بدون ارسال به سرور.

اگر به‌جای ویرایش فایل محلی ترجیح می‌دهید ویرایش تعاملی کنید، می‌توانید از دستور edit استفاده کنید که آخرین وضعیت object را دانلود می‌کند و ویرایشگری با تعریف object باز می‌کند:

$ kubectl edit <resource-name> <obj-name>

پس از ذخیرهٔ فایل، به‌طور خودکار دوباره به کلاستر Kubernetes آپلود می‌شود.

دستور apply همچنین تاریخچهٔ پیکربندی‌های قبلی را در annotation داخل object ثبت می‌کند. می‌توانید این رکوردها را با دستورات edit-last-applied، set-last-applied و view-last-applied دستکاری کنید. مثلاً:

$ kubectl apply -f myobj.yaml view-last-applied

آخرین وضیتی که روی object اعمال شده را نشان می‌دهد.

وقتی می‌خواهید object را حذف کنید:

$ kubectl delete -f obj.yaml

مهم است توجه کنید kubectl برای تأیید حذف از شما سؤال نمی‌کند. با صدور دستور، object حذف می‌شود.

به‌همین‌ترتیب می‌توانید object را با نوع منبع و نام حذف کنید:

$ kubectl delete <resource-name> <obj-name>

برچسب‌گذاری و annotation روی objectها

label و annotation برچسب‌هایی برای objectهای شما هستند. تفاوت‌ها را در فصل ۶ بحث می‌کنیم، اما فعلاً می‌توانید label و annotation روی هر object Kubernetes را با دستورات annotate و label به‌روز کنید. مثلاً برای افزودن label color=red به Pod به نام bar:

$ kubectl label pods bar color=red

نحو annotation یکسان است.

به‌طور پیش‌فرض label و annotate اجازهٔ بازنویسی label موجود را نمی‌دهند. برای این کار پرچم --overwrite لازم است.

اگر می‌خواهید label را حذف کنید، از نحو <label-name>- استفاده کنید:

$ kubectl label pods bar color-

این label color را از Pod به نام bar حذف می‌کند.

دستورات دیباگ

kubectl تعداد زیادی دستور برای دیباگ containerهای شما دارد. برای دیدن logهای container در حال اجرا:

$ kubectl logs <pod-name>

اگر چند container در Pod دارید، با پرچم -c container مورد نظر را انتخاب کنید.

به‌طور پیش‌فرض kubectl logs logهای فعلی را فهرست می‌کند و خارج می‌شود. اگر می‌خواهید logها به‌طور پیوسته به ترمینال stream شوند بدون خروج، پرچم -f (follow) را اضافه کنید.

همچنین می‌توانید با دستور exec در container در حال اجرا دستور اجرا کنید:

$ kubectl exec -it <pod-name> -- bash

این shell تعاملی داخل container در حال اجرا می‌دهد تا دیباگ بیشتری انجام دهید.

اگر bash یا ترمینال دیگری در container ندارید، همیشه می‌توانید به process در حال اجرا attach کنید:

$ kubectl attach -it <pod-name>

این به process در حال اجرا attach می‌شود. شبیه kubectl logs است اما ورودی به process در حال اجرا می‌فرستد، به‌شرطی که process برای خواندن از standard input تنظیم شده باشد.

همچنین می‌توانید فایل‌ها را به و از container با دستور cp کپی کنید:

$ kubectl cp <pod-name>:</path/to/remote/file> </path/to/local/file>

این فایل را از container در حال اجرا به ماشین محلی کپی می‌کند. می‌توانید دایرکتوری مشخص کنید یا نحو را معکوس کنید تا فایل از ماشین محلی به container کپی شود.

اگر می‌خواهید از طریق شبکه به Pod دسترسی پیدا کنید، از دستور port-forward برای forward کردن ترافیک شبکه از ماشین محلی به Pod استفاده کنید. این امکان تونل امن ترافیک شبکه به containerهایی را می‌دهد که شاید در شبکهٔ عمومی در دسترس نباشند. مثلاً دستور زیر:

$ kubectl port-forward <pod-name> 8080:80

اتصالی باز می‌کند که ترافیک از ماشین محلی روی پورت ۸۰۸۰ به container راه‌دور روی پورت ۸۰ forward می‌شود.

می‌توانید دستور port-forward را با service هم استفاده کنید با مشخص کردن services/<service-name> به‌جای <pod-name>، اما توجه کنید اگر به service port-forward کنید، درخواست‌ها فقط به یک Pod در آن service forward می‌شوند. از load balancer سرویس عبور نمی‌کنند.

در نهایت اگر به نحوهٔ استفادهٔ کلاستر از منابع علاقه‌مندید، از دستور top برای دیدن فهرست منابع در حال استفاده توسط nodeها یا Podها استفاده کنید. این دستور:

kubectl top nodes

مجموع CPU و memory در حال استفاده توسط nodeها را هم به واحدهای مطلق (مثلاً core) و هم به درصد منابع در دسترس (مثلاً تعداد کل coreها) نمایش می‌دهد.

به‌همین‌ترتیب این دستور:

kubectl top pods

همهٔ Podها و مصرف منابعشان را نشان می‌دهد. به‌طور پیش‌فرض فقط Podهای namespace فعلی را نمایش می‌دهد، اما پرچم --all-namespaces را اضافه کنید تا مصرف منابع همهٔ Podهای کلاستر را ببینید.

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

kubectl از یکپارچگی با shell شما برای تکمیل خودکار tab هم برای دستورات و هم منابع پشتیبانی می‌کند. بسته به محیط ممکن است قبل از فعال‌سازی تکمیل خودکار دستور، بستهٔ bash-completion را نصب کنید. با package manager مناسب:

# macOS
brew install bash-completion

# CentOS/Red Hat
yum install bash-completion

# Debian/Ubuntu
apt-get install bash-completion

در macOS حتماً دستورالعمل brew دربارهٔ فعال‌سازی tab completion با ${HOME}/.bash_profile را دنبال کنید.

پس از نصب bash-completion، می‌توانید موقتاً برای ترمینال فعال کنید:

source <(kubectl completion bash)

برای خودکار شدن در هر ترمینال، به فایل ${HOME}/.bashrc اضافه کنید:

echo "source <(kubectl completion bash)" >> ${HOME}/.bashrc

اگر از zsh استفاده می‌کنید دستورالعمل مشابه را آنلاین پیدا می‌کنید.

راه‌های جایگزین مشاهدهٔ کلاستر

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

مثلاً افزونه‌هایی برای چند ویرایشگر وجود دارد که Kubernetes و محیط ویرایشگر را یکپارچه می‌کنند، از جمله:

• Visual Studio Code
• IntelliJ
• Eclipse

علاوه بر این، یک برنامهٔ موبایل متن‌باز وجود دارد که دسترسی به کلاستر از تلفن را ممکن می‌کند.

خلاصه

kubectl ابزار قدرتمندی برای مدیریت برنامه‌های شما در کلاستر Kubernetes است. این فصل بسیاری از کاربردهای رایج ابزار را نشان داد، اما kubectl help داخلی زیادی دارد. می‌توانید با این دستور help را ببینید:

$ kubectl help

یا:

$ kubectl help <command-name>