Come utilizzare kubectl in modo più efficace: una guida dettagliata

Se lavori con Kubernetes, kubectl è probabilmente una delle utility che usi di più. E ogni volta che passi molto tempo a lavorare con un particolare strumento, vale la pena studiarlo bene e imparare come usarlo in modo efficace.

Squadra Kubernetes aaS da Mail.ru ha tradotto un articolo di Daniel Weibel in cui troverete suggerimenti e trucchi per lavorare in modo efficace con kubectl. Ti aiuterà anche ad acquisire una comprensione più approfondita di Kubernetes.

Secondo l'autore, l'obiettivo dell'articolo è rendere il vostro lavoro quotidiano con Kubernetes non solo più efficiente, ma anche più divertente!

Introduzione: Cos'è kubectl

Prima di poter imparare a utilizzare kubectl in modo più efficace, è necessario acquisire una conoscenza di base di cosa sia e come funzioni.

Dal punto di vista dell'utente, kubectl è un pannello di controllo che consente di eseguire operazioni Kubernetes.

Tecnicamente kubectl è un client API Kubernetes.

L'API Kubernetes è un'API REST HTTP. Questa API è la vera interfaccia utente di Kubernetes, attraverso la quale è completamente controllata. Ciò significa che ogni operazione Kubernetes viene esposta come endpoint API e può essere effettuata con una richiesta HTTP a tale endpoint.

Pertanto, il compito principale di kubectl è effettuare richieste HTTP all'API Kubernetes:

Kubernetes è un sistema completamente orientato alle risorse. Ciò significa che mantiene lo stato interno delle risorse e tutte le operazioni Kubernetes sono operazioni CRUD.

Hai il controllo completo di Kubernetes gestendo queste risorse e Kubernetes capisce cosa fare in base allo stato attuale delle risorse. Per questo motivo, il riferimento API Kubernetes è organizzato come un elenco di tipi di risorse con le relative operazioni associate.

Diamo un'occhiata a un esempio.

Supponiamo che tu voglia creare una risorsa ReplicaSet. A tale scopo, descrivere il ReplicaSet in un file in base al nome replicaset.yaml, quindi esegui il comando:

$ kubectl create -f replicaset.yaml

Ciò creerà una risorsa ReplicaSet. Ma cosa succede dietro le quinte?

Kubernetes dispone di un'operazione di creazione di ReplicaSet. Come qualsiasi altra operazione, viene esposta come endpoint API. L'endpoint API specifico per questa operazione è simile al seguente:

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

Gli endpoint API per tutte le operazioni Kubernetes sono disponibili all'indirizzo Riferimento API (compresi il punto finale di cui sopra). Per effettuare una richiesta effettiva a un endpoint, devi prima aggiungere l'URL del server API ai percorsi dell'endpoint elencati nel riferimento API.

Pertanto, quando esegui il comando precedente, kubectl invia una richiesta HTTP POST all'endpoint API precedente. La definizione ReplicaSet fornita nel file replicaset.yaml, viene inviato nel corpo della richiesta.

Ecco come funziona kubectl per tutti i comandi che interagiscono con il cluster Kubernetes. In tutti questi casi, kubectl effettua semplicemente richieste HTTP agli endpoint API Kubernetes appropriati.

Tieni presente che puoi gestire completamente Kubernetes utilizzando un'utilità come curlinviando manualmente richieste HTTP all'API Kubernetes. Kubectl semplifica semplicemente l'utilizzo dell'API Kubernetes.

Queste sono le nozioni di base su cosa è kubectl e come funziona. Ma c'è qualcos'altro nell'API Kubernetes che ogni utente kubectl dovrebbe sapere. Diamo una rapida occhiata al mondo interno di Kubernetes.

Il mondo interiore di Kubernetes

Kubernetes è costituito da un insieme di componenti indipendenti che vengono eseguiti come processi separati sui nodi del cluster. Alcuni componenti vengono eseguiti su nodi master, altri su nodi di lavoro, ciascun componente esegue la propria attività specifica.

Ecco i componenti più importanti sui nodi principali:

1. Conservazione - memorizza le definizioni delle risorse (di solito è etcd).
2. server API — fornisce un'API e gestisce l'archiviazione.
3. Responsabile del controllore — Garantisce che gli stati delle risorse siano conformi alle specifiche.
4. Pianificatore — pianifica i pod sui nodi di lavoro.

Ed ecco un componente più importante sui nodi di lavoro:

1. kubelet — gestisce il lancio dei container sul nodo di lavoro.

Per capire come interagiscono questi componenti, facciamo un esempio.

Supponiamo che tu abbia appena completato kubectl create -f replicaset.yaml, dopodiché kubectl ha effettuato una richiesta HTTP POST a Endpoint API ReplicaSet (passando la definizione della risorsa ReplicaSet).

Cosa sta succedendo nel cluster?

1. Dopo aver fatto kubectl create -f replicaset.yaml Il server API archivia la definizione della risorsa ReplicaSet nell'archivio:

   

