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

Нека видим прост пример:

$ 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 са списъци, а този оператор позволява да се избират елементи от тези списъци. Често се използва с заместващ знак като [*], за да избере всички елементи от списъка.

Примери за приложение

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

1. Показване на изображения на контейнери за подовете:

   $ 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

   Тази команда показва имената на изображенията на контейнерите за всеки под.

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

2. Показване на зони за достъп на нодовете:

   $ 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, следвайте инструкциите на 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 за смяна на пространството за имена.

Написах два плъгина, които правят това:

• kubectl-ctx
• kubectl-ns

Работата на плъгините се основава на алиасите от предишния раздел.

Ето как работят:

Обърнете внимание, че плъгините използват fzf за предоставяне на интерактивен интерфейс за свободно търсене (както в интерактивния режим на kubectx). Това означава, че трябва инсталирате fzf, за да използвате тези алиаси.

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

5. Съкратено въвеждане с автоалиаси

Алиасите на командния ред са чудесен начин да ускорите въвеждането. Проектът kubectl-aliases съдържа около 800 съкращения за основни команди kubectl.

Може да се запитате — как да запомните 800 алиаса? Но не е нужно да ги помните всички, тъй като те се създават по проста схема, показана по-долу:

Например:

1. kgpooyaml — kubectl get pods oyaml
2. ksysgsvcw — kubectl -n kube-system get svc w
3. ksysrmcm — kubectl -n kube-system rm cm
4. kgdepallsl — kubectl get deployment all sl

Както виждате, алиасите се състоят от компоненти, всеки от които представлява определен елемент от командата kubectl. Всеки алиас може да има един компонент за основната команда, операция и ресурс, и няколко компонента за параметри. Вие просто "попълвате" тези компоненти отляво надясно в съответствие с горепосочената схема.

Текущата подробна схема се намира на GitHub. Там можете да намерите и пълен списък на псевдонимите.

Например, алиасът kgpooyamlall е равен на командата kubectl get pods -o yaml --all-namespaces.

Относителният ред на опции не е важен: командата kgpooyamlall е равна на командата kgpoalloyaml.

Не е необходимо да използвате всички компоненти като алиаси. Например k, kg, klo, ksys, kgpo също може да се използва. Освен това, в командния ред можете да комбинирате алиаси и обикновени команди или опции:

Например:

1. Вместо kubectl proxy може да бъде написано k proxy.
2. Вместо kubectl get roles може да бъде написано kg roles (в момента няма алиас за ресурса Roles).
3. За да получите информация за конкретен под, можете да използвате командата 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, вероятно сте използвали автозавършване за такива неща, като имена на ресурси. Но възможно ли е да направите това, когато се използват алиаси?

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

Отговорът зависи от това, каква командна обвивка използвате:

1. За Zsh автозавършването за алиаси работи «извън кутията».
2. За Bash, за съжаление, са необходими някои действия, за да накарате автозавършването да работи.

Активиране на автозавършване за алиаси в Bash

Проблемът с Bash е, че той се опитва да завърши (всеки път, когато натискате Tab) алиас, а не командата, на която се позовава алиасът (както прави Zsh). Тъй като нямате скриптове за завършване за всички 800 псевдонима, автозавършването не работи.

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

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

Инсталиране на complete-alias

Преди всичко, complete-alias зависи от bash-completion. Следователно, преди да инсталирате 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. Това означава, че за да използвате complete-alias в MacOS, трябва да инсталирате по-нова версия на Bash.

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

source ~\/bash_completion.sh

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

Активиране на автоматично допълнение за алиасите на kubectl

Технически complete-alias предоставя функция на черупката _complete_alias. Тази функция проверява алиаса и връща подсказки за допълнение за командата на алиаса.

За свързване на функция с определен алиас трябва да използвате вграден механизъм на Bash complete, за да зададете _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); \ndo\n  complete -F _complete_alias "$_a"\ndone

Този код трябва да бъде поставен в вашия ~/.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 е подобен на Brew).

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 за тази функция има отворен тикет. Така че, е възможно тази функция да бъде реализирана някога в бъдеще.

Успех!!!

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

1. Три нива на автоскалиране в Kubernetes и как да ги използвате ефективно.
2. Kubernetes вдъхновен от пиратството с шаблон за внедряване.
3. Нашият канал Вокруг Kubernetes в Телеграме.

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