🥇Как да използвате kubectl по-ефективно: подробно ръководство

Ако работите с Kubernetes, тогава kubectl вероятно е една от помощните програми, които използвате най-много. И винаги, когато прекарвате много време в работа с определен инструмент, си струва да го проучите добре и да се научите как да го използвате ефективно.

Отбор Kubernetes aaS от Mail.ru преведете статия от Daniel Weibel, в която ще намерите съвети и трикове за ефективна работа с kubectl. Освен това ще ви помогне да разберете по-задълбочено Kubernetes.

Според автора, целта на статията е да направи ежедневната ви работа с Kubernetes не само по-ефективна, но и по-приятна!

Въведение: Какво е kubectl

Преди да можете да се научите да използвате kubectl по-ефективно, трябва да придобиете основно разбиране за това какво представлява и как работи.

От гледна точка на потребителя kubectl е контролен панел, който ви позволява да извършвате операции на Kubernetes.

Технически погледнато, kubectl е API клиент на Kubernetes.

Kubernetes API е HTTP REST API. Този API е истинският потребителски интерфейс на Kubernetes, чрез който се контролира напълно. Това означава, че всяка операция на Kubernetes е изложена като крайна точка на API и може да бъде направена с HTTP заявка към тази крайна точка.

Следователно основната работа на kubectl е да прави HTTP заявки към Kubernetes API:

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 заявки към съответните крайни точки на Kubernetes API.

Моля, имайте предвид, че можете напълно да управлявате Kubernetes с помощта на помощна програма като curlчрез ръчно изпращане на HTTP заявки към Kubernetes API. Kubectl просто улеснява използването на Kubernetes API.

Това са основите на това какво е kubectl и как работи. Но има още нещо за Kubernetes API, което всеки потребител на 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 създава дефиниция на pod за всяка реплика на ReplicaSet (според шаблона на pod в дефиницията на ReplicaSet) и ги съхранява в хранилище:
Планировчикът се стартира, проследявайки модули, които все още не са присвоени на работни възли:
Планировчикът избира подходящ работен възел за всеки pod и добавя тази информация към дефиницията на pod в магазина:
На работния възел, към който е присвоен подът, Kubelet се стартира, той проследява подовете, присвоени на този възел:
Kubelet чете дефиницията на pod от хранилището и инструктира среда за изпълнение на контейнер, като Docker, да стартира контейнери на възела:

По-долу е текстова версия на това описание.

API заявката към крайната точка за създаване на ReplicaSet се обработва от API сървъра. API сървърът удостоверява заявката и съхранява дефиницията на ресурса ReplicaSet в хранилището.

Това събитие стартира контролера ReplicaSet, който е подпроцес на мениджъра на контролера. Контролерът ReplicaSet следи създаването, актуализирането и изтриването на ресурси на ReplicaSet в хранилището и получава известие за събитие, когато това се случи.

Задачата на контролера ReplicaSet е да гарантира, че съществува необходимия брой модули ReplicaSet. В нашия пример все още не съществуват подове, така че контролерът на ReplicaSet създава тези дефиниции на под (според шаблона на под в дефиницията на ReplicaSet) и ги съхранява в хранилище.

Създаването на нови подове се задейства от планировчик, който следи дефиниции на подове, които все още не са планирани за работни възли. Планировчикът избира подходящ работен възел за всеки pod и актуализира дефинициите на pod в хранилището.

Обърнете внимание, че до този момент никъде в клъстера не се изпълняваше код за работно натоварване. Всичко, което е направено до момента - това е създаването и актуализирането на ресурси в хранилището на главния възел.

Последното събитие задейства Kubelets, които наблюдават модулите, планирани за техните работни възли. Kubelet на работния възел, на който са инсталирани вашите модули ReplicaSet, трябва да инструктира средата за изпълнение на контейнера, като Docker, да изтегли необходимите изображения на контейнера и да ги стартира.

В този момент вашето приложение ReplicaSet най-накрая работи!

Роля на Kubernetes API

Както видяхте в предишния пример, компонентите на Kubernetes (с изключение на API сървъра и хранилището) следят за промени в ресурсите в хранилището и променят информацията за ресурсите в хранилището.

Разбира се, тези компоненти не взаимодействат директно със съхранението, а само чрез Kubernetes API.

Разгледайте следните примери:

Контролерът ReplicaSet използва крайната точка на API списък ReplicaSets с параметър watch за наблюдение на промените в ресурсите на ReplicaSet.
Контролерът ReplicaSet използва крайната точка на API създайте Pod (създаване на под), за да създадете под.
Планировчикът използва крайна точка на API кръпка под (edit pod), за да актуализирате pods с информация за избрания работен възел.

Както можете да видите, това е същият 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, така че първо трябва да го инсталирате:

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

Можете да проверите дали пакетът е инсталиран успешно, като използвате следната команда:

$ type _init_completion

