როგორ გამოვიყენოთ kubectl უფრო ეფექტურად: დეტალური სახელმძღვანელო

თუ მუშაობთ Kubernetes-თან, მაშინ kubectl არის ალბათ ერთ-ერთი კომუნალური პროგრამა, რომელსაც ყველაზე ხშირად იყენებთ. და როცა დიდ დროს უთმობთ კონკრეტულ ინსტრუმენტთან მუშაობას, ღირს მისი კარგად შესწავლა და მისი ეფექტურად გამოყენების სწავლა.

გუნდი Kubernetes aaS Mail.ru-დან თარგმნა დანიელ ვეიბელის სტატია, რომელშიც ნახავთ რჩევებსა და ხრიკებს kubectl-თან ეფექტური მუშაობისთვის. ის ასევე დაგეხმარებათ Kubernetes-ის უფრო ღრმა გაგებაში.

ავტორის თქმით, სტატიის მიზანია თქვენი ყოველდღიური მუშაობა Kubernetes-თან არა მხოლოდ უფრო ეფექტური, არამედ უფრო სასიამოვნოც იყოს!

შესავალი: რა არის 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 ისეთი უტილიტის გამოყენებით, როგორიცაა curlHTTP მოთხოვნების ხელით გაგზავნით Kubernetes API-ზე. Kubectl უბრალოდ აადვილებს Kubernetes API-ს გამოყენებას.

ეს არის საფუძვლები, თუ რა არის kubectl და როგორ მუშაობს იგი. მაგრამ არის კიდევ რაღაც Kubernetes API-ს შესახებ, რაც კუბექტლის ყველა მომხმარებელმა უნდა იცოდეს. მოდით გადავხედოთ კუბერნეტის შიდა სამყაროს.

კუბერნეტის შიდა სამყარო

Kubernetes შედგება დამოუკიდებელი კომპონენტებისგან, რომლებიც მუშაობს როგორც ცალკეული პროცესები კლასტერულ კვანძებზე. ზოგიერთი კომპონენტი მუშაობს მთავარ კვანძებზე, სხვები მუშა კვანძებზე, თითოეული კომპონენტი ასრულებს თავის კონკრეტულ დავალებას.

აქ არის ყველაზე მნიშვნელოვანი კომპონენტები მთავარ კვანძებზე:

1. საცავი - ინახავს რესურსების განმარტებებს (ჩვეულებრივ ეს არის ა.შ).
2. API სერვერი — უზრუნველყოფს API-ს და მართავს მეხსიერებას.
3. კონტროლერის მენეჯერი — უზრუნველყოფს, რომ რესურსის სტატუსი შეესაბამება სპეციფიკაციებს.
4. განრიგი — აწყობს პოდებს მუშათა კვანძებზე.

და აქ არის ერთი ყველაზე მნიშვნელოვანი კომპონენტი მუშა კვანძებზე:

1. კუბელეტი — მართავს კონტეინერების გაშვებას სამუშაო კვანძზე.

იმის გასაგებად, თუ როგორ მუშაობს ეს კომპონენტები ერთად, მოდით შევხედოთ მაგალითს.

დავუშვათ, რომ ახლახან დაასრულეთ kubectl create -f replicaset.yaml, რის შემდეგაც kubectl-მა გააკეთა HTTP POST მოთხოვნა ReplicaSet API ბოლო წერტილი (ReplicaSet რესურსის განმარტების გავლა).

რა ხდება კლასტერში?

1. გაკეთების შემდეგ kubectl create -f replicaset.yaml API სერვერი ინახავს თქვენს ReplicaSet რესურსის განმარტებას საცავში:

   

2. შემდეგი, ReplicaSet კონტროლერი გაშვებულია კონტროლერის მენეჯერში, რომელიც ამუშავებს ReplicaSet რესურსების შექმნას, შეცვლას და წაშლას:

   

3. ReplicaSet კონტროლერი ქმნის pod განმარტებას ReplicaSet-ის თითოეული ასლისთვის (ReplicaSet-ის განმარტების pod შაბლონის მიხედვით) და ინახავს მათ საცავში:

   

4. განრიგის ამოქმედება, თვალთვალის კვანძები, რომლებიც ჯერ არ არის მინიჭებული არცერთ მუშა კვანძზე:

   

5. დამგეგმავი ირჩევს შესაფერის მუშა კვანძს თითოეული პოდისთვის და ამატებს ამ ინფორმაციას განყოფილების განმარტებას მაღაზიაში:

   

6. მუშა კვანძზე, რომელსაც ენიჭება pod, Kubelet გაშვებულია, ის აკონტროლებს ამ კვანძს მინიჭებულ კვანძებს:

   

7. Kubelet კითხულობს pod განმარტებას საცავიდან და ავალებს კონტეინერების გაშვებას, როგორიცაა Docker, გაუშვას კონტეინერები კვანძზე:

   

ქვემოთ მოცემულია ამ აღწერილობის ტექსტური ვერსია.

