🥇Kubectl'ди кантип натыйжалуураак колдонуу керек: толук колдонмо

Эгер сиз Kubernetes менен иштесеңиз, анда kubectl сиз эң көп колдонгон утилиталардын бири болушу мүмкүн. Ал эми кайсы бир инструмент менен иштөөгө көп убакыт сарптасаңыз, аны жакшылап изилдеп, аны кантип натыйжалуу колдонууну үйрөнүү пайдалуу.

команда Mail.ru сайтынан Kubernetes aaS Даниел Вейбелдин макаласын которгон, анда kubectl менен эффективдүү иштөө боюнча кеңештерди жана ыкмаларды таба аласыз. Ал ошондой эле Kubernetes жөнүндө тереңирээк түшүнүүгө жардам берет.

Автордун айтымында, макаланын максаты - Kubernetes менен күнүмдүк ишиңизди эффективдүүрөөк гана эмес, жагымдуураак кылуу!

Киришүү: kubectl деген эмне

Kubectlди натыйжалуураак колдонууну үйрөнүүдөн мурун, анын эмне экенин жана анын кантип иштээри жөнүндө негизги түшүнүккө ээ болушуңуз керек.

Колдонуучунун көз карашы боюнча, kubectl - бул Kubernetes операцияларын аткарууга мүмкүндүк берген башкаруу панели.

Техникалык жактан алганда, kubectl бул Kubernetes API кардары.

Kubernetes API - бул HTTP REST API. Бул API чыныгы Kubernetes колдонуучу интерфейси, ал аркылуу ал толугу менен башкарылат. Бул ар бир Kubernetes операциясы API акыркы чекити катары ачыкка чыгып, ошол акыркы чекитке HTTP сурамы менен жасалышы мүмкүн экенин билдирет.

Ошондуктан, kubectlдин негизги жумушу - Kubernetes API'ге HTTP сурамдарын берүү:

Kubernetes - бул толугу менен ресурстарга багытталган система. Бул ал ресурстардын ички абалын сактайт жана бардык Kubernetes операциялары CRUD операциялары экенин билдирет.

Бул ресурстарды башкаруу менен сиз Кубернетести толук көзөмөлдөйсүз жана Kubernetes ресурстардын учурдагы абалына жараша эмне кылуу керектигин аныктайт. Ушул себептен улам, Kubernetes API шилтемеси алар менен байланышкан операциялары менен ресурс түрлөрүнүн тизмеси катары уюштурулган.

Келгиле, бир мисал карап көрөлү.

Сиз ReplicaSet ресурсун түзгүңүз келет дейли. Бул үчүн, сиз ReplicaSet файлын аты менен сүрөттөп бересиз replicaset.yaml, андан кийин буйрукту иштетиңиз:

$ kubectl create -f replicaset.yaml

Бул ReplicaSet ресурсун түзөт. Бирок көшөгө артында эмне болот?

Kubernetesте ReplicaSet түзүү операциясы бар. Башка операциялар сыяктуу эле, ал API акыркы чекити катары ачылат. Бул операция үчүн атайын API акыркы чекити төмөнкүдөй көрүнөт:

POST /apis/apps/v1/namespaces/{namespace}/replicasets

Бардык Kubernetes операциялары үчүн API акыркы чекиттерин бул жерден тапса болот API шилтемеси (анын ичинде жогорудагы акыркы чекит). Акыркы чекитке иш жүзүндө суроо-талап кылуу үчүн, адегенде API серверинин URL дарегин API шилтемесинде тизмеленген акыркы чекиттин жолдоруна кошушуңуз керек.

Демек, сиз жогорудагы буйрукту аткарганда, kubectl жогорудагы API акыркы чекитине HTTP POST өтүнүчүн жөнөтөт. Файлда сиз берген ReplicaSet аныктамасы replicaset.yaml, суроо-талаптын текстинде жөнөтүлөт.

Kubernetes кластери менен иштешкен бардык буйруктар үчүн kubectl ушундай иштейт. Бул учурларда, kubectl жөн гана тиешелүү Kubernetes API акыркы чекиттерине HTTP сурамдарын жасайт.

сыяктуу утилитаны колдонуп, Kubernetesти толугу менен башкара аларыңызды эске алыңыз curlHTTP сурамдарын кол менен Kubernetes API'ге жөнөтүү менен. Kubectl жөн гана Kubernetes API колдонууну жеңилдетет.

