🥇Cara menggunakan kubectl dengan lebih berkesan: panduan terperinci

Jika anda bekerja dengan Kubernetes, maka kubectl mungkin merupakan salah satu utiliti yang paling anda gunakan. Dan setiap kali anda menghabiskan banyak masa bekerja dengan alat tertentu, ia berbaloi untuk mengkajinya dengan baik dan belajar cara menggunakannya dengan berkesan.

Pasukan Kubernetes aaS daripada Mail.ru menterjemah artikel oleh Daniel Weibel di mana anda akan menemui petua dan helah untuk bekerja dengan berkesan dengan kubectl. Ia juga akan membantu anda memperoleh pemahaman yang lebih mendalam tentang Kubernetes.

Menurut penulis, matlamat artikel itu adalah untuk menjadikan kerja harian anda dengan Kubernetes bukan sahaja lebih cekap, tetapi juga lebih menyeronokkan!

Pengenalan: Apakah itu kubectl

Sebelum anda boleh belajar menggunakan kubectl dengan lebih berkesan, anda perlu mendapatkan pemahaman asas tentang apa itu dan cara ia berfungsi.

Dari perspektif pengguna, kubectl ialah panel kawalan yang membolehkan anda melaksanakan operasi Kubernetes.

Dari segi teknikal, kubectl ialah pelanggan API Kubernetes.

API Kubernetes ialah API REST HTTP. API ini ialah antara muka pengguna Kubernetes sebenar, yang melaluinya ia dikawal sepenuhnya. Ini bermakna setiap operasi Kubernetes didedahkan sebagai titik akhir API dan boleh dibuat dengan permintaan HTTP ke titik akhir tersebut.

Oleh itu, tugas utama kubectl ialah membuat permintaan HTTP kepada API Kubernetes:

Kubernetes ialah sistem berorientasikan sumber sepenuhnya. Ini bermakna ia mengekalkan keadaan dalaman sumber dan semua operasi Kubernetes adalah operasi CRUD.

Anda berada dalam kawalan sepenuhnya ke atas Kubernetes dengan mengurus sumber ini dan Kubernetes memikirkan perkara yang perlu dilakukan berdasarkan keadaan semasa sumber tersebut. Atas sebab ini, rujukan API Kubernetes disusun sebagai senarai jenis sumber dengan operasi berkaitannya.

Mari kita lihat satu contoh.

Katakan anda ingin mencipta sumber ReplicaSet. Untuk melakukan ini, anda menerangkan ReplicaSet dalam fail mengikut nama replicaset.yaml, kemudian jalankan arahan:

$ kubectl create -f replicaset.yaml

Ini akan mencipta sumber ReplicaSet. Tetapi apa yang berlaku di sebalik tabir?

Kubernetes mempunyai operasi penciptaan ReplicaSet. Seperti mana-mana operasi lain, ia terdedah sebagai titik akhir API. Titik akhir API khusus untuk operasi ini kelihatan seperti ini:

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

Titik akhir API untuk semua operasi Kubernetes boleh didapati di rujukan API (termasuk titik akhir di atas). Untuk membuat permintaan sebenar kepada titik akhir, anda mesti menambah URL pelayan API terlebih dahulu pada laluan titik akhir yang disenaraikan dalam rujukan API.

Oleh itu, apabila anda melaksanakan arahan di atas, kubectl menghantar permintaan HTTP POST ke titik akhir API di atas. Definisi ReplicaSet yang anda berikan dalam fail replicaset.yaml, dihantar dalam kandungan permintaan.

Beginilah cara kubectl berfungsi untuk semua arahan yang berinteraksi dengan gugusan Kubernetes. Dalam semua kes ini, kubectl hanya membuat permintaan HTTP kepada titik akhir API Kubernetes yang sesuai.

Sila ambil perhatian bahawa anda boleh mengurus Kubernetes sepenuhnya menggunakan utiliti seperti curldengan menghantar permintaan HTTP secara manual ke API Kubernetes. Kubectl hanya memudahkan untuk menggunakan API Kubernetes.

Ini adalah asas tentang kubectl dan cara ia berfungsi. Tetapi ada perkara lain tentang API Kubernetes yang perlu diketahui oleh setiap pengguna kubectl. Mari kita lihat dengan pantas dunia dalaman Kubernetes.

Dunia dalaman Kubernetes

Kubernetes terdiri daripada satu set komponen bebas yang berjalan sebagai proses berasingan pada nod kelompok. Sesetengah komponen berjalan pada nod induk, yang lain pada nod pekerja, setiap komponen melaksanakan tugas khususnya sendiri.

Berikut adalah komponen paling penting pada nod utama:

repositori - menyimpan definisi sumber (selalunya etcd).
pelayan API — menyediakan API dan mengurus storan.
Pengurus Pengawal — Memastikan status sumber mematuhi spesifikasi.
Penjadual — menjadualkan pod pada nod pekerja.

Dan inilah satu komponen paling penting pada nod pekerja:

kubelet — menguruskan pelancaran bekas pada nod kerja.

Untuk memahami cara komponen ini berfungsi bersama, mari lihat contoh.

Katakan anda baru sahaja selesai kubectl create -f replicaset.yaml, selepas itu kubectl membuat permintaan HTTP POST kepada Titik akhir API ReplicaSet (melepasi definisi sumber ReplicaSet).

Apa yang berlaku dalam kluster?

