Jak efektywnie korzystać z kubectl: szczegółowy przewodnik

Zobaczmy prosty przykład:

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

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

Wyjście zawiera jedną kolumnę z nazwami podów.

Wyrażenie w opcji wybiera nazwy podów z pola metadata.name. To dlatego, że nazwa podu jest określona w podrzędnym polu name pola metadata w opisie zasobu podu. Można zapoznać się z tym bliżej w dokumentacji API lub wpisać komendę kubectl explain pod.metadata.name.

Załóżmy teraz, że chcesz dodać dodatkową kolumnę do wyjścia, na przykład pokazując węzeł, na którym działa każda aplikacja. Aby to zrobić, wystarczy dodać odpowiednią specyfikację kolumny do opcji kolumn niestandardowych:

$ 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

Wyrażenie wybiera nazwę węzła z spec.nodeName — gdy aplikacja jest przypisywana do węzła, jej nazwa jest zapisywana w polu spec.nodeName specyfikacji zasobów aplikacji. Więcej informacji można znaleźć w wyjściu kubectl explain pod.spec.nodeName.

Pamiętaj, że pola zasobów Kubernetes są wrażliwe na wielkość liter.

Możesz wyświetlić dowolne pole zasobu w postaci kolumny. Po prostu przejrzyj specyfikację zasobu i wypróbuj dowolne pola, które Ci się podobają.

Ale najpierw przyjrzyjmy się dokładniej wyrażeniom wybierającym pola.

Wyrażenia JSONPath

Wyrażenia do wybierania pól zasobów opierają się na JSONPath.

JSONPath to język zapytań do danych w dokumentach JSON. Wybór jednego pola to najprostszy przypadek użycia JSONPath. Ma znacznie więcej możliwości, w tym selektory, filtry i tak dalej.

Kubectl explain obsługuje ograniczoną liczbę możliwości JSONPath. Poniżej opisano możliwości i przykłady ich zastosowania:

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

Oprócz tego ważna jest operator []. Wiele pól zasobów Kubernetes to listy, a ten operator pozwala na wybieranie elementów tych list. Często używa się go z symbolem wieloznacznym, np. [*], aby wybrać wszystkie elementy listy.

Przykłady zastosowania

Możliwości użycia niestandardowego formatu wyjściowego kolumn są nieograniczone, ponieważ możesz wyświetlić dowolne pole lub kombinację pól zasobu w wyjściu. Oto kilka przykładów zastosowań, ale nie wahaj się badać ich samodzielnie i znajdować przydatnych dla siebie zastosowań.

1. Wyświetlanie obrazów kontenerów dla aplikacji:

   $ 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

   To polecenie wyświetla nazwy obrazów kontenerów dla każdej aplikacji.

   Pamiętaj, że pod może zawierać wiele kontenerów, więc nazwy obrazów będą wyświetlane w jednej linii oddzielone przecinkami.

2. Wyświetlanie stref dostępności węzłów:

   $ 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

   To polecenie jest przydatne, gdy twój klaster jest zlokalizowany w publicznej chmurze. Wyświetla strefę dostępności dla każdego węzła.

   Strefa dostępności to koncepcja chmurowa, która ogranicza zasięg replikacji do regionu geograficznego.

   Strefy dostępności dla każdego węzła są pozyskiwane dzięki specjalnej etykiecie — failure-domain.beta.kubernetes.io/zone. Jeśli klaster działa w publicznej chmurze, ta etykieta jest tworzona automatycznie i wypełniana nazwami stref dostępności dla każdego węzła.

   Etykiety nie są częścią specyfikacji zasobów Kubernetes, więc nie znajdziesz o nich informacji w dokumentacji API. Można je jednak zobaczyć (tak jak wszystkie inne etykiety), gdy zapytasz o informacje o węzłach w formacie YAML lub JSON:

   $ kubectl get nodes -o yaml
   # albo
   $ kubectl get nodes -o json

   To świetny sposób, aby dowiedzieć się więcej o zasobach, oprócz przestudiowania specyfikacji zasobów.

4. Łatwe przełączanie między klastrami i przestrzeniami nazw