API მოთხოვნა ReplicaSet-ის შექმნის საბოლოო წერტილისადმი დამუშავებულია API სერვერის მიერ. API სერვერი ახდენს მოთხოვნის ავთენტიფიკაციას და ინახავს ReplicaSet რესურსის განმარტებას საცავში.

ეს ღონისძიება იწყებს ReplicaSet კონტროლერს, რომელიც არის კონტროლერის მენეჯერის ქვეპროცესი. ReplicaSet კონტროლერი აკონტროლებს ReplicaSet რესურსების შექმნას, განახლებას და წაშლას მაღაზიაში და იღებს ღონისძიების შეტყობინებას, როდესაც ეს მოხდება.

ReplicaSet კონტროლერის ამოცანაა უზრუნველყოს საჭირო რაოდენობის ReplicaSet pods. ჩვენს მაგალითში ჯერ არ არსებობს პოდლები, ამიტომ ReplicaSet კონტროლერი ქმნის ამ pod განმარტებებს (ReplicaSet-ის განსაზღვრების პოდ შაბლონის მიხედვით) და ინახავს მათ საცავში.

ახალი pod-ების შექმნა ხდება გრაფიკის მიერ, რომელიც აკონტროლებს პოდ განსაზღვრებებს, რომლებიც ჯერ არ არის დაგეგმილი მუშა კვანძებისთვის. დამგეგმავი ირჩევს შესაფერის მუშა კვანძს თითოეული პოდისთვის და განაახლებს პოდ განმარტებებს საცავში.

გაითვალისწინეთ, რომ ამ მომენტამდე კლასტერში არსად გაშვებული არ იყო სამუშაო დატვირთვის კოდი. ყველაფერი რაც აქამდე გაკეთდა - ეს არის რესურსების შექმნა და განახლება საცავში მთავარ კვანძზე.

ბოლო მოვლენა იწვევს Kubelets-ს, რომელიც მონიტორინგს უწევს მათი მუშა კვანძებისთვის დაგეგმილ პოდებს. მუშა კვანძის Kubelet, რომელზეც დაინსტალირებულია თქვენი ReplicaSet pods, უნდა დაავალოს კონტეინერის გაშვების დრო, როგორიცაა Docker, ჩამოტვირთოს საჭირო კონტეინერის სურათები და გაუშვას ისინი.

ამ ეტაპზე, თქვენი ReplicaSet აპლიკაცია საბოლოოდ მუშაობს!

Kubernetes API-ს როლი

როგორც წინა მაგალითში ნახე, Kubernetes კომპონენტები (გარდა API სერვერისა და შენახვისა) აკვირდებიან ცვლილებებს საცავში არსებულ რესურსებში და ცვლის ინფორმაციას საცავში არსებული რესურსების შესახებ.

რა თქმა უნდა, ეს კომპონენტები არ ურთიერთქმედებენ უშუალოდ საცავთან, არამედ მხოლოდ Kubernetes API-ის მეშვეობით.

განვიხილოთ შემდეგი მაგალითები:

1. ReplicaSet კონტროლერი იყენებს API ბოლო წერტილს ჩამოთვალეთ ReplicaSets პარამეტრით watch ReplicaSet რესურსებში ცვლილებების მონიტორინგი.
2. ReplicaSet კონტროლერი იყენებს API ბოლო წერტილს Pod-ის შექმნა (შექმენით პოდი) ბუდეების შესაქმნელად.
3. Scheduler იყენებს API ბოლო წერტილს პატჩი პოდი (რედაქტირება pod) განაახლოს pods ინფორმაცია არჩეული მუშა კვანძის შესახებ.

როგორც ხედავთ, ეს არის იგივე API, რომელსაც kubectl წვდება. შიდა კომპონენტებისთვის და გარე მომხმარებლებისთვის იგივე API-ს გამოყენება ფუნდამენტური კონცეფციაა Kubernetes-ის დიზაინში.

ახლა ჩვენ შეგვიძლია შევაჯამოთ როგორ მუშაობს Kubernetes:

1. შენახვის მაღაზიებში წერია, ანუ Kubernetes რესურსები.
2. API სერვერი უზრუნველყოფს ინტერფეისს საცავში Kubernetes API-ის სახით.
3. Kubernetes-ის ყველა სხვა კომპონენტი და მომხმარებელი კითხულობს, აკვირდება და მანიპულირებს Kubernetes-ის მდგომარეობას (რესურსებს) API-ის მეშვეობით.

ამ ცნებების ცოდნა დაგეხმარებათ უკეთ გაიგოთ kubectl და მიიღოთ მაქსიმალური სარგებლობა.

ახლა მოდით გადავხედოთ რამდენიმე კონკრეტულ რჩევას და ხრიკს, რომლებიც დაგეხმარებათ გააუმჯობესოთ თქვენი პროდუქტიულობა kubectl-ით.

1. დააჩქარეთ შეყვანა ბრძანების დასრულების გამოყენებით