Selepas melakukan kubectl create -f replicaset.yaml Pelayan API menyimpan definisi sumber ReplicaSet anda dalam storan:
Seterusnya, pengawal ReplicaSet dilancarkan dalam pengurus pengawal, yang mengendalikan penciptaan, pengubahsuaian dan pemadaman sumber ReplicaSet:
Pengawal ReplicaSet mencipta definisi pod untuk setiap replika ReplicaSet (mengikut templat pod dalam definisi ReplicaSet) dan menyimpannya dalam storan:
Penjadual dilancarkan, menjejak pod yang belum diberikan kepada mana-mana nod pekerja:
Penjadual memilih nod pekerja yang sesuai untuk setiap pod dan menambahkan maklumat ini pada definisi pod dalam stor:
Pada nod pekerja yang pod diperuntukkan, Kubelet dilancarkan, ia menjejaki pod yang diperuntukkan kepada nod ini:
Kubelet membaca definisi pod daripada storan dan mengarahkan masa jalan kontena, seperti Docker, untuk melancarkan bekas pada nod:

Di bawah ialah versi teks penerangan ini.

Permintaan API kepada titik akhir penciptaan ReplicaSet diproses oleh pelayan API. Pelayan API mengesahkan permintaan dan menyimpan definisi sumber ReplicaSet dalam storan.

Acara ini memulakan pengawal ReplicaSet, yang merupakan subproses pengurus pengawal. Pengawal ReplicaSet memantau penciptaan, pengemaskinian dan pemadaman sumber ReplicaSet dalam kedai dan menerima pemberitahuan acara apabila ini berlaku.

Tugas pengawal ReplicaSet adalah untuk memastikan bilangan pod ReplicaSet yang diperlukan wujud. Dalam contoh kami, tiada pod wujud lagi, jadi pengawal ReplicaSet mencipta definisi pod ini (mengikut templat pod dalam definisi ReplicaSet) dan menyimpannya dalam storan.

Penciptaan pod baharu dicetuskan oleh penjadual yang menjejaki definisi pod yang belum dijadualkan untuk nod pekerja. Penjadual memilih nod pekerja yang sesuai untuk setiap pod dan mengemas kini definisi pod dalam repositori.

Ambil perhatian bahawa sehingga ketika ini, tiada kod beban kerja dijalankan di mana-mana dalam kelompok. Semua yang telah dilakukan selama ini - ini ialah penciptaan dan pengemaskinian sumber dalam repositori pada nod induk.

Peristiwa terakhir mencetuskan Kubelets, yang memantau pod yang dijadualkan untuk nod pekerja mereka. Kubelet nod pekerja di mana pod ReplicaSet anda dipasang mesti mengarahkan masa jalan kontena, seperti Docker, untuk memuat turun imej kontena yang diperlukan dan menjalankannya.

Pada ketika ini, aplikasi ReplicaSet anda akhirnya berjalan!

Peranan API Kubernetes

Seperti yang anda lihat dalam contoh sebelumnya, komponen Kubernetes (kecuali untuk pelayan dan storan API) memantau perubahan kepada sumber dalam storan dan menukar maklumat tentang sumber dalam storan.

Sudah tentu, komponen ini tidak berinteraksi dengan storan secara langsung, tetapi hanya melalui API Kubernetes.

Pertimbangkan contoh berikut:

Pengawal ReplicaSet menggunakan titik akhir API senaraikan ReplicaSets dengan parameter watch untuk memantau perubahan kepada sumber ReplicaSet.
Pengawal ReplicaSet menggunakan titik akhir API buat Pod (buat pod) untuk mencipta pod.
Penjadual menggunakan titik akhir API tampal pod (edit pod) untuk mengemas kini pod dengan maklumat tentang nod pekerja yang dipilih.

Seperti yang anda lihat, ini adalah API yang sama yang diakses oleh kubectl. Menggunakan API yang sama untuk komponen dalaman dan pengguna luaran ialah konsep asas dalam reka bentuk Kubernetes.

Sekarang kita boleh meringkaskan cara Kubernetes berfungsi:

Stor storan menyatakan, iaitu sumber Kubernetes.
Pelayan API menyediakan antara muka kepada storan dalam bentuk API Kubernetes.
Semua komponen dan pengguna Kubernetes lain membaca, memerhati dan memanipulasi keadaan (sumber) Kubernetes melalui API.

Mengetahui konsep ini akan membantu anda memahami kubectl dengan lebih baik dan memanfaatkannya sepenuhnya.

Sekarang mari kita lihat beberapa petua dan helah khusus yang akan membantu meningkatkan produktiviti anda dengan kubectl.

1. Percepatkan input menggunakan penyelesaian arahan

Salah satu teknik yang paling berguna, tetapi sering diabaikan, untuk meningkatkan prestasi dengan kubectl ialah penyelesaian perintah.

Penyiapan arahan membolehkan anda melengkapkan bahagian perintah kubectl secara automatik menggunakan kekunci Tab. Ini berfungsi untuk subperintah, pilihan dan hujah, termasuk sesuatu yang kompleks seperti nama sumber.

Lihat cara penyelesaian perintah kubectl berfungsi:

Penyiapan arahan berfungsi untuk cengkerang Bash dan Zsh.

Panduan rasmi mengandungi arahan terperinci untuk menyediakan autolengkap, tetapi di bawah kami akan memberikan petikan ringkas.

Cara penyelesaian perintah berfungsi

Penyelesaian arahan ialah ciri shell yang berfungsi menggunakan skrip penyelesaian. Skrip sambungan ialah skrip shell yang mentakrifkan kelakuan sambungan untuk arahan tertentu.

Kubectl secara automatik menjana dan mengeluarkan skrip sambungan untuk Bash dan Zsh menggunakan arahan berikut:

$ kubectl completion bash

Или:

$ kubectl completion zsh

Secara teori, sudah cukup untuk menyambungkan output arahan ini kepada shell arahan yang sesuai supaya kubectl boleh melengkapkan arahan.

Dalam amalan, kaedah sambungan adalah berbeza untuk Bash (termasuk perbezaan antara Linux dan MacOS) dan Zsh. Di bawah ini kita akan melihat semua pilihan ini.

Bash pada Linux

Skrip penyiapan Bash bergantung pada pakej penyiapan bash, jadi anda perlu memasangnya terlebih dahulu:

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

Anda boleh menguji bahawa pakej berjaya dipasang menggunakan arahan berikut:

$ type _init_completion

Jika ini mengeluarkan kod fungsi shell, maka bash-completion dipasang dengan betul. Jika arahan memberikan ralat "Tidak Ditemui", anda perlu menambah baris berikut pada fail anda ~ / .bashrc:

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

Adakah perlu menambah baris ini pada fail ~ / .bashrc atau tidak bergantung pada pengurus pakej yang anda gunakan untuk memasang bash-completion. Ini perlu untuk APT, tetapi bukan untuk YUM.

Selepas memasang bash-completion, anda perlu mengkonfigurasi segala-galanya supaya skrip penyelesaian kubectl didayakan dalam semua sesi shell.

Satu cara untuk melakukan ini ialah menambah baris berikut pada fail ~ / .bashrc:

source <(kubectl completion bash)

Cara lain ialah menambah skrip sambungan kubectl ke direktori /etc/bash_completion.d (buat jika ia tidak wujud):

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

Semua skrip tambahan dalam katalog /etc/bash_completion.d disertakan secara automatik dalam bash-completion.

Kedua-dua pilihan adalah sama terpakai.

Selepas memulakan semula shell, penyelesaian arahan kubectl akan berfungsi.

Bash pada MacOS

Pada MacOS, persediaan adalah sedikit lebih rumit. Hakikatnya ialah secara lalai, MacOS menggunakan Bash versi 3.2, dan skrip autocompletion kubectl memerlukan versi Bash sekurang-kurangnya 4.1 dan tidak berfungsi dalam Bash 3.2.

Terdapat isu pelesenan yang dikaitkan dengan menggunakan versi Bash yang lapuk pada MacOS. Bash versi 4 dilesenkan di bawah GPLv3, yang tidak disokong oleh Apple.

Untuk mengkonfigurasi autolengkap kubectl pada MacOS, anda perlu memasang versi Bash yang lebih terkini. Anda juga boleh menetapkan Bash yang dikemas kini sebagai cangkerang lalai anda, yang akan menjimatkan banyak masalah pada masa hadapan. Ia tidak sukar, butiran diberikan dalam artikel "Mengemas kini Bash pada MacOS'.

Sebelum meneruskan, pastikan anda menggunakan versi Bash terkini (semak output bash --version).

Skrip penyiapan Bash berbeza mengikut projek bash-completion, jadi anda perlu memasangnya terlebih dahulu.

Anda boleh memasang bash-completion menggunakan Homebrew:

$ brew install bash-completion@2

ia adalah @2 singkatan kepada bash-completion versi 2. kubectl autocompletion memerlukan bash-completion v2, dan bash-completion v2 memerlukan minimum Bash versi 4.1.

Keluaran arahan brew-install mengandungi bahagian Kaveat, yang menentukan perkara yang perlu ditambahkan pada fail ~/.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"

Walau bagaimanapun, saya mengesyorkan agar tidak menambah baris ini ~/.bash_profile, dan dalam ~/.bashrc. Dalam kes ini, autolengkap akan tersedia bukan sahaja dalam bahagian utama, tetapi juga dalam cengkerang arahan kanak-kanak.

Selepas memulakan semula shell arahan, anda boleh mengesahkan pemasangan adalah betul menggunakan arahan berikut:

$ type _init_completion

Jika anda melihat fungsi shell dalam output, maka semuanya dikonfigurasikan dengan betul.

Sekarang kita perlu memastikan bahawa autolengkap kubectl didayakan dalam semua sesi.

Satu cara ialah menambah baris berikut pada anda ~/.bashrc:

source <(kubectl completion bash)

Cara kedua ialah menambah skrip autolengkap pada folder /usr/local/etc/bash_completion.d:

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

Kaedah ini hanya akan berfungsi jika anda memasang bash-completion menggunakan Homebrew. Dalam kes ini, bash-completion memuatkan semua skrip daripada direktori ini.

Jika anda memasang kubectl menggunakan Homebrew, maka tidak perlu melakukan langkah sebelumnya, kerana skrip autolengkap akan diletakkan secara automatik dalam folder /usr/local/etc/bash_completion.d semasa pemasangan. Dalam kes ini, autocompletion kubectl akan mula berfungsi sebaik sahaja anda memasang bash-completion.

Akibatnya, semua pilihan ini adalah setara.

Zsh

Skrip autolengkap untuk Zsh tidak memerlukan sebarang kebergantungan. Apa yang anda perlu lakukan ialah membolehkannya apabila anda memuatkan shell arahan.

Anda boleh melakukan ini dengan menambahkan baris pada anda ~/.zshrc fail:

source <(kubectl completion zsh)

Jika anda menerima ralat not found: compdef selepas memulakan semula shell anda, anda perlu mendayakan fungsi terbina compdef. Anda boleh mendayakannya dengan menambahkannya pada permulaan fail anda ~/.zshrc yang berikut:

autoload -Uz compinit
compinit

2. Lihat spesifikasi sumber dengan pantas

Apabila anda membuat definisi sumber YAML, anda perlu mengetahui medan dan maksudnya untuk sumber tersebut. Satu tempat untuk mencari maklumat ini adalah dalam rujukan API, yang mengandungi spesifikasi lengkap untuk semua sumber.

Walau bagaimanapun, beralih kepada pelayar web setiap kali anda perlu mencari sesuatu adalah menyusahkan. Oleh itu kubectl menyediakan arahan kubectl explain, yang menunjukkan spesifikasi semua sumber terus dalam terminal anda.

Format arahan adalah seperti berikut:

$ kubectl explain resource[.field]...

Perintah akan mengeluarkan spesifikasi sumber atau medan yang diminta. Maklumat yang dipaparkan adalah sama dengan yang terkandung dalam manual API.

По умолчанию kubectl explain hanya menunjukkan tahap pertama sarang medan.

Lihat bagaimana rupanya boleh berada di sini.

Anda boleh memaparkan keseluruhan pokok jika anda menambah pilihan --recursive:

$ kubectl explain deployment.spec --recursive

Jika anda tidak tahu dengan tepat sumber yang diperlukan, anda boleh memaparkan semuanya dengan arahan berikut:

$ kubectl api-resources

Perintah ini memaparkan nama sumber dalam bentuk jamak, mis. deployments bukannya deployment. Ia juga memaparkan nama pendek, sebagai contoh deploy, untuk sumber yang memilikinya. Jangan risau tentang perbezaan ini. Semua pilihan penamaan ini adalah setara untuk kubectl. Iaitu, anda boleh menggunakan mana-mana daripada mereka untuk kubectl explain.

Semua arahan berikut adalah setara:

$ kubectl explain deployments.spec
# или
$ kubectl explain deployment.spec
# или        
$ kubectl explain deploy.spec

3. Gunakan format output lajur tersuai

Format output arahan lalai 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

Format ini mudah, tetapi ia mengandungi jumlah maklumat yang terhad. Berbanding dengan format definisi sumber penuh, hanya beberapa medan dipaparkan di sini.

Dalam kes ini, anda boleh menggunakan format output lajur tersuai. Ia membolehkan anda menentukan data yang hendak dikeluarkan. Anda boleh memaparkan sebarang medan sumber sebagai lajur yang berasingan.

Penggunaan format tersuai ditentukan menggunakan pilihan:

-o custom-columns=<header>:<jsonpath>[,<header>:<jsonpath>]...

Anda boleh menentukan setiap lajur output sebagai pasangan <header>:<jsonpath>Jika <header> ialah nama lajur, dan <jsonpath> — ungkapan yang mentakrifkan medan sumber.

Mari lihat contoh mudah:

$ kubectl get pods -o custom-columns='NAME:metadata.name'

NAME
engine-544b6b6467-22qr6
engine-544b6b6467-lw5t8
engine-544b6b6467-tvgmg
web-ui-6db964458-8pdw4

Output mengandungi satu lajur dengan nama pod.

Ungkapan pilihan memilih nama pod daripada medan metadata.name. Ini kerana nama pod ditakrifkan dalam medan nama anak metadata dalam perihalan sumber pod. Butiran lanjut boleh didapati di Panduan API atau taip arahan kubectl explain pod.metadata.name.

Sekarang katakan anda ingin menambah lajur tambahan pada output, contohnya menunjukkan nod setiap pod sedang dijalankan. Untuk melakukan ini, anda hanya boleh menambah spesifikasi lajur yang sesuai pada pilihan lajur tersuai:

$ 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

Ungkapan memilih nama nod daripada spec.nodeName — apabila pod diberikan kepada nod, namanya ditulis dalam medan spec.nodeName spesifikasi sumber pod. Maklumat yang lebih terperinci boleh didapati dalam output kubectl explain pod.spec.nodeName.

Sila ambil perhatian bahawa medan sumber Kubernetes adalah sensitif huruf besar-besaran.

Anda boleh melihat mana-mana medan sumber sebagai lajur. Hanya semak spesifikasi sumber dan cuba dengan mana-mana medan yang anda suka.

Tetapi pertama-tama, mari kita lihat lebih dekat pada ungkapan pemilihan medan.

Ungkapan JSONPath

Ungkapan untuk memilih medan sumber adalah berdasarkan JSONPath.

JSONPath ialah bahasa untuk mendapatkan semula data daripada dokumen JSON. Memilih medan tunggal ialah kes penggunaan yang paling mudah untuk JSONPath. Dia ada banyak lebih banyak kemungkinan, termasuk pemilih, penapis dan sebagainya.

Kubectl explain menyokong bilangan terhad ciri JSONPath. Kemungkinan dan contoh penggunaannya diterangkan di bawah:

# Выбрать все элементы списка
$ 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'

Pengendali [] amat penting. Banyak medan sumber Kubernetes adalah senarai, dan operator ini membenarkan anda memilih ahli senarai tersebut. Ia sering digunakan dengan kad bebas seperti [*] untuk memilih semua elemen senarai.

Contoh aplikasi

Kemungkinan untuk menggunakan format output lajur tersuai adalah tidak berkesudahan, kerana anda boleh memaparkan sebarang medan atau gabungan medan sumber dalam output. Berikut ialah beberapa contoh apl, tetapi jangan ragu untuk menerokanya sendiri dan mencari aplikasi yang sesuai untuk anda.

Memaparkan imej bekas untuk pod:

$ 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