Бул kubectl деген эмне жана ал кандайча иштейт. Бирок Kubernetes API жөнүндө дагы бир нерсе бар, аны ар бир kubectl колдонуучусу билиши керек. Келгиле, Кубернетестин ички дүйнөсүнө тез көз чаптыралы.

Кубернетестин ички дүйнөсү

Kubernetes кластердик түйүндөрдө өзүнчө процесстер катары иштеген көз карандысыз компоненттердин жыйындысынан турат. Кээ бир компоненттер башкы түйүндөрдө, башкалары жумушчу түйүндөрдө иштейт, ар бир компонент өзүнүн өзгөчө тапшырмасын аткарат.

Бул жерде негизги түйүндөрдөгү эң маанилүү компоненттер:

Vault - ресурстун аныктамаларын сактайт (адатта бул ж.б).
API сервери — API камсыз кылат жана сактагычты башкарат.
Контроллер менеджери — Ресурстук статустардын спецификацияларга ылайык келишин камсыздайт.
Пландаштыруучу — жумушчу түйүндөрүндөгү подкасттарды пландаштырат.

Жана бул жерде жумушчу түйүндөрдөгү эң маанилүү бир компонент:

Кубелет — жумушчу түйүн боюнча контейнерлерди ишке киргизүүнү башкарат.

Бул компоненттердин кантип чогуу иштээрин түшүнүү үчүн, бир мисалды карап көрөлү.

Келгиле, сиз жаңы эле бүтүрдүңүз деп коёлу kubectl create -f replicaset.yaml, андан кийин kubectl HTTP POST өтүнүчүн жасады ReplicaSet API акыркы чекити (ReplicaSet ресурстук аныктамасынан өтүп).

Кластерде эмне болуп жатат?

кылгандан кийин kubectl create -f replicaset.yaml API сервери сиздин ReplicaSet ресурсуңуздун аныктамасын сактагычта сактайт:
Андан кийин, ReplicaSet контроллери контроллердин менеджеринде ишке киргизилет, ал ReplicaSet ресурстарын түзүү, өзгөртүү жана жок кылуу менен алектенет:
ReplicaSet контроллери ар бир ReplicaSet репликасы үчүн поддон аныктамасын түзөт (ReplicaSet аныктамасындагы под шаблонго ылайык) жана аларды сактагычта сактайт:
Пландоочу ишке киргизилди, ал азырынча бир дагы жумушчу түйүндөргө дайындала элек подкасттарды көзөмөлдөйт:
Пландоочу ар бир поддон үчүн ылайыктуу жумушчу түйүн тандайт жана бул маалыматты дүкөндөгү подкасттын аныктамасына кошот:
Pod дайындалган жумушчу түйүндө, Kubelet ишке киргизилет, ал бул түйүнгө дайындалган подкектерге көз салат:
Kubelet сактагычтан поддондун аныктамасын окуйт жана Docker сыяктуу контейнердин иштөө убактысына түйүндөгү контейнерлерди ишке киргизүүнү буйруйт:

Төмөндө бул сүрөттөмөнүн тексттик версиясы келтирилген.

ReplicaSet түзүү акыркы чекитине API сурамы API сервери тарабынан иштетилет. API сервери сурамдын аныктыгын текшерет жана ReplicaSet ресурсунун аныктамасын сактагычта сактайт.

Бул окуя контроллер менеджеринин субпроцесси болгон ReplicaSet контроллерин баштайт. ReplicaSet контроллери дүкөндөгү ReplicaSet ресурстарын түзүүгө, жаңыртууга жана жок кылууга көзөмөл кылат жана бул болгондо окуя тууралуу эскертме алат.

ReplicaSet контроллерунун милдети зарыл болгон сандагы ReplicaSet поддондорунун бар экендигин камсыз кылуу. Биздин мисалда, азырынча эч кандай поддондор жок, ошондуктан ReplicaSet контроллери бул подстук аныктамаларды түзөт (ReplicaSet аныктамасындагы подкачка шаблонуна ылайык) жана аларды сактагычта сактайт.

Жаңы поддондорду түзүү жумушчу түйүндөр үчүн пландаштырыла элек подконун аныктамаларына көз салган пландаштыргыч тарабынан ишке ашырылат. Пландоочу ар бир поддон үчүн ылайыктуу жумушчу түйүн тандайт жана репозиторийдеги поддондун аныктамаларын жаңыртат.