Kubectl-ით შესრულების გაუმჯობესების ერთ-ერთი ყველაზე სასარგებლო, მაგრამ ხშირად შეუმჩნეველი ტექნიკა არის ბრძანების დასრულება.

ბრძანების დასრულება საშუალებას გაძლევთ ავტომატურად დაასრულოთ kubectl ბრძანებების ნაწილები Tab კლავიშის გამოყენებით. ეს მუშაობს ქვებრძანებებისთვის, ვარიანტებისთვის და არგუმენტებისთვის, მათ შორის ისეთი რთული, როგორიც არის რესურსების სახელები.

ნახეთ, როგორ მუშაობს kubectl ბრძანების დასრულება:

ბრძანების დასრულების სამუშაოები Bash და Zsh ჭურვებისთვის.

ოფიციალური სახელმძღვანელო შეიცავს დეტალურ ინსტრუქციებს ავტომატური დასრულების დასაყენებლად, მაგრამ ქვემოთ შემოგთავაზებთ მოკლე ამონარიდს.

როგორ მუშაობს ბრძანების დასრულება

ბრძანების დასრულება არის ჭურვის ფუნქცია, რომელიც მუშაობს დასრულების სკრიპტის გამოყენებით. გაფართოების სკრიპტი არის shell სკრიპტი, რომელიც განსაზღვრავს გაფართოების ქცევას კონკრეტული ბრძანებისთვის.

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-დასრულებაში.

ორივე ვარიანტი თანაბრად გამოიყენება.

ჭურვის გადატვირთვის შემდეგ, kubectl ბრძანების დასრულება იმუშავებს.

Bash MacOS-ზე

MacOS-ზე დაყენება ცოტა უფრო რთულია. ფაქტია, რომ ნაგულისხმევად, MacOS იყენებს Bash 3.2 ვერსიას, ხოლო kubectl ავტომატური დასრულების სკრიპტი მოითხოვს Bash ვერსიას მინიმუმ 4.1 და არ მუშაობს Bash 3.2-ში.

არსებობს ლიცენზირების პრობლემები, რომლებიც დაკავშირებულია Bash-ის მოძველებული ვერსიის გამოყენებასთან MacOS-ზე. Bash ვერსია 4 ლიცენზირებულია GPLv3-ით, რომელიც არ არის მხარდაჭერილი Apple-ის მიერ.

MacOS-ზე kubectl ავტომატური დასრულების კონფიგურაციისთვის, თქვენ უნდა დააინსტალიროთ Bash-ის უახლესი ვერსია. თქვენ ასევე შეგიძლიათ განახლებული Bash დააყენოთ თქვენს ნაგულისხმევ გარსად, რაც მომავალში ბევრ პრობლემას გიშველის. ეს არ არის რთული, დეტალები მოცემულია სტატიაში "Bash-ის განახლება MacOS-ზე".

სანამ გააგრძელებთ, დარწმუნდით, რომ იყენებთ Bash-ის უახლეს ვერსიას (შეამოწმეთ გამომავალი bash --version).

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

თუ გამომავალში ხედავთ ჭურვის ფუნქციას, მაშინ ყველაფერი სწორად არის კონფიგურირებული.

ახლა ჩვენ უნდა დავრწმუნდეთ, რომ 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 autocompletion დაიწყებს მუშაობას 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 სახელმძღვანელოში მოცემული.

სტანდარტულად 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 — როდესაც pod ენიჭება კვანძს, მისი სახელი იწერება ველში 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-ის მრავალი რესურსის ველი არის სიები და ეს ოპერატორი გაძლევთ საშუალებას აირჩიოთ ამ სიების წევრები. ის ხშირად გამოიყენება ველური ბარათით, როგორიცაა [*] სიის ყველა ელემენტის შესარჩევად.

განაცხადის მაგალითები

პერსონალური სვეტის გამომავალი ფორმატის გამოყენების შესაძლებლობები გაუთავებელია, რადგან გამომავალში შეგიძლიათ აჩვენოთ ნებისმიერი ველი ან რესურსის ველების კომბინაცია. აქ არის რამდენიმე აპლიკაციის ნიმუში, მაგრამ თავისუფლად შეისწავლეთ ისინი და იპოვნეთ თქვენთვის შესაფერისი აპლიკაციები.

1. კონტეინერის სურათების ჩვენება პოდებისთვის:

   $ kubectl get pods 
     -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'
   
   NAME                        IMAGES
   engine-544b6b6467-22qr6     rabbitmq:3.7.8-management,nginx
   engine-544b6b6467-lw5t8     rabbitmq:3.7.8-management,nginx
   engine-544b6b6467-tvgmg     rabbitmq:3.7.8-management,nginx
   web-ui-6db964458-8pdw4      wordpress

   ეს ბრძანება აჩვენებს კონტეინერის გამოსახულების სახელებს თითოეული პოდისთვის.

   გახსოვდეთ, რომ პოდი შეიძლება შეიცავდეს რამდენიმე კონტეინერს, შემდეგ გამოსახულების სახელები გამოჩნდება ერთ ხაზზე, გამოყოფილი მძიმეებით.