Perintah ini memaparkan nama imej bekas untuk setiap pod.

Ingat bahawa pod boleh mengandungi beberapa bekas, maka nama imej akan dipaparkan pada satu baris, dipisahkan dengan koma.

Memaparkan zon ketersediaan nod:
```
$ 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
```
Perintah ini berguna jika kluster anda dihoskan dalam awan awam. Ia memaparkan zon ketersediaan untuk setiap nod.

Zon ketersediaan ialah konsep awan yang mengehadkan zon replikasi kepada rantau geografi.

Zon ketersediaan untuk setiap nod diperoleh melalui label khas - failure-domain.beta.kubernetes.io/zone. Jika kluster berjalan dalam awan awam, label ini dibuat secara automatik dan diisi dengan nama zon ketersediaan untuk setiap nod.

Label bukan sebahagian daripada spesifikasi sumber Kubernetes, jadi anda tidak akan menemui maklumat tentangnya Panduan API. Walau bagaimanapun, ia boleh dilihat (seperti mana-mana label lain) jika anda meminta maklumat tentang nod dalam format YAML atau JSON:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Ini ialah cara yang bagus untuk mengetahui lebih lanjut tentang sumber, selain daripada mempelajari spesifikasi sumber.

4. Tukar antara kluster dan ruang nama dengan mudah

Apabila kubectl membuat permintaan kepada API Kubernetes, ia mula-mula membaca fail kubeconfig untuk mendapatkan semua parameter yang diperlukan untuk sambungan.

Secara lalai fail kubeconfig ialah ~/.kube/config. Biasanya fail ini dicipta atau dikemas kini dengan arahan khas.

Apabila anda bekerja dengan berbilang kluster, fail kubeconfig anda mengandungi tetapan untuk menyambung ke semua kluster tersebut. Anda memerlukan satu cara untuk memberitahu arahan kubectl yang anda sedang bekerjasama.

Dalam gugusan, anda boleh mencipta berbilang ruang nama—sejenis gugusan maya dalam gugusan fizikal. Kubectl juga menentukan ruang nama yang hendak digunakan berdasarkan fail kubeconfig. Ini bermakna anda juga memerlukan cara untuk memberitahu arahan kubectl ruang nama yang hendak digunakan.

Dalam bab ini kami akan menerangkan cara ia berfungsi dan cara menjadikannya berfungsi dengan berkesan.

Ambil perhatian bahawa anda mungkin mempunyai berbilang fail kubeconfig yang disenaraikan dalam pembolehubah persekitaran KUBECONFIG. Dalam kes ini, semua fail ini akan digabungkan menjadi satu konfigurasi biasa pada masa jalan. Anda juga boleh menukar fail kubeconfig lalai dengan menjalankan kubectl dengan parameter --kubeconfig. Tengok dokumentasi rasmi.

fail kubeconfig

Mari lihat apa sebenarnya yang terkandung dalam fail kubeconfig:

Seperti yang anda lihat, fail kubeconfig mengandungi satu set konteks. Konteks terdiri daripada tiga elemen:

Kluster — URL API pelayan kluster.
Pengguna - kelayakan pengesahan pengguna dalam kelompok.
Ruang nama - ruang nama yang digunakan semasa menyertai kluster.

Dalam amalan, mereka sering menggunakan satu konteks setiap kelompok dalam kubeconfig mereka. Walau bagaimanapun, anda boleh mempunyai berbilang konteks setiap kelompok, dibezakan mengikut pengguna atau ruang nama. Walau bagaimanapun, konfigurasi berbilang konteks ini jarang berlaku, jadi biasanya terdapat pemetaan satu-sama-satu antara kelompok dan konteks.

Pada bila-bila masa, salah satu konteks adalah semasa:

Apabila kubectl membaca fail konfigurasi, ia sentiasa mengambil maklumat daripada konteks semasa. Dalam contoh di atas, kubectl akan menyambung ke kluster Hare.

Sehubungan itu, untuk beralih ke kluster lain, anda perlu menukar konteks semasa dalam fail kubeconfig:

Sekarang kubectl akan menyambung ke kelompok Fox.

Untuk bertukar kepada ruang nama yang berbeza dalam kelompok yang sama, anda perlu menukar nilai elemen ruang nama untuk konteks semasa:

Dalam contoh di atas, kubectl akan menggunakan ruang nama Prod kelompok Fox (sebelum ini ruang nama Ujian telah ditetapkan).

Ambil perhatian bahawa kubectl juga menyediakan pilihan --cluster, --user, --namespace и --context, yang membolehkan anda menulis ganti elemen individu dan konteks semasa itu sendiri, tanpa mengira apa yang ditetapkan dalam kubeconfig. Tengok kubectl options.

Secara teori, anda boleh menukar tetapan secara manual dalam kubeconfig. Tetapi ia menyusahkan. Untuk memudahkan operasi ini, terdapat pelbagai utiliti yang membolehkan anda menukar parameter secara automatik.

Gunakan kubectx

Utiliti yang sangat popular untuk menukar antara kluster dan ruang nama.

Utiliti menyediakan arahan kubectx и kubens untuk menukar konteks semasa dan ruang nama masing-masing.

Seperti yang dinyatakan, menukar konteks semasa bermakna menukar kluster jika anda hanya mempunyai satu konteks setiap kluster.

Berikut ialah contoh menjalankan arahan ini:

Pada asasnya, arahan ini hanya mengedit fail kubeconfig seperti yang diterangkan di atas.

untuk memasang kubectx, ikut arahan pada Github.