Эскерте кетсек, ушул учурга чейин эч кандай жумуш жүктөө коду кластердин эч бир жеринде иштеген эмес. Буга чейин жасалгандардын баары - бул башкы түйүндөгү репозиторийдеги ресурстарды түзүү жана жаңыртуу.

Акыркы окуя Кубелецти ишке киргизет, алар жумушчу түйүндөрүнө пландаштырылган поддондорду көзөмөлдөйт. ReplicaSet подъездиңиз орнотулган жумушчу түйүнүнүн Кубелети Docker сыяктуу контейнердин иштөө убактысына керектүү контейнер сүрөттөрүн жүктөп алып, аларды иштетүүгө көрсөтмө бериши керек.

Бул учурда, сиздин ReplicaSet колдонмоңуз иштеп жатат!

Kubernetes API'нин ролу

Мурунку мисалда көргөнүңүздөй, Kubernetes компоненттери (API серверинен жана сактагычтан тышкары) сактагычтагы ресурстардын өзгөрүшүнө көз салып турат жана сактагычтагы ресурстар жөнүндө маалыматты өзгөртөт.

Албетте, бул компоненттер сактагыч менен түз иштешпейт, бирок Kubernetes API аркылуу гана.

Төмөнкү мисалдарды карап көрөлү:

ReplicaSet контроллери API акыркы чекитин колдонот ReplicaSets тизмеси параметр менен watch ReplicaSet ресурстарына өзгөртүүлөрдү көзөмөлдөө.
ReplicaSet контроллери API акыркы чекитин колдонот Pod түзүү (түзүү подъезд) капчыктарды түзүү.
Графикчи API акыркы чекитин колдонот патч под тандалган жумушчу түйүн жөнүндө маалымат менен подкасттарды жаңыртуу үчүн (түзөтүү подк.).

Көрүнүп тургандай, бул kubectl кире турган ошол эле API. Ички компоненттер жана тышкы колдонуучулар үчүн ошол эле API колдонуу Kubernetes дизайнында негизги түшүнүк болуп саналат.

Эми биз Kubernetes кантип иштээрин кыскача айта алабыз:

Сактагыч дүкөндөр, башкача айтканда, Kubernetes ресурстары.
API сервери Kubernetes API түрүндө сактагычка интерфейсти камсыз кылат.
Бардык башка Kubernetes компоненттери жана колдонуучулар API аркылуу Kubernetes абалын (ресурстарын) окуп, байкап жана башкарат.

Бул түшүнүктөрдү билүү kubectlди жакшыраак түшүнүүгө жана андан максималдуу пайда алууга жардам берет.

Эми kubectl менен өндүрүмдүүлүгүңүздү жакшыртууга жардам бере турган кээ бир конкреттүү кеңештерди жана ыкмаларды карап көрөлү.

1. Буйрукту аяктоо аркылуу киргизүүнү тездетүү

Kubectl менен иштөөнү жакшыртуунун эң пайдалуу, бирок көп учурда көңүл бурулбаган ыкмаларынын бири - бул буйрукту аяктоо.

Буйруктарды аяктоо Tab баскычын колдонуп kubectl буйруктарынын бөлүктөрүн автоматтык түрдө бүтүрүүгө мүмкүндүк берет. Бул ресурстун аталыштары сыяктуу татаал нерсени камтыган подкомандалар, опциялар жана аргументтер үчүн иштейт.

kubectl буйругун аяктоо кантип иштээрин көрүңүз:

Баш жана Зш снаряддары үчүн команданы аяктоо иштери.

Официалдуу гид автотолтурууну орнотуу боюнча кеңири нускамаларды камтыйт, бирок төмөндө биз кыскача үзүндүнү беребиз.

Буйрукту аяктоо кантип иштейт

Буйруктарды аяктоо - бул аяктоо скриптин колдонуу менен иштеген кабык өзгөчөлүгү. Кеңейтүү скрипти - бул белгилүү бир буйрук үчүн кеңейтүүнүн жүрүм-турумун аныктаган кабык скрипти.

Kubectl төмөнкү буйруктарды колдонуу менен Bash жана Zsh үчүн кеңейтүү скрипттерин автоматтык түрдө жаратат жана чыгарат:

$ kubectl completion bash

же:

$ kubectl completion zsh

Теориялык жактан алганда, kubectl буйруктарды толуктай алышы үчүн, бул буйруктардын чыгышын тиешелүү командалык кабыкчага туташтыруу жетиштүү.

Иш жүзүндө, байланыш ыкмасы Bash (анын ичинде Linux жана MacOS ортосундагы айырмачылыктар) жана Zsh үчүн ар түрдүү. Төмөндө биз бул варианттардын баарын карап чыгабыз.

Linux боюнча Bash

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-толтурууну орнотуу үчүн колдонгон пакет менеджериңизден көз каранды. Бул 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-толтурууга кошулат.

Эки вариант тең бирдей колдонулат.

Кабакты кайра баштагандан кийин, kubectl буйругун аткаруу иштейт.

MacOSдо Bash

MacOSдо орнотуу бир аз татаалыраак. Чындыгында, демейки боюнча, MacOS Bash 3.2 версиясын колдонот, ал эми kubectl автотолтуруучу скрипт үчүн Bash версиясы жок дегенде 4.1 талап кылынат жана Bash 3.2де иштебейт.

MacOSдо Bashтын эскирген версиясын колдонууга байланыштуу лицензиялоо маселелери бар. Bash версиясы 4 GPLv3 астында лицензияланган, ал Apple тарабынан колдоого алынбайт.

MacOSдо kubectl автотолтурууну конфигурациялоо үчүн Bashтын акыркы версиясын орнотушуңуз керек. Сиз ошондой эле жаңыртылган Bashты демейки кабыкча катары орното аласыз, бул келечекте көптөгөн көйгөйлөрдү сактап калат. Бул кыйын эмес, чоо-жайы макалада берилген "MacOSдо Bash жаңыртылууда«.

Улантуудан мурун, Bashтын акыркы версиясын колдонуп жатканыңызды текшериңиз (чыгарууну текшериңиз bash --version).

Bash аяктоо сценарийи долбоорго жараша өзгөрөт баш-аяктоо, андыктан адегенде аны орнотуу керек.

колдонуу менен bash-толтурууну орното аласыз Үй Портер:

$ brew install bash-completion@2

бул @2 bash-толтуруунун 2-версиясын билдирет. kubectl автотолтуруусу bash-толтурууну v2 талап кылат, ал эми bash-толтурууну 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

Бул ыкма сиз Homebrew аркылуу bash-толтурууну орнотконуңузда гана иштейт. Бул учурда, bash-толгоо бул каталогдон бардык скрипттерди жүктөйт.

Эгер сиз орнотсоңуз kubectl Homebrew аркылуу, анда мурунку кадамды аткаруунун кереги жок, анткени автотолтуруунун скрипти автоматтык түрдө папкага жайгаштырылат. /usr/local/etc/bash_completion.d орнотуу учурунда. Бул учурда, kubectl автотолтуруу сиз bash-толтурууну орнотконуңуздан кийин иштей баштайт.

Натыйжада, бул параметрлердин баары бирдей.

Зш

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.

Эми сиз чыгарууга кошумча тилке кошкуңуз келет дейли, мисалы, ар бир поддон иштеп жаткан түйүндү көрсөтүү. Бул үчүн, сиз жөн гана ыңгайлаштырылган мамычалар опциясына тиешелүү мамычанын спецификациясын кошо аласыз:

$ 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 Expressions

Ресурстук талааларды тандоо үчүн туюнтмалар негизделген JSONPath.

JSONPath – JSON документтеринен маалыматтарды алуу тили. Жалгыз талааны тандоо JSONPath үчүн эң жөнөкөй колдонуу учуру. Ал көп нерсеге ээ көбүрөөк мүмкүнчүлүктөр, анын ичинде селекторлор, чыпкалар жана башкалар.

Kubectl description чектелген сандагы 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 файлдары болушу мүмкүн экенин эске алыңыз. Бул учурда, бул файлдардын бардыгы иштөө убагында бир жалпы конфигурацияга бириктирилет. Сиз параметр менен kubectl иштетүү менен демейки kubeconfig файлын да өзгөртө аласыз --kubeconfig. Караңыз расмий документтер.

kubeconfig файлдары

Келгиле, kubeconfig файлында так эмне бар экенин карап көрөлү:

Көрүнүп тургандай, kubeconfig файлы контексттердин топтомун камтыйт. Контекст үч элементтен турат:

Кластер — кластер серверинин API URL дареги.
Колдонуучу - кластердеги колдонуучунун аныктыгын текшерүү маалыматтары.
Ат мейкиндиги - кластерге кошулууда колдонулган аттар мейкиндиги.

Иш жүзүндө, алар көбүнчө kubeconfigде кластерге бир контекстти колдонушат. Бирок, сизде колдонуучу же аттар мейкиндиги боюнча айырмаланган кластерге бир нече контексттер болушу мүмкүн. Бирок, бул көп контексттик конфигурация сейрек кездешет, ошондуктан кластерлер менен контексттердин ортосунда адатта бирден-бир карта түзүлөт.

Кайсы убакта болбосун, контексттердин бири учурдагы:

kubectl конфигурация файлын окуганда, ал ар дайым учурдагы контексттен маалымат алат. Жогорудагы мисалда kubectl Hare кластерине туташат.

Демек, башка кластерге өтүү үчүн kubeconfig файлындагы учурдагы контекстти өзгөртүү керек:

Эми kubectl Fox кластерине туташат.

Ошол эле кластерде башка аттар мейкиндигине өтүү үчүн, учурдагы контекст үчүн аттар мейкиндигинин элементинин маанисин өзгөртүү керек:

Жогорудагы мисалда kubectl Fox кластеринин Prod аталыш мейкиндигин колдонот (мурда Test аттар мейкиндиги коюлган).

kubectl дагы варианттарды камсыздай тургандыгын белгилеңиз --cluster, --user, --namespace и --context, бул kubeconfigде эмне орнотулганына карабастан, айрым элементтерди жана учурдагы контексттин үстүнөн жазууга мүмкүндүк берет. Кара kubectl options.

Теориялык жактан алганда, сиз kubeconfigдеги орнотууларды кол менен өзгөртө аласыз. Бирок бул ыңгайсыз. Бул операцияларды жөнөкөйлөтүү үчүн, параметрлерди автоматтык түрдө өзгөртүүгө мүмкүндүк берген ар кандай утилиталар бар.

kubectx колдонуңуз

Кластерлердин жана аттар мейкиндигинин ортосунда которулуу үчүн абдан популярдуу утилита.

Утилита буйруктарды берет kubectx и kubens тиешелүүлүгүнө жараша учурдагы контекстти жана аттар мейкиндигин өзгөртүү үчүн.

Жогоруда айтылгандай, учурдагы контекстти өзгөртүү кластерди өзгөртүү дегенди билдирет, эгерде сизде кластерге бир гана контекст болсо.

Бул жерде бул буйруктарды иштетүүнүн бир мисалы болуп саналат:

Негизи, бул буйруктар жөн гана kubeconfig файлын жогоруда сүрөттөлгөндөй түзөтөт.

орнотуу kubectx, боюнча нускамаларды аткарыңыз Github.

Эки команда тең контексттин жана аттар мейкиндигинин аталыштарын автотолтурууну колдойт, бул аларды толугу менен терүүнүн зарылдыгын жок кылат. Автотолтурууну орнотуу боюнча нускамалар бул жерде.

Дагы бир пайдалуу өзгөчөлүк kubectx Ал интерактивдүү режим. Бул коммуналдык менен бирге иштейт fzf, өзүнчө орнотулушу керек. fzf автоматтык түрдө орнотуу интерактивдүү режимди жеткиликтүү кылат kubectx. Интерактивдүү түрдө, сиз fzf тарабынан берилген интерактивдүү акысыз издөө интерфейси аркылуу контекстти жана аттар мейкиндигин тандай аласыз.

Shell лакап аттарын колдонуу

Учурдагы контекстти жана аттар мейкиндигин өзгөртүү үчүн сизге өзүнчө куралдардын кереги жок, анткени 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-нс PATH өзгөрмөңүздүн каалаган каталогуна киргизиңиз жана аларды мис. chmod +x. Андан кийин дароо колдоно аласыз kubectl ctx и kubectl ns.

5. Автоалиаздар менен киргизүүнү азайтыңыз

Shell лакап аттары киргизүүнү тездетүүнүн жакшы жолу. Долбоор kubectl-лакап аттар негизги kubectl буйруктары үчүн 800гө жакын жарлыктарды камтыйт.

