🥇Як ефективніше використовувати kubectl: докладний посібник

Якщо ви працюєте з Kubernetes, то, ймовірно, kubectl — одна з найуживаніших утиліт. А щоразу, коли ви витрачаєте багато часу працювати з певним інструментом, варто добре його вивчити і навчитися ефективно використовувати.

Команда Kubernetes aaS від Mail.ru переклала статтю Даніеля Вейбеля, в якій ви знайдете поради та прийоми для ефективної роботи з kubectl. Також вона допоможе глибше зрозуміти роботу Kubernetes.

За словами автора, мета статті — зробити вашу щоденну роботу з Kubernetes не лише ефективнішою, а й приємнішою!

Що таке kubectl

Перед тим, як вчитися використовувати kubectl більш ефективно, потрібно отримати базове розуміння того, що це таке і як працює.

З погляду користувача, kubectl — панель керування, що дозволяє виконувати операції Kubernetes.

З технічного погляду, kubectl - клієнт Kubernetes API.

Kubernetes API – це HTTP REST API. Цей API - справжній інтерфейс користувача Kubernetes, через який він повністю контролюється. Це означає, що кожна операція Kubernetes представляється як кінцева точка API і може бути виконана HTTP-запитом цієї кінцевої точки.

Отже, основне завдання kubectl – виконувати HTTP-запити до API Kubernetes:

Kubernetes – повністю ресурсно-орієнтована система. Це означає, що він підтримує внутрішній стан ресурсів і всі операції Kubernetes є операціями CRUD.

Ви повністю контролюєте Kubernetes, керуючи цими ресурсами, і Kubernetes з'ясовує, що робити, ґрунтуючись на поточному стані ресурсів. Тому посилання на API Kubernetes організовано у вигляді списку типів ресурсів із пов'язаними з ними операціями.

Давайте розглянемо приклад.

Припустимо, що ви хочете створити ресурс 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 просто полегшує використання API Kubernetes.

Це основа того, що таке kubectl і як він працює. Але є ще щось про API Kubernetes, що повинен знати кожен користувач kubectl. Давайте коротко поринемо у внутрішній світ Kubernetes.

Внутрішній світ Kubernetes

Kubernetes складається з набору незалежних компонентів, які виконуються як окремі процеси на вузлах кластера. Деякі компоненти працюють на головних вузлах, інші на робочих вузлах, кожен компонент виконує своє спеціальне завдання.

Ось найважливіші компоненти на головних нодах:

Сховище - Зберігає визначення ресурсів (зазвичай це etcd).
API сервер — надає API та керує сховищем.
Диспетчер контролерів гарантує, що статуси ресурсів відповідають специфікаціям.
Планувальник - Планує поди на робочих вузлах.

І ось один найважливіший компонент на робочих нодах:

Кубелет - керує запуском контейнерів на робочій ноді.

Щоб зрозуміти, як ці компоненти працюють разом, розглянемо приклад.

Припустимо, ви щойно виконали kubectl create -f replicaset.yaml, після чого kubectl зробив HTTP-запит POST до кінцевої точки API-інтерфейсу ReplicaSet (Передаючи визначення ресурсу ReplicaSet).

Що відбувається у кластері?

Після виконання kubectl create -f replicaset.yaml API-сервер зберігає визначення вашого ресурсу ReplicaSet у сховищі:
Далі запускається контролер ReplicaSet у диспетчері контролерів, який обслуговує створення, зміну та видалення ресурсів ReplicaSet:
Контролер ReplicaSet створює визначення пода для кожної репліки ReplicaSet (відповідно до шаблону пода у визначенні ReplicaSet) і зберігає їх у сховищі:
Запускається планувальник, який відстежує поди, які ще не були призначені жодній робочій ноді:
Планувальник вибирає відповідну робочу ноду для кожного пода і додає цю інформацію для визначення пода в сховищі:
На робочій ноді, якій призначено під, запускається Kubelet, він відстежує поди, призначені цій ноді:
Kubelet зчитує визначення пода зі сховища і дає команді середовищу виконання контейнерів, наприклад Docker, на запуск контейнерів на ноді:

Нижче текстовий варіант цього опису.

Запит API на кінцеву точку створення ReplicaSet обробляється сервером API. Сервер API аутентифікує запит і зберігає визначення ресурсу ReplicaSet у сховищі.

Цю подію запускає контролер ReplicaSet, який є підпроцес диспетчера контролерів. Контролер ReplicaSet стежить за створенням, оновленням та видаленням ресурсів ReplicaSet у сховищі та отримує сповіщення про подію, коли це відбувається.