Kedua-dua arahan menyokong autolengkap nama konteks dan ruang nama, yang menghapuskan keperluan untuk menaipnya sepenuhnya. Arahan untuk menyediakan autolengkap di sini.

Satu lagi ciri berguna kubectx adalah mod interaktif. Ia berfungsi bersama-sama dengan utiliti fzf, yang mesti dipasang secara berasingan. Memasang fzf secara automatik menjadikan mod interaktif tersedia dalam kubectx. Secara interaktif, anda boleh memilih konteks dan ruang nama melalui antara muka carian percuma interaktif yang disediakan oleh fzf.

Menggunakan alias shell

Anda tidak memerlukan alat berasingan untuk menukar konteks semasa dan ruang nama kerana kubectl juga menyediakan arahan untuk ini. Ya, pasukan kubectl config menyediakan subperintah untuk mengedit fail kubeconfig.

Berikut adalah sebahagian daripada mereka:

kubectl config get-contexts: memaparkan semua konteks;
kubectl config current-context: dapatkan konteks semasa;
kubectl config use-context: tukar konteks semasa;
kubectl config set-context: Tukar elemen konteks.

Walau bagaimanapun, menggunakan arahan ini secara langsung tidak begitu mudah kerana ia panjang. Anda boleh membuat alias shell untuk mereka yang mudah dilaksanakan.

Saya mencipta satu set alias berdasarkan arahan ini yang menyediakan fungsi yang serupa dengan kubectx. Di sini anda boleh melihat mereka beraksi:

Ambil perhatian bahawa alias menggunakan fzf untuk menyediakan antara muka carian percuma interaktif (seperti mod interaktif kubectx). Ini bermakna anda perlukan pasang fzfuntuk menggunakan alias ini.

Berikut ialah takrifan alias itu sendiri:

# Получить текущий контекст
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/^..//")"'

Untuk menetapkan alias ini, anda perlu menambah takrifan di atas pada fail anda ~/.bashrc atau ~/.zshrc dan but semula shell anda.

Menggunakan pemalam

Kubectl membolehkan anda memuatkan pemalam yang dilaksanakan dengan cara yang sama seperti arahan asas. Anda boleh, sebagai contoh, memasang pemalam kubectl-foo dan menjalankannya dengan melaksanakan arahan kubectl foo.

Adalah mudah untuk menukar konteks dan ruang nama dengan cara ini, contohnya dengan menjalankan kubectl ctx untuk menukar konteks dan kubectl ns untuk menukar ruang nama.

Saya telah menulis dua pemalam yang melakukan ini:

Kerja pemalam adalah berdasarkan alias dari bahagian sebelumnya.

Begini cara mereka berfungsi:

Ambil perhatian bahawa pemalam menggunakan fzf untuk menyediakan antara muka carian percuma interaktif (seperti mod interaktif kubectx). Ini bermakna anda perlukan pasang fzfuntuk menggunakan alias ini.

Untuk memasang pemalam, anda perlu memuat turun skrip shell bernama kubectl-ctx и kubectl-ns ke mana-mana direktori dalam pembolehubah PATH anda dan jadikannya boleh laku dengan mis. chmod +x. Sejurus selepas ini anda akan dapat menggunakan kubectl ctx и kubectl ns.

5. Kurangkan input dengan autoalias

Alias Shell ialah cara yang baik untuk mempercepatkan input. Projek kubectl-alias mengandungi kira-kira 800 pintasan untuk perintah kubectl asas.

Anda mungkin tertanya-tanya - bagaimana anda mengingati 800 alias? Tetapi anda tidak perlu mengingati semuanya, kerana ia dibina mengikut skema mudah, yang diberikan di bawah:

Sebagai contoh:

kgpooyaml - kubectl dapatkan buah oyaml
ksysgsvcw — kubectl -n kube-system dapatkan svc w
ksysrmcm -kubectl -n kube-sistem rm cm
kgdepallsl - kubectl dapatkan penggunaan semua sl

Seperti yang anda lihat, alias terdiri daripada komponen, setiap satunya mewakili elemen khusus perintah kubectl. Setiap alias boleh mempunyai satu komponen untuk perintah asas, operasi dan sumber, dan berbilang komponen untuk parameter. Anda hanya "mengisi" komponen ini dari kiri ke kanan mengikut rajah di atas.

Gambar rajah terperinci semasa adalah di GitHub. Di sana anda juga boleh mencari senarai penuh alias.

Sebagai contoh, alias kgpooyamlall adalah bersamaan dengan arahan kubectl get pods -o yaml --all-namespaces.

Susunan relatif pilihan tidak penting: perintah kgpooyamlall adalah setara dengan perintah kgpoalloyaml.

Anda tidak perlu menggunakan semua komponen sebagai alias. Sebagai contoh k, kg, klo, ksys, kgpo boleh juga digunakan. Selain itu, anda boleh menggabungkan alias dan arahan biasa atau pilihan pada baris arahan:

Sebagai contoh:

Sebaliknya kubectl proxy anda boleh menulis k proxy.
Sebaliknya kubectl get roles anda boleh menulis kg roles (pada masa ini tiada alias untuk sumber Peranan).
Untuk mendapatkan data untuk pod tertentu, anda boleh menggunakan arahan kgpo my-pod — kubectl get pod my-pod.

Sila ambil perhatian bahawa sesetengah alias memerlukan hujah baris arahan. Contohnya, alias kgpol bermakna kubectl get pods -l. Pilihan -l memerlukan hujah - spesifikasi label. Jika anda menggunakan alias ia akan kelihatan seperti kgpol app=ui.

