🥇Ինչպես ավելի արդյունավետ օգտագործել 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 հարցումներ կատարել Kubernetes API-ին.

Kubernetes-ը լիովին ռեսուրսների վրա հիմնված համակարգ է: Սա նշանակում է, որ այն պահպանում է ռեսուրսների ներքին վիճակը, և Kubernetes-ի բոլոր գործողությունները CRUD գործողություններ են:

Դուք լիովին վերահսկում եք Kubernetes-ը՝ կառավարելով այս ռեսուրսները, և Kubernetes-ը պարզում է, թե ինչ անել՝ ելնելով ռեսուրսների ներկա վիճակից: Այս պատճառով Kubernetes API-ի հղումը կազմակերպվում է որպես ռեսուրսների տեսակների ցանկ՝ իրենց հարակից գործառնություններով:

Դիտարկենք մի օրինակ.

Ենթադրենք, դուք ցանկանում եք ստեղծել ReplicaSet ռեսուրս: Դա անելու համար դուք նկարագրում եք ReplicaSet-ը ֆայլում անունով replicaset.yaml, ապա գործարկեք հրամանը.

$ kubectl create -f replicaset.yaml

Սա կստեղծի ReplicaSet ռեսուրս: Բայց ի՞նչ է կատարվում կուլիսների հետևում։

Kubernetes-ն ունի ReplicaSet-ի ստեղծման գործողություն: Ինչպես ցանկացած այլ գործողություն, այն բացահայտվում է որպես API վերջնակետ: Այս գործողության հատուկ API-ի վերջնակետը հետևյալն է.

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

API-ի վերջնակետերը Kubernetes-ի բոլոր գործողությունների համար կարելի է գտնել այստեղ API հղում (այդ թվում վերը նշված վերջնակետը) Վերջնական կետին փաստացի հարցում կատարելու համար նախ պետք է API սերվերի URL-ն ավելացնեք վերջնակետի ուղիներին, որոնք նշված են API հղումում:

Հետևաբար, երբ կատարում եք վերը նշված հրամանը, kubectl-ը HTTP POST հարցում է ուղարկում վերը նշված API-ի վերջնակետին: ReplicaSet սահմանումը, որը դուք տրամադրել եք ֆայլում replicaset.yaml, ուղարկվում է հարցումի մարմնում։

Այսպես է աշխատում kubectl-ը բոլոր հրամանների համար, որոնք փոխազդում են Kubernetes կլաստերի հետ։ Այս բոլոր դեպքերում kubectl-ը պարզապես HTTP հարցումներ է կատարում Kubernetes API-ի համապատասխան վերջնակետերին:

Խնդրում ենք նկատի ունենալ, որ դուք կարող եք ամբողջությամբ կառավարել Kubernetes-ը՝ օգտագործելով այնպիսի օգտակար ծրագիր, ինչպիսին է curlձեռքով ուղարկելով HTTP հարցումներ Kubernetes API-ին: Kubectl-ը պարզապես հեշտացնում է Kubernetes API-ի օգտագործումը:

Սա է այն հիմքերը, թե ինչ է kubectl-ը և ինչպես է այն աշխատում: Բայց Kubernetes API-ի հետ կապված այլ բան կա, որը պետք է իմանա kubectl-ի յուրաքանչյուր օգտվող: Եկեք արագ նայենք Kubernetes-ի ներաշխարհին:

Կուբերնետեսի ներաշխարհը

Kubernetes-ը բաղկացած է մի շարք անկախ բաղադրիչներից, որոնք աշխատում են որպես առանձին գործընթացներ կլաստերային հանգույցների վրա։ Որոշ բաղադրիչներ աշխատում են հիմնական հանգույցների վրա, մյուսները աշխատող հանգույցների վրա, յուրաքանչյուր բաղադրիչ կատարում է իր հատուկ առաջադրանքը:

Ահա հիմնական հանգույցների ամենակարևոր բաղադրիչները.

Պահոց - պահպանում է ռեսուրսների սահմանումները (սովորաբար դա և այլն).
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-ը կարդում է pod սահմանումը պահեստից և հրահանգում է կոնտեյների գործարկման ժամանակին, ինչպիսին է Docker-ը, բեռնարկղերը գործարկել հանգույցի վրա.

Ստորև ներկայացված է այս նկարագրության տեքստային տարբերակը:

ReplicaSet-ի ստեղծման վերջնակետին API հարցումը մշակվում է API սերվերի կողմից: API սերվերը վավերացնում է հարցումը և պահում է ReplicaSet ռեսուրսի սահմանումը պահեստում:

Այս իրադարձությունը սկսում է ReplicaSet կարգավորիչը, որը վերահսկիչի կառավարչի ենթագործընթաց է: ReplicaSet վերահսկիչը վերահսկում է ReplicaSet ռեսուրսների ստեղծումը, թարմացումը և ջնջումը խանութում և ստանում է իրադարձության ծանուցում, երբ դա տեղի է ունենում:

ReplicaSet վերահսկիչի խնդիրն է ապահովել, որ ReplicaSet-ի անհրաժեշտ թվով պատյաններ կան: Մեր օրինակում դեռևս չկա պատիճ, ուստի ReplicaSet կարգավորիչը ստեղծում է այս պատիճ սահմանումները (ըստ ReplicaSet սահմանման պատիճ ձևանմուշի) և պահում դրանք պահեստում:

Նոր բլոկների ստեղծումը գործարկվում է ժամանակացույցի միջոցով, որը հետևում է պատիճների սահմանումներին, որոնք դեռ նախատեսված չեն աշխատանքային հանգույցների համար: Ժամանակացույցը յուրաքանչյուր պատի համար ընտրում է համապատասխան աշխատող հանգույց և թարմացնում է պահեստի սահմանումները:

Նկատի ունեցեք, որ մինչև այս պահը կլաստերի ոչ մի տեղ աշխատանքային ծանրաբեռնվածության ծածկագիր չէր գործում: Այն ամենը, ինչ արվել է մինչ այժմ - սա հիմնական հանգույցի պահեստում ռեսուրսների ստեղծումն ու թարմացումն է:

Վերջին իրադարձությունը գործարկում է Kubelets-ը, որը վերահսկում է իրենց աշխատանքային հանգույցների համար նախատեսված պատյանները: Աշխատող հանգույցի Kubelet-ը, որի վրա տեղադրված են ձեր ReplicaSet պատիճները, պետք է ցուցում տա կոնտեյների գործարկման ժամանակին, ինչպիսին է Docker-ը, ներբեռնելու անհրաժեշտ կոնտեյների պատկերները և գործարկելու դրանք:

Այս պահին ձեր ReplicaSet հավելվածը վերջապես գործարկվում է:

Kubernetes API-ի դերը

Ինչպես տեսաք նախորդ օրինակում, Kubernetes-ի բաղադրիչները (բացառությամբ API սերվերի և պահեստի) հետևում են պահեստի ռեսուրսների փոփոխություններին և փոխում են պահեստի ռեսուրսների մասին տեղեկատվությունը:

Իհարկե, այս բաղադրիչները ուղղակիորեն չեն փոխազդում պահեստավորման հետ, այլ միայն Kubernetes API-ի միջոցով:

Դիտարկենք հետևյալ օրինակները:

ReplicaSet վերահսկիչն օգտագործում է API-ի վերջնակետը ցուցակ ReplicaSets պարամետրով watch ReplicaSet ռեսուրսների փոփոխությունները վերահսկելու համար:
ReplicaSet վերահսկիչն օգտագործում է API-ի վերջնակետը ստեղծել Pod (create pod) պատիճներ ստեղծելու համար:
Ժամանակացույցն օգտագործում է API-ի վերջնակետը կարկատել պատիճ (խմբագրել պատիճ)՝ ընտրված աշխատող հանգույցի մասին տեղեկություններով բլոկները թարմացնելու համար:

Ինչպես տեսնում եք, սա նույն API-ն է, որին հասանելի է kubectl-ը: Ներքին բաղադրիչների և արտաքին օգտագործողների համար նույն API-ի օգտագործումը Kubernetes-ի դիզայնի հիմնարար հայեցակարգ է:

Այժմ մենք կարող ենք ամփոփել, թե ինչպես է աշխատում Kubernetes-ը.

Պահեստային խանութներում նշվում է, այսինքն՝ Kubernetes ռեսուրսները։
API սերվերն ապահովում է ինտերֆեյս պահեստին Kubernetes API-ի տեսքով:
Kubernetes-ի մյուս բոլոր բաղադրիչները և օգտվողները կարդում, դիտում և շահարկում են Kubernetes-ի վիճակը (ռեսուրսները) API-ի միջոցով:

Այս հասկացությունների իմացությունը կօգնի ձեզ ավելի լավ հասկանալ kubectl-ը և առավելագույն օգուտ քաղել դրանից:

Այժմ եկեք տեսնենք մի քանի կոնկրետ խորհուրդներ և հնարքներ, որոնք կօգնեն բարելավել ձեր արտադրողականությունը kubectl-ի հետ:

1. Արագացրեք մուտքագրումը, օգտագործելով հրամանի ավարտը

Kubectl-ով կատարողականը բարելավելու ամենաօգտակար, բայց հաճախ անտեսված տեխնիկաներից մեկը հրամանի ավարտն է:

Հրամանի ավարտը թույլ է տալիս ավտոմատ կերպով լրացնել kubectl հրամանների մասերը՝ օգտագործելով Tab ստեղնը: Սա աշխատում է ենթահրամանների, տարբերակների և փաստարկների համար, ներառյալ այնպիսի բարդ բան, ինչպիսին ռեսուրսների անուններն են:

Տեսեք, թե ինչպես է աշխատում kubectl հրամանի ավարտը.

Հրամանների ավարտի աշխատանքներ Bash և Zsh պատյանների համար:

Պաշտոնական ուղեցույց պարունակում է մանրամասն հրահանգներ ավտոմատ լրացումը կարգավորելու համար, բայց ստորև մենք կտրամադրենք կարճ հատված:

Ինչպես է աշխատում հրամանի ավարտը

Հրամանի ավարտը կեղևի հատկություն է, որն աշխատում է ավարտման սցենարի միջոցով: Ընդլայնման սկրիպտը shell script է, որը սահմանում է ընդլայնման վարքագիծը կոնկրետ հրամանի համար:

Kubectl-ը ավտոմատ կերպով ստեղծում և թողարկում է ընդլայնման սցենարներ Bash-ի և Zsh-ի համար՝ օգտագործելով հետևյալ հրամանները.

$ kubectl completion bash

Или:

$ kubectl completion zsh

Տեսականորեն բավական է այս հրամանների ելքը միացնել համապատասխան հրամանի վահանակին, որպեսզի kubectl-ը կարողանա լրացնել հրամանները։

Գործնականում միացման եղանակը տարբեր է Bash-ի համար (ներառյալ Linux-ի և MacOS-ի տարբերությունները) և Zsh-ի համար: Ստորև մենք կանդրադառնանք այս բոլոր տարբերակներին:

Bash Linux-ում

Bash-ի ավարտման սկրիպտը կախված է bash-լրացման փաթեթից, այնպես որ նախ պետք է այն տեղադրել.

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

Դուք կարող եք ստուգել, որ փաթեթը հաջողությամբ տեղադրվել է՝ օգտագործելով հետևյալ հրամանը.

$ type _init_completion

Եթե սա թողարկում է shell ֆունկցիայի կոդը, ապա bash-completion-ը ճիշտ է տեղադրված: Եթե հրամանը տալիս է «Չգտնվել» սխալ, դուք պետք է ձեր ֆայլին ավելացնեք հետևյալ տողը ~ / .bashrc:

$ source /usr/share/bash-completion/bash_completion

Արդյո՞ք անհրաժեշտ է այս տողը ավելացնել ֆայլին ~ / .bashrc թե ոչ, կախված է փաթեթի կառավարիչից, որը դուք օգտագործել եք bash-completion-ը տեղադրելու համար: Սա անհրաժեշտ է APT-ի համար, բայց ոչ YUM-ի համար:

Bash-completion-ը տեղադրելուց հետո դուք պետք է ամեն ինչ կարգավորեք այնպես, որ kubectl-ի ավարտման սցենարը միացված լինի shell-ի բոլոր նիստերում:

Դա անելու եղանակներից մեկը ֆայլին հետևյալ տողն ավելացնելն է ~ / .bashrc:

source <(kubectl completion bash)

Մեկ այլ միջոց է ավելացնել kubectl ընդլայնման սցենարը գրացուցակում /etc/bash_completion.d (ստեղծեք այն, եթե այն գոյություն չունի):

$ kubectl completion bash >/etc/bash_completion.d/kubectl

Բոլոր հավելյալ սցենարները կատալոգում /etc/bash_completion.d ավտոմատ կերպով ներառվում են bash-լրացման մեջ:

Երկու տարբերակներն էլ հավասարապես կիրառելի են։

Shell-ը վերագործարկելուց հետո կաշխատի kubectl հրամանի ավարտը:

Bash MacOS-ի վրա

MacOS-ում կարգավորումը մի փոքր ավելի բարդ է: Փաստն այն է, որ լռելյայնորեն MacOS-ն օգտագործում է Bash 3.2 տարբերակը, իսկ kubectl ավտոմատ լրացման սցենարը պահանջում է առնվազն 4.1 Bash տարբերակ և չի աշխատում Bash 3.2-ում։

Կան լիցենզավորման հետ կապված խնդիրներ՝ կապված MacOS-ում Bash-ի հնացած տարբերակի օգտագործման հետ: Bash-ի 4-րդ տարբերակը լիցենզավորված է GPLv3-ով, որը չի աջակցվում Apple-ի կողմից:

MacOS-ում kubectl-ի ավտոմատ լրացումը կարգավորելու համար հարկավոր է տեղադրել Bash-ի ավելի վերջին տարբերակը: Դուք կարող եք նաև տեղադրել թարմացված Bash-ը որպես ձեր լռելյայն պատյան, որը հետագայում կփրկի ձեզ բազմաթիվ խնդիրներից: Դժվար չէ, մանրամասները ներկայացված են հոդվածում «Bash-ի թարմացում MacOS-ում.

Շարունակելուց առաջ համոզվեք, որ օգտագործում եք Bash-ի վերջին տարբերակը (ստուգեք ելքը bash --version).

Bash-ի ավարտի սցենարը տատանվում է ըստ նախագծի բաշ-լրացում, այնպես որ նախ անհրաժեշտ է տեղադրել այն:

Դուք կարող եք տեղադրել bash-լրացումը՝ օգտագործելով Homebrew:

$ brew install bash-completion@2

Այստեղ @2 նշանակում է bash-completion տարբերակ 2: kubectl-ի ավտոմատ լրացումը պահանջում է bash-completion v2, իսկ bash-completion v2-ը պահանջում է նվազագույնը Bash 4.1 տարբերակ:

Հրամանի ելք brew-install պարունակում է Զգուշացումներ բաժին, որը նշում է, թե ինչ պետք է ավելացվի ֆայլին ~/.bash_profile:

export BASH_COMPLETION_COMPAT_DIR=/usr/local/etc/bash_completion.d
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . 
"/usr/local/etc/profile.d/bash_completion.sh"