Завдання контролера ReplicaSet – переконатися, що існує необхідна кількість подів репліки ReplicaSet. У нашому прикладі подів поки не існує, тому контролер ReplicaSet створює ці визначення подів (відповідно до шаблону пода у визначенні ReplicaSet) і зберігає їх у сховищі.

Створення нових подів запускає планувальник, який відстежує визначення подів, які ще не заплановані для робочих нод. Планувальник вибирає відповідну робочу ноду для кожного пода і оновлює визначення пода у сховищі.

Зауважте, що до цього моменту ніде в кластері не виконувався код робочого навантаження. Все, що було зроблено досі, - це створення та оновлення ресурсів у сховищі на головному вузлі.

Остання подія запускає Kubelet, які стежать за подами, запланованими для їхніх робочих нод. Kubelet робочої ноди, для якої встановлені ваші поди ReplicaSet, повинен дати вказівку середовищу виконання контейнерів, наприклад Docker, завантажити необхідні образи контейнерів та запустити їх.

У цей момент, нарешті, ваш додаток ReplicaSet запущено!

Роль API Kubernetes

Як ви побачили в попередньому прикладі, компоненти Kubernetes (за винятком сервера API та сховища) стежать за зміною ресурсів у сховищі та змінюють інформацію про ресурси у сховищі.

Звичайно, ці компоненти не взаємодіють із сховищем безпосередньо, а лише через Kubernetes API.

Розглянемо такі приклади:

Контролер ReplicaSet використовує кінцеву точку API list ReplicaSets з параметром watch для спостереження за змінами ресурсів ReplicaSet.
Контролер ReplicaSet використовує кінцеву точку API create Pod (Створити під) для створення подів.
Планувальник використовує кінцеву точку API patch Pod (змінити під) для оновлення подів з інформацією про обрану робочу ноду.

Як ви бачите, це те саме API, до якого звертається kubectl. Використання одного і того ж API для роботи внутрішніх компонентів та зовнішніх користувачів є фундаментальною концепцією дизайну Kubernetes.

Тепер можна узагальнити, як працює Kubernetes:

Сховище зберігає стан, тобто ресурси Kubernetes.
API сервер надає інтерфейс до сховища як Kubernetes API.
Всі інші компоненти та користувачі Kubernetes читають, спостерігають та маніпулюють станом (ресурсами) Kubernetes через API.

Знання цих концепцій допоможе краще зрозуміти kubectl і використовувати його максимально.

Тепер давайте розглянемо ряд конкретних порад та прийомів, які допоможуть підвищити продуктивність роботи з Kubectl.

1. Прискорення введення за допомогою доповнення команд

Один з найкорисніших, але найчастіше упущених з уваги прийомів, дозволяють підвищити продуктивність роботи з kubectl, — доповнення команд.

Доповнення команд дозволяє автоматично заповнювати окремі частини команд kubectl кнопкою Tab. Це працює для підкоманд, опцій та аргументів, у тому числі таких складних як імена ресурсів.

Подивіться, як працює доповнення команд kubectl:

Додаток команд працює для командних оболонок Bash та Zsh.

Офіційний посібник містить детальні інструкції з налаштування автодоповнення, але нижче наведемо коротку витримку.

Як працює доповнення команд

Доповнення команд – функція оболонки, яка працює за допомогою скрипта доповнення. Скрипт доповнення — це сценарій оболонки, який визначає поведінку доповнення для конкретної команди.

Kubectl автоматично генерує та виводить скрипти доповнення для Bash та Zsh за допомогою наступних команд:

$ kubectl completion bash

Або:

$ kubectl completion zsh

Теоретично - достатньо підключити виведення цих команд у відповідну командну оболонку, щоб kubectl зміг доповнювати команди.

На практиці спосіб підключення відрізняється для Bash (включаючи відмінності між Linux і MacOS) і Zsh. Нижче ми розглянемо ці варіанти.

Bash у Linux

Скрипт доповнення Bash залежить від пакета bash-completion, тому спочатку необхідно встановити його:

$ sudo apt-get install bash-completion

Або:

$ yum install bash-completion

Ви можете протестувати, що пакет встановлений успішно за допомогою наступної команди:

$ type _init_completion

Якщо виводиться код функції оболонки, то bash-completion правильно встановлено. Якщо команда видає помилку «Не знайдено», необхідно додати наступний рядок у файл ~ / .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 пов'язане з питаннями ліцензування. Bash версії 4 поширюється під ліцензією GPLv3, яку Apple не підтримує.