Kiedy kubectl wykonuje zapytanie do API Kubernetes, wcześniej odczytuje plik kubeconfig, aby uzyskać wszystkie niezbędne parametry do połączenia.

Domyślnie plik kubeconfig to ~/.kube/config. Zazwyczaj ten plik jest tworzony lub aktualizowany przez specjalne polecenie.

Gdy pracujesz z wieloma klastrami, twój plik kubeconfig zawiera parametry połączenia do wszystkich tych klastrów. Potrzebujesz sposobu, aby wskazać komendzie kubectl, z którym dokładnie klastrem pracujesz.

W obrębie klastra możesz utworzyć wiele przestrzeni nazw — rodzaj wirtualnego klastra w obrębie fizycznego klastra. Kubectl określa, którą przestrzeń nazw używać na podstawie danych pliku kubeconfig. Oznacza to, że potrzebujesz także sposobu na wskazanie komendzie kubectl, z którą przestrzenią nazw pracować.

W tym rozdziale opowiemy, jak to działa i jak osiągnąć efektywną pracę.

Zauważ, że możesz mieć wiele plików kubeconfig wymienionych w zmiennej środowiskowej KUBECONFIG. W takim przypadku wszystkie te pliki zostaną połączone w jedną wspólną konfigurację podczas wykonywania. Możesz także zmienić domyślny plik kubeconfig, uruchamiając kubectl z parametrem --kubeconfig. Zobacz dokumentację oficjalną.

Pliki kubeconfig

Przyjrzyjmy się, co dokładnie zawiera plik kubeconfig:

Jak widać, plik kubeconfig zawiera zestaw kontekstów. Kontekst składa się z trzech elementów:

• Cluster — URL API serwera klastra.
• User — dane uwierzytelniające użytkownika w klastrze.
• Namespace — przestrzeń nazw używana podczas łączenia się z klastrem.

W praktyce często używa się jednego kontekstu na klaster w pliku kubeconfig. Niemniej jednak możesz mieć kilka kontekstów dla klastra, różniących się użytkownikiem lub przestrzenią nazw. Taka konfiguracja z wieloma kontekstami jest jednak rzadkością, więc zazwyczaj istnieje jednoznaczne odwzorowanie między klastrami a kontekstami.

W każdym momencie jeden z kontekstów jest bieżący:

Gdy kubectl odczytuje plik konfiguracyjny, zawsze bierze informacje z bieżącego kontekstu. W powyższym przykładzie kubectl połączy się z klastrem Hare.

Odpowiednio, aby przełączyć się na inny klaster, musisz zmienić bieżący kontekst w pliku kubeconfig:

Teraz kubectl połączy się z klastrem Fox.

Aby przełączyć się na inną przestrzeń nazw w tym samym klastrze, musisz zmienić wartość elementu namespace dla bieżącego kontekstu:

W powyższym przykładzie kubectl będzie korzystać z przestrzeni nazw Prod klastra Fox (wcześniej było ustawione na przestrzeń nazw Test).

Zauważ, że kubectl również oferuje opcje --cluster, --user, --namespace i --context, które pozwalają na nadpisanie poszczególnych elementów oraz samego bieżącego kontekstu, niezależnie od tego, co jest ustawione w pliku kubeconfig. Zobacz opcje kubectl.

Teoretycznie możesz ręcznie zmieniać parametry w pliku kubeconfig. Ale to jest niewygodne. Aby uprościć te operacje, istnieje wiele narzędzi, które pozwalają na automatyczne zmienianie parametrów.

Użyj kubectx

Bardzo popularne narzędzie do przełączania między klastrami i przestrzeniami nazw.

Narzędzie udostępnia polecenia kubectx i kubens do zmiany bieżącego kontekstu i przestrzeni nazw odpowiednio.

Jak już wspomniano, zmiana bieżącego kontekstu oznacza zmianę klastra, jeśli masz tylko jeden kontekst dla klastra.

Oto przykład użycia tych poleceń:

W zasadzie, te polecenia jedynie edytują plik kubeconfig, jak opisano powyżej.

Aby zainstalować kubectx, postępuj zgodnie z instrukcjami na Github.