2. კვანძების ხელმისაწვდომობის ზონების ჩვენება:

   $ kubectl get nodes 
     -o 
   custom-columns='NAME:metadata.name,ZONE:metadata.labels.failure-domain.beta.kubernetes.io/zone'
   
   NAME                          ZONE
   ip-10-0-118-34.ec2.internal   us-east-1b
   ip-10-0-36-80.ec2.internal    us-east-1a
   ip-10-0-80-67.ec2.internal    us-east-1b

   ეს ბრძანება სასარგებლოა, თუ თქვენი კლასტერი განთავსებულია საჯარო ღრუბელში. ის აჩვენებს ხელმისაწვდომობის ზონას თითოეული კვანძისთვის.

   ხელმისაწვდომობის ზონა არის ღრუბლის კონცეფცია, რომელიც ზღუდავს რეპლიკაციის ზონას გეოგრაფიულ რეგიონში.

   თითოეული კვანძისთვის ხელმისაწვდომობის ზონები მიიღება სპეციალური ეტიკეტის საშუალებით - failure-domain.beta.kubernetes.io/zone. თუ კლასტერი მუშაობს საჯარო ღრუბელში, ეს ლეიბლი იქმნება ავტომატურად და ივსება ხელმისაწვდომობის ზონების სახელებით თითოეული კვანძისთვის.

   ლეიბლები არ არის Kubernetes-ის რესურსის სპეციფიკაციის ნაწილი, ასე რომ თქვენ ვერ იპოვით მათ შესახებ ინფორმაციას API სახელმძღვანელო. თუმცა, მათი ნახვა შესაძლებელია (როგორც ნებისმიერი სხვა ლეიბლი), თუ მოითხოვთ ინფორმაციას კვანძების შესახებ YAML ან JSON ფორმატში:

   $ kubectl get nodes -o yaml
   # или
   $ kubectl get nodes -o json

   ეს შესანიშნავი გზაა რესურსების შესახებ მეტის გასაგებად, რესურსების სპეციფიკაციების შესწავლის გარდა.

4. მარტივად გადართეთ კლასტერებსა და სახელთა სივრცეებს ​​შორის

როდესაც kubectl უგზავნის მოთხოვნას Kubernetes API-ს, ის ჯერ კითხულობს kubeconfig ფაილს, რათა მიიღოს ყველა საჭირო პარამეტრი კავშირისთვის.

ნაგულისხმევად არის kubeconfig ფაილი ~/.kube/config. როგორც წესი, ეს ფაილი იქმნება ან განახლდება სპეციალური ბრძანებით.

როდესაც მუშაობთ მრავალ კლასტერთან, თქვენი kubeconfig ფაილი შეიცავს პარამეტრებს ყველა ამ კლასტერთან დასაკავშირებლად. თქვენ გჭირდებათ გზა, რომ უთხრათ kubectl ბრძანებას, რომელ კლასტერთან მუშაობთ.

კლასტერში შეგიძლიათ შექმნათ მრავალი სახელთა სივრცე - ვირტუალური კლასტერის ტიპი ფიზიკურ კლასტერში. Kubectl ასევე განსაზღვრავს რომელი სახელთა სივრცე გამოიყენოს kubeconfig ფაილის საფუძველზე. ეს ნიშნავს, რომ თქვენ ასევე გჭირდებათ გზა, რომ უთხრათ kubectl ბრძანებას, რომელ სახელთა სივრცეში იმუშაოთ.

ამ თავში ჩვენ განვმარტავთ, თუ როგორ მუშაობს და როგორ გავაუმჯობესოთ ის ეფექტურად.

გაითვალისწინეთ, რომ შეიძლება გქონდეთ რამდენიმე kubeconfig ფაილი ჩამოთვლილი KUBECONFIG გარემოს ცვლადში. ამ შემთხვევაში, ყველა ეს ფაილი გაერთიანდება ერთ საერთო კონფიგურაციაში გაშვების დროს. თქვენ ასევე შეგიძლიათ შეცვალოთ ნაგულისხმევი kubeconfig ფაილი პარამეტრით kubectl-ით --kubeconfig. შეხედე ოფიციალური დოკუმენტაცია.

kubeconfig ფაილები

ვნახოთ, კონკრეტულად რას შეიცავს kubeconfig ფაილი:

როგორც ხედავთ, kubeconfig ფაილი შეიცავს კონტექსტების კომპლექტს. კონტექსტი შედგება სამი ელემენტისგან:

• კლასტერი — კლასტერული სერვერის API URL.
• მომხმარებელი - მომხმარებლის ავტორიზაციის სერთიფიკატები კლასტერში.
• სახელთა სივრცე - სახელთა სივრცე, რომელიც გამოიყენება კლასტერთან შეერთებისას.