2. Successivamente, il controller ReplicaSet viene avviato nel gestore controller, che gestisce la creazione, la modifica e l'eliminazione delle risorse ReplicaSet:

   

3. Il controller ReplicaSet crea una definizione di pod per ogni replica ReplicaSet (in base al modello di pod nella definizione ReplicaSet) e la archivia nell'archivio:

   

4. Lo scheduler viene avviato, monitorando i pod che non sono stati ancora assegnati ad alcun nodo di lavoro:

   

5. Lo scheduler seleziona un nodo di lavoro adatto per ciascun pod e aggiunge queste informazioni alla definizione del pod nello store:

   

6. Sul nodo di lavoro a cui è assegnato il pod, viene avviato Kubelet, che tiene traccia dei pod assegnati a questo nodo:

   

7. Kubelet legge la definizione del pod dallo spazio di archiviazione e istruisce un runtime del contenitore, come Docker, ad avviare i contenitori sul nodo:

   

Di seguito è riportata una versione testuale di questa descrizione.

La richiesta API all'endpoint di creazione ReplicaSet viene elaborata dal server API. Il server API autentica la richiesta e archivia la definizione della risorsa ReplicaSet nell'archivio.

Questo evento avvia il controller ReplicaSet, che è un sottoprocesso del gestore controller. Il controller ReplicaSet monitora la creazione, l'aggiornamento e l'eliminazione delle risorse ReplicaSet nell'archivio e riceve una notifica di evento quando ciò si verifica.

Il compito del controller ReplicaSet è garantire che esista il numero richiesto di pod ReplicaSet. Nel nostro esempio, non esistono ancora pod, quindi il controller ReplicaSet crea queste definizioni di pod (in base al modello di pod nella definizione ReplicaSet) e le archivia nell'archivio.

La creazione di nuovi pod viene attivata da uno scheduler che tiene traccia delle definizioni di pod non ancora pianificate per i nodi di lavoro. Lo scheduler seleziona un nodo di lavoro adatto per ciascun pod e aggiorna le definizioni dei pod nel repository.

Tieni presente che fino a questo punto nessun codice del carico di lavoro era in esecuzione in nessuna parte del cluster. Tutto quello che è stato fatto finora - questa è la creazione e l'aggiornamento delle risorse nel repository sul nodo master.

L'ultimo evento attiva Kubelet, che monitorano i pod pianificati per i loro nodi di lavoro. Il Kubelet del nodo di lavoro su cui sono installati i tuoi pod ReplicaSet deve istruire il runtime del contenitore, come Docker, per scaricare le immagini del contenitore richieste ed eseguirle.

A questo punto, l'applicazione ReplicaSet è finalmente in esecuzione!

Ruolo dell'API Kubernetes

Come hai visto nell'esempio precedente, i componenti Kubernetes (ad eccezione del server API e dell'archiviazione) controllano le modifiche alle risorse nell'archiviazione e modificano le informazioni sulle risorse nell'archiviazione.

Naturalmente questi componenti non interagiscono direttamente con lo storage, ma solo tramite le API Kubernetes.

Considera i seguenti esempi:

1. Il controller ReplicaSet utilizza l'endpoint API elenca i set di repliche con parametro watch per monitorare le modifiche alle risorse ReplicaSet.
2. Il controller ReplicaSet utilizza l'endpoint API creare il pod (crea pod) per creare pod.
3. Lo scheduler utilizza l'endpoint API baccello di toppa (modifica pod) per aggiornare i pod con le informazioni sul nodo di lavoro selezionato.

Come puoi vedere, questa è la stessa API a cui accede kubectl. Utilizzare la stessa API per componenti interni e utenti esterni è un concetto fondamentale nella progettazione di Kubernetes.

Ora possiamo riassumere come funziona Kubernetes:

1. Lo stato degli archivi di archiviazione, ovvero le risorse Kubernetes.
2. Il server API fornisce un'interfaccia allo storage sotto forma di API Kubernetes.
3. Tutti gli altri componenti e utenti Kubernetes leggono, osservano e manipolano lo stato (risorse) Kubernetes tramite l'API.

Conoscere questi concetti ti aiuterà a comprendere meglio kubectl e a trarne il massimo.

Ora diamo un'occhiata ad alcuni suggerimenti e trucchi specifici che ti aiuteranno a migliorare la tua produttività con kubectl.

1. Accelera l'input utilizzando il completamento del comando

Una delle tecniche più utili, ma spesso trascurate, per migliorare le prestazioni con kubectl è il completamento dei comandi.

Il completamento dei comandi ti consente di completare automaticamente parti dei comandi kubectl utilizzando il tasto Tab. Funziona con sottocomandi, opzioni e argomenti, inclusi elementi complessi come i nomi delle risorse.

Scopri come funziona il completamento del comando kubectl:

Il completamento dei comandi funziona per le shell Bash e Zsh.