Сиз кызыктырышы мүмкүн - 800 лакап атын кантип эстейсиз? Бирок алардын баарын эстеп отуруунун кереги жок, анткени алар төмөндө келтирилген жөнөкөй схема боюнча курулган:

Мисалы:

кгпооамл - кубектл алуу подс оямл
ksysgsvcw — kubectl -n кубе-системасы svc w
ksysrmcm -kubectl -n кубе-системасы rm см
kgdepallls - 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 ресурсу үчүн эч кандай лакап ат жок).
Белгилүү бир поддон үчүн маалыматтарды алуу үчүн, сиз буйрукту колдоно аласыз kgpo my-pod — kubectl get pod my-pod.

Кээ бир лакап аттар буйрук сабынын аргументин талап кыларын эске алыңыз. Мисалы, лакап ат kgpol каражаттар kubectl get pods -l. Опция -l аргументти талап кылат - энбелги спецификациясы. Эгер сиз лакап ат колдонсоңуз, ал окшош болот kgpol app=ui.

Кээ бир лакап аттар аргументтерди талап кылгандыктан, a, f жана l лакап аттары акыркы колдонулушу керек.

Жалпысынан алганда, бул схеманы үйрөнгөндөн кийин, сиз аткаргыңыз келген буйруктардан интуитивдик түрдө лакап аттарды алып, терүү убактысын үнөмдөй аласыз.

орнотуу

kubectl-лакап аттарды орнотуу үчүн, сиз файлды жүктөп алышыңыз керек .kubectl_aliases GitHub тартып жана аны файлга кошуңуз ~/.bashrc же ~/.zshrc:

source ~/.kubectl_aliases

Автотолтуруу

Мурда айткандай, сиз көп учурда буйрук сабындагы лакап атка кошумча сөздөрдү кошосуз. Мисалы:

$ kgpooyaml test-pod-d4b77b989

Эгер сиз kubectl буйругун аяктоо функциясын колдонсоңуз, анда ресурстун аталыштары сыяктуу нерселер үчүн автотолтурууну колдонсоңуз керек. Бирок бул лакап аттар колдонулганда жасалышы мүмкүнбү?

Бул абдан маанилүү суроо, анткени автотолуктоо иштебесе, лакап аттардын кээ бир артыкчылыктарын жоготосуз.

Жооп сиз колдонуп жаткан кабыктан көз каранды:

Zsh үчүн, лакап ат менен бүтүрүү кутудан тышкары иштейт.
Bash үчүн, тилекке каршы, автотолтурууну ишке ашыруу үчүн кээ бир иштер талап кылынат.

Bashдагы лакап аттар үчүн автотолтурууну иштетүү

Bash менен көйгөй, ал лакап ат шилтеме кылган буйрукту эмес, (мисалы, Zsh кылгандай) лакап атын (Табылды баскан сайын) аягына чыгарууга аракет кылат. Бардык 800 лакап ат үчүн аяктоо скрипттери жок болгондуктан, автотолтуру иштебейт.

долбоору толук лакап ат бул маселенин жалпы чечилишин камсыз кылат. Ал лакап аттар үчүн аяктоо механизмине туташып, лакап атын буйрукка чейин кеңейтет жана аткарылган буйрук үчүн аяктоо параметрлерин кайтарат. Бул псевдоним үчүн толтургуч толук буйруктагыдай эле иштейт дегенди билдирет.

Төмөндө, мен адегенде толук лакап аттарды кантип орнотууну, андан кийин бардык kubectl лакап аттары үчүн аяктоону иштетүү үчүн аны кантип конфигурациялоону түшүндүрөм.

Толук лакап ат орнотулууда

Биринчиден, толук лакап ат көз каранды баш-аяктоо. Ошондуктан, толук лакап атын орнотуудан мурун, bash-толуктоо орнотулганын текшеришиңиз керек. Орнотуу көрсөтмөлөрү мурда Linux жана MacOS үчүн берилген.

MacOS колдонуучулары үчүн маанилүү эскертүү: Kubectl автотолтуруучу скрипт сыяктуу, толук лакап ат MacOSдо демейки болгон Bash 3.2 менен иштебейт. Атап айтканда, толук лакап ат bash-толтурулган v2 (brew install bash-completion@2), жок дегенде Bash 4.1 талап кылат. Бул MacOSдо толук лакап атын колдонуу үчүн Bashтын жаңыраак версиясын орнотуу керек дегенди билдирет.

