معرفی
کیوبکتل (kubectl) ابزار خط فرمان رسمی Kubernetes برای ارتباط با API کلاستر و مدیریت منابع آن است. با استفاده از این ابزار میتوانید وضعیت منابعی مانند Pod، Deployment، Service و Namespace را بررسی کنید، آنها را ایجاد یا ویرایش کنید و در صورت نیاز حذف کنید.
در تیمهایی که سرویسها را روی Kubernetes اجرا میکنند، میزان استفاده از kubectl به مسئولیتها و سطح دسترسی هر فرد بستگی دارد. برای نمونه، مهندس دواپس، مهندس کلود، مدیر سیستم یا توسعهدهندهای که مسئول استقرار، بررسی لاگها یا عیبیابی سرویسها است، ممکن است هر روز با این ابزار کار کند.
کار با kubectl به شناخت Kubernetes نیاز دارد و یادگیری فرمانها بهتنهایی کافی نیست. دستورهایی مانند delete ممکن است منابع فعال کلاستر را حذف کنند. بنابراین، پیش از کار با کلاسترهای اشتراکی یا عملیاتی باید با مفاهیمی مانند context، namespace، manifest و کنترل دسترسی آشنا شوید. Kubernetes برای نگهداری اتصالها، کاربران و contextهای چند کلاستر از فایل kubeconfig استفاده میکند. راهنمای رسمی پیکربندی دسترسی به چند کلاستر این سازوکار را توضیح میدهد.
پیش از اعمال تغییرهای مهم، context و namespace مقصد را بررسی کنید. همچنین، در دستورهایی که از گزینه dry-run پشتیبانی میکنند، میتوانید نتیجه عملیات را پیش از اعمال تغییرات ارزیابی کنید. گزینههای dry-run در مستندات kubectl apply شرح داده شدهاند.
کیوبکتل در کنار ابزارهایی مانند Helm و Kustomize استفاده میشود. Helm برای بستهبندی و انتشار برنامهها با استفاده از Chart کاربرد دارد و Kustomize امکان مدیریت و اعمال تغییرهای لایهای روی فایلهای manifest با فرمت YAML را فراهم میکند. kubectl میتواند پیکربندی Kustomize را با apply -k اعمال کند. این روش در مستندات رسمی Kustomize توضیح داده شده است.
Docker در فرایند ساخت ایمیج کانتینر کاربرد دارد، درحالیکه kubectl برای مدیریت منابع Kubernetes و کنترل اجرای کانتینرها در کلاستر استفاده میشود. Terraform نیز معمولا برای تعریف و ایجاد زیرساخت بهکار میرود، اما kubectl بیشتر بر مدیریت و بررسی منابع داخل کلاستر تمرکز دارد. Prometheus و Grafana نیز ابزارهای پایش و مشاهدهپذیری هستند. خروجی آنها میتواند به عیبیابی با kubectl جهت بدهد، اما جایگزین آن نیست.
برای استفاده مؤثر از kubectl، آشنایی با مفاهیمی مانند کانتینرسازی، مدیریت زیرساخت ابری، زیرساخت بهعنوان کد و پایش سامانهها نیز مفید است. شناخت کانتینرها به درک وضعیت Podها و ایمیجها کمک میکند. آشنایی با زیرساخت ابری و زیرساخت بهعنوان کد نیز در شناخت نحوه ایجاد و پیکربندی کلاستر مؤثر است. دادههای حاصل از پایش سامانهها هم میتوانند نقطه شروع مناسبی برای بررسی رخدادها و لاگها با kubectl باشند.
این ابزار را با نامهای دیگری نیز میشناسند:
- کوبکتل
- Kubernetes command-line tool
- Kubernetes CLI
ویژگیهای کلیدی
در ادامه، مهمترین موارد این بخش به تفکیک معرفی شدهاند.
-
مدیریت مستقیم منابع Kubernetes
منابعی مانند Pod، Deployment، Service، ConfigMap و Secret را از طریق API کلاستر ایجاد، مشاهده، ویرایش و حذف میکند. مرجع دستورها در مستندات رسمی kubectl است: kubernetes.io
-
اعمال فایلهای پیکربندی YAML
با دستورهایی مانند kubectl apply -f میتوانید وضعیت مطلوب منابع را از فایلهای manifest به کلاستر اعمال کنید. گزینهها و رفتار apply در مستندات رسمی آمده است: kubernetes.io
-
بررسی وضعیت و عیبیابی
دستورهای get، describe، logs و events برای یافتن Podهای ناموفق، رویدادهای زمانبندی و خطاهای اجرای کانتینر کاربرد دارند. مرجع دستورهای عیبیابی در مستندات kubectl است: kubernetes.io
-
کار با چند کلاستر و Namespace
از kubeconfig برای نگهداری اتصالها، کاربران و contextهای مختلف استفاده میکند و امکان انتخاب کلاستر یا namespace هدف را میدهد. راهنمای رسمی: kubernetes.io
-
اجرای دستور و انتقال پورت
با kubectl exec میتوانید در کانتینر دستور اجرا کنید و با kubectl port-forward یک پورت محلی را موقتاً به سرویس یا Pod وصل کنید. مرجع port-forward: kubernetes.io
-
پشتیبانی از Kustomize
میتواند پیکربندیهای Kustomize را با kubectl apply -k اعمال کند. این قابلیت برای مدیریت تفاوت محیطهای توسعه، آزمایش و عملیاتی مفید است. راهنمای رسمی: kubernetes.io
کاربردها
موارد زیر تصویری کلی از این بخش برای این ابزار ارائه میکنند.
-
بررسی خرابی یک سرویس پس از استقرار
وقتی نسخه جدید سرویس اجرا نمیشود، با kubectl get pods، kubectl describe pod و kubectl logs علتهایی مانند خطای ImagePull، CrashLoopBackOff یا مشکل متغیرهای محیطی را بررسی میکنید. مرجع دستورها: kubernetes.io
-
اعمال تغییر پیکربندی سرویس
تیم پس از بازبینی فایل YAML، تغییر Deployment یا Service را با kubectl apply -f اعمال میکند و سپس وضعیت rollout را کنترل میکند. جزئیات apply و dry-run: kubernetes.io
-
مشاهده منابع یک محیط مشخص
در کلاسترهای مشترک، با انتخاب context و namespace درست، فقط منابع محیط موردنظر مانند staging یا production را مشاهده و مدیریت میکنید. راهنمای context و kubeconfig: kubernetes.io
-
دسترسی موقت به سرویس داخلی
برای آزمایش یا عیبیابی سرویسی که از اینترنت در دسترس نیست، از kubectl port-forward برای اتصال موقت پورت محلی به Pod یا Service استفاده میشود. مرجع رسمی: kubernetes.io
-
اعمال پیکربندیهای محیطی با Kustomize
برای یک برنامه با تنظیمات متفاوت در چند محیط، overlayهای Kustomize را با kubectl apply -k اعمال میکنید تا manifest مناسب هر محیط ساخته و اجرا شود. راهنمای رسمی: kubernetes.io
پرسشهای رایج درباره کیوبکتل
اگر درباره این ابزار پرسشی دارید، ممکن است پاسخ آن را در میان موارد زیر پیدا کنید.
آیا برای یادگیری kubectl باید Kubernetes را بلد باشم؟
بله، در حد پایه. ابتدا مفهوم کلاستر، Node، Pod، Deployment، Service، Namespace و فایل YAML را یاد بگیرید. بدون این مفاهیم، حفظ کردن دستورها برای عیبیابی واقعی کافی نیست.
تفاوت kubectl با Kubernetes چیست؟
Kubernetes سامانه ارکستراسیون کانتینرها است. kubectl یک برنامه خط فرمان است که درخواستهای مدیریتی را به API Kubernetes میفرستد. مرجع رسمی kubectl: kubernetes.io
تفاوت kubectl با Helm و Kustomize چیست؟
kubectl ابزار تعامل مستقیم با کلاستر است. Helm برای بستهبندی و انتشار برنامهها با Chart استفاده میشود. Kustomize برای ساخت تغییرهای لایهای روی فایلهای YAML کاربرد دارد و میتواند از طریق kubectl اجرا شود. راهنمای Kustomize: kubernetes.io
چگونه از اعمال تغییر روی کلاستر اشتباه جلوگیری کنم؟
پیش از هر تغییر، context فعال را با kubectl config current-context و namespace هدف را بررسی کنید. برای تغییرهای حساس، خروجی manifest را بازبینی کنید، از dry-run استفاده کنید و دسترسیهای kubeconfig را محدود نگه دارید. راهنمای context: kubernetes.io و مرجع apply: kubernetes.io
آیا kubectl فقط برای مدیران دواپس است؟
خیر. توسعهدهندهای که برنامهاش روی Kubernetes اجرا میشود نیز برای دیدن لاگ، بررسی وضعیت استقرار و عیبیابی اولیه به kubectl نیاز دارد. اما سطح دسترسی او باید متناسب با مسئولیتش باشد.