Այնուամենայնիվ, ես խորհուրդ եմ տալիս այս տողերը չավելացնել ~/.bash_profile, իսկ ներսում ~/.bashrc. Այս դեպքում ավտոմատ լրացումը հասանելի կլինի ոչ միայն հիմնական, այլ նաև մանկական հրամանների պատյաններում:

Հրամանի վահանակը վերագործարկելուց հետո կարող եք ստուգել, որ տեղադրումը ճիշտ է, օգտագործելով հետևյալ հրամանը.

$ type _init_completion

Եթե ելքում տեսնում եք 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-ի ավտոմատ լրացման սցենարները որևէ կախվածություն չեն պահանջում: Ձեզ անհրաժեշտ է ընդամենը միացնել դրանք, երբ բեռնում եք հրամանի վահանակը:

Դուք կարող եք դա անել՝ ավելացնելով ձեր տող ~/.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 ձեռնարկում պարունակվողին:

By default 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 արտահայտություններ

Ռեսուրսների դաշտերի ընտրության արտահայտությունները հիմնված են JSONPath.

JSONPath-ը JSON փաստաթղթերից տվյալների առբերման լեզու է: Մեկ դաշտ ընտրելը JSONPath-ի օգտագործման ամենապարզ դեպքն է: Նա շատ բան ունի ավելի շատ հնարավորություններ, ներառյալ ընտրիչներ, զտիչներ և այլն:

Kubectl-ի բացատրությունն աջակցում է JSONPath-ի սահմանափակ թվով հնարավորությունների: Դրանց օգտագործման հնարավորություններն ու օրինակները նկարագրված են ստորև.

# Выбрать все элементы списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[*].image'
# Выбрать специфический элемент списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[0].image'
# Выбрать элементы списка, попадающие под фильтр
$ kubectl get pods -o custom-columns='DATA:spec.containers[?(@.image!="nginx")].image'
# Выбрать все поля по указанному пути, независимо от их имени
$ kubectl get pods -o custom-columns='DATA:metadata.*'
# Выбрать все поля с указанным именем, вне зависимости от их расположения
$ kubectl get pods -o custom-columns='DATA:..image'

Հատկապես կարևոր է [] օպերատորը: Kubernetes-ի ռեսուրսների շատ դաշտեր ցուցակներ են, և այս օպերատորը թույլ է տալիս ընտրել այդ ցուցակների անդամներին: Այն հաճախ օգտագործվում է նիշերի հետ, ինչպիսին է [*]՝ ցուցակի բոլոր տարրերն ընտրելու համար:

Կիրառման օրինակներ

Պատվերով սյունակի ելքային ձևաչափի օգտագործման հնարավորություններն անսահման են, քանի որ դուք կարող եք ցուցադրել ցանկացած դաշտ կամ ռեսուրսների դաշտերի համակցություն արդյունքում: Ահա որոշ հավելվածների նմուշներ, բայց ազատ զգալ ուսումնասիրել դրանք ինքներդ և գտնել ձեզ համար հարմար հավելվածներ:

Ցուցադրվում են բեռնարկղերի պատկերներ պատիճների համար.
```
$ kubectl get pods 
  -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

NAME                        IMAGES
engine-544b6b6467-22qr6     rabbitmq:3.7.8-management,nginx
engine-544b6b6467-lw5t8     rabbitmq:3.7.8-management,nginx
engine-544b6b6467-tvgmg     rabbitmq:3.7.8-management,nginx
web-ui-6db964458-8pdw4      wordpress
```
Այս հրամանը ցուցադրում է կոնտեյների պատկերների անունները յուրաքանչյուր պատի համար:

Հիշեք, որ պատիճը կարող է պարունակել մի քանի կոնտեյներ, այնուհետև պատկերների անունները կցուցադրվեն մեկ տողի վրա՝ բաժանված ստորակետերով:
Ցուցադրվում են հանգույցների հասանելիության գոտիները.
```
$ kubectl get nodes 
  -o 
custom-columns='NAME:metadata.name,ZONE:metadata.labels.failure-domain.beta.kubernetes.io/zone'

NAME                          ZONE
ip-10-0-118-34.ec2.internal   us-east-1b
ip-10-0-36-80.ec2.internal    us-east-1a
ip-10-0-80-67.ec2.internal    us-east-1b
```
Այս հրամանը օգտակար է, եթե ձեր կլաստերը տեղակայված է հանրային ամպի մեջ: Այն ցուցադրում է յուրաքանչյուր հանգույցի հասանելիության գոտին:

Հասանելիության գոտին ամպային հասկացություն է, որը սահմանափակում է կրկնօրինակման գոտին աշխարհագրական տարածաշրջանով:

Յուրաքանչյուր հանգույցի համար հասանելիության գոտիները ձեռք են բերվում հատուկ պիտակի միջոցով. failure-domain.beta.kubernetes.io/zone. Եթե կլաստերը աշխատում է հանրային ամպի մեջ, այս պիտակը ստեղծվում է ավտոմատ կերպով և լրացվում է յուրաքանչյուր հանգույցի համար հասանելիության գոտիների անուններով:

Պիտակները Kubernetes ռեսուրսների ճշգրտման մաս չեն կազմում, ուստի դրանց մասին տեղեկություններ չեք գտնի API ուղեցույց. Այնուամենայնիվ, դրանք կարելի է տեսնել (ինչպես ցանկացած այլ պիտակ), եթե YAML կամ JSON ձևաչափով հանգույցների մասին տեղեկատվություն եք պահանջում.
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Սա հիանալի միջոց է ռեսուրսների մասին ավելին իմանալու համար, բացի ռեսուրսների առանձնահատկություններից:

4. Հեշտությամբ անցեք կլաստերների և անվանատարածքների միջև

Երբ kubectl-ը հարցում է կատարում Kubernetes API-ին, այն նախ կարդում է kubeconfig ֆայլը՝ կապի համար անհրաժեշտ բոլոր պարամետրերը ստանալու համար։

Լռելյայնորեն kubeconfig ֆայլն է ~/.kube/config. Սովորաբար այս ֆայլը ստեղծվում կամ թարմացվում է հատուկ հրամանով:

Երբ աշխատում եք մի քանի կլաստերների հետ, ձեր kubeconfig ֆայլը պարունակում է կարգավորումներ՝ այդ բոլոր կլաստերներին միանալու համար: Ձեզ անհրաժեշտ է միջոց՝ ասելու kubectl հրամանին, թե որ կլաստերի հետ եք աշխատում:

Կլաստերի ներսում դուք կարող եք ստեղծել բազմաթիվ անվանատարածքներ՝ վիրտուալ կլաստերի տեսակ ֆիզիկական կլաստերի մեջ: Kubectl-ը նաև որոշում է, թե որ անվանատարածքն օգտագործել՝ հիմնվելով kubeconfig ֆայլի վրա: Սա նշանակում է, որ ձեզ նույնպես պետք է միջոց՝ ասելու kubectl հրամանին, թե ինչ անվանատարածքի հետ աշխատել:

Այս գլխում մենք կբացատրենք, թե ինչպես է այն աշխատում և ինչպես այն արդյունավետորեն աշխատել:

Նկատի ունեցեք, որ դուք կարող եք ունենալ բազմաթիվ kubeconfig ֆայլեր, որոնք նշված են KUBECONFIG միջավայրի փոփոխականում: Այս դեպքում բոլոր այս ֆայլերը կմիավորվեն մեկ ընդհանուր կազմաձևման մեջ՝ գործարկման ժամանակ: Կարող եք նաև փոխել լռելյայն kubeconfig ֆայլը՝ գործարկելով kubectl պարամետրով --kubeconfig. Նայել պաշտոնական փաստաթղթեր.

kubeconfig ֆայլեր

Տեսնենք, թե կոնկրետ ինչ է պարունակում kubeconfig ֆայլը.

Ինչպես տեսնում եք, kubeconfig ֆայլը պարունակում է մի շարք համատեքստեր: Համատեքստը բաղկացած է երեք տարրերից.

Կլաստեր — կլաստերի սերվերի API URL:
Օգտատեր - օգտագործողի նույնականացման հավատարմագրերը կլաստերում:
Անվանատարածք - անվանատարածք, որն օգտագործվում է կլաստերին միանալիս:

Գործնականում նրանք հաճախ օգտագործում են մեկ համատեքստ յուրաքանչյուր կլաստերի համար իրենց kubeconfig-ում: Այնուամենայնիվ, յուրաքանչյուր կլաստերի համար դուք կարող եք ունենալ բազմաթիվ համատեքստեր, որոնք տարբերվում են օգտագործողի կամ անվանատարածքից: Այնուամենայնիվ, այս բազմատեքստային կոնֆիգուրացիան հազվադեպ է, ուստի սովորաբար լինում է մեկ առ մեկ քարտեզագրում կլաստերների և համատեքստերի միջև:

Ցանկացած պահի համատեքստերից մեկը արդիական է.

Երբ kubectl-ը կարդում է կազմաձևման ֆայլը, այն միշտ տեղեկատվություն է վերցնում ընթացիկ համատեքստից: Վերևի օրինակում kubectl-ը կմիանա Նապաստակի կլաստերին:

Համապատասխանաբար, մեկ այլ կլաստերի անցնելու համար անհրաժեշտ է փոխել ընթացիկ համատեքստը kubeconfig ֆայլում.

Այժմ kubectl-ը կմիանա Fox կլաստերին:

Նույն կլաստերում այլ անվանատարածք անցնելու համար անհրաժեշտ է փոխել անվանատարածքի տարրի արժեքը ընթացիկ համատեքստում.

Վերոնշյալ օրինակում kubectl-ը կօգտագործի Fox կլաստերի Prod անվանատարածքը (նախկինում դրված էր Test namespace-ը):

Նշենք, որ kubectl-ը տրամադրում է նաև տարբերակներ --cluster, --user, --namespace и --context, որոնք թույլ են տալիս վերագրել առանձին տարրեր և բուն ներկա համատեքստը՝ անկախ նրանից, թե ինչ է սահմանված kubeconfig-ում: Նայել kubectl options.

Տեսականորեն, դուք կարող եք ձեռքով փոխել կարգավորումները kubeconfig-ում: Բայց դա անհարմար է: Այս գործողությունները պարզեցնելու համար կան տարբեր կոմունալ ծառայություններ, որոնք թույլ են տալիս ավտոմատ կերպով փոխել պարամետրերը:

Օգտագործեք kubectx

Կլաստերների և անվանատարածքների միջև անցում կատարելու համար շատ տարածված օգտակար ծրագիր:

Կոմունալը հրամաններ է տալիս kubectx и kubens փոխելու ընթացիկ համատեքստը և անվանատարածքը համապատասխանաբար:

Ինչպես նշվեց, ներկայիս համատեքստը փոխելը նշանակում է փոխել կլաստերը, եթե յուրաքանչյուր կլաստերի համար ունեք միայն մեկ համատեքստ:

Ահա այս հրամանները գործարկելու օրինակ.

Ըստ էության, այս հրամանները պարզապես խմբագրում են kubeconfig ֆայլը, ինչպես նկարագրված է վերևում:

տեղադրել kubectx, հետևեք հրահանգներին Գիտուբ.

Երկու հրամաններն էլ աջակցում են համատեքստի և անվանատարածքի անունների ավտոմատ լրացմանը, ինչը վերացնում է դրանք ամբողջությամբ մուտքագրելու անհրաժեշտությունը: Ավտոմատ լրացումը կարգավորելու ցուցումներ այստեղ.

Մեկ այլ օգտակար հատկություն 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 plugin-ը և գործարկել այն՝ կատարելով հրամանը kubectl foo.

Հարմար կլիներ այս կերպ փոխել համատեքստն ու անվանատարածքը, օրինակ՝ գործարկելով kubectl ctx փոխել համատեքստը և kubectl ns անվանատարածքը փոխելու համար։

Ես գրել եմ երկու պլագին, որոնք անում են սա.

Պլագինների աշխատանքը հիմնված է նախորդ բաժնի այլ անունների վրա:

Ահա թե ինչպես են նրանք աշխատում.

Նկատի ունեցեք, որ հավելումները օգտագործում են fzf՝ ինտերակտիվ անվճար որոնման ինտերֆեյս ապահովելու համար (ինչպես kubectx-ի ինտերակտիվ ռեժիմը): Սա նշանակում է, որ դուք պետք է տեղադրել fzfօգտագործել այս կեղծանունները:

Փլագիններ տեղադրելու համար հարկավոր է ներբեռնել կեղևի անուններով սկրիպտներ kubectl-ctx и kubectl-ns ձեր PATH փոփոխականի ցանկացած գրացուցակում և դրանք գործարկելի դարձրեք, օրինակ. chmod +x. Դրանից անմիջապես հետո դուք կկարողանաք օգտագործել kubectl ctx и kubectl ns.

5. Նվազեցրեք մուտքագրումը autoaliases-ով

Shell կեղծանունները մուտքագրումն արագացնելու լավ միջոց են: Նախագիծ kubectl-aliases պարունակում է մոտ 800 դյուրանցումներ հիմնական kubectl հրամանների համար:

Ձեզ կարող է հետաքրքրել՝ ինչպե՞ս եք հիշում 800 այլանունները: Բայց ձեզ հարկավոր չէ բոլորին հիշել, քանի որ դրանք կառուցված են պարզ սխեմայի համաձայն, որը տրված է ստորև.

Օրինակ `

kgpooyaml - kubectl ստանալ pods oyaml
ksysgsvcw — kubectl -n kube-system ստանալ svc w
ksysrmcm -kubectl -n kube-system rm cm
kgdepallsl - kubectl ստանալ տեղակայում բոլոր sl

Ինչպես տեսնում եք, կեղծանունները կազմված են բաղադրիչներից, որոնցից յուրաքանչյուրը ներկայացնում է kubectl հրամանի որոշակի տարր: Յուրաքանչյուր կեղծանուն կարող է ունենալ մեկ բաղադրիչ՝ բազային հրամանի, գործողության և ռեսուրսի համար, և մի քանի բաղադրիչ՝ պարամետրերի համար: Դուք պարզապես «բնակեցնում եք» այս բաղադրիչները ձախից աջ՝ համաձայն վերևի գծապատկերի:

Ընթացիկ մանրամասն դիագրամը գտնվում է GitHub. Այնտեղ կարող եք նաև գտնել ծածկանունների ամբողջական ցանկը.

Օրինակ, kgpooyamlall կեղծանունը համարժեք է հրամանին kubectl get pods -o yaml --all-namespaces.

Ընտրանքների հարաբերական հերթականությունը կարևոր չէ՝ հրաման kgpooyamlall համարժեք է հրամանին kgpoalloyaml.

Պետք չէ բոլոր բաղադրիչներն օգտագործել որպես այլանուններ: Օրինակ k, kg, klo, ksys, kgpo կարող է օգտագործվել նաև. Ավելին, հրամանի տողում կարող եք համատեղել փոխանունները և կանոնավոր հրամանները կամ տարբերակները.

Օրինակ `

Փոխարենը kubectl proxy կարող ես գրել k proxy.
Փոխարենը kubectl get roles կարող ես գրել kg roles (ներկայումս դերերի ռեսուրսի այլանուն չկա):
Կոնկրետ պատիվի համար տվյալներ ստանալու համար կարող եք օգտագործել հրամանը kgpo my-pod — kubectl get pod my-pod.

