🥇 كيفية استخدام kubectl بشكل أكثر كفاءة: دليل مفصل

إذا كنت تعمل مع Kubernetes ، فمن المحتمل أن يكون kubectl أحد أكثر الأدوات المساعدة استخدامًا. وكلما قضيت الكثير من الوقت في العمل باستخدام أداة معينة ، فإن الأمر يستحق أن تتعلمها جيدًا وتتعلم كيفية استخدامها بفعالية.

فريق Kubernetes aaS من Mail.ru ترجمة مقال لدانييل ويبل يقدم النصائح والحيل للعمل بفعالية مع kubectl. سيساعدك أيضًا على فهم كيفية عمل Kubernetes بشكل أفضل.

وفقًا للمؤلف ، فإن الغرض من المقالة هو جعل عملك اليومي مع Kubernetes ليس أكثر كفاءة فحسب ، بل أكثر إمتاعًا أيضًا!

مقدمة: ما هو kubectl

قبل أن تتعلم كيفية استخدام kubectl بشكل أكثر فاعلية ، تحتاج إلى الحصول على فهم أساسي لما هو وكيف يعمل.

من وجهة نظر المستخدم ، kubectl عبارة عن لوحة تحكم تتيح لك إجراء عمليات Kubernetes.

من وجهة نظر فنية ، kubectl هو عميل Kubernetes API.

Kubernetes API هي واجهة برمجة تطبيقات HTTP REST. واجهة برمجة التطبيقات هذه هي واجهة مستخدم Kubernetes الحقيقية التي يتم التحكم فيها بالكامل من خلالها. هذا يعني أن كل عملية Kubernetes يتم عرضها كنقطة نهاية لواجهة برمجة التطبيقات ويمكن إجراؤها مع طلب HTTP لنقطة النهاية هذه.

لذلك ، فإن المهمة الرئيسية لـ kubectl هي إرسال طلبات HTTP إلى Kubernetes API:

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 لخادم واجهة برمجة التطبيقات إلى مسارات نقطة النهاية المدرجة في مرجع واجهة برمجة التطبيقات.

ومن ثم ، عند تنفيذ الأمر أعلاه ، يرسل kubectl طلب HTTP POST إلى نقطة نهاية API أعلاه. تعريف ReplicaSet الذي قدمته في الملف replicaset.yaml، تم تمريره في نص الطلب.

هذه هي الطريقة التي يعمل بها kubectl لجميع الأوامر التي تتفاعل مع مجموعة Kubernetes. في كل هذه الحالات ، يرسل kubectl طلبات HTTP إلى نقاط نهاية Kubernetes API المناسبة.

يرجى ملاحظة أنه يمكنك إدارة Kubernetes بالكامل باستخدام أداة مساعدة مثل curlعن طريق إرسال طلبات HTTP يدويًا إلى Kubernetes API. يجعل Kubectl من السهل استخدام Kubernetes API.

هذه هي أساسيات ماهية kubectl وكيف يعمل. ولكن هناك شيء آخر حول Kubernetes API يجب على كل مستخدم kubectl معرفته. دعنا نغوص بإيجاز في عالم Kubernetes الداخلي.

العالم الداخلي لـ Kubernetes

يتكون Kubernetes من مجموعة من المكونات المستقلة التي تعمل كعمليات منفصلة على عقد المجموعة. تعمل بعض المكونات على العقد الرئيسية ، بينما تعمل المكونات الأخرى على العقد العاملة ، حيث يؤدي كل مكون مهمته الخاصة.

فيما يلي أهم المكونات في العقد الرئيسية:

التخزين - يخزن تعريفات الموارد (عادة ما يكون إلخ).
خادم API - يوفر API ويدير التخزين.
مدير تحكم - يضمن أن حالات الموارد تتوافق مع المواصفات.
مخطط - جدولة القرون على عقد العمال.

وهنا أحد أهم المكونات في عقد العمال:

kubelet - يدير إطلاق الحاويات على عقدة العمل.

لفهم كيفية عمل هذه المكونات معًا ، ضع في اعتبارك مثالاً.