პრაქტიკაში, ისინი ხშირად იყენებენ ერთ კონტექსტს თითო კლასტერში თავიანთ kubeconfig-ში. თუმცა, თქვენ შეგიძლიათ გქონდეთ მრავალი კონტექსტი თითო კლასტერზე, დიფერენცირებული მომხმარებლის ან სახელების სივრცის მიხედვით. თუმცა, ეს მრავალკონტექსტური კონფიგურაცია იშვიათია, ამიტომ, როგორც წესი, ხდება ერთი-ერთზე დახატვა კლასტერებსა და კონტექსტებს შორის.

ნებისმიერ დროს, ერთ-ერთი კონტექსტი აქტუალურია:

როდესაც kubectl კითხულობს კონფიგურაციის ფაილს, ის ყოველთვის იღებს ინფორმაციას მიმდინარე კონტექსტიდან. ზემოთ მოყვანილ მაგალითში kubectl დაუკავშირდება კურდღლის კლასტერს.

შესაბამისად, სხვა კლასტერზე გადასასვლელად, თქვენ უნდა შეცვალოთ მიმდინარე კონტექსტი kubeconfig ფაილში:

ახლა kubectl დაუკავშირდება Fox კლასტერს.

იმავე კლასტერში სხვა სახელთა სივრცეზე გადასართავად, თქვენ უნდა შეცვალოთ სახელთა სივრცის ელემენტის მნიშვნელობა მიმდინარე კონტექსტში:

ზემოთ მოყვანილ მაგალითში, kubectl გამოიყენებს Fox კლასტერის Prod სახელთა სივრცეს (ადრე დაყენებული იყო სატესტო სახელების სივრცე).

გაითვალისწინეთ, რომ 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 მოდული და გაუშვათ იგი ბრძანების შესრულებით kubectl foo.

მოსახერხებელი იქნებოდა კონტექსტის და სახელების სივრცის შეცვლა ამ გზით, მაგალითად გაშვებით kubectl ctx კონტექსტის შეცვლა და kubectl ns სახელთა სივრცის შესაცვლელად.

მე დავწერე ორი დანამატი, რომლებიც ამას აკეთებენ:

• kubectl-ctx
• kubectl-ns

დანამატების მუშაობა ეფუძნება წინა განყოფილების მეტსახელებს.

აი, როგორ მუშაობენ ისინი:

გაითვალისწინეთ, რომ დანამატები იყენებენ fzf-ს ინტერაქტიული უფასო საძიებო ინტერფეისის უზრუნველსაყოფად (როგორც kubectx-ის ინტერაქტიული რეჟიმი). ეს ნიშნავს, რომ გჭირდებათ დააინსტალირე fzfამ მეტსახელების გამოსაყენებლად.

დანამატების ინსტალაციისთვის, თქვენ უნდა ჩამოტვირთოთ დასახელებული shell სკრიპტები kubectl-ctx и kubectl-ns თქვენს PATH ცვლადის ნებისმიერ დირექტორიაში და გახადეთ ისინი შესრულებადი მაგ. chmod +x. ამის შემდეგ დაუყოვნებლივ შეძლებთ გამოყენებას kubectl ctx и kubectl ns.

5. შეამცირეთ შეყვანა ავტოალიაზებით

Shell მეტსახელები კარგი გზაა შეყვანის დასაჩქარებლად. პროექტი kubectl-ის სახელი შეიცავს დაახლოებით 800 მალსახმობას კუბექტლის ძირითადი ბრძანებებისთვის.

ალბათ გაინტერესებთ - როგორ გახსოვთ 800 მეტსახელი? მაგრამ თქვენ არ გჭირდებათ მათი დამახსოვრება, რადგან ისინი აგებულია მარტივი სქემის მიხედვით, რომელიც მოცემულია ქვემოთ:

მაგალითად:

1. kgpooyaml - kubectl მიიღეთ pods oyaml
2. ksysgsvcw — kubectl -n kube-system მიიღეთ svc w
3. ksysrmcm -kubectl -n kube-system rm cm
4. kgdepallsl - kubectl მიიღეთ განლაგება ყველა sl

როგორც ხედავთ, მეტსახელები შედგება კომპონენტებისგან, რომელთაგან თითოეული წარმოადგენს kubectl ბრძანების კონკრეტულ ელემენტს. თითოეულ ალიასს შეიძლება ჰქონდეს ერთი კომპონენტი საბაზისო ბრძანებისთვის, ოპერაციისა და რესურსისთვის და მრავალი კომპონენტი პარამეტრებისთვის. თქვენ უბრალოდ „დაასახლებთ“ ამ კომპონენტებს მარცხნიდან მარჯვნივ ზემოთ მოცემული დიაგრამის მიხედვით.

მიმდინარე დეტალური დიაგრამა არის GitHub. იქაც შეგიძლიათ იპოვოთ მეტსახელების სრული სია.

მაგალითად, მეტსახელი kgpooyamlall არის ბრძანების ექვივალენტი kubectl get pods -o yaml --all-namespaces.