Для налаштування автодоповнення kubectl у MacOS потрібно встановити свіжішу версію Bash. Ви також можете встановити оновлений Bash як командну оболонку за промовчанням, що вбереже в майбутньому від багатьох проблем. Це нескладно, деталі наведені у статтіОновлення Bash у MacOS».

Перед тим, як продовжити, переконайтеся, що ви використовуєте свіжу версію Bash (перевірте висновок bash --version).

Скрипт автодоповнення в Bash залежить від проекту bash-завершеннятому спочатку потрібно встановити його.

Ви можете встановити bash-completion за допомогою Homebrew:

$ 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

Якщо у виведенні ви бачите shell-функцію, все налаштовано правильно.

Тепер потрібно зробити так, щоб автодоповнення 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

Скрипти автодоповнення для 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. Це тому, що ім'я пода визначається в дочірньому полі 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.

Зауважте, що поля ресурсів Kubernetes чутливі до регістру.

Ви можете переглянути будь-яке поле ресурсу у вигляді стовпця. Просто перегляньте специфікацію ресурсу та спробуйте її з будь-якими полями, які вам подобаються.

Але спочатку давайте докладніше розглянемо вирази вибору полів.

Вирази JSONPath

Висловлювання для вибору полів ресурсів базуються на JSONPath.

JSONPath – це мова для вибірки даних із JSON-документів. Вибір одного поля – найпростіший випадок використання JSONPath. У нього набагато більше можливостейвключаючи селектори, фільтри і так далі.

Kubectl explain підтримує обмежену кількість можливостей 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 містить набір контекстів. Контекст складається із трьох елементів:

Cluster – URL API сервера кластера.
User — облікові дані автентифікації користувача у кластері.
Namespace — простір імен, який використовується при приєднанні до кластера.

На практиці часто використовують один контекст на кластер у своєму файлі kubeconfig. Тим не менш, у вас може бути кілька контекстів на кластер, що розрізняються за користувачем або простір імен. Однак така конфігурація з кількома контекстами зустрічається нечасто, тому зазвичай існує взаємно-однозначне зіставлення між кластерами та контекстами.

У будь-який момент часу один із контекстів є поточним:

Коли kubectl читає конфігураційний файл, завжди береться інформація з поточного контексту. У прикладі вище kubectl коннектиться до кластера Hare.

Відповідно, щоб перейти на інший кластер, потрібно змінити поточний контекст у файлі kubeconfig:

Тепер kubectl буде коннектуватися до кластера Fox.

Щоб переключитися на інший простір імен у тому ж кластері, потрібно змінити значення елемента namespace для поточного контексту:

У наведеному вище прикладі kubectl буде використовувати простір імен Prod кластера Fox (раніше було встановлено простір імен Test).

Зверніть увагу, що 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 для надання інтерактивного інтерфейсу вільного пошуку (як в інтерактивному режимі 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. Скорочення введення з автоаліасами

Аліаси командної оболонки – гарна можливість прискорити введення. Проект kubectl-aliases містить близько 800 скорочень для основних команд Kubectl.

Ви можете здивуватися як запам'ятати 800 аліасів? Але не потрібно пам'ятати їх усі, адже вони будуються за простою схемою, яка наведена нижче:

Наприклад:

kgpooyaml — kubectl get pods oyaml
ksysgsvcw - kubectl -n kube-system get svc w
ksysrmcm - kubectl -n kube-system rm cm
kgdepallsl — kubectl get deployment all 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).
Щоб отримати дані щодо конкретного поду, можна використовувати команду kgpo my-pod — kubectl get pod my-pod.

Врахуйте, що деякі аліаси вимагають аргументу в командному рядку. Наприклад, аліас kgpol означає kubectl get pods -l. Опція -l вимагає аргумент - специфікацію мітки. Якщо ви використовуєте аліас, то він виглядатиме як kgpol app=ui.

Через те, що частина аліасів вимагає аргументів, аліаси а, f і l потрібно використовувати останніми.

Загалом, як тільки ви освоїте цю схему, зможете інтуїтивно вивести аліаси з команд, які хочете виконати, і заощадити багато часу на введенні.

інсталяція

Щоб встановити kubectl-aliases, потрібно завантажити файл .kubectl_aliases з GitHub і включити його до файлу ~/.bashrc або ~/.zshrc:

source ~/.kubectl_aliases

Автодоповнення

Як ми вже говорили, ви часто додаєте додаткові слова до аліасу у командному рядку. Наприклад:

$ kgpooyaml test-pod-d4b77b989