لنفترض أنك فعلت للتو kubectl create -f replicaset.yaml، وبعد ذلك قدم kubectl طلب HTTP POST إلى نقطة نهاية API ReplicaSet (بتمرير تعريف مورد ReplicaSet).

ماذا يحدث في الكتلة؟

بعد القيام kubectl create -f replicaset.yaml يخزن خادم API تعريف مورد ReplicaSet في المتجر:
بعد ذلك ، يتم تشغيل وحدة التحكم ReplicaSet في مدير وحدة التحكم ، والذي يتولى إنشاء وتعديل وحذف موارد ReplicaSet:
تنشئ وحدة التحكم ReplicaSet تعريفًا للقرص لكل مجموعة ReplicaSet (وفقًا لقالب pod في تعريف ReplicaSet) وتخزنها في المتجر:
يبدأ المجدول ، مع تتبع البودات التي لم يتم تعيينها بعد لأي عقدة عاملة:
يحدد المجدول العقدة العاملة المناسبة لكل جراب ويضيف هذه المعلومات إلى تعريف البود في المستودع:
في العقدة العاملة التي تم تعيين جراب لها ، يبدأ Kubelet في العمل ويتتبع القرون المخصصة لتلك العقدة:
يقرأ Kubelet تعريف البود من المستودع ويوجه وقت تشغيل الحاوية مثل Docker لتشغيل الحاويات على العقدة:

فيما يلي النسخة النصية لهذا الوصف.

تتم معالجة طلب API إلى نقطة نهاية إنشاء مجموعة النسخ المتماثلة بواسطة خادم واجهة برمجة التطبيقات. يصادق خادم API الطلب ويخزن تعريف مورد ReplicaSet في التخزين.

يبدأ هذا الحدث وحدة تحكم ReplicaSet ، وهي عملية فرعية لمدير وحدة التحكم. تراقب وحدة التحكم ReplicaSet إنشاء موارد ReplicaSet وتحديثها وحذفها في المخزن وتتلقى إعلامًا بالحدث عند حدوثه.

مهمة وحدة التحكم ReplicaSet هي التأكد من وجود العدد المطلوب من ReplicaSet Replica Pods. في مثالنا ، لا توجد كبسولات حتى الآن ، لذلك تقوم وحدة التحكم ReplicaSet بإنشاء تعريفات pod هذه (وفقًا لقالب pod في تعريف ReplicaSet) وحفظها في المتجر.

يؤدي إنشاء حاضنات جديدة إلى بدء برنامج الجدولة ، الذي يتتبع تعريفات البودات التي لم تتم جدولتها بعد لعقد العمال. يحدد المجدول العقدة العاملة المناسبة لكل حجرة ويقوم بتحديث تعريفات البود في المستودع.

لاحظ أنه حتى هذه النقطة ، لم يتم تشغيل أي رمز حمل عمل في أي مكان في المجموعة. كل ما تم القيام به حتى الآن - إنه يقوم بإنشاء وتحديث الموارد في التخزين على العقدة الرئيسية.

يبدأ الحدث الأخير Kubelet ، الذي يتتبع البودات المجدولة لعقد العمال الخاصة بهم. يجب أن يوجه kubelet الخاصة بالعقدة العاملة التي تم تثبيت مجموعات ReplicaSet الخاصة بك من أجلها وقت تشغيل الحاوية ، مثل Docker ، لتنزيل صور الحاوية المطلوبة وتشغيلها.

في هذه المرحلة ، يتم تشغيل تطبيق ReplicaSet الخاص بك أخيرًا!

دور Kubernetes API

كما رأيت في المثال السابق ، فإن مكونات Kubernetes (باستثناء خادم واجهة برمجة التطبيقات والتخزين) تراقب التغييرات في الموارد الموجودة في التخزين وتغير المعلومات حول الموارد الموجودة في التخزين.

بالطبع ، لا تتفاعل هذه المكونات بشكل مباشر مع التخزين ، ولكن فقط من خلال Kubernetes API.

تأمل الأمثلة التالية:

تستخدم وحدة تحكم ReplicaSet نقطة نهاية API قائمة مجموعات المقلدة مع المعلمة watch لمراقبة التغييرات على موارد ReplicaSet.
تستخدم وحدة تحكم ReplicaSet نقطة نهاية API إنشاء جراب (إنشاء جراب) لإنشاء القرون.
يستخدم المجدول نقطة نهاية API جراب التصحيح (تغيير الحجرة) لتحديث البودات بمعلومات حول عقدة العامل المحددة.

كما ترى ، هذه هي نفس واجهة برمجة التطبيقات التي يصل إليها kubectl. يعد استخدام نفس واجهة برمجة التطبيقات للمكونات الداخلية والمستخدمين الخارجيين مفهومًا أساسيًا لتصميم Kubernetes.

الآن يمكننا تلخيص كيفية عمل Kubernetes:

يحتفظ المتجر بالحالة ، أي موارد Kubernetes.
يوفر خادم API واجهة للتخزين في شكل Kubernetes API.
تقوم جميع مكونات ومستخدمي Kubernetes الآخرين بقراءة حالة (موارد) Kubernetes ومراقبتها والتعامل معها من خلال واجهة برمجة التطبيقات.

ستساعدك معرفة هذه المفاهيم على فهم kubectl بشكل أفضل وتحقيق أقصى استفادة منه.

الآن دعنا نلقي نظرة على بعض النصائح والحيل المحددة لمساعدتك على زيادة إنتاجيتك مع kubectl.

1. تسريع الإدخال مع إكمال الأمر

واحدة من أكثر حيل أداء kubectl فائدة ولكن غالبًا ما يتم تجاهلها هي إكمال الأوامر.

يتيح لك إكمال الأمر إكمال أجزاء معينة من أوامر kubectl تلقائيًا باستخدام مفتاح Tab. يعمل هذا مع الأوامر الفرعية والخيارات والوسيطات ، بما في ذلك المعقدة مثل أسماء الموارد.

شاهد كيف يعمل إكمال أوامر kubectl:

استكمال القيادة لقذائف Bash و Zsh.

الدليل الرسمي يحتوي على إرشادات مفصلة لإعداد الإكمال التلقائي ، ولكن أدناه سنقدم مقتطفًا قصيرًا.

كيف يعمل إكمال الأمر

إكمال الأمر هو دالة قذيفة تعمل بمساعدة البرنامج النصي للإكمال. نص تكميلي - برنامج نصي للقذيفة يحدد سلوك المكمل لأمر معين.

يقوم Kubectl تلقائيًا بإنشاء وإخراج البرامج النصية الإضافية لـ Bash و Zsh بالأوامر التالية:

$ kubectl completion bash

Или:

$ kubectl completion zsh

نظريًا ، يكفي توصيل إخراج هذه الأوامر بقذيفة الأوامر المناسبة حتى يتمكن kubectl من إكمال الأوامر.

من الناحية العملية ، تختلف طريقة الاتصال بالنسبة إلى Bash (بما في ذلك الاختلافات بين Linux و MacOS) و Zsh. سننظر في كل هذه الخيارات أدناه.

باش على لينكس

يعتمد البرنامج النصي لإكمال Bash على حزمة bash-complete ، لذلك تحتاج إلى تثبيته أولاً:

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

يمكنك اختبار تثبيت الحزمة بنجاح باستخدام الأمر التالي:

$ type _init_completion

إذا كان هذا يطبع رمز وظيفة shell ، فسيتم ضبط إكمال bash بشكل صحيح. إذا أعطى الأمر خطأ "لم يتم العثور عليه" ، فأنت بحاجة إلى إضافة السطر التالي إلى ملفك ~ / .bashrc:

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

هل أحتاج إلى إضافة هذا السطر إلى الملف ~ / .bashrc أو لا يعتمد على مدير الحزم الذي استخدمته لتثبيت إكمال bash. تتطلب APT هذا ، ولكن YUM لا تتطلب ذلك.

بمجرد تثبيت bash-complete ، نحتاج إلى إعداد كل شيء حتى يتم تمكين البرنامج النصي لإكمال kubectl في جميع جلسات shell.

