Kubectl nasıl daha etkili kullanılır: ayrıntılı bir kılavuz

Kubernetes ile çalışıyorsanız kubectl muhtemelen en çok kullandığınız yardımcı programlardan biridir. Belirli bir araçla çalışmak için çok fazla zaman harcadığınızda, onu iyi incelemeniz ve etkili bir şekilde nasıl kullanacağınızı öğrenmeniz faydalı olacaktır.

Ekip Mail.ru'dan Kubernetes aaS kubectl ile etkili bir şekilde çalışmak için ipuçları ve püf noktaları bulacağınız Daniel Weibel tarafından yazılan bir makaleyi tercüme etti. Ayrıca Kubernetes hakkında daha derin bir anlayış kazanmanıza da yardımcı olacaktır.

Yazara göre makalenin amacı Kubernetes ile günlük çalışmalarınızı sadece daha verimli değil aynı zamanda daha keyifli hale getirmek!

Giriş: Kubectl nedir?

Kubectl'i daha etkili kullanmayı öğrenmeden önce onun ne olduğu ve nasıl çalıştığı hakkında temel bir anlayışa sahip olmanız gerekir.

Kullanıcı açısından bakıldığında kubectl, Kubernetes işlemlerini gerçekleştirmenize olanak tanıyan bir kontrol panelidir.

Teknik olarak kubectl bir Kubernetes API istemcisidir.

Kubernetes API bir HTTP REST API'sidir. Bu API, tamamen kontrol edildiği gerçek Kubernetes kullanıcı arayüzüdür. Bu, her Kubernetes işleminin bir API uç noktası olarak kullanıma sunulduğu ve bu uç noktaya bir HTTP isteği ile yapılabileceği anlamına gelir.

Bu nedenle kubectl'in asıl işi Kubernetes API'sine HTTP istekleri yapmaktır:

Kubernetes tamamen kaynak odaklı bir sistemdir. Bu, kaynakların dahili durumunu koruduğu ve tüm Kubernetes işlemlerinin CRUD işlemleri olduğu anlamına gelir.

Bu kaynakları yöneterek Kubernetes üzerinde tam kontrole sahip olursunuz ve Kubernetes, kaynakların mevcut durumuna göre ne yapılacağına karar verir. Bu nedenle Kubernetes API referansı, ilişkili işlemleriyle birlikte kaynak türlerinin bir listesi olarak düzenlenmiştir.

Bir örneğe bakalım.

Bir ReplicaSet kaynağı oluşturmak istediğinizi varsayalım. Bunu yapmak için, ReplicaSet'i bir dosyada adıyla tanımlayın replicaset.yaml, ardından şu komutu çalıştırın:

$ kubectl create -f replicaset.yaml

Bu bir ReplicaSet kaynağı oluşturacaktır. Peki perde arkasında ne oluyor?

Kubernetes'in ReplicaSet oluşturma işlemi vardır. Diğer tüm işlemler gibi, bir API uç noktası olarak kullanıma sunulur. Bu işlem için özel API uç noktası şuna benzer:

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

Tüm Kubernetes işlemlerine yönelik API uç noktaları şu adreste bulunabilir: API referansı (dahil yukarıdaki son nokta). Bir uç noktaya gerçek bir istekte bulunmak için öncelikle API referansında listelenen uç nokta yollarına API sunucusu URL'sini eklemeniz gerekir.

Dolayısıyla yukarıdaki komutu çalıştırdığınızda kubectl, yukarıdaki API uç noktasına bir HTTP POST isteği gönderir. Dosyada sağladığınız ReplicaSet tanımı replicaset.yaml, isteğin gövdesinde gönderilir.

Kubectl, Kubernetes kümesiyle etkileşime giren tüm komutlar için bu şekilde çalışır. Tüm bu durumlarda kubectl, uygun Kubernetes API uç noktalarına HTTP isteklerinde bulunur.

Aşağıdaki gibi bir yardımcı programı kullanarak Kubernetes'i tam olarak yönetebileceğinizi lütfen unutmayın. curlHTTP isteklerini Kubernetes API'sine manuel olarak göndererek. Kubectl, Kubernetes API'nin kullanımını kolaylaştırır.

Bu kubectl'in ne olduğu ve nasıl çalıştığı ile ilgili temel bilgilerdir. Ancak Kubernetes API hakkında her kubectl kullanıcısının bilmesi gereken başka bir şey daha var. Kubernetes'in iç dünyasına hızlıca bir göz atalım.

Kubernetes'in iç dünyası

Kubernetes, küme düğümlerinde ayrı işlemler olarak çalışan bir dizi bağımsız bileşenden oluşur. Bazı bileşenler ana düğümlerde, diğerleri ise çalışan düğümlerde çalışır ve her bileşen kendi özel görevini yerine getirir.

Ana düğümlerdeki en önemli bileşenler şunlardır:

1. depo - kaynak tanımlarını saklar (genellikle vbd'dir).
2. API sunucusu — bir API sağlar ve depolamayı yönetir.
3. Denetleyici Yöneticisi — Kaynak durumlarının spesifikasyonlara uygun olmasını sağlar.
4. zamanlayıcı — çalışan düğümlerdeki bölmeleri programlar.

Ve işte çalışan düğümlerdeki en önemli bileşenlerden biri:

1. kubelet — çalışma düğümünde konteynerlerin başlatılmasını yönetir.

Bu bileşenlerin birlikte nasıl çalıştığını anlamak için bir örneğe bakalım.

Diyelim ki yeni tamamladınız kubectl create -f replicaset.yaml, bundan sonra kubectl bir HTTP POST isteğinde bulundu ReplicaSet API uç noktası (ReplicaSet kaynak tanımını geçirerek).

Kümede neler oluyor?

1. Yaptıktan sonra kubectl create -f replicaset.yaml API sunucusu ReplicaSet kaynak tanımınızı depolama alanında saklar:

   

2. Daha sonra, ReplicaSet kaynaklarının oluşturulmasını, değiştirilmesini ve silinmesini yöneten ReplicaSet denetleyicisi denetleyici yöneticisinde başlatılır:

   

3. ReplicaSet denetleyicisi, her ReplicaSet kopyası için bir bölme tanımı oluşturur (ReplicaSet tanımındaki bölme şablonuna göre) ve bunları depolama alanında saklar:

   

4. Zamanlayıcı başlatılır ve henüz herhangi bir çalışan düğüme atanmamış bölmeler izlenir:

   

5. Zamanlayıcı, her bölme için uygun bir çalışan düğümü seçer ve bu bilgiyi mağazadaki bölme tanımına ekler:

   

6. Pod'un atandığı çalışan düğümde Kubelet başlatılır ve bu düğüme atanan pod'ları takip eder:

   

7. Kubelet, depodan pod tanımını okur ve Docker gibi bir konteyner çalışma zamanına düğümdeki konteynerleri başlatması talimatını verir:

   

Aşağıda bu açıklamanın metin versiyonu bulunmaktadır.

ReplicaSet oluşturma uç noktasına yapılan API isteği, API sunucusu tarafından işlenir. API sunucusu isteğin kimliğini doğrular ve ReplicaSet kaynak tanımını depolamada saklar.

Bu olay, denetleyici yöneticisinin bir alt işlemi olan ReplicaSet denetleyicisini başlatır. ReplicaSet denetleyicisi, depodaki ReplicaSet kaynaklarının oluşturulmasını, güncellenmesini ve silinmesini izler ve bu gerçekleştiğinde bir olay bildirimi alır.

ReplicaSet denetleyicisinin görevi gerekli sayıda ReplicaSet bölmesinin mevcut olmasını sağlamaktır. Örneğimizde henüz hiçbir bölme mevcut olmadığından ReplicaSet denetleyicisi bu bölme tanımlarını oluşturur (ReplicaSet tanımındaki bölme şablonuna göre) ve bunları depolama alanında saklar.

Yeni bölmelerin oluşturulması, henüz çalışan düğümler için planlanmamış bölme tanımlarını takip eden bir zamanlayıcı tarafından tetiklenir. Zamanlayıcı, her bölme için uygun bir çalışan düğümü seçer ve depodaki bölme tanımlarını günceller.

Bu noktaya kadar kümenin hiçbir yerinde hiçbir iş yükü kodunun çalışmadığını unutmayın. Şu ana kadar yapılan her şey - bu, ana düğümdeki depodaki kaynakların oluşturulması ve güncellenmesidir.

Son olay, çalışan düğümleri için planlanan bölmeleri izleyen Kubelets'i tetikler. ReplicaSet bölmelerinizin kurulu olduğu çalışan düğümün Kubelet'i, Docker gibi konteyner çalışma zamanına gerekli konteyner görüntülerini indirmesi ve çalıştırması talimatını vermelidir.

Bu noktada ReplicaSet uygulamanız nihayet çalışıyor!

Kubernetes API'sinin Rolü

Önceki örnekte gördüğünüz gibi Kubernetes bileşenleri (API sunucusu ve depolama hariç), depolamadaki kaynaklarda yapılan değişiklikleri izler ve depolamadaki kaynaklarla ilgili bilgileri değiştirir.

Elbette bu bileşenler depolama alanıyla doğrudan etkileşime girmiyor, yalnızca Kubernetes API aracılığıyla etkileşime giriyor.

Aşağıdaki örnekleri göz önünde bulundurun:

1. ReplicaSet denetleyicisi API uç noktasını kullanır ReplicaSet'leri listele parametreli watch ReplicaSet kaynaklarındaki değişiklikleri izlemek için.
2. ReplicaSet denetleyicisi API uç noktasını kullanır Kapsül oluştur (kapsül oluştur) bölmeler oluşturmak için.
3. Zamanlayıcı API uç noktasını kullanır yama bölmesi (düzenleme bölmesi), seçilen çalışan düğüm hakkındaki bilgilerle bölmeleri güncellemek için.

Gördüğünüz gibi bu, kubectl'in eriştiği API'nin aynısıdır. Dahili bileşenler ve harici kullanıcılar için aynı API'yi kullanmak Kubernetes tasarımında temel bir kavramdır.

Artık Kubernetes'in nasıl çalıştığını özetleyebiliriz:

1. Depolama depoları Kubernetes kaynaklarını belirtir.
2. API sunucusu, depolamaya Kubernetes API biçiminde bir arayüz sağlar.
3. Diğer tüm Kubernetes bileşenleri ve kullanıcıları, API aracılığıyla Kubernetes durumunu (kaynaklarını) okur, gözlemler ve değiştirir.

Bu kavramları bilmek kubectl'i daha iyi anlamanıza ve ondan en iyi şekilde yararlanmanıza yardımcı olacaktır.

Şimdi kubectl ile üretkenliğinizi artırmanıza yardımcı olacak bazı özel ipuçlarına ve püf noktalarına bakalım.

1. Komut tamamlamayı kullanarak girişi hızlandırın

Kubectl ile performansı artırmaya yönelik en kullanışlı ancak sıklıkla gözden kaçırılan tekniklerden biri komut tamamlamadır.

Komut tamamlama, Tab tuşunu kullanarak kubectl komutlarının bazı bölümlerini otomatik olarak tamamlamanıza olanak tanır. Bu, kaynak adları kadar karmaşık şeyler de dahil olmak üzere alt komutlar, seçenekler ve argümanlar için işe yarar.

Kubectl komut tamamlamanın nasıl çalıştığını görün:

Bash ve Zsh kabukları için komut tamamlama çalışmaları.

Resmi rehber otomatik tamamlamanın ayarlanmasıyla ilgili ayrıntılı talimatlar içerir, ancak aşağıda kısa bir alıntı yapacağız.

Komut tamamlama nasıl çalışır?

Komut tamamlama, tamamlama komut dosyası kullanılarak çalışan bir kabuk özelliğidir. Uzantı komut dosyası, belirli bir komut için bir uzantının davranışını tanımlayan bir kabuk komut dosyasıdır.

Kubectl, aşağıdaki komutları kullanarak Bash ve Zsh için uzantı komut dosyalarını otomatik olarak oluşturur ve çıktısını alır:

$ kubectl completion bash

Или:

$ kubectl completion zsh

Teorik olarak kubectl'in komutları tamamlayabilmesi için bu komutların çıktısını uygun komut kabuğuna bağlamak yeterlidir.

Pratikte bağlantı yöntemi Bash (Linux ve MacOS arasındaki farklar dahil) ve Zsh için farklıdır. Aşağıda tüm bu seçeneklere bakacağız.

Linux'ta Bash

Bash tamamlama betiği, bash tamamlama paketine bağlıdır, bu nedenle önce onu yüklemeniz gerekir:

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

Aşağıdaki komutu kullanarak paketin başarıyla yüklendiğini test edebilirsiniz:

$ type _init_completion

Bu, kabuk işlev kodunun çıktısını veriyorsa, bash tamamlama doğru şekilde yüklenmiştir. Komut "Bulunamadı" hatası veriyorsa aşağıdaki satırı dosyanıza eklemeniz gerekir. ~ / .bashrc:

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

Bu satırı dosyaya eklemek gerekli mi? ~ / .bashrc bash-tamamlamayı yüklemek için kullandığınız paket yöneticisine bağlı olup olmadığı. Bu APT için gereklidir ancak YUM için gerekli değildir.

Bash tamamlamayı yükledikten sonra, kubectl tamamlama komut dosyasının tüm kabuk oturumlarında etkinleştirilmesi için her şeyi yapılandırmanız gerekir.

Bunu yapmanın bir yolu dosyaya aşağıdaki satırı eklemektir. ~ / .bashrc:

source <(kubectl completion bash)

Başka bir yol da kubectl eklenti betiğini dizine eklemektir. /etc/bash_completion.d (eğer mevcut değilse oluşturun):

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

Katalogdaki tüm eklenti komut dosyaları /etc/bash_completion.d otomatik olarak bash tamamlamaya dahil edilir.

Her iki seçenek de eşit derecede geçerlidir.

Kabuğu yeniden başlattıktan sonra kubectl komutunu tamamlama işlemi çalışacaktır.

MacOS'ta Bash

MacOS'ta kurulum biraz daha karmaşıktır. Gerçek şu ki, MacOS varsayılan olarak Bash 3.2 sürümünü kullanıyor ve kubectl otomatik tamamlama komut dosyası en az 4.1 Bash sürümünü gerektiriyor ve Bash 3.2'de çalışmıyor.

MacOS'ta Bash'in eski bir sürümünün kullanılmasıyla ilgili lisanslama sorunları vardır. Bash sürüm 4, Apple tarafından desteklenmeyen GPLv3 kapsamında lisanslanmıştır.

MacOS'ta kubectl otomatik tamamlamayı yapılandırmak için Bash'in daha yeni bir sürümünü yüklemeniz gerekir. Güncellenmiş Bash'i varsayılan kabuğunuz olarak da ayarlayabilirsiniz; bu, sizi gelecekte birçok sorundan kurtaracaktır. Zor değil, ayrıntılar makalede verilmiştir “MacOS'ta Bash'i Güncelleme'.

Devam etmeden önce Bash'in güncel bir sürümünü kullandığınızdan emin olun (çıktıyı kontrol edin) bash --version).

Bash tamamlama komut dosyası projeye göre değişir bash tamamlama, bu yüzden önce onu yüklemeniz gerekir.

Bash tamamlamayı kullanarak yükleyebilirsiniz. Ev yapımı içki:

$ brew install bash-completion@2

öyle @2 bash tamamlama sürüm 2 anlamına gelir. kubectl otomatik tamamlama, bash tamamlama v2'yi gerektirir ve bash tamamlama v2, minimum Bash sürüm 4.1'i gerektirir.

Komut çıkışı brew-install dosyaya nelerin eklenmesi gerektiğini belirten bir Uyarılar bölümü içerir ~/.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"

Ancak bu satırları eklemenizi tavsiye etmem. ~/.bash_profileVe içinde ~/.bashrc. Bu durumda, otomatik tamamlama yalnızca ana komut kabuklarında değil aynı zamanda alt komut kabuklarında da mevcut olacaktır.

Komut kabuğunu yeniden başlattıktan sonra aşağıdaki komutu kullanarak kurulumun doğru olduğunu doğrulayabilirsiniz:

$ type _init_completion

Çıktıda bir kabuk işlevi görüyorsanız her şey doğru yapılandırılmıştır.

Artık tüm oturumlarda kubectl otomatik tamamlamanın etkinleştirildiğinden emin olmamız gerekiyor.

Bunun bir yolu aşağıdaki satırı eklemektir. ~/.bashrc:

source <(kubectl completion bash)

İkinci yol ise klasöre otomatik tamamlama komut dosyası eklemektir. /usr/local/etc/bash_completion.d:

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

Bu yöntem yalnızca Homebrew kullanarak bash tamamlamayı yüklediyseniz işe yarar. Bu durumda bash tamamlama, bu dizindeki tüm komut dosyalarını yükler.

Eğer yüklediyseniz Homebrew kullanarak kubectlotomatik tamamlama komut dosyası otomatik olarak klasöre yerleştirileceğinden önceki adımı gerçekleştirmeye gerek yoktur. /usr/local/etc/bash_completion.d Kurulum sırasında. Bu durumda kubectl otomatik tamamlama, bash tamamlamayı yüklediğiniz anda çalışmaya başlayacaktır.

Sonuç olarak tüm bu seçenekler eşdeğerdir.

zsh

Zsh için otomatik tamamlama komut dosyaları herhangi bir bağımlılık gerektirmez. Tek yapmanız gereken, komut kabuğunu yüklediğinizde bunları etkinleştirmektir.

Bunu, satırınıza bir satır ekleyerek yapabilirsiniz. ~/.zshrc dosya:

source <(kubectl completion zsh)

Bir hata alırsanız not found: compdef kabuğunuzu yeniden başlattıktan sonra yerleşik işlevi etkinleştirmeniz gerekir compdef. Dosyanızın başına ekleyerek etkinleştirebilirsiniz. ~/.zshrc aşağıdaki:

autoload -Uz compinit
compinit

2. Kaynak özelliklerini hızla görüntüleyin

YAML kaynak tanımlarını oluşturduğunuzda alanları ve bu kaynaklara ait anlamlarını bilmeniz gerekir. Bu bilgiyi aratabileceğiniz yerlerden biri, tüm kaynaklara ilişkin tüm spesifikasyonları içeren API referansıdır.

Ancak bir şeyi her aramanız gerektiğinde web tarayıcısına geçmek sakıncalıdır. Bu nedenle kubectl komutu sağlar kubectl explain, tüm kaynakların özelliklerini doğrudan terminalinizde gösterir.

Komut formatı aşağıdaki gibidir:

$ kubectl explain resource[.field]...

Komut, istenen kaynağın veya alanın spesifikasyonunun çıktısını verecektir. Görüntülenen bilgiler API kılavuzunda yer alan bilgilerle aynıdır.

Varsayılan olarak kubectl explain alanların iç içe geçmesinin yalnızca ilk düzeyini gösterir.

Neye benzediğini görün burada olabilir.

Seçeneği eklerseniz ağacın tamamını görüntüleyebilirsiniz --recursive:

$ kubectl explain deployment.spec --recursive

Tam olarak hangi kaynakların gerekli olduğunu bilmiyorsanız aşağıdaki komutla hepsini görüntüleyebilirsiniz:

$ kubectl api-resources

Bu komut kaynak adlarını çoğul biçimde görüntüler, ör. deployments yerine deployment. Ayrıca kısa adı da görüntüler; örneğin deploy, buna sahip olan kaynaklar için. Bu farklılıklar konusunda endişelenmeyin. Bu adlandırma seçeneklerinin tümü kubectl için eşdeğerdir. Yani bunlardan herhangi birini kullanabilirsiniz. kubectl explain.

Aşağıdaki komutların tümü eşdeğerdir:

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

3. Özel bir sütun çıktı formatı kullanın

Varsayılan komut çıktı formatı 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

Bu format kullanışlıdır ancak sınırlı miktarda bilgi içerir. Tam kaynak tanımı formatıyla karşılaştırıldığında burada yalnızca birkaç alan görüntülenir.

Bu durumda özel bir sütun çıktı biçimi kullanabilirsiniz. Hangi verilerin çıktısını alacağınızı belirlemenizi sağlar. Herhangi bir kaynak alanını ayrı bir sütun olarak görüntüleyebilirsiniz.

Özel formatın kullanımı seçenekler kullanılarak belirlenir:

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

Her çıktı sütununu bir çift olarak tanımlayabilirsiniz <header>:<jsonpath>Nerede <header> sütun adıdır ve <jsonpath> — bir kaynak alanını tanımlayan bir ifade.

Basit bir örneğe bakalım:

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

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

Çıktı, bölmelerin adlarını içeren bir sütun içerir.

Seçenek ifadesi alandaki bölme adlarını seçer metadata.name. Bunun nedeni, bölmenin adının alt öğe adı alanında tanımlanmış olmasıdır. metadata bölmenin kaynak açıklamasında. Daha fazla ayrıntıyı şu adreste bulabilirsiniz: API Kılavuzu veya komutu yazın kubectl explain pod.metadata.name.

Şimdi çıktıya, örneğin her bölmenin üzerinde çalıştığı düğümü gösteren fazladan bir sütun eklemek istediğinizi varsayalım. Bunu yapmak için özel sütunlar seçeneğine uygun sütun spesifikasyonunu eklemeniz yeterlidir:

$ 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

İfade düğüm adını seçer spec.nodeName — bir düğüme bir pod atandığında adı alana yazılır spec.nodeName bölme kaynak spesifikasyonu. Daha ayrıntılı bilgiyi çıktıda bulabilirsiniz kubectl explain pod.spec.nodeName.

Lütfen Kubernetes kaynak alanlarının büyük/küçük harfe duyarlı olduğunu unutmayın.

Herhangi bir kaynak alanını sütun olarak görüntüleyebilirsiniz. Kaynak spesifikasyonunu gözden geçirmeniz ve istediğiniz alanlarla denemeniz yeterli.

Ancak önce alan seçimi ifadelerine daha yakından bakalım.

JSONPath İfadeleri

Kaynak alanlarını seçmeye yönelik ifadeler şunları temel alır: JSONYol.

JSONPath, JSON belgelerinden veri almaya yönelik bir dildir. Tek bir alan seçmek JSONPath için en basit kullanım durumudur. Onun çok şeyi var daha büyük sesseçiciler, filtreler vb. dahil.

Kubectl, sınırlı sayıda JSONPath özelliğini destekler. Kullanım olanakları ve örnekleri aşağıda açıklanmıştır:

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

[] operatörü özellikle önemlidir. Kubernetes kaynak alanlarının çoğu listelerdir ve bu operatör, bu listelerin üyelerini seçmenize olanak tanır. Bir listenin tüm öğelerini seçmek için genellikle [*] gibi bir joker karakterle birlikte kullanılır.

Uygulama örnekleri

Çıktıda herhangi bir alanı veya kaynak alanları kombinasyonunu görüntüleyebildiğiniz için, özel bir sütun çıktı formatı kullanma olanakları sonsuzdur. İşte bazı örnek uygulamalar; ancak bunları kendiniz keşfetmekten ve işinize yarayacak uygulamaları bulmaktan çekinmeyin.

1. Kapsüller için konteyner görselleri gösteriliyor:

   $ 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

   Bu komut, her bölme için kapsayıcı görüntü adlarını görüntüler.

   Bir bölmenin birden fazla kapsayıcı içerebileceğini, ardından görüntü adlarının virgüllerle ayrılmış olarak tek bir satırda görüntüleneceğini unutmayın.

2. Düğüm kullanılabilirliği bölgeleri görüntüleniyor:

   $ 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

   Bu komut, kümeniz genel bir bulutta barındırılıyorsa kullanışlıdır. Her düğüm için kullanılabilirlik bölgesini görüntüler.

   Erişilebilirlik bölgesi, çoğaltma bölgesini coğrafi bir bölgeyle sınırlayan bir bulut konseptidir.

   Her düğüm için kullanılabilirlik bölgeleri özel bir etiket aracılığıyla elde edilir - failure-domain.beta.kubernetes.io/zone. Küme genel bir bulutta çalışıyorsa bu etiket otomatik olarak oluşturulur ve her düğüm için kullanılabilirlik bölgelerinin adlarıyla doldurulur.

   Etiketler Kubernetes kaynak spesifikasyonunun bir parçası değildir, bu nedenle onlar hakkında bilgiyi burada bulamazsınız. API Kılavuzu. Ancak, düğümler hakkında YAML veya JSON biçiminde bilgi talep ederseniz bunlar görülebilir (diğer etiketler gibi):

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

   Bu, kaynak özelliklerini öğrenmenin yanı sıra kaynaklar hakkında daha fazla bilgi edinmenin harika bir yoludur.

4. Kümeler ve ad alanları arasında kolayca geçiş yapın

Kubectl, Kubernetes API'sine bir istek yaptığında, bağlantı için gerekli tüm parametreleri almak üzere ilk önce kubeconfig dosyasını okur.

Varsayılan olarak kubeconfig dosyası ~/.kube/config. Genellikle bu dosya özel bir komutla oluşturulur veya güncellenir.

Birden fazla kümeyle çalıştığınızda kubeconfig dosyanız bu kümelerin tümüne bağlanmaya yönelik ayarları içerir. Kubectl komutuna hangi kümeyle çalıştığınızı söylemenin bir yoluna ihtiyacınız var.

Bir küme içinde birden çok ad alanı (fiziksel bir küme içindeki bir tür sanal küme) oluşturabilirsiniz. Kubectl ayrıca kubeconfig dosyasına göre hangi ad alanının kullanılacağını da belirler. Bu aynı zamanda kubectl komutuna hangi ad alanıyla çalışılacağını söylemenin bir yoluna ihtiyacınız olduğu anlamına gelir.

Bu bölümde nasıl çalıştığını ve nasıl etkili bir şekilde çalışmasını sağlayacağımızı açıklayacağız.

KUBECONFIG ortam değişkeninde listelenen birden fazla kubeconfig dosyanız olabileceğini unutmayın. Bu durumda, tüm bu dosyalar çalışma zamanında tek bir ortak konfigürasyonda birleştirilecektir. Varsayılan kubeconfig dosyasını kubectl'i parametreyle çalıştırarak da değiştirebilirsiniz. --kubeconfig. Bakmak resmi belgeler.

kubeconfig dosyaları

Kubeconfig dosyasının tam olarak ne içerdiğini görelim:

Gördüğünüz gibi kubeconfig dosyası bir dizi bağlam içeriyor. Bağlam üç unsurdan oluşur:

• Küme — Küme sunucusunun API URL'si.
• Kullanıcı - kümedeki kullanıcı kimlik doğrulama bilgileri.
• Ad alanı - kümeye katılırken kullanılan ad alanı.

Pratikte genellikle kubeconfig'lerinde küme başına bir bağlam kullanırlar. Bununla birlikte, küme başına kullanıcı veya ad alanına göre farklılaştırılmış birden çok bağlamınız olabilir. Ancak bu çoklu bağlam konfigürasyonu yaygın değildir, dolayısıyla kümeler ve bağlamlar arasında genellikle bire bir eşleme bulunur.

Herhangi bir zamanda bağlamlardan biri günceldir:

Kubectl bir yapılandırma dosyasını okuduğunda her zaman geçerli bağlamdan bilgi alır. Yukarıdaki örnekte kubectl Hare kümesine bağlanacaktır.

Buna göre başka bir kümeye geçmek için kubeconfig dosyasındaki mevcut içeriği değiştirmeniz gerekir:

Artık kubectl Fox kümesine bağlanacak.

Aynı kümede farklı bir ad alanına geçmek için geçerli bağlama ilişkin ad alanı öğesinin değerini değiştirmeniz gerekir:

Yukarıdaki örnekte kubectl, Fox kümesinin Prod ad alanını kullanacaktır (daha önce Test ad alanı ayarlanmıştı).

Kubectl'in ayrıca seçenekler sunduğunu unutmayın --cluster, --user, --namespace и --contextBu, kubeconfig'te ne ayarlandığından bağımsız olarak tek tek öğelerin ve mevcut bağlamın üzerine yazmanıza olanak tanır. Bakmak kubectl options.

Teorik olarak kubeconfig'teki ayarları manuel olarak değiştirebilirsiniz. Ama bu uygunsuz. Bu işlemleri basitleştirmek için parametreleri otomatik olarak değiştirmenize olanak tanıyan çeşitli yardımcı programlar vardır.

kubectx'i kullan

Kümeler ve ad alanları arasında geçiş yapmak için çok popüler bir yardımcı program.

Yardımcı program komutlar sağlar kubectx и kubens sırasıyla geçerli bağlamı ve ad alanını değiştirmek için.

Belirtildiği gibi, mevcut bağlamı değiştirmek, küme başına yalnızca bir bağlamınız varsa kümeyi değiştirmek anlamına gelir.

Bu komutları çalıştırmanın bir örneği aşağıda verilmiştir:

Temel olarak bu komutlar, yukarıda açıklandığı gibi kubeconfig dosyasını düzenler.

yüklemek kubectx, talimatları izleyin Github.

Her iki komut da bağlam ve ad alanı adlarının otomatik olarak tamamlanmasını destekler; bu da bunların tamamen yazılması ihtiyacını ortadan kaldırır. Otomatik tamamlamayı ayarlama talimatları burada.

Başka bir kullanışlı özellik kubectx olduğunu etkileşimli mod. Yardımcı programla birlikte çalışır fzfayrı olarak kurulması gereken. Fzf'nin yüklenmesi, etkileşimli modun otomatik olarak kullanılabilir olmasını sağlar. kubectx. Etkileşimli olarak, fzf tarafından sağlanan etkileşimli ücretsiz arama arayüzü aracılığıyla bağlamı ve ad alanını seçebilirsiniz.

Kabuk takma adlarını kullanma

Geçerli bağlamı ve ad alanını değiştirmek için ayrı araçlara ihtiyacınız yoktur çünkü kubectl bunun için komutlar da sağlar. Evet takım kubectl config kubeconfig dosyalarını düzenlemek için alt komutlar sağlar.

İşte bunlardan bazıları:

• kubectl config get-contexts: tüm bağlamları göster;
• kubectl config current-context: mevcut bağlamı alın;
• kubectl config use-context: mevcut bağlamı değiştirin;
• kubectl config set-context: Bağlam öğesini değiştirin.

Ancak bu komutların doğrudan kullanılması uzun olduğundan pek kullanışlı değildir. Onlar için yürütülmesi kolay kabuk takma adları oluşturabilirsiniz.

Bu komutlara dayanarak kubectx'e benzer işlevsellik sağlayan bir dizi takma ad oluşturdum. Burada bunları çalışırken görebilirsiniz:

Takma adların etkileşimli ücretsiz bir arama arayüzü (kubectx'in etkileşimli modu gibi) sağlamak için fzf kullandığını unutmayın. Bu, ihtiyacınız olduğu anlamına gelir fzf'yi yüklebu takma adları kullanmak için.

Takma adların tanımları aşağıda verilmiştir:

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

Bu takma adları ayarlamak için yukarıdaki tanımları dosyanıza eklemeniz gerekir. ~/.bashrc veya ~/.zshrc ve kabuğunuzu yeniden başlatın.

Eklentileri kullanma

Kubectl, temel komutlarla aynı şekilde yürütülen eklentileri yüklemenize olanak tanır. Örneğin kubectl-foo eklentisini yükleyebilir ve komutu çalıştırarak çalıştırabilirsiniz. kubectl foo.

Bağlamı ve ad alanını bu şekilde, örneğin çalıştırarak değiştirmek uygun olacaktır. kubectl ctx bağlamı değiştirmek ve kubectl ns ad alanını değiştirmek için.

Bunu yapan iki eklenti yazdım:

• kubectl-ctx
• kubectl-n'ler

Eklentilerin çalışması önceki bölümdeki takma adlara dayanmaktadır.

İşte nasıl çalıştıkları:

Eklentilerin etkileşimli bir ücretsiz arama arayüzü (kubectx'in etkileşimli modu gibi) sağlamak için fzf kullandığını unutmayın. Bu, ihtiyacınız olduğu anlamına gelir fzf'yi yüklebu takma adları kullanmak için.

Eklentileri yüklemek için adlı kabuk komut dosyalarını indirmeniz gerekir. kubectl-ctx и kubectl-n'ler PATH değişkeninizdeki herhangi bir dizine ekleyin ve bunları örneğin çalıştırılabilir hale getirin. chmod +x. Bundan hemen sonra kullanabileceksiniz kubectl ctx и kubectl ns.

5. Otomatik takma adlarla girişi azaltın

Kabuk takma adları yazmayı hızlandırmanın iyi bir yoludur. Proje kubectl-takma adlar temel kubectl komutları için yaklaşık 800 kısayol içerir.

Merak ediyor olabilirsiniz: 800 takma adı nasıl hatırlıyorsunuz? Ancak hepsini hatırlamanıza gerek yok çünkü aşağıda verilen basit bir şemaya göre inşa edilmişler:

Örneğin:

1. kgpooyaml - kubectl baklaları al oyaml
2. ksysgsvcw — kubectl -n kube-sistemi svc w'yi alır
3. ksysrmcm -kubectl -n kube-sistemi rm cm
4. kgdepallsl - kubectl tüm sl dağıtımını alır

Gördüğünüz gibi takma adlar, her biri kubectl komutunun belirli bir öğesini temsil eden bileşenlerden oluşur. Her takma adın temel komut, işlem ve kaynak için bir bileşeni ve parametreler için birden fazla bileşeni olabilir. Yukarıdaki şemaya göre bu bileşenleri soldan sağa "doldurmanız" yeterlidir.

Mevcut ayrıntılı diyagram şu adrestedir: GitHub. Orada ayrıca bulabilirsiniz takma adların tam listesi.

Örneğin, kgpooyamlall takma adı şu komuta eşdeğerdir: kubectl get pods -o yaml --all-namespaces.

Seçeneklerin göreceli sırası önemli değildir: komut kgpooyamlall komuta eşdeğerdir kgpoalloyaml.

Tüm bileşenleri takma ad olarak kullanmanıza gerek yoktur. Örneğin k, kg, klo, ksys, kgpo da kullanılabilir. Ayrıca, takma adları ve normal komutları veya seçenekleri komut satırında birleştirebilirsiniz:

Örneğin:

1. Yerine kubectl proxy Yazabilirsin k proxy.
2. Yerine kubectl get roles Yazabilirsin kg roles (Şu anda Roller kaynağı için bir takma ad yoktur).
3. Belirli bir bölmeye ilişkin verileri almak için şu komutu kullanabilirsiniz: kgpo my-pod — kubectl get pod my-pod.

Lütfen bazı takma adların bir komut satırı argümanı gerektirdiğini unutmayın. Örneğin, takma ad kgpol araç kubectl get pods -l. Seçenek -l bir argüman gerektirir - bir etiket spesifikasyonu. Bir takma ad kullanırsanız şöyle görünecektir kgpol app=ui.

Bazı takma adlar argüman gerektirdiğinden, a, f ve l takma adlarının en son kullanılması gerekir.

Genel olarak, bu şemayı bir kez anladığınızda, yürütmek istediğiniz komutlardan sezgisel olarak takma adlar türetebilir ve yazma süresinden büyük ölçüde tasarruf edebilirsiniz.

tesisat

Kubectl-aliases'i yüklemek için dosyayı indirmeniz gerekir .kubectl_aliases GitHub'dan alıp dosyaya ekleyin ~/.bashrc veya ~/.zshrc:

source ~/.kubectl_aliases

Otomatik tamamlama

Daha önce de söylediğimiz gibi, genellikle komut satırında bir takma ada ek kelimeler eklersiniz. Örneğin:

$ kgpooyaml test-pod-d4b77b989

Kubectl komut tamamlamayı kullanıyorsanız muhtemelen kaynak adları gibi şeyler için otomatik tamamlamayı kullanmışsınızdır. Ancak takma adlar kullanıldığında bu yapılabilir mi?

Bu çok önemli bir soru çünkü otomatik tamamlama işe yaramazsa takma adların bazı faydalarını kaybedeceksiniz.

Cevap, hangi kabuğu kullandığınıza bağlıdır:

1. Zsh için takma ad tamamlama özelliği kutudan çıktığı gibi çalışır.
2. Bash'te ne yazık ki otomatik tamamlamanın işe yaraması için biraz çalışma gerekiyor.

Bash'te takma adlar için otomatik tamamlamayı etkinleştirme

Bash'in sorunu, takma adın atıfta bulunduğu komutu değil (örneğin Zsh'nin yaptığı gibi) takma adı tamamlamaya çalışmasıdır (Tab'a her basışınızda). 800 takma adın tümü için tamamlama komut dosyalarınız olmadığından otomatik tamamlama çalışmaz.

Proje tam takma ad bu soruna genel bir çözüm sağlar. Takma adlar için tamamlama mekanizmasına bağlanır, takma adı dahili olarak bir komuta genişletir ve tamamlanan komut için tamamlama seçeneklerini döndürür. Bu, takma adın dolgusunun tam komutla tamamen aynı şekilde davrandığı anlamına gelir.

Aşağıda öncelikle tam takma adın nasıl kurulacağını ve ardından tüm kubectl takma adlarının tamamlanmasını sağlayacak şekilde nasıl yapılandırılacağını açıklayacağım.

Complete-alias kurulumu

Her şeyden önce, tam takma ad şunlara bağlıdır: bash tamamlama. Bu nedenle, tam takma adı kurmadan önce bash tamamlamanın kurulu olduğundan emin olmanız gerekir. Linux ve MacOS için kurulum talimatları daha önce verilmişti.

MacOS Kullanıcıları İçin Önemli Not: Kubectl otomatik tamamlama komut dosyası gibi tam takma ad, MacOS'ta varsayılan olan Bash 3.2 ile çalışmaz. Özellikle tam takma ad, bash tamamlama v2'ye bağlıdır (brew install bash-completion@2), en azından Bash 4.1 gerektirir. Bu, MacOS'ta tam takma adı kullanmak için Bash'in daha yeni bir sürümünü yüklemeniz gerektiği anlamına gelir.

Scripti indirmeniz gerekiyor bash_completion.sh arasında GitHub deposu ve dosyanıza ekleyin ~/.bashrc:

source ~/bash_completion.sh

Kabuğu yeniden başlattıktan sonra tam takma ad tamamen yüklenecektir.

Kubectl takma adları için otomatik tamamlamayı etkinleştirme

Teknik olarak tam takma ad, sarmalayıcı işlevi sağlar _complete_alias. Bu işlev, takma adı kontrol eder ve takma ad komutunun tamamlanma ipuçlarını döndürür.

Bir işlevi belirli bir takma adla ilişkilendirmek için yerleşik Bash mekanizmasını kullanmanız gerekir. tamamlamak, yüklemek _complete_alias takma ad tamamlama işlevi olarak.

Örnek olarak kubectl komutunun kısaltması olan k takma adını ele alalım. yüklemek _complete_alias Bu takma adın tamamlayıcı işlevi olarak aşağıdaki komutu çalıştırmalısınız:

$ complete -F _complete_alias k

Bunun sonucu olarak, k takma adını otomatik olarak tamamladığınızda işlev çağrılır. _complete_aliastakma adı kontrol eden ve komutun tamamlanma ipuçlarını döndüren kubectl.

İkinci bir örnek olarak takma adı ele alalım kg, anlamına gelir kubectl get:

$ complete -F _complete_alias kg

Önceki örnekte olduğu gibi, kg'ı otomatik olarak tamamladığınızda, için alacağınız tamamlama ipuçlarının aynısını alırsınız. kubectl get.

Sisteminizdeki herhangi bir takma ad için tam takma adı kullanabileceğinizi unutmayın.

Bu nedenle, tüm kubectl takma adları için otomatik tamamlamayı etkinleştirmek amacıyla her biri için yukarıdaki komutu çalıştırmanız gerekir. Aşağıdaki kod parçası, kubectl-aliases'i şu şekilde ayarlamanız koşuluyla tam olarak bunu yapar: ~/.kubectl-aliases:

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

Bu kod parçasının cihazınıza yerleştirilmesi gerekiyor ~/.bashrc, komut kabuğunu yeniden başlatın; otomatik tamamlama 800 kubectl takma adın tümü için kullanılabilir hale gelecektir.

6. Kubectl'i eklentilerle genişletme

Beri versiyon 1.12kubectl destekler eklenti mekanizmasıek komutlarla işlevlerini genişletmenize olanak tanır.

aşina iseniz Git eklenti mekanizmaları, o zaman kubectl eklentileri aynı prensip üzerine inşa edilmiştir.

Bu bölümde eklentilerin nasıl kurulacağını, onları nerede bulacağınızı ve kendi eklentilerinizi nasıl oluşturacağınızı ele alacağız.

Eklentileri yükleme

Kubectl eklentileri aşağıdaki adlarla basit yürütülebilir dosyalar olarak dağıtılır: kubectl-x. Önek kubectl- gereklidir ve ardından eklentiyi çağırmanıza olanak tanıyan yeni bir kubectl alt komutu gelir.

Örneğin merhaba eklentisi adlı bir dosya olarak dağıtılacaktır. kubectl-hello.

Eklentiyi yüklemek için dosyayı kopyalamanız gerekir kubectl-x PATH'inizdeki herhangi bir dizine kopyalayın ve çalıştırılabilir hale getirin, örneğin chmod +x. Bundan hemen sonra eklentiyi şu şekilde çağırabilirsiniz: kubectl x.

Sisteminizde halihazırda yüklü olan tüm eklentileri listelemek için aşağıdaki komutu kullanabilirsiniz:

$ kubectl plugin list

Bu komut aynı ada sahip birden fazla eklentiniz varsa veya çalıştırılabilir olmayan bir eklenti dosyası varsa da uyarılar görüntüler.

Krew kullanarak eklentileri bulma ve yükleme

Kubectl eklentileri, yazılım paketleri gibi paylaşılabilir veya yeniden kullanılabilir. Peki başkalarının paylaştığı eklentileri nerede bulabilirsiniz?

Proje Krew kubectl eklentilerini paylaşmak, aramak, yüklemek ve yönetmek için birleşik bir çözüm sağlamayı amaçlamaktadır. Proje kendisini "kubectl eklentileri için paket yöneticisi" olarak adlandırıyor (Krew şuna benzer: Demlemek).

Krew, seçip yükleyebileceğiniz kubectl eklentilerinin bir listesidir. Krew aynı zamanda kubectl için de bir eklentidir.

Bu, Krew'un kurulumunun aslında herhangi bir kubectl eklentisinin kurulumu gibi çalıştığı anlamına gelir. Ayrıntılı talimatları şu adreste bulabilirsiniz: GitHub sayfası.

En önemli Krew komutları şunlardır:

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

Krew'i kullanarak eklenti yüklemenin, yukarıda açıklanan standart yöntemi kullanarak eklenti yüklemeyi engellemediğini lütfen unutmayın.

Lütfen komutun kubectl krew list yalnızca Krew kullanılarak yüklenen eklentileri görüntülerken komut kubectl plugin list Krew kullanılarak yüklenenler ve diğer yöntemlerle yüklenenler olmak üzere tüm eklentileri listeler.

Başka Yerde Eklenti Bulma

Krew şu anda geliştirme aşamasında olan genç bir projedir. liste yalnızca yaklaşık 30 eklenti. İhtiyacınız olanı bulamıyorsanız eklentileri GitHub gibi başka bir yerde bulabilirsiniz.

GitHub bölümüne bakmanızı öneririm kubectl eklentileri. Orada kontrol etmeye değer düzinelerce eklenti bulacaksınız.

Kendi eklentilerinizi yazma

kendin yapabilirsin eklentiler oluştur - Zor değil. İhtiyacınız olanı yapan bir yürütülebilir dosya oluşturmanız gerekir; buna şöyle bir ad verin: kubectl-x ve yukarıda açıklandığı gibi yükleyin.

Dosya bir bash betiği, bir python betiği veya derlenmiş bir GO uygulaması olabilir; fark etmez. Tek koşul, doğrudan işletim sisteminde yürütülebilmesidir.

Hemen örnek bir eklenti oluşturalım. Önceki bölümde her bir kapsülün kapsayıcılarını listelemek için kubectl komutunu kullandınız. Bu komutu, örneğin arayabileceğiniz bir eklentiye dönüştürmek kolaydır. kubectl img.

Dosya oluştur kubectl-img aşağıdaki içerik:

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

Şimdi dosyayı çalıştırılabilir hale getirin chmod +x kubectl-img ve onu PATH'inizdeki herhangi bir dizine taşıyın. Bundan hemen sonra eklentiyi kullanabilirsiniz. kubectl img.

Belirtildiği gibi kubectl eklentileri herhangi bir programlama veya betik dilinde yazılabilir. Eğer kabuk betikleri kullanıyorsanız eklenti içinden kubectl'i kolayca çağırabilme avantajı. Ancak gerçek programlama dillerinde daha karmaşık eklentiler yazabilirsiniz. Kubernetes istemci kitaplığı. Go kullanıyorsanız şunu da kullanabilirsiniz: cli-çalışma zamanı kitaplığıözellikle kubectl eklentileri yazmak için mevcut olan.

Eklentilerinizi nasıl paylaşabilirsiniz?

Eklentilerinizin başkaları için yararlı olabileceğini düşünüyorsanız GitHub'da paylaşmaktan çekinmeyin. Konuya eklemeyi unutmayın kubectl eklentileri.

Ayrıca eklentinizin eklenmesini de talep edebilirsiniz. Krew listesi. Bunun nasıl yapılacağına ilişkin talimatlar şuradadır GitHub depoları.

Komut tamamlama

Eklentiler şu anda otomatik tamamlamayı desteklemiyor. Yani eklentinin tam adını ve argümanların tam adlarını girmelisiniz.

Bu işlev için GitHub kubectl deposunda açık istek. Dolayısıyla bu özelliğin gelecekte bir zamanda hayata geçirilmesi mümkün.

İyi şanslar!

Konuyla ilgili başka ne okunmalı?:

1. Kubernetes'te üç otomatik ölçeklendirme düzeyi ve bunların etkili bir şekilde nasıl kullanılacağı.
2. Uygulamaya yönelik bir şablonla korsanlık ruhuna sahip Kubernet'ler.
3. Telegram'da Kubernetes Çevresindeki Kanalımız.

Kaynak: habr.com