Ако това извежда код на функцията на обвивката, тогава bash-завършването е инсталирано правилно. Ако командата дава грешка „Не е намерено“, трябва да добавите следния ред към вашия файл ~ / .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 autocompletion изисква bash-completion v2, а bash-completion 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. В този случай автоматичното довършване ще бъде достъпно не само в главните, но и в дъщерните командни черупки.

След като рестартирате командната обвивка, можете да проверите дали инсталацията е правилна, като използвате следната команда:

$ 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

Скриптовете за автоматично довършване за 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 спецификация на ресурса на pod. По-подробна информация можете да намерите в изхода 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 съдържа набор от контексти. Контекстът се състои от три елемента:

Клъстер — API URL на сървъра на клъстера.
Потребител - потребителски идентификационни данни за удостоверяване в клъстера.
Пространство от имена - пространството от имена, използвано при присъединяване към клъстера.

На практика те често използват един контекст на клъстер в своя kubeconfig. Можете обаче да имате множество контексти на клъстер, диференцирани по потребител или пространство от имена. Въпреки това, тази многоконтекстна конфигурация е необичайна, така че обикновено има съпоставяне едно към едно между клъстери и контексти.

Във всеки един момент един от контекстите е актуален:

Когато kubectl чете конфигурационен файл, той винаги взема информация от текущия контекст. В горния пример kubectl ще се свърже с клъстера Hare.

Съответно, за да превключите към друг клъстер, трябва да промените текущия контекст във файла kubeconfig:

Сега kubectl ще се свърже с клъстера Fox.

За да превключите към различно пространство от имена в същия клъстер, трябва да промените стойността на елемента от пространство от имена за текущия контекст:

В горния пример kubectl ще използва пространството от имена Prod на клъстера на Fox (преди това беше зададено пространството от имена 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да използвате тези псевдоними.

За да инсталирате плъгини, трябва да изтеглите shell скриптове на име kubectl-ctx и kubectl-ns към всяка директория във вашата променлива PATH и ги направете изпълними с напр. chmod +x. Веднага след това ще можете да използвате kubectl ctx и kubectl ns.

5. Намалете въвеждането с автоматични псевдоними

Псевдонимите на Shell са добър начин за ускоряване на въвеждането. Проект kubectl-псевдоними съдържа около 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 получи внедряване на всички 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 псевдонима, автоматичното довършване не работи.

Проект пълен псевдоним предлага общо решение на този проблем. Той се свързва с механизма за завършване на псевдоними, вътрешно разширява псевдонима до команда и връща опции за завършване за завършената команда. Това означава, че подложката за псевдоним се държи точно както за пълна команда.

По-долу първо ще обясня как да инсталирам complete-alias и след това как да го конфигурирам, за да активирам завършване за всички kubectl псевдоними.

Инсталиране на пълен псевдоним

На първо място, пълният псевдоним зависи от bash-завършване. Следователно, преди да инсталирате complete-alias, трябва да се уверите, че bash-completion е инсталиран. Инструкциите за инсталиране са предоставени по-рано за Linux и MacOS.

Важна забележка за потребителите на MacOS: Подобно на скрипта за автоматично довършване kubectl, complete-alias не работи с Bash 3.2, което е по подразбиране в MacOS. По-специално, complete-alias зависи от bash-completion v2 (brew install bash-completion@2), което изисква поне Bash 4.1. Това означава, че за да използвате пълен псевдоним на MacOS, трябва да инсталирате по-нова версия на Bash.

Трябва да изтеглите скрипта bash_completion.sh на GitHub хранилище и го включете във вашия файл ~/.bashrc:

source ~/bash_completion.sh

След рестартиране на обвивката, complete-alias ще бъде напълно инсталиран.

Активиране на автоматично довършване за псевдоними 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

Точно както в предишния пример, когато автоматично довършвате 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, рестартирайте командната обвивка и автоматичното довършване ще стане достъпно за всичките 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 скрипт, скрипт на python или компилирано 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 могат да бъдат написани на всеки език за програмиране или скриптове. Ако използвате shell скриптове, предимството е да можете лесно да извиквате kubectl от плъгина. Можете обаче да пишете по-сложни плъгини в реални езици за програмиране, като използвате Клиентска библиотека на Kubernetes. Ако използвате Go, можете също да използвате библиотека за изпълнение на cli, който съществува специално за писане на kubectl добавки.

Как да споделяте своите добавки

Ако смятате, че вашите приставки могат да бъдат полезни за други, не се колебайте да ги споделите в GitHub. Не пропускайте да ги добавите към темата kubectl-плъгини.

Можете също да поискате вашият плъгин да бъде добавен към Списък на Крю. Инструкции как да направите това са в Хранилища на GitHub.

Завършване на командата

Понастоящем добавките не поддържат автоматично довършване. Тоест трябва да въведете пълното име на плъгина и пълните имена на аргументите.

Хранилището kubectl на GitHub за тази функция има отворена заявка. Така че е възможно тази функция да бъде внедрена някъде в бъдеще.

Успех !!!

Какво още да прочетете по темата:

Източник: www.habr.com

Как да използвате kubectl по-ефективно: подробно ръководство