Oba polecenia wspierają autouzupełnianie nazw kontekstów i przestrzeni nazw, co pozwala uniknąć wpisywania ich w całości. Instrukcje dotyczące konfiguracji autouzupełniania tutaj.

Inną przydatną funkcją kubectx jest tryb interaktywny. Działa on w połączeniu z narzędziem fzf, które trzeba zainstalować osobno. Instalacja fzf automatycznie udostępnia tryb interaktywny w kubectx. W trybie interaktywnym możesz wybierać kontekst i przestrzeń nazw za pomocą interaktywnego interfejsu pełnotekstowego, dostarczonego przez fzf.

Zastosowanie aliasów powłoki

Nie potrzebujesz osobnych narzędzi do zmiany bieżącego kontekstu i przestrzeni nazw, ponieważ kubectl również dostarcza polecenia do tego celu. Tak więc polecenie kubectl config udostępnia podpolecenia do edytowania plików kubeconfig.

Oto niektóre z nich:

• kubectl config get-contexts: wyświetl wszystkie konteksty;
• kubectl config current-context: pobierz bieżący kontekst;
• kubectl config use-context: zmień bieżący kontekst;
• kubectl config set-context: zmień element kontekstu.

Jednak użycie tych poleceń bezpośrednio nie jest zbyt wygodne, ponieważ są one długie. Można więc stworzyć aliasy powłoki dla ich łatwej realizacji.

Stworzyłem zestaw aliasów oparty na tych poleceniach, które oferują funkcjonalność podobną do kubectx. Możesz zobaczyć ich działanie:

Zauważ, że aliasy wykorzystują fzf do dostarczania interaktywnego interfejsu pełnotekstowego (jak w interaktywnym trybie kubectx). Oznacza to, że musisz zainstalować fzf, aby używać tych aliasów.

Oto definicje aliasów:

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

Aby zainstalować te aliasy, musisz dodać podane powyżej definicje do swojego pliku ~\/ .bashrc lub ~/.zshrc i ponownie uruchomić swoją powłokę.

Zastosowanie wtyczek

Kubectl pozwala na ładowanie wtyczek, które działają tak jak podstawowe polecenia. Można na przykład zainstalować wtyczkę kubectl-foo i uruchamiać ją, wykonując polecenie kubectl foo.

Byłoby wygodnie zmieniać kontekst i przestrzeń nazw w ten sposób, na przykład uruchamiając kubectl ctx do zmiany kontekstu i kubectl ns do zmiany przestrzeni nazw.

Napisałem dwa pluginy, które to robią:

• kubectl-ctx
• kubectl-ns

Działanie pluginów opiera się na aliasach z poprzedniego rozdziału.

Oto jak one działają:

Zauważ, że pluginy używają fzf do zapewnienia interaktywnego interfejsu swobodnego wyszukiwania (jak w interaktywnym trybie kubectx). Oznacza to, że musisz zainstalować fzf, aby używać tych aliasów.

Aby zainstalować pluginy, musisz pobrać skrypty powłoki o nazwach kubectl-ctx i kubectl-ns do dowolnego katalogu w swojej zmiennej PATH i uczynić je wykonywalnymi, na przykład za pomocą chmod +x. Zaraz po tym będziesz mógł używać kubectl ctx i kubectl ns.

5. Skrócenie wejścia za pomocą autoaliasów

Aliaszy powłoki to dobra możliwość przyspieszenia wprowadzania. Projekt kubectl-aliases zawiera około 800 skrótów dla podstawowych poleceń kubectl.

Możesz się zdziwić — jak zapamiętać 800 aliasów? Ale nie musisz pamiętać ich wszystkich, ponieważ są one skonstruowane według prostego schematu, który przedstawiony jest poniżej:

Na przykład:

1. kgpooyaml — kubectl get pods oyaml
2. ksysgsvcw — kubectl -n kube-system get svc w
3. ksysrmcm — kubectl -n kube-system rm cm
4. kgdepallsl — kubectl get deployment all sl

Jak widzisz, aliasy składają się z komponentów, z których każdy oznacza określony element polecenia kubectl. Każdy alias może mieć jeden komponent dla podstawowego polecenia, operacji i zasobu oraz kilka komponentów dla parametrów. Po prostu "wypełniasz" te komponenty od lewej do prawej zgodnie z przedstawionym powyżej schematem.