პარამეტრების შედარებითი თანმიმდევრობა არ არის მნიშვნელოვანი: ბრძანება kgpooyamlall ბრძანების ტოლფასია kgpoalloyaml.

თქვენ არ გჭირდებათ ყველა კომპონენტის ფსევდონიმად გამოყენება. Მაგალითად k, kg, klo, ksys, kgpo ასევე შეიძლება გამოყენებულ იქნას. გარდა ამისა, შეგიძლიათ დააკავშიროთ მეტსახელები და რეგულარული ბრძანებები ან პარამეტრები ბრძანების სტრიქონზე:

მაგალითად:

1. ნაცვლად kubectl proxy შეგიძლიათ დაწეროთ k proxy.
2. ნაცვლად kubectl get roles შეგიძლიათ დაწეროთ kg roles (ამჟამად არ არსებობს როლების რესურსის მეტსახელი).
3. კონკრეტული პოდისთვის მონაცემების მისაღებად, შეგიძლიათ გამოიყენოთ ბრძანება kgpo my-pod — kubectl get pod my-pod.

გთხოვთ გაითვალისწინოთ, რომ ზოგიერთი მეტსახელი მოითხოვს ბრძანების ხაზის არგუმენტს. მაგალითად, მეტსახელი kgpol ნიშნავს kubectl get pods -l. ვარიანტი -l მოითხოვს არგუმენტს - ეტიკეტის სპეციფიკაციას. თუ იყენებთ მეტსახელს, ის ასე გამოიყურება kgpol app=ui.

იმის გამო, რომ ზოგიერთი მეტსახელი მოითხოვს არგუმენტებს, მეტსახელები a, f და l უნდა იქნას გამოყენებული ბოლოს.

ზოგადად, ამ სქემის გათიშვის შემდეგ, შეგიძლიათ ინტუიციურად გამოიტანოთ მეტსახელები იმ ბრძანებებიდან, რომელთა შესრულებაც გსურთ და დაზოგოთ აკრეფის დიდი დრო.

ინსტალაცია

kubectl-aliases-ის ინსტალაციისთვის, თქვენ უნდა ჩამოტვირთოთ ფაილი .kubectl_aliases GitHub-დან და ჩართეთ ფაილში ~/.bashrc ან ~/.zshrc:

source ~/.kubectl_aliases

ავტომატური დასრულება

როგორც უკვე ვთქვით, თქვენ ხშირად ამატებთ დამატებით სიტყვებს ალიასს ბრძანების სტრიქონზე. Მაგალითად:

$ kgpooyaml test-pod-d4b77b989

თუ იყენებთ kubectl ბრძანების დასრულებას, თქვენ ალბათ გამოიყენეთ ავტომატური დასრულება ისეთი რამისთვის, როგორიცაა რესურსების სახელები. მაგრამ შეიძლება თუ არა ამის გაკეთება, როდესაც გამოიყენება მეტსახელები?

ეს ძალიან მნიშვნელოვანი კითხვაა, რადგან თუ ავტომატური დასრულება არ იმუშავებს, თქვენ დაკარგავთ მეტსახელების უპირატესობებს.

პასუხი დამოკიდებულია იმაზე, თუ რომელ გარსს იყენებთ:

1. Zsh-სთვის, ალიასის დასრულება უპრობლემოდ მუშაობს.
2. Bash-ისთვის, სამწუხაროდ, გარკვეული სამუშაოა საჭირო იმისათვის, რომ ავტომატური დასრულება იმუშაოს.

Bash-ში მეტსახელების ავტომატური შევსების ჩართვა

Bash-ის პრობლემა ის არის, რომ ის ცდილობს შეავსოს (ყოველ ჯერზე, როცა Tab-ს დააჭერთ) მეტსახელი და არა ბრძანება, რომელსაც ალიასი ეხება (როგორც აკეთებს Zsh, მაგალითად). ვინაიდან 800-ვე მეტსახელის დასრულების სკრიპტები არ გაქვთ, ავტომატური დასრულება არ მუშაობს.

პროექტი სრული-ასევე გთავაზობთ ამ პრობლემის ზოგად გადაწყვეტას. ის უერთდება მეტსახელების დასრულების მექანიზმს, შინაგანად აფართოებს ალიასს ბრძანებაზე და აბრუნებს დასრულების ვარიანტებს დასრულებული ბრძანებისთვის. ეს ნიშნავს, რომ ფსევდონიმისთვის padding იქცევა ზუსტად ისევე, როგორც სრული ბრძანებისთვის.

შემდეგში ჯერ აგიხსნით, თუ როგორ უნდა დააინსტალიროთ სრული ალიასი და შემდეგ როგორ დავაკონფიგურიროთ ის, რომ ჩართოთ დასრულება ყველა kubectl მეტსახელისთვის.

სრული ალიასის ინსტალაცია

უპირველეს ყოვლისა, სრული მეტსახელი დამოკიდებულია ბაშ-დასრულება. ამიტომ, სრული ალიასის დაყენებამდე, თქვენ უნდა დარწმუნდეთ, რომ bash-completion დაყენებულია. ინსტალაციის ინსტრუქციები ადრე იყო მოწოდებული Linux-ისა და MacOS-ისთვის.