Խնդրում ենք նկատի ունենալ, որ որոշ կեղծանուններ պահանջում են հրամանի տողի արգումենտ: Օրինակ՝ կեղծանունը kgpol միջոց kubectl get pods -l. Տարբերակ -l պահանջում է փաստարկ՝ պիտակի հստակեցում: Եթե օգտագործեք այլանուն, այն նման կլինի kgpol app=ui.

Քանի որ որոշ այլանուններ պահանջում են փաստարկներ, a, f և l անունները պետք է օգտագործվեն վերջինը:

Ընդհանրապես, այս սխեմայից կախված լինելուն պես, դուք կարող եք ինտուիտիվ կերպով ստանալ անուն-ազգանուններ այն հրամաններից, որոնք ցանկանում եք կատարել և խնայել տպելու շատ ժամանակ:

Տեղադրում

Kubectl-aliases տեղադրելու համար անհրաժեշտ է ներբեռնել ֆայլը .kubectl_aliases GitHub-ից և ներառեք այն ֆայլում ~/.bashrc կամ ~/.zshrc:

source ~/.kubectl_aliases

Ավտոլրացում

Ինչպես նախկինում ասացինք, դուք հաճախ լրացուցիչ բառեր եք ավելացնում հրամանի տողում գտնվող այլանունին: Օրինակ:

$ kgpooyaml test-pod-d4b77b989

Եթե դուք օգտագործում եք kubectl հրամանի ավարտը, դուք հավանաբար օգտագործել եք ավտոմատ լրացում այնպիսի բաների համար, ինչպիսիք են ռեսուրսների անունները: Բայց կարո՞ղ է դա անել, երբ օգտագործվում են կեղծանուններ:

Սա շատ կարևոր հարց է, քանի որ եթե ինքնալրացումը չաշխատի, դուք կկորցնեք այլանունների որոշ առավելություններ:

Պատասխանը կախված է նրանից, թե որ պատյան եք օգտագործում.

Zsh-ի համար alias-ի լրացումն աշխատում է առանց տուփի:
Bash-ի համար, ցավոք, որոշակի աշխատանք է պահանջվում, որպեսզի ավտոմատ լրացումն աշխատի:

Bash-ում մականունների ավտոմատ լրացման ակտիվացում

Bash-ի խնդիրն այն է, որ այն փորձում է լրացնել (ամեն անգամ, երբ սեղմում եք Tab-ը) alias-ը, այլ ոչ թե հրամանը, որին վերաբերում է alias-ը (ինչպես, օրինակ, Zsh-ն է անում): Քանի որ դուք չունեք ավարտման սկրիպտներ բոլոր 800 փոխանունների համար, ավտոմատ լրացումը չի աշխատում:

Ծրագիր ամբողջական-անուն տալիս է այս խնդրի ընդհանուր լուծումը: Այն միանում է փոխանունների ավարտման մեխանիզմին, ներքուստ ընդլայնում է փոխանունը հրամանի մեջ և վերադարձնում ավարտված հրամանի ավարտման տարբերակները: Սա նշանակում է, որ կեղծանունի լիցքը ճիշտ նույն կերպ է վարվում, ինչ ամբողջական հրամանի համար:

Հետևյալում ես նախ կբացատրեմ, թե ինչպես տեղադրել ամբողջական-ալիասը, ապա ինչպես կարգավորել այն, որպեսզի հնարավոր լինի լրացնել բոլոր kubectl կեղծանունները:

Ամբողջական կեղծանունների տեղադրում

Առաջին հերթին, լրիվ-alias-ը կախված է բաշ-լրացում. Հետեւաբար, նախքան full-alias-ը տեղադրելը, դուք պետք է համոզվեք, որ bash-completion-ը տեղադրված է: Տեղադրման հրահանգները նախկինում տրամադրվել են Linux-ի և MacOS-ի համար:

Կարևոր նշում MacOS-ի օգտատերերի համարԻնչպես kubectl-ի ավտոմատ լրացման սկրիպտը, Complete-alias-ը չի աշխատում Bash 3.2-ի հետ, որը լռելյայն է MacOS-ում: Մասնավորապես, full-alias-ը կախված է bash-completion v2-ից (brew install bash-completion@2), որը պահանջում է առնվազն Bash 4.1: Սա նշանակում է, որ MacOS-ում ամբողջական կեղծանուն օգտագործելու համար հարկավոր է տեղադրել Bash-ի ավելի նոր տարբերակը:

Դուք պետք է ներբեռնեք սցենարը bash_completion.sh - ից GitHub պահոց և ներառեք այն ձեր ֆայլում ~/.bashrc:

source ~/bash_completion.sh

Շելլը վերագործարկելուց հետո ամբողջական կեղծանունը ամբողջությամբ կտեղադրվի:

Միացնելով ավտոմատ լրացումը kubectl փոխանունների համար

Տեխնիկապես ամբողջական կեղծանունը ապահովում է փաթաթման գործառույթ _complete_alias. Այս ֆունկցիան ստուգում է alias-ը և վերադարձնում է 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

Ինչպես նախորդ օրինակում, երբ դուք ավտոմատ լրացնում եք կգ-ը, դուք ստանում եք ավարտման նույն հուշումները, որոնք կստանաք 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. Ընդլայնելով kubectl-ը պլագիններով