Oleh kerana sesetengah alias memerlukan hujah, alias a, f dan l mesti digunakan terakhir.

Secara umum, sebaik sahaja anda memahami skim ini, anda secara intuitif boleh memperoleh alias daripada arahan yang anda ingin laksanakan dan menjimatkan banyak masa menaip.

pemasangan

Untuk memasang kubectl-aliases, anda perlu memuat turun fail .kubectl_aliases dari GitHub dan masukkannya ke dalam fail ~/.bashrc atau ~/.zshrc:

source ~/.kubectl_aliases

Autolengkap

Seperti yang kami katakan sebelum ini, anda sering menambah perkataan tambahan pada alias pada baris arahan. Sebagai contoh:

$ kgpooyaml test-pod-d4b77b989

Jika anda menggunakan penyelesaian perintah kubectl, anda mungkin telah menggunakan autolengkap untuk perkara seperti nama sumber. Tetapi bolehkah ini dilakukan apabila alias digunakan?

Ini ialah soalan yang sangat penting kerana jika autolengkap tidak berfungsi, anda akan kehilangan beberapa faedah alias.

Jawapannya bergantung pada shell yang anda gunakan:

Untuk Zsh, penyiapan alias berfungsi di luar kotak.
Untuk Bash, malangnya, beberapa kerja diperlukan untuk mendapatkan autolengkap untuk berfungsi.

Mendayakan autolengkap untuk alias dalam Bash

Masalah dengan Bash ialah ia cuba melengkapkan (setiap kali anda menekan Tab) alias, bukan perintah yang dirujuk oleh alias (seperti yang dilakukan Zsh, sebagai contoh). Memandangkan anda tidak mempunyai skrip pelengkap untuk semua 800 alias, autolengkap tidak berfungsi.

Projek alias lengkap memberikan penyelesaian umum kepada masalah ini. Ia bersambung kepada mekanisme penyiapan untuk alias, secara dalaman mengembangkan alias kepada arahan, dan mengembalikan pilihan penyiapan untuk arahan yang lengkap. Ini bermakna bahawa padding untuk alias berkelakuan sama seperti untuk arahan penuh.

Dalam perkara berikut, saya akan menerangkan terlebih dahulu cara memasang alias lengkap dan kemudian cara mengkonfigurasinya untuk membolehkan penyiapan semua alias kubectl.

Memasang alias lengkap

Pertama sekali, alias lengkap bergantung pada bash-completion. Oleh itu, sebelum memasang alias lengkap, anda perlu memastikan bahawa bash-completion dipasang. Arahan pemasangan telah disediakan sebelum ini untuk Linux dan MacOS.

Nota Penting untuk Pengguna MacOS: Seperti skrip autocompletion kubectl, complete-alias tidak berfungsi dengan Bash 3.2, yang merupakan lalai pada MacOS. Khususnya, alias lengkap bergantung pada bash-completion v2 (brew install bash-completion@2), yang memerlukan sekurang-kurangnya Bash 4.1. Ini bermakna untuk menggunakan alias lengkap pada MacOS anda perlu memasang versi Bash yang lebih baharu.

Anda perlu memuat turun skrip bash_completion.sh daripada repositori GitHub dan masukkannya ke dalam fail anda ~/.bashrc:

source ~/bash_completion.sh

Selepas but semula shell, alias lengkap akan dipasang sepenuhnya.

Mendayakan autolengkap untuk alias kubectl

Secara teknikal lengkap-alias menyediakan fungsi pembungkus _complete_alias. Fungsi ini menyemak alias dan mengembalikan petunjuk penyelesaian untuk arahan alias.

Untuk mengaitkan fungsi dengan alias tertentu, anda perlu menggunakan mekanisme Bash terbina dalam melengkapkan, untuk memasang _complete_alias sebagai fungsi pelengkap alias.

Sebagai contoh, mari kita ambil alias k, yang bermaksud arahan kubectl. untuk memasang _complete_alias Sebagai fungsi pelengkap untuk alias ini, anda harus menjalankan arahan berikut:

$ complete -F _complete_alias k

Hasilnya ialah apabila anda melengkapkan alias k secara automatik, fungsi itu dipanggil _complete_alias, yang menyemak alias dan mengembalikan petunjuk penyelesaian untuk arahan kubectl.

Sebagai contoh kedua, mari kita ambil alias kg, yang menandakan kubectl get:

$ complete -F _complete_alias kg

Sama seperti dalam contoh sebelumnya, apabila anda melengkapkan kg secara automatik, anda mendapat petunjuk penyiapan yang sama yang anda akan dapat untuk kubectl get.

Ambil perhatian bahawa anda boleh menggunakan alias lengkap untuk sebarang alias pada sistem anda.

Oleh itu, untuk mendayakan autolengkap bagi semua alias kubectl, anda perlu menjalankan arahan di atas untuk setiap satu daripadanya. Coretan berikut melakukan perkara ini, dengan syarat anda telah menetapkan kubectl-alias kepada ~/.kubectl-aliases:

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

Sekeping kod ini perlu diletakkan di dalam anda ~/.bashrc, mulakan semula shell arahan dan autolengkap akan tersedia untuk semua 800 alias kubectl.

6. Memanjangkan kubectl dengan pemalam

Bermula dari versi 1.12, kubectl menyokong mekanisme pemalam, yang membolehkan anda mengembangkan fungsinya dengan arahan tambahan.

Jika anda biasa dengan Mekanisme pemalam Git, maka pemalam kubectl dibina berdasarkan prinsip yang sama.