მნიშვნელოვანი შენიშვნა MacOS მომხმარებლებისთვის: ისევე როგორც kubectl ავტომატური შევსების სკრიპტი, სრული მეტსახელი არ მუშაობს Bash 3.2-თან, რომელიც ნაგულისხმევია MacOS-ზე. კერძოდ, სრული მეტსახელი დამოკიდებულია bash-completion v2 (brew install bash-completion@2), რომელიც მოითხოვს მინიმუმ Bash 4.1. ეს ნიშნავს, რომ MacOS-ზე სრული ალიასის გამოსაყენებლად, თქვენ უნდა დააინსტალიროთ Bash-ის უფრო ახალი ვერსია.

თქვენ უნდა ჩამოტვირთოთ სკრიპტი ბაშ_დასრულება.შ საქართველოს GitHub საცავი და შეიტანეთ იგი თქვენს ფაილში ~/.bashrc:

source ~/bash_completion.sh

ჭურვის გადატვირთვის შემდეგ, სრული ალიასი სრულად დაინსტალირდება.

ავტომატური დასრულების ჩართვა kubectl მეტსახელებისთვის

ტექნიკურად სრული მეტსახელი უზრუნველყოფს wrapper ფუნქციას _complete_alias. ეს ფუნქცია ამოწმებს ალიასს და აბრუნებს ალიასის ბრძანების დასრულების მინიშნებებს.

ფუნქციის კონკრეტულ მეტსახელთან დასაკავშირებლად, თქვენ უნდა გამოიყენოთ ჩაშენებული Bash მექანიზმი დაასრულებს, დასაყენებლად _complete_alias როგორც მეტსახელის დასრულების ფუნქცია.

მაგალითად, ავიღოთ მეტსახელი k, რომელიც ნიშნავს kubectl ბრძანებას. დააინსტალიროთ _complete_alias როგორც ამ მეტსახელის შემავსებელი ფუნქცია, თქვენ უნდა აწარმოოთ შემდეგი ბრძანება:

$ complete -F _complete_alias k

ამის შედეგი ის არის, რომ როდესაც თქვენ ავტომატურად ავსებთ alias 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 მხარს უჭერს დანამატის მექანიზმი, რომელიც საშუალებას გაძლევთ გააფართოვოთ მისი ფუნქციები დამატებითი ბრძანებებით.

თუ იცნობთ Git დანამატის მექანიზმები, მაშინ kubectl დანამატები აგებულია იმავე პრინციპით.

ამ თავში განვიხილავთ, თუ როგორ დააინსტალიროთ დანამატები, სად ვიპოვოთ ისინი და როგორ შექმნათ თქვენი საკუთარი დანამატები.

დანამატების ინსტალაცია

Kubectl დანამატები ნაწილდება მარტივი შესრულებადი ფაილების სახით, მსგავსი სახელით kubectl-x. პრეფიქსი kubectl- საჭიროა, რასაც მოჰყვება ახალი kubectl ქვებრძანება, რომელიც საშუალებას გაძლევთ დარეკოთ დანამატი.

მაგალითად, hello მოდული გავრცელდება ფაილის სახით, რომელსაც ეწოდება kubectl-hello.

მოდულის ინსტალაციისთვის საჭიროა ფაილის კოპირება kubectl-x ნებისმიერ დირექტორიაში თქვენს PATH-ში და გახადეთ იგი შესრულებადი, მაგალითად chmod +x. ამის შემდეგ დაუყოვნებლივ შეგიძლიათ დარეკოთ მოდული kubectl x.

თქვენ შეგიძლიათ გამოიყენოთ შემდეგი ბრძანება, რომ ჩამოთვალოთ ყველა დანამატი, რომელიც ამჟამად არის დაინსტალირებული თქვენს სისტემაში:

$ kubectl plugin list

ეს ბრძანება ასევე აჩვენებს გაფრთხილებებს, თუ თქვენ გაქვთ მრავალი დანამატი ერთი და იგივე სახელით, ან თუ არის დანამატის ფაილი, რომელიც არ არის შესრულებადი.

მოდულების პოვნა და ინსტალაცია Krew-ის გამოყენებით

Kubectl დანამატები შეიძლება იყოს გაზიარებული ან ხელახლა გამოყენებული, როგორც პროგრამული პაკეტები. მაგრამ სად შეგიძლიათ იპოვოთ დანამატები, რომლებიც სხვებმა გააზიარეს?

პროექტი Krew მიზნად ისახავს უზრუნველყოს ერთიანი გადაწყვეტა kubectl დანამატების გაზიარების, ძიების, ინსტალაციისა და მართვისთვის. პროექტი საკუთარ თავს უწოდებს "პაკეტის მენეჯერს kubectl დანამატებისთვის" (Krew მსგავსია Brew).