Якщо ви користуєтеся автодоповненням команди kubectl, то, ймовірно, використовували автодоповнення для таких речей, як імена ресурсів. Але чи можна це зробити, коли використовуються аліаси?

Це дуже важливе питання, тому що, якщо автодоповнення не працює, ви втратите частину переваг аліасів.

Відповідь залежить від того, яку командну оболонку ви використовуєте:

Для Zsh автодоповнення для аліасів працює "з коробки".
Для Bash, на жаль, потрібні деякі дії, щоб змусити працювати автодоповнення.

Включення автодоповнення для аліасів у Bash

Проблема з Bash полягає в тому, що він намагається доповнити (щоразу, коли ви натискаєте Tab) аліас, а не команду, на яку посилається аліас (як, наприклад, робить Zsh). Оскільки ви не маєте скриптів доповнення для всіх 800 псевдонімів, автодоповнення не працює.

Проект complete-alias надає загальне вирішення цієї проблеми. Він підключається до механізму доповнення для аліасів, всередині доповнює аліас до команди та повертає варіанти доповнення для доповненої команди. Це означає, що доповнення для аліасу поводиться так само, як для повної команди.

Далі я спочатку поясню, як встановити complete-alias, а потім як його налаштувати, щоб включити доповнення для всіх псевдонімів kubectl.

Установка complete-alias

Насамперед, complete-alias залежить від bash-завершення. Тому перед встановленням complete-alias необхідно переконатися, що bash-completion встановлений. Інструкції зі встановлення були надані раніше для Linux та MacOS.

Важлива примітка для користувачів MacOS: як і скрипт автодоповнення kubectl, сomplete-alias не працює з Bash 3.2, який за умовчанням використовується MacOS. Зокрема, complete-alias залежить від bash-completion v2 (brew install bash-completion@2), для якого потрібно як мінімум Bash 4.1. Це означає, що для використання complete-alias у MacOS потрібно встановити новішу версію Bash.

Вам потрібно завантажити скрипт bash_completion.sh з репозиторія GitHub та включити його у своєму файлі ~/.bashrc:

source ~/bash_completion.sh

Після перезавантаження командної оболонки complete-alias буде повністю встановлений.

Включення автодоповнення для аліасів kubectl

Технічно complete-alias надає функцію оболонки _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

Точно так само, як і в попередньому прикладі, коли ви автодоповнюєте kg, ви отримуєте ті ж підказки доповнення, які отримали б для kubectl get.

Зверніть увагу, що так можна використовувати complete-alias для будь-якого аліасу у вашій системі.

Отже, щоб увімкнути автодоповнення для всіх аліасів kubectl, потрібно виконати вказану вище команду для кожного з них. Наступний фрагмент робить саме це за умови, що ви встановили kubectl-aliases в ~/.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 придатні для спільного або повторного використання подібно до програмних пакетів. Але де можна знайти плагіни, якими поділилися інші люди?

Проект Krew спрямований на надання уніфікованого рішення для спільного використання, пошуку, встановлення та керування плагінами 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-plugins. Там ви знайдете кілька десятків доступних плагінів, які варто подивитися.

Написання власних плагінів

Ви можете самі створювати плагіни - це не важко. Вам потрібно створити файл, що виконується, який робить те, що потрібно, назвати його у вигляді kubectl-x та встановити, як було описано вище.

Файл може бути bash-скриптом, python-скриптом або скомпільованим 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 можуть бути написані будь-якою мовою програмування чи сценаріїв. Якщо ви використовуєте сценарії командної оболонки, то перевагу в можливості легко викликати kubectl з плагіна. Однак ви можете писати більш складні плагіни реальними мовами програмування, використовуючи клієнтську бібліотеку Kubernetes. Якщо ви використовуєте Go, то також можете використати бібліотеку cli-runtime, що існує спеціально для написання плагінів kubectl.

Як поділитися своїми плагінами

Якщо ви вважаєте, що ваші плагіни можуть бути корисними для інших, не соромтеся ділитися ним на GitHub. Обов'язково додайте їх у тему kubectl-plugins.

Ви також можете запросити додавання вашого плагіна в список Krew. Інструкції про те, як це зробити, є в репозиторії GitHub.

Автодоповнення команд

В даний час плагіни не підтримують автодоповнення. Тобто ви повинні вводити повне ім'я плагіна та повні імена аргументів.

У репозиторії GitHub kubectl для цієї функції є відкритий запит. Таким чином, можливо, що ця функція буде реалізована колись у майбутньому.

Удачи !!!

Що ще почитати на тему:

Джерело: habr.com

Як ефективніше використовувати kubectl: докладний посібник