Dalam bab ini, kami akan membincangkan cara memasang pemalam, tempat mencari pemalam dan cara mencipta pemalam anda sendiri.

Memasang pemalam

Pemalam Kubectl diedarkan sebagai fail boleh laku mudah dengan nama seperti kubectl-x. Awalan kubectl- diperlukan, diikuti dengan subperintah kubectl baharu yang membolehkan anda memanggil pemalam.

Sebagai contoh, pemalam hello akan diedarkan sebagai fail yang dipanggil kubectl-hello.

Untuk memasang pemalam, anda perlu menyalin fail kubectl-x ke mana-mana direktori dalam PATH anda dan jadikannya boleh laku, contohnya dengan chmod +x. Sejurus selepas ini anda boleh memanggil pemalam dengan kubectl x.

Anda boleh menggunakan arahan berikut untuk menyenaraikan semua pemalam yang sedang dipasang pada sistem anda:

$ kubectl plugin list

Perintah ini juga akan memaparkan amaran jika anda mempunyai berbilang pemalam dengan nama yang sama, atau jika terdapat fail pemalam yang tidak boleh dilaksanakan.

Mencari dan memasang pemalam menggunakan Krew

Pemalam Kubectl boleh dikongsi atau digunakan semula seperti pakej perisian. Tetapi di manakah anda boleh mencari pemalam yang telah dikongsi oleh orang lain?

Projek Krew bertujuan untuk menyediakan penyelesaian bersatu untuk berkongsi, mencari, memasang dan mengurus pemalam kubectl. Projek itu memanggil dirinya sebagai "pengurus pakej untuk pemalam kubectl" (Krew adalah serupa dengan Brew).

Krew ialah senarai pemalam kubectl yang boleh anda pilih dan pasang. Pada masa yang sama, Krew juga merupakan pemalam untuk kubectl.

Ini bermakna memasang Krew berfungsi pada asasnya seperti memasang mana-mana pemalam kubectl lain. Anda boleh mendapatkan arahan terperinci di Halaman GitHub.

Perintah Krew yang paling penting ialah:

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

Sila ambil perhatian bahawa memasang pemalam menggunakan Krew tidak mengganggu pemasangan pemalam menggunakan kaedah standard yang diterangkan di atas.

Sila ambil perhatian bahawa arahan kubectl krew list hanya memaparkan pemalam yang dipasang menggunakan Krew, manakala arahan kubectl plugin list menyenaraikan semua pemalam, iaitu, yang dipasang menggunakan Krew dan yang dipasang dengan kaedah lain.

Mencari Pemalam di Tempat Lain

Krew adalah projek muda, kini dalam projeknya senarai hanya kira-kira 30 pemalam. Jika anda tidak menemui apa yang anda perlukan, anda boleh mencari pemalam di tempat lain, seperti GitHub.

Saya cadangkan melihat bahagian GitHub kubectl-plugins. Di sana anda akan menemui berpuluh-puluh pemalam yang tersedia yang patut anda lihat.

Menulis pemalam anda sendiri

anda boleh sendiri buat pemalam - Ia tidak sukar. Anda perlu mencipta boleh laku yang melakukan apa yang anda perlukan, namakannya kubectl-x dan pasang seperti yang diterangkan di atas.

Fail itu boleh menjadi skrip bash, skrip python, atau aplikasi GO yang disusun - tidak mengapa. Satu-satunya syarat ialah ia boleh dilaksanakan secara langsung dalam sistem pengendalian.

Mari buat pemalam contoh sekarang. Dalam bahagian sebelumnya, anda menggunakan perintah kubectl untuk menyenaraikan bekas untuk setiap pod. Sangat mudah untuk menukar arahan ini menjadi pemalam yang boleh anda panggil dengan cth. kubectl img.

Buat fail kubectl-img kandungan berikut:

#!/bin/bash
kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

Sekarang buat fail boleh laku dengan chmod +x kubectl-img dan alihkannya ke mana-mana direktori dalam PATH anda. Sejurus selepas ini anda boleh menggunakan pemalam kubectl img.

Seperti yang dinyatakan, pemalam kubectl boleh ditulis dalam mana-mana bahasa pengaturcaraan atau skrip. Jika anda menggunakan skrip shell, kelebihan dapat memanggil kubectl dengan mudah dari dalam pemalam. Walau bagaimanapun, anda boleh menulis pemalam yang lebih kompleks dalam bahasa pengaturcaraan sebenar menggunakan Pustaka pelanggan Kubernetes. Jika anda menggunakan Go, anda juga boleh menggunakan perpustakaan cli-runtime, yang wujud khusus untuk menulis pemalam kubectl.

Cara berkongsi pemalam anda

Jika anda rasa pemalam anda boleh berguna kepada orang lain, sila kongsikannya di GitHub. Pastikan anda menambahkannya pada topik kubectl-plugins.

Anda juga boleh meminta pemalam anda ditambahkan ke senarai krew. Arahan tentang cara melakukan ini ada dalam Repositori GitHub.

Penyelesaian arahan

Pemalam tidak menyokong autolengkap pada masa ini. Iaitu, anda mesti memasukkan nama penuh pemalam dan nama penuh hujah.

Repositori kubectl GitHub untuk fungsi ini mempunyai permintaan terbuka. Jadi kemungkinan ciri ini akan dilaksanakan pada masa hadapan.

Semoga berjaya!!!

Apa lagi yang perlu dibaca mengenai topik tersebut:

Sumber: www.habr.com

Cara menggunakan kubectl dengan lebih berkesan: panduan terperinci