Сиз скрипт жүктөп алышыңыз керек bash_completion.sh чейин GitHub репозиторий жана аны файлыңызга киргизиңиз ~/.bashrc:

source ~/bash_completion.sh

Кабакты кайра жүктөөдөн кийин, толук лакап ат толугу менен орнотулат.

kubectl лакап аттары үчүн автотолтурууну иштетүү

Техникалык жактан толук лакап ат орогуч функциясын камсыз кылат _complete_alias. Бул функция лакап атты текшерет жана лакап ат буйругу үчүн аяктоо ишаратын кайтарат.

Функцияны белгилүү бир лакап ат менен байланыштыруу үчүн, сиз орнотулган Bash механизмин колдонушуңуз керек аяктоо, орнотуу _complete_alias лакап атын аяктоо функциясы катары.

Мисал катары kubectl буйругун билдирген k лакап атын алалы. орнотуу _complete_alias Бул лакап ат үчүн кошумча функция катары, сиз төмөнкү буйрукту аткарышыңыз керек:

$ complete -F _complete_alias k

Мунун натыйжасы, к лакап атын автотолтурган сайын функция чакырылат _complete_alias, ал лакап атын текшерет жана буйрук үчүн аяктоо ишаратын кайтарат kubectl.

Экинчи мисал катары лакап атын алалы kg, дегенди билдирет kubectl get:

$ complete -F _complete_alias kg

Мурунку мисалдагыдай эле, сиз kg автоматтык түрдө толтурганда, сиз ала тургандай эле аяктоо кеңештерин аласыз. kubectl get.

Сиз тутумуңуздагы каалаган лакап ат үчүн толук лакап атын колдоно аласыз.

Ошондуктан, бардык kubectl лакап аттары үчүн автотолтурууну иштетүү үчүн, алардын ар бири үчүн жогорудагы буйрукту аткарышыңыз керек. Төмөнкү үзүндү дал ушундай кылат, эгерде сиз kubectl-лакап аттарды койгонсуз ~/.kubectl-aliases:

for _a in $(sed '/^alias /!d;s/^alias //;s/=.*$//' ~/.kubectl_aliases); 
do
  complete -F _complete_alias "$_a"
done

Бул код бөлүгүндө жайгаштырылышы керек ~/.bashrc, буйрук кабыгын кайра күйгүзүңүз жана автотолуктоо бардык 800 kubectl лакап аттар үчүн жеткиликтүү болот.

6. Plugins менен 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 баракчасы.

Крюнун эң маанилүү буйруктары:

# Поиск в списке плагинов
$ 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 аркылуу орнотулгандарды жана башка ыкмалар менен орнотулгандарды тизмелейт.

Башка жерден плагиндерди табуу

Крю - бул жаш долбоор, азыркы учурда тизме 30га жакын гана плагиндер. Эгер сизге керектүү нерсени таба албасаңыз, GitHub сыяктуу башка жерден плагиндерди таба аласыз.

Мен GitHub бөлүмүн карап чыгууну сунуштайм kubectl-плагиндер. Ал жерден сиз текшерүүгө арзырлык ондогон жеткиликтүү плагиндерди таба аласыз.

Өзүңүздүн плагиндериңизди жазуу

сен өзүң аласың плагиндерди түзүү - Бул кыйын эмес. Сизге керектүү нерсени аткарган аткарылуучу файлды түзүшүңүз керек, ага окшош 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-плагиндер.

Сиз ошондой эле плагиниңизди кошууну сурансаңыз болот Krew тизмеси. Муну кантип кылуу керектиги боюнча көрсөтмөлөр бар GitHub репозиторийлери.

Буйруктун бүтүшү

Плагиндер учурда автотолтурууну колдобойт. Башкача айтканда, сиз плагиндин толук атын жана аргументтердин толук аталышын киргизишиңиз керек.

Бул функция үчүн GitHub kubectl репозиторийинде бар ачык өтүнүч. Демек, бул өзгөчөлүк келечекте качандыр бир убакта ишке ашырылышы мүмкүн.

Жолуңуз ачык болсун!!!

Тема боюнча дагы эмнени окуу керек:

Source: www.habr.com

kubectl кантип натыйжалуураак колдонсо болот: деталдуу колдонмо