Krew არის kubectl დანამატების სია, რომლებიც შეგიძლიათ აირჩიოთ და დააინსტალიროთ. ამავდროულად, Krew ასევე არის kubectl-ის დანამატი.

ეს ნიშნავს, რომ Krew-ის ინსტალაცია არსებითად მუშაობს როგორც ნებისმიერი სხვა kubectl მოდულის დაყენება. დეტალური ინსტრუქციები შეგიძლიათ იხილოთ აქ GitHub გვერდი.

ყველაზე მნიშვნელოვანი Krew ბრძანებებია:

# Поиск в списке плагинов
$ kubectl krew search [<query>]
# Посмотреть информацию о плагине
$ kubectl krew info <plugin>
# Установить плагин
$ kubectl krew install <plugin>
# Обновить все плагины до последней версии
$ kubectl krew upgrade
# Посмотреть все плагины, установленные через Krew
$ kubectl krew list
# Деинсталлировать плагин
$ kubectl krew remove <plugin>

გთხოვთ გაითვალისწინოთ, რომ დანამატების დაყენება Krew-ის გამოყენებით არ ერევა დანამატების დაყენებას ზემოთ აღწერილი სტანდარტული მეთოდის გამოყენებით.

გთხოვთ გაითვალისწინოთ, რომ ბრძანება kubectl krew list აჩვენებს მხოლოდ დანამატებს, რომლებიც დაინსტალირებული იყო Krew-ის გამოყენებით, ხოლო ბრძანება kubectl plugin list ჩამოთვლის ყველა დანამატს, ანუ Krew-ის გამოყენებით დაინსტალირებული და სხვა მეთოდებით დაინსტალირებული.

დანამატების პოვნა სხვაგან

Krew არის ახალგაზრდა პროექტი, რომელიც ამჟამად მიმდინარეობს სია მხოლოდ დაახლოებით 30 დანამატი. თუ ვერ პოულობთ იმას, რაც გჭირდებათ, შეგიძლიათ იპოვოთ დანამატები სხვაგან, როგორიცაა GitHub.

გირჩევთ გადახედოთ GitHub განყოფილებას kubectl-პლაგინები. აქ ნახავთ ათობით ხელმისაწვდომ დანამატს, რომელთა შემოწმებაც ღირს.

საკუთარი დანამატების დაწერა

შენ თვითონ შეგიძლია შექმენით დანამატები - არ არის რთული. თქვენ უნდა შექმნათ შესრულებადი, რომელიც აკეთებს იმას, რაც გჭირდებათ, დაარქვით სახელი kubectl-x და დააინსტალირეთ, როგორც ზემოთ აღწერილი.

ფაილი შეიძლება იყოს bash სკრიპტი, პითონის სკრიპტი ან შედგენილი 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 დანამატები შეიძლება დაიწეროს ნებისმიერ პროგრამირების ან სკრიპტირების ენაზე. თუ თქვენ იყენებთ shell სკრიპტებს, უპირატესობა ის არის, რომ შეგიძლიათ მარტივად დარეკოთ kubectl მოდულის შიგნიდან. თუმცა, თქვენ შეგიძლიათ დაწეროთ უფრო რთული დანამატები რეალურ პროგრამირების ენებზე Kubernetes კლიენტის ბიბლიოთეკა. თუ იყენებთ Go-ს, ასევე შეგიძლიათ გამოიყენოთ cli-runtime ბიბლიოთეკა, რომელიც სპეციალურად არსებობს kubectl დანამატების დასაწერად.

როგორ გააზიაროთ თქვენი დანამატები

თუ ფიქრობთ, რომ თქვენი დანამატები შეიძლება სასარგებლო იყოს სხვებისთვის, მოგერიდებათ გააზიაროთ იგი GitHub-ზე. აუცილებლად დაამატეთ ისინი თემას kubectl-პლაგინები.

თქვენ ასევე შეგიძლიათ მოითხოვოთ თქვენი მოდულის დამატება კრეუს სია. ინსტრუქციები, თუ როგორ უნდა გავაკეთოთ ეს, მოცემულია GitHub საცავი.

ბრძანების დასრულება

დანამატები ამჟამად არ უჭერს მხარს ავტომატურ დასრულებას. ანუ, თქვენ უნდა შეიყვანოთ მოდულის სრული სახელი და არგუმენტების სრული სახელები.

აქვს GitHub kubectl საცავი ამ ფუნქციისთვის ღია მოთხოვნა. ასე რომ, შესაძლებელია, რომ ეს ფუნქცია ოდესმე მომავალში განხორციელდეს.

Წარმატებები!!!

კიდევ რა წავიკითხოთ თემაზე:

1. ავტოსკალირების სამი დონე Kubernetes-ში და როგორ გამოვიყენოთ ისინი ეფექტურად.
2. Kubernetes მეკობრეობის სულისკვეთებით განხორციელების შაბლონით.
3. ჩვენი არხი Kubernetes-ის გარშემო Telegram-ში.

წყარო: www.habr.com