تتمثل إحدى طرق القيام بذلك في إضافة السطر التالي إلى الملف ~ / .bashrc:

source <(kubectl completion bash)

طريقة أخرى هي إضافة البرنامج النصي لإضافة kubectl إلى الدليل /etc/bash_completion.d (قم بإنشائه إذا لم يكن موجودًا):

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

جميع البرامج النصية الإضافية في الدليل /etc/bash_completion.d تم تضمينه تلقائيًا في bash-complete.

كلا الخيارين قابلة للتطبيق على قدم المساواة.

بعد إعادة تحميل الصدفة ، سيعمل إكمال أمر kubectl.

bash على macOS

في نظام MacOS ، يكون الإعداد أكثر تعقيدًا إلى حد ما. الحقيقة هي أنه افتراضيًا على نظام التشغيل MacOS ، يتم تثبيت الإصدار 3.2 من Bash ، ويتطلب البرنامج النصي للإكمال التلقائي kubectl إصدار Bash 4.1 على الأقل ولا يعمل في Bash 3.2.

يرتبط استخدام إصدار قديم من Bash على نظام MacOS بقضايا الترخيص. يتم توزيع Bash الإصدار 4 بموجب ترخيص GPLv3 ، وهو غير مدعوم من قبل Apple.

لإعداد الإكمال التلقائي kubectl على نظام MacOS ، تحتاج إلى تثبيت إصدار أحدث من Bash. يمكنك أيضًا تعيين Bash المحدث باعتباره الصدفة الافتراضية ، مما سيوفر لك الكثير من المشاكل في المستقبل. إنه أمر سهل ، وترد التفاصيل في المقالة "ترقية Bash على macOS".

قبل المتابعة ، تأكد من أنك تستخدم أحدث إصدار من Bash (تحقق من الإخراج bash --version).

يختلف سكريبت الإكمال التلقائي لـ Bash حسب المشروع إكمال باشلذلك تحتاج إلى تثبيته أولاً.

يمكنك تثبيت bash-complete مع ملفات البيرة:

$ brew install bash-completion@2

ومن @2 لتقف على إصدار bash-complete 2. يتطلب إكمال kubectl إصدار bash-complete v2 ، ويتطلب bash-complete v2 إصدار Bash 4.1 على الأقل.

إخراج الأمر brew-install يحتوي على قسم تحذيرات يخبرك بما يجب إضافته إلى الملف ~/.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. في هذه الحالة ، سيكون الإكمال التلقائي متاحًا ليس فقط في الغلاف الرئيسي ، ولكن أيضًا في الصدفة الفرعية.

بعد إعادة تشغيل shell ، يمكنك التحقق من صحة التثبيت باستخدام الأمر التالي:

$ type _init_completion

إذا رأيت دالة shell في الإخراج ، فسيتم إعداد كل شيء بشكل صحيح.

الآن نحن بحاجة إلى تمكين الإكمال التلقائي kubectl في جميع الجلسات.

إحدى الطرق هي إضافة السطر التالي إلى ملف ~/.bashrc:

source <(kubectl completion bash)

الطريقة الثانية هي إضافة نص الإكمال التلقائي إلى المجلد /usr/local/etc/bash_completion.d:

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

لن تعمل هذه الطريقة إلا إذا قمت بتثبيت bash-complete مع Homebrew. في هذه الحالة ، سيتم تحميل جميع البرامج النصية من هذا الدليل.

إذا قمت بتثبيت ملفات kubectl مع البيرة، فلن تحتاج إلى تنفيذ الخطوة السابقة ، حيث سيتم وضع نص الإكمال التلقائي تلقائيًا في المجلد /usr/local/etc/bash_completion.d أثناء التثبيت. في هذه الحالة ، سيبدأ إكمال kubectl في العمل بمجرد تثبيت bash-complete.

في النهاية ، كل هذه الخيارات متكافئة.

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 يظهر فقط المستوى الأول من تداخل الحقول.

انظر كيف تبدو يمكنك بعد ذلك.

يمكنك عرض الشجرة بأكملها إذا قمت بإضافة الخيار --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.