Aktualny szczegółowy schemat znajduje się na GitHub. Tam możesz również znaleźć pełną listę pseudonimów.

Na przykład alias kgpooyamlall jest równoważny poleceniu kubectl get pods -o yaml --all-namespaces.

Relatywna kolejność opcji nie ma znaczenia: polecenie kgpooyamlall jest równoważne poleceniu kgpoalloyaml.

Możesz nie używać wszystkich komponentów jako aliasów. Na przykład k, kg, klo, ksys, kgpo można także używać. Co więcej, w wierszu poleceń można łączyć aliasy z zwykłymi poleceniami lub opcjami:

Na przykład:

1. Zamiast kubectl proxy można napisać k proxy.
2. Zamiast kubectl get roles można napisać kg roles (obecnie nie istnieje alias dla zasobu Roles).
3. Aby uzyskać dane dla konkretnego poda, można użyć polecenia kgpo my-pod — kubectl get pod my-pod.

Pamiętaj, że niektóre aliasy wymagają argumentu w wierszu poleceń. Na przykład alias kgpol oznacza kubectl get pods -l. Opcja -l wymaga argumentu – specyfikacji etykiety. Jeśli używasz aliasu, będzie on wyglądał jak kgpol app=ui.

Ze względu na to, że część aliasów wymaga argumentów, aliasy a, f i l należy używać jako ostatnich.

Ogólnie rzecz biorąc, gdy już opanujesz ten schemat, będziesz mógł intuicyjnie wydobywać aliasy z poleceń, które chcesz wykonać, oszczędzając dużo czasu na ich wprowadzanie.

Instalacja

Aby zainstalować kubectl-aliases, musisz pobrać plik .kubectl_aliases z GitHub i dołączyć go do pliku ~\/ .bashrc lub ~/.zshrc:

source ~\/./kubectl_aliases

Autouzupełnianie

Jak już wspomnieliśmy, często dodajesz dodatkowe słowa do aliasu w wierszu poleceń. Na przykład:

$ kgpooyaml test-pod-d4b77b989

Jeśli korzystasz z autouzupełniania polecenia kubectl, prawdopodobnie korzystałeś z autouzupełniania dla takich rzeczy jak nazwy zasobów. Ale czy można to zrobić, gdy używane są aliasy?

To bardzo ważne pytanie, ponieważ jeśli autouzupełnianie nie działa, stracisz część zalet aliasów.

Odpowiedź zależy od tego, jaką powłokę używasz:

1. Dla Zsh autouzupełnianie dla aliasów działa "od razu".
2. Dla Bash, niestety, potrzebne są dodatkowe kroki, aby autouzupełnianie zadziałało.

Włączenie autouzupełniania dla aliasów w Bash

Problem z Bash polega na tym, że stara się uzupełniać (za każdym razem, gdy naciśniesz Tab) alias, a nie polecenie, do którego odnosi się alias (tak jak robi to Zsh). Ponieważ nie masz skryptów uzupełniania dla wszystkich 800 aliasów, autouzupełnianie nie działa.

Projekt complete-alias zapewnia ogólne rozwiązanie tego problemu. Podłącza się do mechanizmu uzupełniania dla aliasów, wewnętrznie uzupełnia alias do polecenia i zwraca opcje uzupełnienia dla uzupełnionego polecenia. Oznacza to, że uzupełnianie dla aliasu działa dokładnie tak samo jak dla pełnego polecenia.

Najpierw wyjaśnię, jak zainstalować complete-alias, a następnie jak skonfigurować go, aby włączyć uzupełnienie dla wszystkich aliasów kubectl.

Instalacja complete-alias

Przede wszystkim complete-alias zależy od bash-completion. Dlatego przed instalacją complete-alias musisz upewnić się, że bash-completion jest zainstalowany. Instrukcje dotyczące instalacji zostały wcześniej podane dla Linux i MacOS.

