🥇Comment utiliser kubectl plus efficacement : un guide détaillé

Si vous travaillez avec Kubernetes, kubectl est probablement l'un des utilitaires que vous utilisez le plus. Et chaque fois que vous passez beaucoup de temps à travailler avec un outil particulier, il est utile de bien l’étudier et d’apprendre à l’utiliser efficacement.

Équipe Kubernetes aaS de Mail.ru a traduit un article de Daniel Weibel dans lequel vous trouverez des trucs et astuces pour travailler efficacement avec kubectl. Cela vous aidera également à mieux comprendre Kubernetes.

Selon l'auteur, l'objectif de l'article est de rendre votre travail quotidien avec Kubernetes non seulement plus efficace, mais aussi plus agréable !

Introduction : Qu'est-ce que Kubectl ?

Avant de pouvoir apprendre à utiliser kubectl plus efficacement, vous devez acquérir une compréhension de base de ce que c'est et de son fonctionnement.

Du point de vue de l'utilisateur, kubectl est un panneau de contrôle qui vous permet d'effectuer des opérations Kubernetes.

Techniquement parlant, kubectl est un client API Kubernetes.

L'API Kubernetes est une API HTTP REST. Cette API est la véritable interface utilisateur de Kubernetes, à travers laquelle elle est entièrement contrôlée. Cela signifie que chaque opération Kubernetes est exposée en tant que point de terminaison d'API et peut être effectuée avec une requête HTTP vers ce point de terminaison.

Par conséquent, la tâche principale de kubectl consiste à envoyer des requêtes HTTP à l'API Kubernetes :

Kubernetes est un système entièrement orienté ressources. Cela signifie qu'il maintient l'état interne des ressources et que toutes les opérations Kubernetes sont des opérations CRUD.

Vous contrôlez totalement Kubernetes en gérant ces ressources, et Kubernetes détermine quoi faire en fonction de l'état actuel des ressources. Pour cette raison, la référence de l'API Kubernetes est organisée sous la forme d'une liste de types de ressources avec leurs opérations associées.

Regardons un exemple.

Supposons que vous souhaitiez créer une ressource ReplicaSet. Pour ce faire, vous décrivez le ReplicaSet dans un fichier par son nom replicaset.yaml, puis exécutez la commande :

$ kubectl create -f replicaset.yaml

Cela créera une ressource ReplicaSet. Mais que se passe-t-il en coulisses ?

Kubernetes dispose d'une opération de création de ReplicaSet. Comme toute autre opération, elle est exposée en tant que point de terminaison d’API. Le point de terminaison d'API spécifique pour cette opération ressemble à ceci :

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

Les points de terminaison de l'API pour toutes les opérations Kubernetes sont disponibles à l'adresse Référence API (y compris le point final ci-dessus). Pour envoyer une demande réelle à un point de terminaison, vous devez d'abord ajouter l'URL du serveur API aux chemins de point de terminaison répertoriés dans la référence de l'API.

Par conséquent, lorsque vous exécutez la commande ci-dessus, kubectl envoie une requête HTTP POST au point de terminaison de l'API ci-dessus. La définition ReplicaSet que vous avez fournie dans le fichier replicaset.yaml, est envoyé dans le corps de la demande.

C'est ainsi que kubectl fonctionne pour toutes les commandes qui interagissent avec le cluster Kubernetes. Dans tous ces cas, kubectl envoie simplement des requêtes HTTP aux points de terminaison de l'API Kubernetes appropriés.

Veuillez noter que vous pouvez gérer entièrement Kubernetes à l'aide d'un utilitaire tel que curlen envoyant manuellement des requêtes HTTP à l'API Kubernetes. Kubectl facilite simplement l'utilisation de l'API Kubernetes.

Ce sont les bases de ce qu'est kubectl et de son fonctionnement. Mais il y a autre chose à propos de l'API Kubernetes que tout utilisateur de Kubectl devrait connaître. Jetons un coup d'œil rapide au monde intérieur de Kubernetes.

Le monde intérieur de Kubernetes

Kubernetes se compose d'un ensemble de composants indépendants qui s'exécutent en tant que processus distincts sur les nœuds du cluster. Certains composants s'exécutent sur des nœuds maîtres, d'autres sur des nœuds travailleurs, chaque composant effectuant sa propre tâche spécifique.

Voici les composants les plus importants sur les nœuds principaux :