لنفترض الآن أنك تريد إضافة عمود إضافي إلى الإخراج ، على سبيل المثال إظهار العقدة التي يعمل عليها كل Pod. للقيام بذلك ، يمكنك ببساطة إضافة مواصفات العمود المناسبة إلى خيار الأعمدة المخصصة:

$ 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. في هذه الحالة ، سيتم دمج كل هذه الملفات في تكوين واحد مشترك في وقت التشغيل. يمكنك أيضًا تغيير ملف kubeconfig الافتراضي عن طريق تشغيل kubectl باستخدام المعلمة --kubeconfig. يرى الوثائق الرسمية.

ملفات kubeconfig

دعنا نرى بالضبط ما يحتويه ملف kubeconfig:

كما ترى ، يحتوي ملف kubeconfig على مجموعة من السياقات. يتكون السياق من ثلاثة عناصر:

الكتلة - عنوان URL لواجهة برمجة تطبيقات خادم الكتلة.
المستخدم - أوراق اعتماد مصادقة المستخدم في الكتلة.
Namespace - مساحة الاسم المستخدمة عند الانضمام إلى الكتلة.

في الممارسة العملية ، غالبًا ما يستخدمون سياقًا واحدًا لكل مجموعة في kubeconfig الخاص بهم. ومع ذلك ، يمكن أن يكون لديك سياقات متعددة لكل مجموعة ، تختلف حسب المستخدم أو مساحة الاسم. ومع ذلك ، فإن هذا التكوين متعدد السياقات ليس شائعًا ، لذلك عادة ما يكون هناك تعيين واحد لواحد بين المجموعات والسياقات.

في أي وقت ، يكون أحد السياقات حاليًا:

عندما يقرأ kubectl ملف التكوين ، فإنه يأخذ دائمًا المعلومات من السياق الحالي. في المثال أعلاه ، سيتصل kubectl بمجموعة هير.

وفقًا لذلك ، للتبديل إلى مجموعة أخرى ، تحتاج إلى تغيير السياق الحالي في ملف kubeconfig:

الآن سوف يتصل kubectl بمجموعة Fox.

للتبديل إلى مساحة اسم مختلفة في نفس المجموعة ، تحتاج إلى تغيير قيمة عنصر مساحة الاسم للسياق الحالي:

في المثال أعلاه ، سيستخدم kubectl مساحة اسم Prod من مجموعة Fox (تم تعيين مساحة اسم الاختبار مسبقًا).

لاحظ أن kubectl يوفر أيضًا خيارات --cluster, --user, --namespace и --context، والذي يسمح لك بالكتابة فوق العناصر الفردية والسياق الحالي نفسه ، بغض النظر عما تم تعيينه في kubeconfig. يرى kubectl options.

نظريًا ، يمكنك تغيير الإعدادات يدويًا في kubeconfig. لكن هذا غير مريح. لتبسيط هذه العمليات ، هناك العديد من الأدوات المساعدة التي تسمح لك بتغيير المعلمات في الوضع التلقائي.

استخدم kubectx

أداة شائعة جدًا للتبديل بين المجموعات ومساحات الأسماء.

توفر الأداة المساعدة الأوامر kubectx и kubens لتغيير السياق الحالي ومساحة الاسم على التوالي.

كما ذكرنا سابقًا ، يعني تغيير السياق الحالي تغيير المجموعة إذا كان لديك سياق واحد فقط لكل مجموعة.

فيما يلي مثال على تشغيل هذه الأوامر:

في جوهرها ، تقوم هذه الأوامر ببساطة بتحرير ملف kubeconfig ، كما هو موضح أعلاه.

لتثبيت kubectx، اتبع التعليمات الموجودة على جيثب.

يدعم كلا الأمرين الإكمال التلقائي للسياق وأسماء مساحة الاسم ، لذلك لا يتعين عليك كتابتها بالكامل. تعليمات الإكمال التلقائي هنا.