Guida ufficiale contiene istruzioni dettagliate per impostare il completamento automatico, ma di seguito forniremo un breve estratto.

Come funziona il completamento dei comandi

Il completamento dei comandi è una funzionalità della shell che funziona utilizzando uno script di completamento. Uno script di estensione è uno script di shell che definisce il comportamento di un'estensione per un comando specifico.

Kubectl genera e restituisce automaticamente script di estensione per Bash e Zsh utilizzando i seguenti comandi:

$ kubectl completion bash

Oppure:

$ kubectl completion zsh

In teoria è sufficiente collegare l'output di questi comandi alla shell dei comandi appropriata affinché kubectl possa integrare i comandi.

In pratica, il metodo di connessione è diverso per Bash (comprese le differenze tra Linux e MacOS) e Zsh. Di seguito esamineremo tutte queste opzioni.

Bash su Linux

Lo script di completamento Bash dipende dal pacchetto bash-completion, quindi devi prima installarlo:

$ sudo apt-get install bash-completion

Oppure:

$ yum install bash-completion

Puoi verificare che il pacchetto sia installato correttamente utilizzando il seguente comando:

$ type _init_completion

Se questo restituisce il codice della funzione della shell, allora bash-completion è installato correttamente. Se il comando restituisce l'errore "Non trovato", devi aggiungere la seguente riga al tuo file ~ / .bashrc:

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

È necessario aggiungere questa riga al file ~ / .bashrc dipende o meno dal gestore pacchetti utilizzato per installare bash-completion. Ciò è necessario per APT, ma non per YUM.

Dopo aver installato bash-completion, devi configurare tutto in modo che lo script di completamento kubectl sia abilitato in tutte le sessioni della shell.

Un modo per farlo è aggiungere la seguente riga al file ~ / .bashrc:

source <(kubectl completion bash)

Un altro modo è aggiungere lo script dell'estensione kubectl alla directory /etc/bash_completion.d (createlo se non esiste):

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

Tutti gli script aggiuntivi nel catalogo /etc/bash_completion.d sono automaticamente inclusi nel completamento bash.

Entrambe le opzioni sono ugualmente applicabili.

Dopo aver riavviato la shell, il completamento del comando kubectl funzionerà.

Bash su MacOS

Su MacOS la configurazione è un po' più complicata. Il fatto è che per impostazione predefinita MacOS utilizza Bash versione 3.2 e lo script di completamento automatico kubectl richiede una versione Bash almeno 4.1 e non funziona in Bash 3.2.

Esistono problemi di licenza associati all'utilizzo di una versione obsoleta di Bash su MacOS. Bash versione 4 è concesso in licenza con GPLv3, che non è supportato da Apple.

Per configurare il completamento automatico di kubectl su MacOS, devi installare una versione più recente di Bash. Puoi anche impostare la Bash aggiornata come shell predefinita, il che ti farà risparmiare molti problemi in futuro. Non è difficile, i dettagli sono riportati nell’articolo”Aggiornamento Bash su MacOS'.