Stockage - stocke les définitions de ressources (généralement c'est etcd).
Serveur API — fournit une API et gère le stockage.
Gestionnaire de contrôleur — S'assure que les statuts des ressources sont conformes aux spécifications.
Planificateur — planifie les pods sur les nœuds de travail.

Et voici l'un des composants les plus importants sur les nœuds de travail :

kubelet — gère le lancement des conteneurs sur le nœud de travail.

Pour comprendre comment ces composants fonctionnent ensemble, regardons un exemple.

Supposons que vous venez de terminer kubectl create -f replicaset.yaml, après quoi kubectl a envoyé une requête HTTP POST à Point de terminaison de l'API ReplicaSet (en passant la définition de ressource ReplicaSet).

Que se passe-t-il dans le cluster ?

Après avoir fait kubectl create -f replicaset.yaml Le serveur API stocke votre définition de ressource ReplicaSet dans le stockage :
Ensuite, le contrôleur ReplicaSet est lancé dans le gestionnaire de contrôleurs, qui gère la création, la modification et la suppression des ressources ReplicaSet :
Le contrôleur ReplicaSet crée une définition de pod pour chaque réplique ReplicaSet (selon le modèle de pod dans la définition ReplicaSet) et les stocke dans le stockage :
Le planificateur est lancé, suivant les pods qui n'ont pas encore été attribués à des nœuds de travail :
Le planificateur sélectionne un nœud de travail approprié pour chaque pod et ajoute ces informations à la définition du pod dans le magasin :
Sur le nœud worker auquel le pod est affecté, Kubelet est lancé, il suit les pods attribués à ce nœud :
Le Kubelet lit la définition du pod à partir du stockage et demande à un environnement d'exécution de conteneur, tel que Docker, de lancer des conteneurs sur le nœud :

Vous trouverez ci-dessous une version texte de cette description.

La requête API adressée au point de terminaison de création ReplicaSet est traitée par le serveur API. Le serveur API authentifie la demande et stocke la définition de ressource ReplicaSet dans le stockage.

Cet événement démarre le contrôleur ReplicaSet, qui est un sous-processus du gestionnaire de contrôleurs. Le contrôleur ReplicaSet surveille la création, la mise à jour et la suppression des ressources ReplicaSet dans le magasin et reçoit une notification d'événement lorsque cela se produit.

Le travail du contrôleur ReplicaSet consiste à garantir que le nombre requis de pods ReplicaSet existe. Dans notre exemple, aucun pod n'existe encore, le contrôleur ReplicaSet crée donc ces définitions de pod (selon le modèle de pod dans la définition ReplicaSet) et les stocke dans le stockage.

La création de nouveaux pods est déclenchée par un planificateur qui assure le suivi des définitions de pods qui ne sont pas encore planifiées pour les nœuds de travail. Le planificateur sélectionne un nœud de travail approprié pour chaque pod et met à jour les définitions de pod dans le référentiel.

Notez que jusqu’à présent, aucun code de charge de travail n’était exécuté nulle part dans le cluster. Tout ce qui a été fait jusqu'à présent - il s'agit de la création et de la mise à jour des ressources dans le référentiel sur le nœud maître.

Le dernier événement déclenche des Kubelets, qui surveillent les pods planifiés pour leurs nœuds de travail. Le Kubelet du nœud de travail sur lequel vos pods ReplicaSet sont installés doit demander au moteur d'exécution du conteneur, tel que Docker, de télécharger les images de conteneur requises et de les exécuter.

À ce stade, votre application ReplicaSet est enfin en cours d'exécution !

Rôle de l'API Kubernetes

Comme vous l'avez vu dans l'exemple précédent, les composants Kubernetes (à l'exception du serveur API et du stockage) surveillent les modifications apportées aux ressources de stockage et modifient les informations sur les ressources de stockage.

Bien entendu, ces composants n’interagissent pas directement avec le stockage, mais uniquement via l’API Kubernetes.

Considérez les exemples suivants:

Le contrôleur ReplicaSet utilise le point de terminaison de l'API lister les ReplicaSets avec paramètre watch pour surveiller les modifications apportées aux ressources ReplicaSet.
Le contrôleur ReplicaSet utilise le point de terminaison de l'API créer un pod (créer un pod) pour créer des pods.
Le planificateur utilise le point de terminaison de l'API module de patch (modifier le pod) pour mettre à jour les pods avec des informations sur le nœud de travail sélectionné.

Comme vous pouvez le voir, il s'agit de la même API à laquelle kubectl accède. Utiliser la même API pour les composants internes et les utilisateurs externes est un concept fondamental dans la conception de Kubernetes.

Nous pouvons maintenant résumer le fonctionnement de Kubernetes :

L’état des magasins de stockage, c’est-à-dire les ressources Kubernetes.
Le serveur API fournit une interface avec le stockage sous la forme de l'API Kubernetes.
Tous les autres composants et utilisateurs Kubernetes lisent, observent et manipulent l'état (ressources) de Kubernetes via l'API.

Connaître ces concepts vous aidera à mieux comprendre kubectl et à en tirer le meilleur parti.

Examinons maintenant quelques trucs et astuces spécifiques qui vous aideront à améliorer votre productivité avec kubectl.

1. Accélérez la saisie en utilisant l'achèvement des commandes

L'une des techniques les plus utiles, mais souvent négligées, pour améliorer les performances avec kubectl est l'achèvement des commandes.

La complétion des commandes vous permet de compléter automatiquement certaines parties des commandes kubectl à l'aide de la touche Tab. Cela fonctionne pour les sous-commandes, les options et les arguments, y compris quelque chose d'aussi complexe que les noms de ressources.

Découvrez comment fonctionne la complétion de la commande kubectl :

L'achèvement des commandes fonctionne pour les shells Bash et Zsh.

Guide officiel contient des instructions détaillées pour configurer la saisie semi-automatique, mais nous en fournirons ci-dessous un court extrait.

Comment fonctionne la complétion des commandes

La complétion des commandes est une fonctionnalité du shell qui fonctionne à l'aide d'un script de complétion. Un script d'extension est un script shell qui définit le comportement d'une extension pour une commande spécifique.

Kubectl génère et génère automatiquement des scripts d'extension pour Bash et Zsh à l'aide des commandes suivantes :

$ kubectl completion bash

Или:

$ kubectl completion zsh

En théorie, il suffit de connecter la sortie de ces commandes au shell de commande approprié pour que kubectl puisse compléter les commandes.

En pratique, la méthode de connexion est différente pour Bash (y compris les différences entre Linux et MacOS) et Zsh. Ci-dessous, nous examinerons toutes ces options.

Bash sous Linux

Le script de complétion Bash dépend du package bash-completion, vous devez donc d'abord l'installer :

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

Vous pouvez tester que le package est installé avec succès à l'aide de la commande suivante :

$ type _init_completion

Si cela génère un code de fonction shell, alors bash-completion est installé correctement. Si la commande renvoie une erreur « Not Found », vous devez ajouter la ligne suivante à votre fichier ~ / .bashrc:

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

Est-il nécessaire d'ajouter cette ligne au fichier ~ / .bashrc ou non, cela dépend du gestionnaire de paquets que vous avez utilisé pour installer bash-completion. Ceci est nécessaire pour APT, mais pas pour YUM.

Après avoir installé bash-completion, vous devez tout configurer pour que le script de complétion kubectl soit activé dans toutes les sessions shell.

Une façon de procéder consiste à ajouter la ligne suivante au fichier ~ / .bashrc:

source <(kubectl completion bash)

Une autre façon consiste à ajouter le script d'extension kubectl au répertoire /etc/bash_completion.d (créez-le s'il n'existe pas) :

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

Tous les scripts complémentaires du catalogue /etc/bash_completion.d sont automatiquement inclus dans bash-completion.

Les deux options sont également applicables.

Après avoir redémarré le shell, l'achèvement de la commande kubectl fonctionnera.

Bash sur MacOS

Sous MacOS, la configuration est un peu plus compliquée. Le fait est que par défaut, MacOS utilise Bash version 3.2 et que le script d'auto-complétion kubectl nécessite une version Bash d'au moins 4.1 et ne fonctionne pas dans Bash 3.2.

Il existe des problèmes de licence associés à l'utilisation d'une version obsolète de Bash sur MacOS. Bash version 4 est sous licence GPLv3, qui n'est pas prise en charge par Apple.

Pour configurer la saisie semi-automatique kubectl sur MacOS, vous devez installer une version plus récente de Bash. Vous pouvez également définir le Bash mis à jour comme shell par défaut, ce qui vous évitera beaucoup de problèmes à l'avenir. Ce n’est pas difficile, les détails sont donnés dans l’article »Mettre à jour Bash sur MacOS».

Avant de continuer, assurez-vous que vous utilisez une version récente de Bash (vérifiez la sortie bash --version).

Le script d'achèvement Bash varie selon le projet bash-achèvement, vous devez donc d'abord l'installer.

Vous pouvez installer bash-complétion en utilisant Homebrew:

$ brew install bash-completion@2

il est @2 signifie bash-completion version 2. L'auto-complétion kubectl nécessite bash-completion v2, et bash-completion v2 nécessite au minimum la version 4.1 de Bash.

Sortie de commande brew-install contient une section Mises en garde, qui spécifie ce qui doit être ajouté au fichier ~/.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"

Cependant, je recommande d'ajouter ces lignes pour ne pas ~/.bash_profileet ~/.bashrc. Dans ce cas, la saisie semi-automatique sera disponible non seulement dans le shell de commande principal, mais également dans les shells de commande enfants.

Après avoir redémarré le shell de commande, vous pouvez vérifier que l'installation est correcte à l'aide de la commande suivante :

$ type _init_completion

Si vous voyez une fonction shell dans la sortie, alors tout est configuré correctement.

Nous devons maintenant nous assurer que la saisie semi-automatique de kubectl est activée dans toutes les sessions.

Une façon consiste à ajouter la ligne suivante à votre ~/.bashrc:

source <(kubectl completion bash)

La deuxième façon consiste à ajouter un script de saisie semi-automatique au dossier /usr/local/etc/bash_completion.d:

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

Cette méthode ne fonctionnera que si vous avez installé bash-completion à l'aide de Homebrew. Dans ce cas, bash-completion charge tous les scripts de ce répertoire.

Si vous avez installé Kubectl utilisant Homebrew, il n'est alors pas nécessaire d'effectuer l'étape précédente, puisque le script d'auto-complétion sera automatiquement placé dans le dossier /usr/local/etc/bash_completion.d pendant l'installation. Dans ce cas, la saisie semi-automatique de kubectl commencera à fonctionner dès que vous installerez bash-completion.

En conséquence, toutes ces options sont équivalentes.

Zsh

Les scripts d'auto-complétion pour Zsh ne nécessitent aucune dépendance. Tout ce que vous avez à faire est de les activer lorsque vous chargez le shell de commande.

Vous pouvez le faire en ajoutant une ligne à votre ~/.zshrc déposer:

source <(kubectl completion zsh)

Si vous recevez une erreur not found: compdef après avoir redémarré votre shell, vous devez activer la fonction intégrée compdef. Vous pouvez l'activer en l'ajoutant au début de votre fichier ~/.zshrc suivant:

autoload -Uz compinit
compinit

2. Visualisez rapidement les spécifications des ressources

Lorsque vous créez des définitions de ressources YAML, vous devez connaître les champs et leur signification pour ces ressources. Un endroit où rechercher ces informations est la référence API, qui contient les spécifications complètes de toutes les ressources.

Cependant, passer au navigateur Web à chaque fois que vous devez rechercher quelque chose n'est pas pratique. Kubectl fournit donc la commande kubectl explain, qui affiche les spécifications de toutes les ressources directement dans votre terminal.

Le format de la commande est le suivant :

$ kubectl explain resource[.field]...

La commande affichera la spécification de la ressource ou du champ demandé. Les informations affichées sont identiques à celles contenues dans le manuel de l'API.

Par défaut kubectl explain affiche uniquement le premier niveau d'imbrication des champs.

Voyez à quoi ça ressemble Vous pouvez ensuite.

Vous pouvez afficher l'intégralité de l'arborescence si vous ajoutez l'option --recursive:

$ kubectl explain deployment.spec --recursive

Si vous ne savez pas exactement quelles ressources sont nécessaires, vous pouvez toutes les afficher avec la commande suivante :

$ kubectl api-resources

Cette commande affiche les noms de ressources au pluriel, par ex. deployments au lieu de deployment. Il affiche également le nom court, par exemple deploy, pour les ressources qui en disposent. Ne vous inquiétez pas de ces différences. Toutes ces options de dénomination sont équivalentes pour kubectl. Autrement dit, vous pouvez utiliser n'importe lequel d'entre eux pour kubectl explain.

Toutes les commandes suivantes sont équivalentes :

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

3. Utilisez un format de sortie de colonne personnalisé

Format de sortie de commande par défaut 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

Ce format est pratique, mais il contient une quantité limitée d'informations. Par rapport au format de définition complète des ressources, seuls quelques champs sont affichés ici.

Dans ce cas, vous pouvez utiliser un format de sortie de colonne personnalisé. Il vous permet de déterminer quelles données sortir. Vous pouvez afficher n’importe quel champ de ressource dans une colonne distincte.

L'utilisation d'un format personnalisé est déterminée à l'aide des options :

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

Vous pouvez définir chaque colonne de sortie comme une paire <header>:<jsonpath>Où <header> est le nom de la colonne, et <jsonpath> — une expression définissant un champ de ressource.

Regardons un exemple simple :

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

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

La sortie contient une colonne avec les noms des pods.

L'expression d'option sélectionne les noms de pods dans le champ metadata.name. En effet, le nom du pod est défini dans le champ du nom de l'enfant. metadata dans la description des ressources du pod. Plus de détails peuvent être trouvés dans Guide des API ou tapez la commande kubectl explain pod.metadata.name.

Supposons maintenant que vous souhaitiez ajouter une colonne supplémentaire à la sortie, affichant par exemple le nœud sur lequel chaque pod s'exécute. Pour ce faire, vous pouvez simplement ajouter la spécification de colonne appropriée à l'option de colonnes personnalisées :

$ 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'expression sélectionne le nom du nœud parmi spec.nodeName — lorsqu'un pod est attribué à un nœud, son nom est écrit dans le champ spec.nodeName spécification des ressources du pod. Des informations plus détaillées peuvent être trouvées dans la sortie kubectl explain pod.spec.nodeName.

Veuillez noter que les champs de ressources Kubernetes sont sensibles à la casse.

Vous pouvez afficher n’importe quel champ de ressource sous forme de colonne. Examinez simplement la spécification de la ressource et essayez-la avec tous les champs de votre choix.

Mais d’abord, examinons de plus près les expressions de sélection de champs.

Expressions JSONPath

Les expressions de sélection des champs de ressources sont basées sur Chemin JSON.

JSONPath est un langage permettant de récupérer des données à partir de documents JSON. La sélection d'un seul champ est le cas d'utilisation le plus simple de JSONPath. Il a beaucoup plus de possibilités, y compris les sélecteurs, les filtres, etc.

Kubectl Explain prend en charge un nombre limité de fonctionnalités JSONPath. Les possibilités et exemples de leur utilisation sont décrits ci-dessous :

# Выбрать все элементы списка
$ 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'opérateur [] est particulièrement important. De nombreux champs de ressources Kubernetes sont des listes et cet opérateur vous permet de sélectionner les membres de ces listes. Il est souvent utilisé avec un caractère générique comme [*] pour sélectionner tous les éléments d'une liste.

Exemples d'application

Les possibilités d'utilisation d'un format de sortie de colonne personnalisé sont infinies, car vous pouvez afficher n'importe quel champ ou combinaison de champs de ressources dans la sortie. Voici quelques exemples d'applications, mais n'hésitez pas à les explorer vous-même et à trouver les applications qui vous conviennent.

Affichage des images de conteneurs pour les pods :

$ 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

Cette commande affiche les noms des images de conteneur pour chaque pod.

N'oubliez pas qu'un pod peut contenir plusieurs conteneurs, alors les noms des images seront affichés sur une seule ligne, séparés par des virgules.

Affichage des zones de disponibilité des nœuds :
```
$ 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
```
Cette commande est utile si votre cluster est hébergé dans un cloud public. Il affiche la zone de disponibilité pour chaque nœud.

La zone de disponibilité est un concept cloud qui limite la zone de réplication à une région géographique.

Les zones de disponibilité pour chaque nœud sont obtenues via une étiquette spéciale - failure-domain.beta.kubernetes.io/zone. Si le cluster s'exécute dans un cloud public, cette étiquette est créée automatiquement et remplie avec les noms des zones de disponibilité pour chaque nœud.

Les étiquettes ne font pas partie de la spécification des ressources Kubernetes. Vous ne trouverez donc aucune information à leur sujet dans Guide des API. Cependant, ils peuvent être vus (comme toutes les autres étiquettes) si vous demandez des informations sur les nœuds au format YAML ou JSON :
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Il s'agit d'un excellent moyen d'en apprendre davantage sur les ressources, en plus d'apprendre les spécifications des ressources.

4. Basculez facilement entre les clusters et les espaces de noms

Lorsque kubectl fait une requête à l'API Kubernetes, il lit d'abord le fichier kubeconfig pour obtenir tous les paramètres nécessaires à la connexion.

Par défaut, le fichier kubeconfig est ~/.kube/config. Généralement, ce fichier est créé ou mis à jour par une commande spéciale.

Lorsque vous travaillez avec plusieurs clusters, votre fichier kubeconfig contient les paramètres de connexion à tous ces clusters. Vous avez besoin d'un moyen d'indiquer à la commande kubectl avec quel cluster vous travaillez.

Au sein d'un cluster, vous pouvez créer plusieurs espaces de noms, un type de cluster virtuel au sein d'un cluster physique. Kubectl détermine également quel espace de noms utiliser en fonction du fichier kubeconfig. Cela signifie que vous avez également besoin d'un moyen d'indiquer à la commande kubectl avec quel espace de noms travailler.

Dans ce chapitre, nous expliquerons comment cela fonctionne et comment le faire fonctionner efficacement.

Notez que vous pouvez avoir plusieurs fichiers kubeconfig répertoriés dans la variable d'environnement KUBECONFIG. Dans ce cas, tous ces fichiers seront combinés en une seule configuration commune au moment de l'exécution. Vous pouvez également modifier le fichier kubeconfig par défaut en exécutant kubectl avec le paramètre --kubeconfig. Voir documentation officielle.

fichiers kubeconfig

Voyons ce que contient exactement le fichier kubeconfig :

Comme vous pouvez le voir, le fichier kubeconfig contient un ensemble de contextes. Le contexte se compose de trois éléments :

Cluster : URL de l'API du serveur de cluster.
Utilisateur : informations d'authentification de l'utilisateur dans le cluster.
Espace de noms : l'espace de noms utilisé lors de la connexion au cluster.

En pratique, ils utilisent souvent un contexte par cluster dans leur kubeconfig. Cependant, vous pouvez avoir plusieurs contextes par cluster, différenciés par utilisateur ou espace de noms. Cependant, cette configuration multi-contexte est rare, il existe donc généralement un mappage un-à-un entre les clusters et les contextes.

À tout moment, l’un des contextes est actuel :

Lorsque kubectl lit un fichier de configuration, il extrait toujours les informations du contexte actuel. Dans l'exemple ci-dessus, kubectl se connectera au cluster Hare.

Par conséquent, pour passer à un autre cluster, vous devez modifier le contexte actuel dans le fichier kubeconfig :

Kubectl va maintenant se connecter au cluster Fox.

Pour passer à un autre espace de noms dans le même cluster, vous devez modifier la valeur de l'élément d'espace de noms pour le contexte actuel :

Dans l'exemple ci-dessus, kubectl utilisera l'espace de noms Prod du cluster Fox (auparavant, l'espace de noms Test était défini).

Notez que kubectl fournit également des options --cluster, --user, --namespace и --context, qui vous permettent d'écraser des éléments individuels et le contexte actuel lui-même, quel que soit ce qui est défini dans kubeconfig. Regarder kubectl options.

En théorie, vous pouvez modifier manuellement les paramètres dans kubeconfig. Mais ce n'est pas pratique. Pour simplifier ces opérations, il existe différents utilitaires qui permettent de modifier automatiquement les paramètres.

Utiliser Kubectx

Un utilitaire très populaire pour basculer entre les clusters et les espaces de noms.

L'utilitaire fournit des commandes kubectx и kubens pour modifier respectivement le contexte et l'espace de noms actuels.

Comme mentionné, changer le contexte actuel signifie changer de cluster si vous n'avez qu'un seul contexte par cluster.

Voici un exemple d'exécution de ces commandes :

Essentiellement, ces commandes modifient simplement le fichier kubeconfig comme décrit ci-dessus.

à installer kubectx, suivez les instructions sur Github.

Les deux commandes prennent en charge la saisie semi-automatique des noms de contexte et d'espace de noms, ce qui élimine le besoin de les saisir complètement. Instructions pour configurer la saisie semi-automatique ici.

Une autre fonctionnalité utile kubectx il est mode interactif. Cela fonctionne en conjonction avec l'utilitaire fzf, qui doit être installé séparément. L'installation de fzf rend automatiquement le mode interactif disponible dans kubectx. De manière interactive, vous pouvez sélectionner le contexte et l'espace de noms via l'interface de recherche interactive gratuite fournie par fzf.

Utiliser des alias de shell

Vous n'avez pas besoin d'outils distincts pour modifier le contexte et l'espace de noms actuels, car kubectl fournit également des commandes pour cela. Oui, l'équipe kubectl config fournit des sous-commandes pour éditer les fichiers kubeconfig.

Voici quelques-uns d'entre eux:

kubectl config get-contexts: afficher tous les contextes;
kubectl config current-context: obtenir le contexte actuel ;
kubectl config use-context: changer le contexte actuel ;
kubectl config set-context: Changez l'élément de contexte.

Cependant, utiliser directement ces commandes n’est pas très pratique car elles sont longues. Vous pouvez créer pour eux des alias shell faciles à exécuter.

J'ai créé un ensemble d'alias basés sur ces commandes qui fournissent des fonctionnalités similaires à kubectx. Ici vous pouvez les voir en action :

Notez que les alias utilisent fzf pour fournir une interface de recherche interactive gratuite (comme le mode interactif de kubectx). Cela signifie que vous avez besoin installer fzfpour utiliser ces alias.

Voici les définitions des alias eux-mêmes :

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

Pour définir ces alias, vous devez ajouter les définitions ci-dessus à votre fichier ~/.bashrc ou ~/.zshrc et redémarrez votre shell.

Utiliser des plugins

Kubectl vous permet de charger des plugins qui s'exécutent de la même manière que les commandes de base. Vous pouvez par exemple installer le plugin kubectl-foo et l'exécuter en exécutant la commande kubectl foo.

Il serait pratique de modifier le contexte et l'espace de noms de cette manière, par exemple en exécutant kubectl ctx changer de contexte et kubectl ns pour changer l'espace de noms.

J'ai écrit deux plugins qui font cela :

Le travail des plugins est basé sur les alias de la section précédente.

Voici comment ils fonctionnent :

Notez que les plugins utilisent fzf pour fournir une interface de recherche gratuite et interactive (comme le mode interactif de kubectx). Cela signifie que vous avez besoin installer fzfpour utiliser ces alias.

Pour installer des plugins, vous devez télécharger des scripts shell nommés kubectl-ctx и Kubectl-NS dans n'importe quel répertoire de votre variable PATH et rendez-les exécutables avec par exemple. chmod +x. Immédiatement après, vous pourrez utiliser kubectl ctx и kubectl ns.

5. Réduisez les entrées avec les alias automatiques

Les alias Shell sont un bon moyen d'accélérer la saisie. Projet alias-kubectl contient environ 800 raccourcis pour les commandes kubectl de base.

Vous vous demandez peut-être : comment mémoriser 800 alias ? Mais vous n'avez pas besoin de tous vous souvenir, car ils sont construits selon un schéma simple, présenté ci-dessous :

Par exemple:

kgpooyaml - kubectl récupère les dosettes oyaml
ksysgsvcw — kubectl -n kube-system obtient svc w
ksysrmcm -kubectl -n système kube rm cm
kgdepallsl - Kubectl obtient le déploiement de tous les SL

Comme vous pouvez le constater, les alias sont constitués de composants dont chacun représente un élément spécifique de la commande kubectl. Chaque alias peut avoir un composant pour la commande, l'opération et la ressource de base, ainsi que plusieurs composants pour les paramètres. Il vous suffit de « remplir » ces composants de gauche à droite selon le schéma ci-dessus.

Le schéma détaillé actuel se trouve à GitHub. Vous y trouverez également liste complète des pseudonymes.

Par exemple, l'alias kgpooyamlall équivaut à la commande kubectl get pods -o yaml --all-namespaces.

L'ordre relatif des options n'a pas d'importance : commande kgpooyamlall est équivalent à la commande kgpoalloyaml.

Vous n'êtes pas obligé d'utiliser tous les composants comme alias. Par exemple k, kg, klo, ksys, kgpo peut également être utilisé. De plus, vous pouvez combiner des alias et des commandes ou options normales sur la ligne de commande :

Par exemple:

Au lieu de kubectl proxy tu peux écrire k proxy.
Au lieu de kubectl get roles tu peux écrire kg roles (il n'existe actuellement aucun alias pour la ressource Rôles).
Pour obtenir des données pour un pod spécifique, vous pouvez utiliser la commande kgpo my-pod — kubectl get pod my-pod.

Veuillez noter que certains alias nécessitent un argument de ligne de commande. Par exemple, alias kgpol moyen kubectl get pods -l. Option -l nécessite un argument - une spécification d'étiquette. Si vous utilisez un alias, cela ressemblera à kgpol app=ui.

Certains alias nécessitant des arguments, les alias a, f et l doivent être utilisés en dernier.

En général, une fois que vous maîtrisez ce schéma, vous pouvez intuitivement dériver des alias à partir des commandes que vous souhaitez exécuter et gagner beaucoup de temps de frappe.

Installation

Pour installer kubectl-aliases, vous devez télécharger le fichier .kubectl_aliases depuis GitHub et incluez-le dans le fichier ~/.bashrc ou ~/.zshrc:

source ~/.kubectl_aliases

Saisie semi-automatique

Comme nous l'avons déjà dit, vous ajoutez souvent des mots supplémentaires à un alias sur la ligne de commande. Par exemple:

$ kgpooyaml test-pod-d4b77b989

Si vous utilisez la saisie semi-automatique de la commande kubectl, vous avez probablement utilisé la saisie semi-automatique pour des éléments tels que les noms de ressources. Mais est-ce possible lorsque des alias sont utilisés ?

C'est une question très importante car si la saisie semi-automatique ne fonctionne pas, vous perdrez certains des avantages des alias.

La réponse dépend du shell que vous utilisez :

Pour Zsh, la complétion d'alias fonctionne immédiatement.
Pour Bash, malheureusement, certains travaux sont nécessaires pour que la saisie semi-automatique fonctionne.

Activation de la saisie semi-automatique pour les alias dans Bash

Le problème avec Bash est qu'il essaie de compléter (chaque fois que vous appuyez sur Tab) l'alias, et non la commande à laquelle l'alias fait référence (comme le fait Zsh, par exemple). Puisque vous ne disposez pas de scripts de saisie semi-automatique pour les 800 alias, la saisie semi-automatique ne fonctionne pas.

Projet alias-complet fournit une solution générale à ce problème. Il se connecte au mécanisme de complétion pour les alias, étend en interne l'alias en une commande et renvoie les options de complétion pour la commande terminée. Cela signifie que le remplissage d'un alias se comporte exactement de la même manière que celui d'une commande complète.

Dans ce qui suit, je vais d'abord expliquer comment installer complete-alias, puis comment le configurer pour activer la complétion pour tous les alias kubectl.

Installation de l'alias complet

Tout d'abord, l'alias complet dépend de bash-achèvement. Par conséquent, avant d'installer complete-alias, vous devez vous assurer que bash-completion est installé. Les instructions d'installation ont été fournies précédemment pour Linux et MacOS.

Remarque importante pour les utilisateurs de MacOS: Comme le script d'auto-complétion kubectl, complete-alias ne fonctionne pas avec Bash 3.2, qui est la valeur par défaut sur MacOS. En particulier, l'alias complet dépend de bash-completion v2 (brew install bash-completion@2), qui nécessite au moins Bash 4.1. Cela signifie que pour utiliser l'alias complet sur MacOS, vous devez installer une version plus récente de Bash.

Vous devez télécharger le script bash_completion.sh de Dépôt GitHub et incluez-le dans votre dossier ~/.bashrc:

source ~/bash_completion.sh

Après avoir redémarré le shell, complete-alias sera entièrement installé.

Activation de la saisie semi-automatique pour les alias kubectl

Techniquement, l'alias complet fournit une fonction wrapper _complete_alias. Cette fonction vérifie l'alias et renvoie des astuces d'achèvement pour la commande alias.

Pour associer une fonction à un alias spécifique, vous devez utiliser le mécanisme Bash intégré complet, à installer _complete_alias comme fonction de complétion d'alias.

A titre d'exemple, prenons l'alias k, qui représente la commande kubectl. à installer _complete_alias En complément de cet alias, vous devez exécuter la commande suivante :

$ complete -F _complete_alias k

Le résultat est que chaque fois que vous complétez automatiquement un alias k, la fonction est appelée _complete_alias, qui vérifie l'alias et renvoie des astuces d'achèvement pour la commande kubectl.

Comme deuxième exemple, prenons l'alias kgQui veut dire kubectl get:

$ complete -F _complete_alias kg

Tout comme dans l'exemple précédent, lorsque vous complétez automatiquement kg, vous obtenez les mêmes indices d'achèvement que vous obtiendriez pour kubectl get.

Notez que vous pouvez utiliser complete-alias pour n’importe quel alias sur votre système.

Par conséquent, pour activer la saisie semi-automatique pour tous les alias kubectl, vous devez exécuter la commande ci-dessus pour chacun d'eux. L'extrait suivant fait exactement cela, à condition que vous ayez défini les alias kubectl sur ~/.kubectl-aliases:

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

Ce morceau de code doit être placé dans votre ~/.bashrc, redémarrez le shell de commande et la saisie semi-automatique deviendra disponible pour les 800 alias kubectl.

6. Extension de Kubectl avec des plugins

Depuis version 1.12, kubectl prend en charge mécanisme de plugin, qui vous permettent d'étendre ses fonctions avec des commandes supplémentaires.

Si vous connaissez Mécanismes du plugin Git, alors les plugins kubectl sont construits sur le même principe.

Dans ce chapitre, nous verrons comment installer des plugins, où les trouver et comment créer vos propres plugins.

Installation de plugins

Les plugins Kubectl sont distribués sous forme de simples fichiers exécutables portant le nom suivant : kubectl-x. Préfixe kubectl- est requis, suivi d'une nouvelle sous-commande kubectl qui vous permet d'appeler le plugin.

Par exemple, le plugin hello sera distribué sous forme de fichier appelé kubectl-hello.

Pour installer le plugin, vous devez copier le fichier kubectl-x vers n'importe quel répertoire de votre PATH et rendez-le exécutable, par exemple avec chmod +x. Immédiatement après, vous pouvez appeler le plugin avec kubectl x.

Vous pouvez utiliser la commande suivante pour répertorier tous les plugins actuellement installés sur votre système :

$ kubectl plugin list

Cette commande affichera également des avertissements si vous avez plusieurs plugins portant le même nom ou s'il existe un fichier de plugins qui n'est pas exécutable.

Trouver et installer des plugins à l'aide de Krew

Les plugins Kubectl peuvent être partagés ou réutilisés comme des progiciels. Mais où pouvez-vous trouver des plugins que d’autres ont partagés ?

Projet Krew vise à fournir une solution unifiée pour le partage, la recherche, l'installation et la gestion des plugins kubectl. Le projet s'appelle un "gestionnaire de paquets pour les plugins kubectl" (Krew est similaire à Brasser).

Krew est une liste de plugins Kubectl que vous pouvez sélectionner et installer. En même temps, Krew est également un plugin pour kubectl.

Cela signifie que l'installation de Krew fonctionne essentiellement comme l'installation de n'importe quel autre plugin Kubectl. Vous pouvez trouver des instructions détaillées sur Page GitHub.

Les commandes Krew les plus importantes sont :

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

Veuillez noter que l'installation de plugins à l'aide de Krew n'interfère pas avec l'installation de plugins en utilisant la méthode standard décrite ci-dessus.

Veuillez noter que la commande kubectl krew list affiche uniquement les plugins installés à l'aide de Krew, alors que la commande kubectl plugin list répertorie tous les plugins, c'est-à-dire ceux installés à l'aide de Krew et ceux installés par d'autres méthodes.

Trouver des plugins ailleurs

Krew est un jeune projet, actuellement en phase de liste des seulement une trentaine de plugins. Si vous ne trouvez pas ce dont vous avez besoin, vous pouvez trouver des plugins ailleurs, comme GitHub.

Je recommande de regarder la section GitHub plugins Kubectl. Vous y trouverez des dizaines de plugins disponibles qui valent le détour.

Écrire vos propres plugins

vous pouvez vous-même créer des plugins - Ce n'est pas difficile. Vous devez créer un exécutable qui fait ce dont vous avez besoin, nommez-le comme kubectl-x et installez-le comme décrit ci-dessus.

Le fichier peut être un script bash, un script python ou une application GO compilée – cela n'a pas d'importance. La seule condition est qu’il puisse être exécuté directement dans le système d’exploitation.

Créons maintenant un exemple de plugin. Dans la section précédente, vous avez utilisé la commande kubectl pour répertorier les conteneurs de chaque pod. Il est facile de transformer cette commande en un plugin que vous pouvez appeler avec, par exemple. kubectl img.

Créer un fichier kubectl-img le contenu suivant:

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

Maintenant, rendez le fichier exécutable avec chmod +x kubectl-img et déplacez-le vers n’importe quel répertoire de votre PATH. Immédiatement après, vous pouvez utiliser le plugin kubectl img.

Comme mentionné, les plugins kubectl peuvent être écrits dans n'importe quel langage de programmation ou de script. Si vous utilisez des scripts shell, l'avantage de pouvoir appeler facilement kubectl depuis le plugin. Cependant, vous pouvez écrire des plugins plus complexes dans de vrais langages de programmation en utilisant Bibliothèque cliente Kubernetes. Si vous utilisez Go, vous pouvez également utiliser bibliothèque d'exécution cli, qui existe spécifiquement pour écrire des plugins kubectl.

Comment partager vos plugins

Si vous pensez que vos plugins pourraient être utiles à d’autres, n’hésitez pas à les partager sur GitHub. Assurez-vous de les ajouter au sujet plugins Kubectl.

Vous pouvez également demander que votre plugin soit ajouté à Liste des Krews. Les instructions sur la façon de procéder se trouvent dans Dépôts GitHub.

Achèvement de la commande

Les plugins ne prennent actuellement pas en charge la saisie semi-automatique. Autrement dit, vous devez saisir le nom complet du plugin et les noms complets des arguments.

Le référentiel GitHub kubectl pour cette fonction a demande ouverte. Il est donc possible que cette fonctionnalité soit implémentée dans le futur.

Bonne chance!

Quoi d'autre à lire sur le sujet:

Source: habr.com

Comment utiliser Kubectl plus efficacement : un guide détaillé