ميزة أخرى مفيدة kubectx هو الوضع التفاعلي. يعمل جنبًا إلى جنب مع الأداة المساعدة و ZFوالتي يجب تثبيتها بشكل منفصل. يؤدي تثبيت fzf تلقائيًا إلى تمكين الوضع التفاعلي في kubectx. في الوضع التفاعلي ، يمكنك اختيار السياق ومساحة الاسم من خلال واجهة البحث المجانية التفاعلية التي توفرها fzf.

استخدام الأسماء المستعارة للقذيفة

لا تحتاج إلى أدوات منفصلة لتغيير السياق الحالي ومساحة الاسم لأن kubectl يوفر أيضًا أوامر للقيام بذلك. نعم الفريق kubectl config يوفر أوامر فرعية لتحرير ملفات kubeconfig.

وهنا بعض منها:

kubectl config get-contexts: عرض كل السياقات.
kubectl config current-context: احصل على السياق الحالي ؛
kubectl config use-context: تغيير السياق الحالي ؛
kubectl config set-context: تغيير عنصر السياق.

ومع ذلك ، فإن استخدام هذه الأوامر مباشرة ليس مناسبًا جدًا لأنها طويلة. يمكنك عمل أسماء مستعارة من shell ، والتي يسهل تنفيذها.

لقد قمت بإنشاء مجموعة من الأسماء المستعارة بناءً على هذه الأوامر التي توفر وظائف مشابهة لـ 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

تعد الأسماء المستعارة لـ Shell طريقة جيدة لتسريع الكتابة. مشروع kubectl- الأسماء المستعارة يحتوي على حوالي 800 اختصار لأوامر kubectl الأساسية.

قد تتساءل - كيف تتذكر 800 اسم مستعار؟ لكن لا داعي لتذكرها جميعًا ، لأنها مبنية وفقًا لمخطط بسيط ، وهو موضح أدناه:

على سبيل المثال:

kgpooyaml - kubectl الحصول على القرون oyaml
ksysgsvcw - kubectl -n kube-system get 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 (لا يوجد حاليًا أي اسم مستعار لمورد الأدوار).
للحصول على بيانات لحجرة معينة ، يمكنك استخدام الأمر 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 ، فإن الإكمال التلقائي لا يعمل.

مشروع الاسم المستعار الكامل يوفر حلاً عامًا لهذه المشكلة. يتصل بآلية الحشو للاسم المستعار ، ويضفي على الاسم المستعار أمرًا داخليًا ويعيد خيارات الحشو للأمر المبطن. هذا يعني أن إضافة الاسم المستعار تتصرف تمامًا مثل الأمر الكامل.

بعد ذلك ، سأشرح أولاً كيفية تثبيت الاسم المستعار الكامل ثم كيفية تكوينه لتمكين الإكمال لجميع الأسماء المستعارة kubectl.

تثبيت الاسم المستعار الكامل

بادئ ذي بدء ، يعتمد الاسم المستعار الكامل على إكمال باش. لذلك ، قبل تثبيت الاسم المستعار الكامل ، تحتاج إلى التأكد من تثبيت bash-complete. تم تقديم إرشادات التثبيت مسبقًا لنظامي Linux و MacOS.

ملاحظة مهمة لمستخدمي macOS: مثل البرنامج النصي لإكمال kubectl ، لا يعمل الاسم المستعار الكامل مع Bash 3.2 ، وهو الإعداد الافتراضي في نظام MacOS. على وجه الخصوص ، يعتمد الاسم المستعار الكامل على إكمال bash v2 (brew install bash-completion@2) ، والذي يتطلب على الأقل Bash 4.1. هذا يعني أنك بحاجة إلى تثبيت إصدار أحدث من Bash لاستخدام الاسم المستعار الكامل على نظام MacOS.

تحتاج إلى تنزيل البرنامج النصي bash_completion.sh من مستودع جيثب وقم بتضمينه في ملفك ~/.bashrc:

source ~/bash_completion.sh

بعد إعادة تشغيل shell ، سيتم تثبيت الاسم المستعار الكامل بالكامل.

تمكين الإكمال التلقائي للأسماء المستعارة kubectl

من الناحية الفنية ، يوفر الاسم المستعار الكامل وظيفة غلاف _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.