Prima di continuare, assicurati di utilizzare una versione recente di Bash (controlla l'output bash --version).

Lo script di completamento di Bash varia in base al progetto bash-completamento, quindi devi prima installarlo.

Puoi installare bash-completion usando Fatto in casa:

$ brew install bash-completion@2

Qui @2 sta per bash-completion versione 2. Il completamento automatico di kubectl richiede bash-completion v2 e bash-completion v2 richiede almeno la versione 4.1 di Bash.

Uscita del comando brew-install contiene una sezione Avvertenze, che specifica cosa deve essere aggiunto al file ~/.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"

Tuttavia, consiglio di non aggiungere queste righe ~/.bash_profile, mentre in ~/.bashrc. In questo caso, il completamento automatico sarà disponibile non solo nella shell dei comandi principale, ma anche in quella secondaria.

Dopo aver riavviato la shell dei comandi, puoi verificare che l'installazione sia corretta utilizzando il seguente comando:

$ type _init_completion

Se vedi una funzione di shell nell'output, tutto è configurato correttamente.

Ora dobbiamo assicurarci che il completamento automatico di kubectl sia abilitato in tutte le sessioni.

Un modo è aggiungere la seguente riga al tuo file ~/.bashrc:

source <(kubectl completion bash)

Il secondo modo è aggiungere uno script di completamento automatico alla cartella /usr/local/etc/bash_completion.d:

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

Questo metodo funzionerà solo se hai installato il completamento bash utilizzando Homebrew. In questo caso, bash-completion carica tutti gli script da questa directory.

Se hai installato kubectl utilizzando Homebrew, non è necessario eseguire il passaggio precedente, poiché lo script di completamento automatico verrà automaticamente inserito nella cartella /usr/local/etc/bash_completion.d durante l'installazione. In questo caso, il completamento automatico di kubectl inizierà a funzionare non appena installi bash-completion.

Di conseguenza, tutte queste opzioni sono equivalenti.

zsh

Gli script di completamento automatico per Zsh non richiedono alcuna dipendenza. Tutto quello che devi fare è abilitarli quando carichi la shell dei comandi.

Puoi farlo aggiungendo una riga al tuo file ~/.zshrc file:

source <(kubectl completion zsh)

Se ricevi un errore not found: compdef dopo aver riavviato la shell, è necessario abilitare la funzione integrata compdef. Puoi abilitarlo aggiungendolo all'inizio del file ~/.zshrc Il seguente:

autoload -Uz compinit
compinit

2. Visualizza rapidamente le specifiche delle risorse

Quando crei le definizioni delle risorse YAML, devi conoscere i campi e il loro significato per tali risorse. Un posto in cui cercare queste informazioni è nel riferimento API, che contiene le specifiche complete per tutte le risorse.

Tuttavia, passare al browser web ogni volta che è necessario cercare qualcosa è scomodo. Pertanto kubectl fornisce il comando kubectl explain, che mostra le specifiche di tutte le risorse direttamente nel tuo terminale.

Il formato del comando è il seguente:

$ kubectl explain resource[.field]...

Il comando restituirà la specifica della risorsa o del campo richiesto. Le informazioni visualizzate sono identiche a quelle contenute nel manuale API.

Per impostazione predefinita kubectl explain mostra solo il primo livello di nidificazione dei campi.

Guarda come appare È quindi possibile.

Puoi visualizzare l'intero albero se aggiungi l'opzione --recursive:

$ kubectl explain deployment.spec --recursive

Se non sai esattamente quali risorse sono necessarie, puoi visualizzarle tutte con il seguente comando:

$ kubectl api-resources

Questo comando visualizza i nomi delle risorse in forma plurale, ad es. deployments invece di deployment. Viene visualizzato, ad esempio, anche il nome breve deploy, per quelle risorse che lo hanno. Non preoccuparti di queste differenze. Tutte queste opzioni di denominazione sono equivalenti per kubectl. Cioè, puoi usarne uno qualsiasi per kubectl explain.

Tutti i seguenti comandi sono equivalenti:

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

3. Utilizzare un formato di output della colonna personalizzato

Formato di output del comando predefinito 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

Questo formato è conveniente, ma contiene una quantità limitata di informazioni. Rispetto al formato completo di definizione della risorsa, qui vengono visualizzati solo pochi campi.

In questo caso, puoi utilizzare un formato di output della colonna personalizzato. Ti consente di determinare quali dati inviare in output. È possibile visualizzare qualsiasi campo risorsa come colonna separata.

L'uso di un formato personalizzato è determinato utilizzando le opzioni:

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

È possibile definire ciascuna colonna di output come coppia <header>:<jsonpath>Dove <header> è il nome della colonna e <jsonpath> — un'espressione che definisce un campo di risorse.

Diamo un'occhiata a un semplice esempio:

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

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

L'output contiene una colonna con i nomi dei pod.

L'espressione dell'opzione seleziona i nomi dei pod dal campo metadata.name. Questo perché il nome del pod è definito nel campo del nome del figlio metadata nella descrizione della risorsa del pod. Maggiori dettagli possono essere trovati in Guida all'API oppure digita il comando kubectl explain pod.metadata.name.

Ora supponiamo che tu voglia aggiungere una colonna extra all'output, ad esempio mostrando il nodo su cui è in esecuzione ciascun pod. Per fare ciò, puoi semplicemente aggiungere la specifica della colonna appropriata all'opzione delle colonne personalizzate:

$ 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

L'espressione seleziona il nome del nodo da spec.nodeName — quando un pod viene assegnato a un nodo, il suo nome viene scritto nel campo spec.nodeName specifica della risorsa pod. Informazioni più dettagliate possono essere trovate nell'output kubectl explain pod.spec.nodeName.

Tieni presente che i campi delle risorse Kubernetes fanno distinzione tra maiuscole e minuscole.

Puoi visualizzare qualsiasi campo risorsa come una colonna. Basta rivedere le specifiche della risorsa e provarla con tutti i campi che preferisci.

Ma prima diamo uno sguardo più da vicino alle espressioni di selezione dei campi.

Espressioni JSONPath

Si basano sulle espressioni per la selezione dei campi delle risorse Percorso JSON.

JSONPath è un linguaggio per il recupero di dati da documenti JSON. La selezione di un singolo campo è il caso d'uso più semplice per JSONPath. Ha molto più possibilità, inclusi selettori, filtri e così via.

Kubectl spiega supporta un numero limitato di funzionalità JSONPath. Le possibilità e gli esempi del loro utilizzo sono descritti di seguito:

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

L'operatore [] è particolarmente importante. Molti campi delle risorse Kubernetes sono elenchi e questo operatore ti consente di selezionare i membri di tali elenchi. Viene spesso utilizzato con un carattere jolly come [*] per selezionare tutti gli elementi di un elenco.

Esempi di applicazione

Le possibilità di utilizzare un formato di output della colonna personalizzato sono infinite, poiché puoi visualizzare qualsiasi campo o combinazione di campi di risorse nell'output. Ecco alcune app di esempio, ma sentiti libero di esplorarle tu stesso e trovare le applicazioni che funzionano per te.

1. Visualizzazione delle immagini del contenitore per i 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

   Questo comando visualizza i nomi delle immagini del contenitore per ciascun pod.

   Ricorda che un pod può contenere più contenitori, quindi i nomi delle immagini verranno visualizzati su un'unica riga, separati da virgole.

2. Visualizzazione delle zone di disponibilità del nodo:

   $ 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

   Questo comando è utile se il tuo cluster è ospitato in un cloud pubblico. Visualizza la zona di disponibilità per ciascun nodo.

   La zona di disponibilità è un concetto cloud che limita la zona di replica a un'area geografica.

   Le zone di disponibilità per ciascun nodo sono ottenute tramite un'etichetta speciale - failure-domain.beta.kubernetes.io/zone. Se il cluster è in esecuzione in un cloud pubblico, questa etichetta viene creata automaticamente e riempita con i nomi delle zone di disponibilità per ciascun nodo.

   Le etichette non fanno parte delle specifiche delle risorse Kubernetes, quindi non troverai informazioni al riguardo Guida all'API. Possono però essere visualizzate (come qualsiasi altra etichetta) se richiedi informazioni sui nodi in formato YAML o JSON:

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

   Questo è un ottimo modo per saperne di più sulle risorse, oltre alle specifiche delle risorse di apprendimento.

4. Passa facilmente tra cluster e spazi dei nomi

Quando kubectl effettua una richiesta all'API Kubernetes, legge prima il file kubeconfig per ottenere tutti i parametri necessari per la connessione.

Per impostazione predefinita, il file kubeconfig è ~/.kube/config. In genere questo file viene creato o aggiornato da un comando speciale.

Quando lavori con più cluster, il tuo file kubeconfig contiene le impostazioni per la connessione a tutti questi cluster. Hai bisogno di un modo per indicare al comando kubectl con quale cluster stai lavorando.

All'interno di un cluster è possibile creare più spazi dei nomi, un tipo di cluster virtuale all'interno di un cluster fisico. Kubectl determina inoltre quale spazio dei nomi utilizzare in base al file kubeconfig. Ciò significa che è necessario anche un modo per indicare al comando kubectl con quale spazio dei nomi lavorare.

In questo capitolo spiegheremo come funziona e come farlo funzionare in modo efficace.

Tieni presente che potresti avere più file kubeconfig elencati nella variabile di ambiente KUBECONFIG. In questo caso, tutti questi file verranno combinati in un'unica configurazione comune in fase di esecuzione. Puoi anche modificare il file kubeconfig predefinito eseguendo kubectl con il parametro --kubeconfig. Vedere documentazione ufficiale.

file kubeconfig

Vediamo cosa contiene esattamente il file kubeconfig:

Come puoi vedere, il file kubeconfig contiene una serie di contesti. Il contesto è costituito da tre elementi:

• Cluster: URL API del server del cluster.
• Utente: credenziali di autenticazione dell'utente nel cluster.
• Spazio dei nomi: lo spazio dei nomi utilizzato quando si unisce al cluster.

In pratica, spesso utilizzano un contesto per cluster nel loro kubeconfig. Tuttavia, puoi avere più contesti per cluster, differenziati per utente o spazio dei nomi. Tuttavia, questa configurazione multi-contesto è rara, quindi di solito esiste una mappatura uno a uno tra cluster e contesti.

In ogni dato momento, uno dei contesti è attuale:

Quando kubectl legge un file di configurazione, prende sempre le informazioni dal contesto corrente. Nell'esempio sopra, kubectl si connetterà al cluster Hare.

Di conseguenza, per passare a un altro cluster, è necessario modificare il contesto corrente nel file kubeconfig:

Ora kubectl si connetterà al cluster Fox.

Per passare a uno spazio dei nomi diverso nello stesso cluster, è necessario modificare il valore dell'elemento namespace per il contesto corrente:

Nell'esempio precedente, kubectl utilizzerà lo spazio dei nomi Prod del cluster Fox (in precedenza era impostato lo spazio dei nomi Test).

Tieni presente che kubectl fornisce anche opzioni --cluster, --user, --namespace и --context, che permettono di sovrascrivere i singoli elementi e il contesto corrente stesso, indipendentemente da quanto impostato nel file kubeconfig. Aspetto kubectl options.

In teoria, puoi modificare manualmente le impostazioni nel file kubeconfig. Ma è scomodo. Per semplificare queste operazioni esistono diverse utility che permettono di modificare i parametri in modo automatico.

Usa kubectx

Un'utilità molto popolare per il passaggio tra cluster e spazi dei nomi.

L'utilità fornisce comandi kubectx и kubens per modificare rispettivamente il contesto corrente e lo spazio dei nomi.

Come accennato, cambiare il contesto corrente significa cambiare il cluster se hai solo un contesto per cluster.

Ecco un esempio di esecuzione di questi comandi:

In sostanza, questi comandi modificano semplicemente il file kubeconfig come descritto sopra.

installare kubectx, seguire le istruzioni su Github.

Entrambi i comandi supportano il completamento automatico dei nomi del contesto e dello spazio dei nomi, eliminando la necessità di digitarli completamente. Istruzioni per impostare il completamento automatico qui.

Un'altra caratteristica utile kubectx è modalità interattiva. Funziona insieme all'utilità FZF, che deve essere installato separatamente. L'installazione di fzf rende automaticamente disponibile la modalità interattiva in kubectx. In modo interattivo, puoi selezionare il contesto e lo spazio dei nomi tramite l'interfaccia di ricerca gratuita interattiva fornita da fzf.

Utilizzo degli alias della shell

Non sono necessari strumenti separati per modificare il contesto e lo spazio dei nomi correnti perché kubectl fornisce anche comandi a questo scopo. Sì, squadra kubectl config fornisce sottocomandi per la modifica dei file kubeconfig.

Qui ci sono alcuni di loro:

• kubectl config get-contexts: visualizza tutti i contesti;
• kubectl config current-context: ottieni il contesto attuale;
• kubectl config use-context: cambia il contesto attuale;
• kubectl config set-context: modifica l'elemento di contesto.

Tuttavia usare direttamente questi comandi non è molto comodo perchè sono lunghi. Puoi creare alias di shell facili da eseguire.

Ho creato una serie di alias basati su questi comandi che forniscono funzionalità simili a kubectx. Qui potete vederli in azione:

Tieni presente che gli alias utilizzano fzf per fornire un'interfaccia di ricerca gratuita interattiva (come la modalità interattiva di kubectx). Ciò significa che hai bisogno installa fzfutilizzare questi alias.

Ecco le definizioni degli alias stessi:

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

Per impostare questi alias devi aggiungere le definizioni di cui sopra al tuo file ~/.bashrc o ~/.zshrc e riavvia la shell.

Utilizzo dei plugin

Kubectl ti consente di caricare plugin che vengono eseguiti allo stesso modo dei comandi di base. Puoi, ad esempio, installare il plugin kubectl-foo ed eseguirlo eseguendo il comando kubectl foo.

Sarebbe conveniente modificare il contesto e lo spazio dei nomi in questo modo, ad esempio eseguendo kubectl ctx cambiare contesto e kubectl ns per modificare lo spazio dei nomi.

Ho scritto due plugin che fanno questo:

• kubectl-ctx
• kubectl-ns

Il lavoro dei plugin si basa sugli alias della sezione precedente.

Ecco come funzionano:

Tieni presente che i plugin utilizzano fzf per fornire un'interfaccia di ricerca gratuita interattiva (come la modalità interattiva di kubectx). Ciò significa che hai bisogno installa fzfutilizzare questi alias.

Per installare i plugin, è necessario scaricare gli script di shell denominati kubectl-ctx и kubectl-ns in qualsiasi directory nella variabile PATH e renderli eseguibili con ad es. chmod +x. Subito dopo sarai in grado di utilizzare kubectl ctx и kubectl ns.

5. Ridurre l'input con gli alias automatici

Gli alias della shell sono un buon modo per velocizzare l'input. Progetto alias kubectl contiene circa 800 scorciatoie per i comandi kubectl di base.

Forse ti starai chiedendo: come ricordi 800 alias? Ma non è necessario ricordarli tutti, perché sono costruiti secondo uno schema semplice, che viene riportato di seguito:

Per esempio:

1. kgpooyaml - kubectl ottiene i pod oyaml
2. ksysgsvcw — kubectl -n kube-system ottieni svc w
3. ksysrmcm -kubectl -n kube-system rm cm
4. kgdepallsl - kubectl ottiene la distribuzione di tutto sl

Come puoi vedere, gli alias sono costituiti da componenti, ognuno dei quali rappresenta un elemento specifico del comando kubectl. Ogni alias può avere un componente per il comando di base, l'operazione e la risorsa e più componenti per i parametri. Basta "popolare" questi componenti da sinistra a destra secondo il diagramma sopra.

L'attuale diagramma dettagliato è a GitHub. Lì puoi anche trovare elenco completo degli alias.

Ad esempio, l'alias kgpooyamlall è equivalente al comando kubectl get pods -o yaml --all-namespaces.

L'ordine relativo delle opzioni non è importante: comando kgpooyamlall è equivalente al comando kgpoalloyaml.

Non è necessario utilizzare tutti i componenti come alias. Per esempio k, kg, klo, ksys, kgpo può anche essere utilizzato. Inoltre, puoi combinare alias e comandi o opzioni regolari sulla riga di comando:

Per esempio:

1. Invece di kubectl proxy tu puoi scrivere k proxy.
2. Invece di kubectl get roles tu puoi scrivere kg roles (al momento non esiste un alias per la risorsa Ruoli).
3. Per ottenere i dati per un pod specifico, puoi utilizzare il comando kgpo my-pod — kubectl get pod my-pod.

Tieni presente che alcuni alias richiedono un argomento della riga di comando. Ad esempio, alias kgpol mezzi kubectl get pods -l. Opzione -l richiede un argomento: una specifica di etichetta. Se usi un alias apparirà come kgpol app=ui.

Poiché alcuni alias richiedono argomenti, gli alias a, f e l devono essere utilizzati per ultimi.

In generale, una volta imparato questo schema, puoi derivare in modo intuitivo gli alias dai comandi che desideri eseguire e risparmiare molto tempo di digitazione.

installazione

Per installare kubectl-aliases è necessario scaricare il file .kubectl_aliases da GitHub e includerlo nel file ~/.bashrc o ~/.zshrc:

source ~/.kubectl_aliases

Completamento automatico

Come abbiamo detto prima, spesso aggiungi parole aggiuntive a un alias sulla riga di comando. Per esempio:

$ kgpooyaml test-pod-d4b77b989

Se utilizzi il completamento del comando kubectl, probabilmente hai utilizzato il completamento automatico per cose come i nomi delle risorse. Ma è possibile farlo quando si utilizzano gli alias?

Questa è una domanda molto importante perché se il completamento automatico non funziona, perderai alcuni dei vantaggi degli alias.

La risposta dipende da quale shell stai utilizzando:

1. Per Zsh, il completamento dell'alias funziona immediatamente.
2. Per Bash, sfortunatamente, è necessario del lavoro per far funzionare il completamento automatico.

Abilitazione del completamento automatico per gli alias in Bash

Il problema con Bash è che tenta di completare (ogni volta che si preme Tab) l'alias, non il comando a cui si riferisce l'alias (come fa Zsh, ad esempio). Poiché non disponi di script di completamento per tutti gli 800 alias, il completamento automatico non funziona.

Progetto alias completo fornisce una soluzione generale a questo problema. Si connette al meccanismo di completamento per gli alias, espande internamente l'alias in un comando e restituisce le opzioni di completamento per il comando completato. Ciò significa che il riempimento di un alias si comporta esattamente come quello di un comando completo.

Di seguito spiegherò prima come installare complete-alias e poi come configurarlo per abilitare il completamento per tutti gli alias kubectl.

Installazione di complete-alias

Prima di tutto, dipende da complete-alias bash-completamento. Pertanto, prima di installare complete-alias, è necessario assicurarsi che sia installato bash-completion. Le istruzioni di installazione sono state fornite in precedenza per Linux e MacOS.

Nota importante per gli utenti MacOS: Come lo script di completamento automatico kubectl, complete-alias non funziona con Bash 3.2, che è l'impostazione predefinita su MacOS. In particolare, complete-alias dipende da bash-completion v2 (brew install bash-completion@2), che richiede almeno Bash 4.1. Ciò significa che per utilizzare l'alias completo su MacOS è necessario installare una versione più recente di Bash.

È necessario scaricare lo script bash_completion.sh di Repositorio GitHub e includilo nel tuo file ~/.bashrc:

source ~/bash_completion.sh

Dopo aver riavviato la shell, complete-alias verrà installato completamente.

Abilitazione del completamento automatico per gli alias kubectl

Tecnicamente complete-alias fornisce una funzione wrapper _complete_alias. Questa funzione controlla l'alias e restituisce suggerimenti di completamento per il comando alias.

Per associare una funzione a un alias specifico, è necessario utilizzare il meccanismo Bash integrato completamento di una, installare _complete_alias come funzione di completamento dell'alias.

Prendiamo ad esempio l'alias k, che sta per il comando kubectl. installare _complete_alias Come funzione complementare per questo alias, dovresti eseguire il seguente comando:

$ complete -F _complete_alias k

Il risultato di ciò è che ogni volta che completi automaticamente un alias k, viene chiamata la funzione _complete_alias, che controlla l'alias e restituisce suggerimenti di completamento per il comando kubectl.

Come secondo esempio, prendiamo l'alias kg, che denota kubectl get:

$ complete -F _complete_alias kg

Proprio come nell'esempio precedente, quando completi automaticamente kg, ottieni gli stessi suggerimenti di completamento che otterresti kubectl get.

Tieni presente che puoi utilizzare complete-alias per qualsiasi alias sul tuo sistema.

Pertanto, per abilitare il completamento automatico per tutti gli alias kubectl, è necessario eseguire il comando precedente per ciascuno di essi. Il seguente snippet fa esattamente questo, a condizione che tu abbia impostato kubectl-aliases su ~/.kubectl-aliases:

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

Questo pezzo di codice deve essere inserito nel tuo file ~/.bashrc, riavvia la shell dei comandi e il completamento automatico diventerà disponibile per tutti gli 800 alias kubectl.

6. Estendere kubectl con plugin

Dato che versione 1.12, supporta kubectl meccanismo di plugin, che permettono di espandere le sue funzioni con comandi aggiuntivi.

Se conosci Meccanismi dei plugin Git, i plugin kubectl si basano sullo stesso principio.

In questo capitolo tratteremo come installare i plugin, dove trovarli e come creare i tuoi plugin.

Installazione di plugin

I plugin Kubectl sono distribuiti come semplici file eseguibili con il nome like kubectl-x. Prefisso kubectl- è richiesto, seguito da un nuovo sottocomando kubectl che ti consente di chiamare il plugin.

Ad esempio, il plugin hello verrà distribuito come file chiamato kubectl-hello.

Per installare il plugin è necessario copiare il file kubectl-x in qualsiasi directory del tuo PERCORSO e rendilo eseguibile, ad esempio con chmod +x. Subito dopo puoi richiamare il plugin con kubectl x.

Puoi utilizzare il seguente comando per elencare tutti i plugin attualmente installati sul tuo sistema:

$ kubectl plugin list

Questo comando visualizzerà anche avvisi se sono presenti più plug-in con lo stesso nome o se è presente un file di plug-in non eseguibile.

Trovare e installare plugin utilizzando Krew

I plugin Kubectl possono essere condivisi o riutilizzati come pacchetti software. Ma dove puoi trovare i plugin che altri hanno condiviso?

Progetto Krew mira a fornire una soluzione unificata per la condivisione, la ricerca, l'installazione e la gestione dei plugin kubectl. Il progetto si definisce un "gestore di pacchetti per plugin kubectl" (Krew è simile a Infuso).

Krew è un elenco di plugin kubectl che puoi selezionare e installare. Allo stesso tempo Krew è anche un plugin per kubectl.

Ciò significa che l'installazione di Krew funziona essenzialmente come l'installazione di qualsiasi altro plugin kubectl. Puoi trovare istruzioni dettagliate su Pagina GitHub.

I comandi Krew più importanti sono:

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

Tieni presente che l'installazione dei plugin utilizzando Krew non interferisce con l'installazione dei plugin utilizzando il metodo standard descritto sopra.

Tieni presente che il comando kubectl krew list mostra solo i plugin installati utilizzando Krew, mentre il comando kubectl plugin list elenca tutti i plugin, cioè quelli installati utilizzando Krew e quelli installati con altri metodi.

Trovare plugin altrove

Krew è un progetto giovane, attualmente in fase di sviluppo elenco di solo circa 30 plugin. Se non riesci a trovare ciò di cui hai bisogno, puoi trovare plugin altrove, come GitHub.

Consiglio di guardare la sezione GitHub plugin kubectl. Lì troverai dozzine di plugin disponibili che vale la pena provare.

Scrivere i propri plugin

puoi te stesso creare plugin - Non è difficile. Devi creare un eseguibile che faccia ciò di cui hai bisogno, chiamalo come kubectl-x e installarlo come descritto sopra.

Il file potrebbe essere uno script bash, uno script python o un'applicazione GO compilata, non importa. L'unica condizione è che possa essere eseguito direttamente nel sistema operativo.

Creiamo subito un plugin di esempio. Nella sezione precedente, hai utilizzato il comando kubectl per elencare i contenitori per ciascun pod. È facile trasformare questo comando in un plugin che puoi chiamare con ad es. kubectl img.

Crea un file kubectl-img come segue:

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

Ora rendi eseguibile il file con chmod +x kubectl-img e spostalo in qualsiasi directory del tuo PERCORSO. Subito dopo puoi utilizzare il plugin kubectl img.

Come accennato, i plugin kubectl possono essere scritti in qualsiasi linguaggio di programmazione o scripting. Se utilizzi script di shell, il vantaggio di poter richiamare facilmente kubectl dall'interno del plugin. Tuttavia, puoi scrivere plugin più complessi in linguaggi di programmazione reali utilizzando Libreria client Kubernetes. Se stai utilizzando Go, puoi anche utilizzare libreria runtime cli, che esiste specificatamente per scrivere plugin kubectl.

Come condividere i tuoi plugin

Se ritieni che i tuoi plugin possano essere utili ad altri, sentiti libero di condividerli su GitHub. Assicurati di aggiungerli all'argomento plugin kubectl.

Puoi anche richiedere che il tuo plugin venga aggiunto a Elenco dell'equipaggio. Le istruzioni su come eseguire questa operazione sono presenti Repository GitHub.

Completamento del comando

I plugin attualmente non supportano il completamento automatico. Cioè, devi inserire il nome completo del plugin e i nomi completi degli argomenti.

Il repository GitHub kubectl per questa funzione ha richiesta aperta. Quindi è possibile che questa funzionalità venga implementata in futuro.

In bocca al lupo!

Cos'altro leggere sull'argomento:

1. Tre livelli di scalabilità automatica in Kubernetes e come utilizzarli in modo efficace.
2. Kubernetes nello spirito della pirateria con un modello per l'implementazione.
3. Il nostro canale Around Kubernetes in Telegram.

Fonte: habr.com