Ważna uwaga dla użytkowników MacOS: podobnie jak skrypt autouzupełniania kubectl, complete-alias nie działa z Bash 3.2, który jest domyślnie używany w MacOS. W szczególności complete-alias zależy od bash-completion v2 (brew install bash-completion@2), co wymaga co najmniej Bash 4.1. Oznacza to, że aby korzystać z complete-alias na MacOS, musisz zainstalować nowszą wersję Bash.

Musisz pobrać skrypt bash_completion.sh z repozytorium GitHub i włączyć go w swoim pliku ~\/ .bashrc:

source ~/bash_completion.sh

Po ponownym uruchomieniu powłoki, complete-alias będzie w pełni zainstalowany.

Włączenie autouzupełniania dla aliasów kubectl

Technicznie complete-alias zapewnia funkcję powłoki _complete_alias. Ta funkcja sprawdza alias i zwraca podpowiedzi uzupełnienia dla komendy aliasu.

Aby powiązać funkcję z danym aliasem, należy użyć wbudowanego mechanizmu Bash complete, aby ustawić _complete_alias jako funkcję uzupełnienia aliasu.

Na przykład przyjmijmy alias k, oznaczający komendę kubectl. Aby ustawić _complete_alias jako funkcję uzupełnienia dla tego aliasu, musisz wykonać następującą komendę:

$ complete -F _complete_alias k

Wynikiem tego jest to, że za każdym razem, gdy autouzupełniasz alias k, wywoływana jest funkcja _complete_alias, która sprawdza alias i zwraca podpowiedzi uzupełnienia dla komendy kubectl.

Na drugi przykład weźmy alias kg, który oznacza kubectl get:

$ complete -F _complete_alias kg

Podobnie jak w poprzednim przykładzie, kiedy autouzupełniasz kg, otrzymujesz te same podpowiedzi uzupełnienia, które uzyskałbyś dla kubectl get.

Zauważ, że w ten sposób można używać complete-alias dla dowolnego aliasu w Twoim systemie.

W związku z tym, aby włączyć autouzupełnianie dla wszystkich aliasów kubectl, musisz wykonać podaną powyżej komendę dla każdego z nich. Następujący fragment robi dokładnie to, zakładając, że zainstalowałeś kubectl-aliases w ~/kubectl-aliases:

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

Ten kawałek kodu należy umieścić w swoim ~\/ .bashrc, ponownie uruchomić powłokę i dla wszystkich 800 aliasów kubectl autouzupełnianie stanie się dostępne.

6. Rozszerzenie kubectl za pomocą wtyczek

Zaczynając od wersji 1.12, kubectl obsługuje mechanizm wtyczek, które pozwalają na rozszerzenie jego funkcji dodatkowymi komendami.

Jeśli znasz mechanizmy wtyczek Git, to wtyczki kubectl są zbudowane na tej samej zasadzie.

W tym rozdziale opowiemy, jak instalować wtyczki, gdzie ich szukać i jak tworzyć własne wtyczki.

Instalacja wtyczek

Wtyczki kubectl są dystrybuowane jako proste pliki wykonywalne o nazwach w postaci kubectl-x. Prefiks kubectl- jest obowiązkowy, następuje po nim nowa podkomenda kubectl, która umożliwia wywołanie wtyczki.

Na przykład, wtyczka hello będzie dystrybuowana jako plik o nazwie kubectl-hello.

Aby zainstalować wtyczkę, musisz skopiować plik kubectl-x do dowolnego katalogu w swojej zmiennej PATH i uczynić go wykonywalnym, na przykład za pomocą chmod +x. Tuż po tym możesz wywołać wtyczkę za pomocą kubectl x.

Możesz użyć następującej komendy, aby wyświetlić listę wszystkich wtyczek, które są obecnie zainstalowane w twoim systemie:

$ kubectl plugin list

Ta komenda również wyświetla ostrzeżenia, jeśli masz kilka wtyczek o tych samych nazwach, lub jeśli jest plik wtyczek, który nie jest wykonywalny.

Wyszukiwanie i instalacja wtyczek za pomocą Krew

Wtyczki Kubectl są odpowiednie do wspólnego lub ponownego użycia jak pakiety oprogramowania. Ale gdzie można znaleźć wtyczki, które zostały udostępnione przez innych?