لاحظ أنه يمكنك استخدام الاسم المستعار الكامل بهذه الطريقة لأي اسم مستعار على نظامك.

لذلك ، لتمكين الإكمال التلقائي لجميع الأسماء المستعارة kubectl ، تحتاج إلى تشغيل الأمر أعلاه لكل منها. المقتطف التالي يفعل ذلك بالضبط ، بشرط أن تكون قد قمت بتثبيت kubectl-aliases في ~/.kubectl-aliases:

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

يجب وضع هذا الجزء من التعليمات البرمجية في ملف ~/.bashrc، أعد تحميل الغلاف وسيتم إكمال جميع الأسماء المستعارة kubectl البالغ عددها 800 تلقائيًا.

6. قم بتوسيع kubectl مع الإضافات

ابتداء من الإصدار 1.12، يدعم kubectl آلية البرنامج المساعد، والتي تسمح لك بتوسيع وظائفها بأوامر إضافية.

إذا كنت معتادًا على آليات البرنامج المساعد Git، kubectl plugins مبنية بنفس الطريقة.

في هذا الفصل ، سنغطي كيفية تثبيت المكونات الإضافية ، ومكان العثور عليها ، وكيفية إنشاء الإضافات الخاصة بك.

تثبيت الإضافات

يتم توزيع ملحقات 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. يمكنك العثور على تعليمات مفصلة في صفحة جيثب.

أهم أوامر 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 وتثبيته كما هو موضح أعلاه.

يمكن أن يكون الملف عبارة عن نص برمجي باش ، أو نص بيثون ، أو جوروتين مترجم ، لا يهم. الشرط الوحيد هو أنه يمكن تنفيذه مباشرة في نظام التشغيل.

لنقم بإنشاء مثال مكون إضافي الآن. في القسم السابق ، استخدمت الأمر kubectl لسرد الحاويات لكل جراب. يمكنك بسهولة تحويل هذا الأمر إلى مكون إضافي يمكنك الاتصال به ، على سبيل المثال kubectl img.

قم بإنشاء ملف kubectl-img المحتوى التالي:

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

الآن اجعل الملف قابلاً للتنفيذ بامتداد chmod +x kubectl-img ونقله إلى أي دليل في المسار الخاص بك. بعد ذلك مباشرة يمكنك استخدام البرنامج المساعد kubectl img.

كما ذكرنا ، يمكن كتابة ملحقات kubectl بأي لغة برمجة أو برمجة نصية. إذا كنت تستخدم برامج نصية shell ، فإن الميزة هي أنه يمكنك بسهولة استدعاء kubectl من البرنامج المساعد. ومع ذلك ، يمكنك كتابة مكونات إضافية أكثر تعقيدًا في لغات البرمجة الحقيقية باستخدام مكتبة عملاء Kubernetes. إذا كنت تستخدم Go ، فيمكنك أيضًا استخدام مكتبة cli-runtime، والذي يوجد خصيصًا لكتابة ملحقات kubectl.

كيفية مشاركة الإضافات الخاصة بك

إذا كنت تعتقد أن المكونات الإضافية الخاصة بك قد تكون مفيدة للآخرين ، فلا تتردد في مشاركتها على GitHub. تأكد من إضافتهم إلى الموضوع ملحقات kubectl.

يمكنك أيضًا طلب إضافة المكون الإضافي الخاص بك إلى قائمة الطاقم. توجد تعليمات حول كيفية القيام بذلك مستودعات جيثب.

إتمام الأمر

لا تدعم المكونات الإضافية حاليًا الإكمال التلقائي. بمعنى أنه يجب عليك إدخال الاسم الكامل للمكون الإضافي والأسماء الكاملة للوسيطات.

يحتوي مستودع GitHub kubectl لهذه الوظيفة على طلب مفتوح. وبالتالي ، من الممكن أن يتم تنفيذ هذه الميزة في وقت ما في المستقبل.

حظا سعيدا!

ماذا تقرأ عن الموضوع:

المصدر: www.habr.com

كيفية استخدام kubectl بشكل أكثر كفاءة: دليل مفصل