Քանի որ տարբերակը 1.12, kubectl աջակցում է plugin մեխանիզմ, որը թույլ է տալիս ընդլայնել նրա գործառույթները լրացուցիչ հրամաններով։

Եթե ծանոթ եք Git plugin մեխանիզմներ, ապա նույն սկզբունքով են կառուցված kubectl փլագինները։

Այս գլխում մենք կքննարկենք, թե ինչպես տեղադրել պլագիններ, որտեղ գտնել դրանք և ինչպես ստեղծել ձեր սեփական պլագինները:

Պլագինների տեղադրում

Kubectl պլագինները բաշխվում են որպես պարզ գործարկվող ֆայլեր՝ նման անունով kubectl-x. Նախածանց kubectl- պահանջվում է, որին հաջորդում է նոր kubectl ենթահրաման, որը թույլ է տալիս զանգահարել plugin-ը:

Օրինակ, hello plugin-ը կբաշխվի որպես ֆայլ, որը կոչվում է kubectl-hello.

Փլագինը տեղադրելու համար անհրաժեշտ է պատճենել ֆայլը kubectl-x ձեր PATH-ի ցանկացած գրացուցակում և այն գործարկելի դարձրեք, օրինակ՝ հետ chmod +x. Դրանից անմիջապես հետո դուք կարող եք զանգահարել plugin-ին kubectl x.

Դուք կարող եք օգտագործել հետևյալ հրամանը՝ թվարկելու բոլոր պլագինները, որոնք ներկայումս տեղադրված են ձեր համակարգում.

$ kubectl plugin list

Այս հրամանը նաև կցուցադրի նախազգուշացումներ, եթե ունեք մի քանի փլագիններ նույն անունով, կամ եթե կա plugins ֆայլ, որը գործարկելի չէ:

Krew-ի միջոցով պլագինների որոնում և տեղադրում

Kubectl հավելվածները կարող են համօգտագործվել կամ նորից օգտագործվել, ինչպես ծրագրային փաթեթները: Բայց որտեղ կարող եք գտնել պլագիններ, որոնք ուրիշները կիսել են:

Project Krew նպատակ ունի տրամադրել միասնական լուծում kubectl հավելվածների փոխանակման, որոնման, տեղադրման և կառավարման համար: Նախագիծն իրեն անվանում է «kubectl plugins-ի փաթեթների կառավարիչ» (Krew-ն նման է եփել).

Krew-ը kubectl հավելումների ցանկ է, որը կարող եք ընտրել և տեղադրել: Միևնույն ժամանակ, Krew-ն նաև plugin է kubectl-ի համար։

Սա նշանակում է, որ Krew-ի տեղադրումն աշխատում է, ըստ էության, ինչպես ցանկացած այլ kubectl plugin տեղադրելը: Դուք կարող եք գտնել մանրամասն հրահանգներ այստեղ 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 script, python script կամ կազմված GO հավելված, դա նշանակություն չունի: Միակ պայմանն այն է, որ այն կարող է ուղղակիորեն գործարկվել օպերացիոն համակարգում:

Եկեք ստեղծենք մի օրինակ plugin հենց հիմա: Նախորդ բաժնում դուք օգտագործել եք 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-ի ցանկացած գրացուցակ: Դրանից անմիջապես հետո դուք կարող եք օգտագործել plugin-ը kubectl img.

Ինչպես նշվեց, kubectl plugin-ները կարող են գրվել ցանկացած ծրագրավորման կամ սկրիպտային լեզվով։ Եթե դուք օգտագործում եք shell scripts, առավելությունն այն է, որ կարող եք հեշտությամբ զանգահարել kubectl հավելվածի ներսում: Այնուամենայնիվ, դուք կարող եք գրել ավելի բարդ պլագիններ իրական ծրագրավորման լեզուներով՝ օգտագործելով Kubernetes հաճախորդների գրադարան. Եթե դուք օգտագործում եք Go, կարող եք նաև օգտագործել cli-runtime գրադարան, որը հատուկ գոյություն ունի kubectl պլագիններ գրելու համար։

Ինչպես կիսել ձեր պլագինները

Եթե կարծում եք, որ ձեր փլագինները կարող են օգտակար լինել ուրիշների համար, ազատ զգալ այն կիսել GitHub-ում: Համոզվեք, որ դրանք ավելացրեք թեմային kubectl-plugins.

Կարող եք նաև խնդրել, որ ձեր փլագինը ավելացվի Կրուի ցուցակը. Հրահանգները, թե ինչպես դա անել, կան GitHub պահոցներ.

Հրամանի ավարտ

Փլագինները ներկայումս չեն աջակցում ավտոմատ լրացմանը: Այսինքն, դուք պետք է մուտքագրեք plugin-ի ամբողջական անվանումը և փաստարկների ամբողջական անվանումները:

Այս ֆունկցիայի համար GitHub kubectl պահոցն ունի բաց հարցում. Այսպիսով, հնարավոր է, որ ապագայում այս գործառույթը կիրառվի:

Հաջողություն!!!

Էլ ինչ կարդալ թեմայի շուրջ:

Source: www.habr.com

Ինչպես ավելի արդյունավետ օգտագործել kubectl-ը. մանրամասն ուղեցույց