Projekt Krew ma na celu dostarczenie ujednoliconego rozwiązania do udostępniania, wyszukiwania, instalacji i zarządzania wtyczkami kubectl. Projekt nazywa siebie „menedżerem pakietów dla wtyczek kubectl” (Krew jest podobny do Brew).

Krew to lista wtyczek kubectl, które możesz wybierać i instalować. Przy tym Krew jest również wtyczką dla kubectl.

To oznacza, że instalacja Krew działa w zasadzie jak instalacja każdej innej wtyczki kubectl. Możesz znaleźć szczegółowe instrukcje na stronie GitHub.

Najważniejsze komendy Krew:

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

Weź pod uwagę, że instalacja wtyczek za pomocą Krew nie przeszkadza w instalacji wtyczek w tradycyjny sposób opisany powyżej.

Zauważ, że komenda kubectl krew list wyświetla tylko te wtyczki, które zostały zainstalowane za pomocą Krew, podczas gdy komenda kubectl plugin list wymienia wszystkie wtyczki, czyli te, które są zainstalowane za pomocą Krew, i te, które są zainstalowane innymi sposobami.

Wyszukiwanie wtyczek w innych miejscach

Krew to młody projekt, na ten moment w jego liście jest około 30 wtyczek. Jeśli nie możesz znaleźć tego, czego potrzebujesz, można znaleźć wtyczki w innym miejscu, na przykład na GitHubie.

Zalecam sprawdzić sekcję GitHub kubectl-plugins. Tam znajdziesz kilka dziesiątek dostępnych wtyczek, które warto sprawdzić.

Tworzenie własnych wtyczek

Możesz samodzielnie tworzyć wtyczki — to nie jest trudne. Musisz stworzyć plik wykonywalny, który zrobi to, co trzeba, nazwać go kubectl-x i zainstalować, jak opisano powyżej.

Plik może być skryptem bash, skryptem python lub skompilowaną aplikacją go — nie ma to znaczenia. Jedynym warunkiem jest to, aby mógł być bezpośrednio wykonywany w systemie operacyjnym.

Stwórzmy teraz przykład wtyczki. W poprzedniej sekcji użyłeś polecenia kubectl do wyświetlenia listy kontenerów dla każdego poda. Można łatwo zamienić to polecenie na wtyczkę, którą możesz wywołać, na przykład używając kubectl img.

Utwórz plik kubectl-img zawartości:

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

Teraz nadaj plikowi uprawnienia do wykonywalności za pomocą chmod +x kubectl-img i przenieś go do dowolnego katalogu w swoim PATH. Od razu po tym możesz korzystać z wtyczki kubectl img.

Jak już wspomniano, wtyczki kubectl mogą być napisane w dowolnym języku programowania lub skryptów. Jeśli używasz skryptów powłoki, to masz przewagę w łatwym wywoływaniu kubectl z wtyczki. Jednak możesz pisać bardziej złożone wtyczki w rzeczywistych językach programowania, korzystając z biblioteki klienckiej Kubernetes. Jeśli używasz Go, możesz również skorzystać z biblioteki cli-runtime, która powstała specjalnie do pisania wtyczek kubectl.

Jak podzielić się swoimi wtyczkami

Jeśli uważasz, że twoje wtyczki mogą być przydatne dla innych, nie wahaj się dzielić nimi na GitHubie. Koniecznie dodaj je do tematu kubectl-plugins.

Możesz również poprosić o dodanie swojej wtyczki do listy Krew. Instrukcje, jak to zrobić, znajdziesz w repozytorium GitHub.

Automatyczne uzupełnianie poleceń

Obecnie wtyczki nie obsługują automatycznego uzupełniania. Musisz więc wpisywać pełne nazwy wtyczek i pełne nazwy argumentów.

W repozytorium GitHub kubectl znajduje się otwarty wniosek. Możliwe zatem, że ta funkcja zostanie wdrożona w przyszłości.

Powodzenia!!!

Co jeszcze przeczytać na ten temat:

1. Trzy poziomy automatycznego skalowania w Kubernetes i jak je skutecznie wykorzystać.
2. Kubernetes w duchu piratów z szablonem wdrożeniowym.
3. Nasz kanał Wokół Kubernetes na Telegramie.

Źródło: habr.com