🥇Як больш эфектыўна выкарыстоўваць 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 c параметрам 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, прытрымлівайцеся інструкцыям на 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, Каб выкарыстоўваць гэтыя аліясы.

Каб усталяваць убудовы, трэба загрузіць сцэнары абалонкі з імёнамі 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: падрабязнае кіраўніцтва