Как да използвате 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); 
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 е подобен на 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