
Si vous travaillez avec Kubernetes, il est probable que kubectl soit l'un de vos outils les plus utilisés. Chaque fois que vous passez beaucoup de temps à travailler avec un outil particulier, il vaut la peine de bien l'étudier et d'apprendre à l'utiliser efficacement.
Commande J'ai traduit un article de Daniel Weibel, dans lequel vous trouverez des conseils et des astuces pour travailler efficacement avec kubectl. Il vous aidera également à mieux comprendre le fonctionnement de 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 d'apprendre à utiliser kubectl plus efficacement, il est nécessaire de comprendre les bases de ce qu'il est et de son fonctionnement.
Du point de vue de l'utilisateur, kubectl est un tableau de bord qui permet d'effectuer des opérations Kubernetes.
D'un point de vue technique, kubectl est un client Kubernetes API.
L'API Kubernetes est une API HTTP REST. Cette API est l'interface utilisateur de Kubernetes, grâce à laquelle il est complètement contrôlé. Cela signifie que chaque opération Kubernetes est représentée comme un endpoint API et peut être exécutée par une requête HTTP à cet endpoint.
Par conséquent, la tâche principale de kubectl est d'exécuter 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 toutes les opérations Kubernetes sont des opérations CRUD.
Vous contrôlez complètement Kubernetes en gérant ces ressources, et Kubernetes détermine quoi faire en fonction de l'état actuel des ressources. Pour cette raison, le lien vers l'API Kubernetes est organisé sous forme de liste de types de ressources avec les opérations qui leur sont associées.
Examinons un exemple.
Supposons que vous souhaitiez créer une ressource ReplicaSet. Pour ce faire, vous décrivez le ReplicaSet dans un fichier nommé replicaset.yaml, puis vous exécutez la commande :
$ kubectl create -f replicaset.yamlCela créerait une ressource ReplicaSet. Mais que se passe-t-il en coulisses ?
Dans Kubernetes, il existe une opération de création de ReplicaSet. Comme toute autre opération, elle est fournie en tant qu'endpoint API. Le endpoint API spécifique pour cette opération est le suivant :
POST /apis/apps/v1/namespaces/{namespace}/replicasetsTous les endpoints API de toutes les opérations Kubernetes peuvent être trouvés dans la y compris le ). Pour effectuer la requête réelle vers le point de terminaison, il faut d'abord ajouter l'URL du serveur API aux chemins des points de terminaison qui sont listés dans le guide API.
Ainsi, lorsque vous exécutez la commande ci-dessus, kubectl envoie une requête HTTP POST à ce point de terminaison API mentionné. La définition du ReplicaSet que vous avez spécifiée dans le fichier replicaset.yaml, est transmise dans le corps de la requête.
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 API correspondants de Kubernetes.
Notez qu'il est possible de gérer complètement Kubernetes avec un utilitaire tel que curl, en envoyant manuellement des requêtes HTTP à l'API Kubernetes. Kubectl simplifie simplement l'utilisation de l'API Kubernetes.
C'est les bases de ce qu'est kubectl et comment il fonctionne. Mais il y a encore quelque chose à propos de l'API Kubernetes que chaque utilisateur de kubectl doit savoir. Plongeons brièvement dans les coulisses de Kubernetes.
Les coulisses de Kubernetes
Kubernetes est composé d'un ensemble de composants indépendants qui s'exécutent comme des processus distincts sur les nœuds du cluster. Certains composants fonctionnent sur les nœuds maîtres, d'autres sur les nœuds de travail, chaque composant exécutant sa tâche spécifique.
Voici les composants les plus importants sur les nœuds maîtres :
- Stockage — conserve les définitions des ressources ().
- Serveur API — fournit l'API et gère le stockage.
- Gestionnaire de contrôleurs — garantit que les états des ressources correspondent aux spécifications.
- Planificateur — planifie les pods sur les nœuds de travail.
Et voici un composant très important sur les nœuds de travail :
- Kubelet — gère le démarrage des conteneurs sur le nœud de travail.
Pour comprendre comment ces composants fonctionnent ensemble, prenons un exemple.
Supposons que vous venez d'exécuter kubectl create -f replicaset.yaml, après quoi kubectl a fait une requête HTTP POST à (en transmettant la définition de la ressource ReplicaSet).
Que se passe-t-il dans le cluster ?
- Après l'exécution de
kubectl create -f replicaset.yamlLe serveur API sauvegarde la définition de votre 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 du ReplicaSet (selon le modèle de pod dans la définition du ReplicaSet) et les sauvegarde dans le stockage :

- Le planificateur se déclenche, surveillant les pods qui n'ont pas encore été assignés à un nœud de travail :

- Le planificateur sélectionne un nœud de travail approprié pour chaque pod et ajoute cette information à la définition du pod dans le stockage :

- Sur le nœud de travail auquel le pod est assigné, Kubelet démarre et surveille les pods assignés à ce nœud :

- Kubelet lit la définition du pod depuis le stockage et donne des instructions à l'environnement d'exécution de conteneurs, comme Docker, pour démarrer les conteneurs sur le nœud :

Voici une version textuelle de cette description.
Une requête API à l'endpoint de création de ReplicaSet est traitée par le serveur API. Le serveur API authentifie la requête et enregistre la définition de la ressource ReplicaSet dans le stockage.
Cet événement déclenche 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 stockage et reçoit une notification lorsque cela se produit.
La tâche du contrôleur ReplicaSet est de s'assurer qu'il y a le bon nombre de pods de réplique ReplicaSet. Dans notre exemple, il n'y a pas encore de pods, donc le contrôleur ReplicaSet crée ces définitions de pods (conformément au modèle de pod dans la définition de ReplicaSet) et les enregistre dans le stockage.
La création de nouveaux pods déclenche le planificateur, qui surveille les définitions des pods qui n'ont pas encore été programmés pour des nœuds de travail. Le planificateur sélectionne un nœud de travail approprié pour chaque pod et met à jour les définitions des pods dans le stockage.
À ce stade, notez que nulle part dans le cluster le code de la charge de travail n'a été exécuté. Tout ce qui a été fait jusqu'à présent, — c'est de créer et de mettre à jour les ressources dans le stockage sur le nœud principal.
Le dernier événement déclenche Kubelet, qui surveille les pods planifiés pour leurs nœuds de travail. Kubelet du nœud de travail pour lequel vos pods ReplicaSet sont installés doit demander à l'environnement d'exécution de conteneurs, comme Docker, de charger les images de conteneurs requises et de les démarrer.
À ce stade, enfin, votre application ReplicaSet est en cours d'exécution !
Le 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 changements des ressources dans le stockage et modifient les informations sur les ressources dans le stockage.
Bien sûr, ces composants n'interagissent pas directement avec le stockage, mais uniquement via l'API Kubernetes.
Examinons les exemples suivants:
- Le contrôleur ReplicaSet utilise un point de terminaison API c avec le paramètre
regarderpour surveiller les modifications des ressources ReplicaSet. - Le contrôleur ReplicaSet utilise un point de terminaison API (créer un pod) pour créer des pods.
- Le planificateur utilise un point de terminaison API (modifier un pod) pour mettre à jour des pods avec des informations sur le nœud de travail sélectionné.
Comme vous le voyez, c'est la même API à laquelle kubectl accède. Utiliser la même API pour interagir avec 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 :
- Le stockage conserve l'état, c'est-à-dire les ressources Kubernetes.
- Le serveur API fournit une interface au stockage sous la forme de l'API Kubernetes.
- Tous les autres composants et utilisateurs de Kubernetes lisent, surveillent et manipulent l'état (ressources) de Kubernetes via l'API.
Comprendre ces concepts aidera à mieux utiliser kubectl et à en tirer le meilleur parti.
Examinons maintenant quelques conseils et astuces spécifiques qui peuvent améliorer l'efficacité de l'utilisation de kubectl.
1. Accélération de la saisie grâce à la complétion des commandes
L'une des astuces les plus utiles, mais souvent négligées, pour augmenter l'efficacité de l'utilisation de kubectl est la complétion des commandes.
La complétion des commandes permet de remplir automatiquement certaines parties des commandes kubectl en appuyant sur la touche Tab. Cela fonctionne pour les sous-commandes, les options et les arguments, y compris les noms de ressources complexes.
Voyez comment fonctionne la complétion des commandes kubectl :

La complétion des commandes fonctionne pour les shells Bash et Zsh.
contient des instructions détaillées sur la configuration de l'autocomplétion, mais ci-dessous, nous fournirons un bref extrait.
Comment fonctionne la complétion des commandes
La complétion des commandes est une fonction de shell qui fonctionne grâce à un script de complétion. Le script de complétion est un script shell qui définit le comportement de la complétion pour une commande spécifique.
Kubectl génère et affiche automatiquement des scripts de complétion pour Bash et Zsh à l'aide des commandes suivantes :
$ kubectl completion bashOu :
$ kubectl completion zshThéoriquement, il suffit de connecter la sortie de ces commandes dans le shell de commande correspondant pour que kubectl puisse compléter les commandes.
En pratique, la méthode de connexion diffère pour Bash (y compris les différences entre Linux et MacOS) et Zsh. Nous allons examiner toutes ces options ci-dessous.
Bash sous Linux
Le script d'extension pour Bash dépend du paquet bash-completion, donc il est nécessaire de l'installer d'abord :
$ sudo apt-get install bash-completionOu :
$ yum install bash-completionVous pouvez tester si le paquet est installé avec la commande suivante :
$ type _init_completion Si le code de la fonction de shell s'affiche, alors bash-completion est correctement installé. Si la commande renvoie une erreur 'Non trouvé', vous devez ajouter la ligne suivante à votre fichier ~ / .bashrc:
$ source /usr/share/bash-completion/bash_completion Ajouter cette ligne au fichier ~ / .bashrc ou non, dépend du gestionnaire de paquets que vous avez utilisé pour installer bash-completion. Pour APT, c'est nécessaire, pour YUM, ce n'est pas le cas.
Après l'installation de bash-completion, il faut tout configurer pour que le script d'extension kubectl soit inclus dans toutes les sessions de shell.
Une des façons de le faire est d'ajouter la ligne suivante au fichier ~ / .bashrc:
source <(kubectl completion bash) Une autre façon est d'ajouter le script d'extension kubectl dans le 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 d'extension dans le répertoire /etc/bash_completion.d sont automatiquement inclus dans bash-completion.
Les deux options sont également applicables.
Après le redémarrage du shell, l'autocomplétion des commandes kubectl fonctionnera.
Bash sous MacOS
Sur MacOS, la configuration est un peu plus compliquée. En effet, par défaut, MacOS utilise Bash version 3.2, tandis que le script d'autocomplétion kubectl nécessite Bash version 4.1 ou supérieure et ne fonctionne pas avec Bash 3.2.
L'utilisation d'une version obsolète de Bash sur MacOS est liée à des questions de licence. Bash version 4 est distribué sous la licence GPLv3, qui n'est pas prise en charge par Apple.
Pour configurer l'autocomplétion kubectl sur MacOS, vous devez installer une version plus récente de Bash. Vous pouvez également installer la version mise à jour de Bash comme shell par défaut, ce qui vous évitera de nombreux problèmes à l'avenir. Ce n'est pas compliqué, les détails sont fournis dans l'article «».
Avant de continuer, assurez-vous que vous utilisez la dernière version de Bash (vérifiez la sortie bash --version).
Le script d'autocomplétion dans Bash dépend du projet , donc il faut d'abord l'installer.
Vous pouvez installer bash-completion via :
$ brew install bash-completion@2 Ici @2 indique bash-completion version 2. L'auto-complétion de kubectl nécessite bash-completion v2, et bash-completion v2 nécessite au minimum la version 4.1 de Bash.
Sortie de la commande brew-install contient une section Caveats, qui indique qu'il faut ajouter 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 non pas dans ~/ .bash_profile, et dans ~\/bashrc. Dans ce cas, l'auto-complétion sera disponible non seulement dans le shell principal, mais aussi dans les shells enfants.
Après avoir redémarré le shell, vous pouvez vérifier la validité de l'installation en utilisant la commande suivante :
$ type _init_completionSi vous voyez une fonction shell dans la sortie, tout est configuré correctement.
Vous devez maintenant faire en sorte que l'auto-complétion de kubectl soit activée dans toutes les sessions.
L'une des façons est d'ajouter la ligne suivante à votre ~\/bashrc:
source <(kubectl completion bash) Une autre méthode consiste à ajouter le script d'auto-complétion dans le dossier /usr/local/etc/bash_completion.d:
$ kubectl completion bash
>/usr/local/etc/bash_completion.d/kubectlCette méthode fonctionnera uniquement si vous avez installé bash-completion via Homebrew. Dans ce cas, bash-completion chargera tous les scripts depuis ce répertoire.
Si vous avez installé , vous n'avez pas besoin de faire l'étape précédente, car le script d'auto-complétion sera automatiquement placé dans le dossier /usr/local/etc/bash_completion.d lors de l'installation. Dans ce cas, l'auto-complétion de kubectl commencera à fonctionner dès que vous aurez installé bash-completion.
En fin de compte, toutes ces options sont équivalentes.
Zsh
Les scripts d'auto-complétion pour Zsh ne nécessitent aucune dépendance. Tout ce que vous devez faire est de les activer au chargement du shell.
Vous pouvez le faire en ajoutant la ligne à votre ~/.zshrc fichier :
source <(kubectl completion zsh) Si vous avez reçu 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 ajoutant au début de votre fichier ~/.zshrc ce qui suit :
autoload -Uz compinit
compinit2. Aperçu rapide des spécifications des ressources
Lorsque vous créez des définitions de ressources YAML, vous devez connaître les champs et leurs valeurs pour ces ressources. L'un des endroits pour rechercher cette information est dans le guide API, qui contient les spécifications complètes de toutes les ressources.
Cependant, passer au navigateur Web chaque fois que vous devez chercher quelque chose est peu pratique. C'est pourquoi kubectl fournit 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]...L'équipe va afficher la spécification de la ressource ou du champ demandé. Les informations affichées sont identiques à celles contenues dans le guide API.
Par défaut kubectl explain affiche uniquement le premier niveau d'imbrication des champs.
Voir à quoi cela ressemble .
Vous pouvez afficher tout l'arbre en ajoutant l'option --recursive:
$ kubectl explain deployment.spec --recursiveSi 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 des ressources au pluriel, par exemple, déploiements au lieu de déploiement. Elle affiche également un nom abrégé, par exemple deploy, pour les ressources pour lesquelles cela existe. Ne vous inquiétez pas de ces différences. Tous ces noms sont équivalents pour kubectl. Cela signifie que vous pouvez utiliser n'importe lequel d'eux pour kubectl explain.
Toutes les commandes suivantes sont équivalentes :
$ kubectl explain deployments.spec
# ou
$ kubectl explain deployment.spec
# ou
$ kubectl explain deploy.spec3. Utilisez un format de sortie de colonnes personnalisé
Par défaut, le format de sortie de la commande kubectl get:
$ kubectl get pods
NOM PRÊT ÉTAT REDÉMARRAGES ÂGE
engine-544b6b6467-22qr6 1/1 En cours 0 78j
engine-544b6b6467-lw5t8 1/1 En cours 0 78j
engine-544b6b6467-tvgmg 1/1 En cours 0 78j
web-ui-6db964458-8pdw4 1/1 En cours 0 78jCe format est pratique, mais il contient un nombre limité d'informations. Comparé au format complet de définition de la ressource, seules quelques champs sont affichés ici.
Dans ce cas, vous pouvez utiliser un format de sortie de colonnes personnalisé. Il vous permet de définir quelles données afficher. Vous pouvez afficher n'importe quel champ de la ressource dans une colonne séparée.
L'utilisation d'un format personnalisé s'exprime avec les options :
-o custom-columns=:[,:]... Vous pouvez définir chaque colonne de sortie par une paire , où — le nom de la colonne, et <jsonpath> — l'expression qui définit le champ de la ressource.
Voyons un exemple simple :
$ kubectl get pods -o custom-columns='NAME:metadata.name'
NOM
engine-544b6b6467-22qr6
engine-544b6b6467-lw5t8
engine-544b6b6467-tvgmg
web-ui-6db964458-8pdw4La sortie contient une colonne avec les noms des pods.
L'expression dans l'option choisit les noms des pods à partir du champ metadata.name. C'est parce que le nom du pod est défini dans le champ enfant name du champ métadonnées dans la description de la ressource de pod. Vous pouvez en savoir plus dans le ou entrer la commande kubectl explain pod.metadata.name.
Supposons maintenant que vous souhaitiez ajouter une colonne supplémentaire à la sortie, par exemple, en montrant le nœud sur lequel chaque pod fonctionne. Pour cela, vous pouvez simplement ajouter la spécification de colonne appropriée dans l'option des 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 à partir de spec.nodeName — lorsque le pod est assigné à un nœud, son nom est inscrit dans le champ spec.nodeName de la spécification des ressources du pod. Vous pouvez trouver plus d'informations dans la sortie kubectl explain pod.spec.nodeName.
Notez que les champs des ressources Kubernetes sont sensibles à la casse.
Vous pouvez visualiser n'importe quel champ de la ressource sous forme de colonne. Il suffit de consulter la spécification de la ressource et d'essayer avec n'importe quel champ que vous souhaitez.
Mais d'abord, examinons de plus près les expressions de sélection de champs.
Expressions JSONPath
Les expressions pour sélectionner des champs de ressources sont basées sur .
JSONPath est un langage pour extraire des données à partir de documents JSON. Sélectionner un seul champ est le cas d'utilisation le plus simple de JSONPath. Il possède beaucoup , y compris des sélecteurs, des filtres, etc.
Kubectl explain prend en charge un nombre limité de fonctionnalités JSONPath. Voici les fonctionnalités et exemples d'utilisation :
# Выбрать все элементы списка
$ 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 [] revêt une importance particulière. De nombreux champs des ressources Kubernetes sont des listes, et cet opérateur permet de sélectionner des éléments de ces listes. Il est souvent utilisé avec un joker tel que [*] pour sélectionner tous les éléments de la liste.
Exemples d'application
Les possibilités d'utilisation d'un format de sortie de colonnes personnalisé sont illimitées, car vous pouvez afficher n'importe quel champ ou combinaison de champs de la ressource dans la sortie. Voici quelques exemples d'applications, mais n'hésitez pas à les explorer vous-même et à trouver des utilisations utiles.
- Affichage des images des 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 wordpressCette commande affiche les noms des images des conteneurs pour chaque pod.
N'oubliez pas qu'un pod peut contenir plusieurs conteneurs, et donc 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-1bCette commande est utile si votre cluster est hébergé dans un cloud public. Elle affiche la zone de disponibilité pour chaque nœud.
Une 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 — . Si le cluster est exécuté 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, donc vous ne trouverez pas d'informations les concernant dans . Cependant, vous pouvez les voir (comme n'importe quelle autre étiquette) en demandant des informations sur les nœuds au format YAML ou JSON :
$ kubectl get nodes -o yaml # ou $ kubectl get nodes -o jsonC'est un excellent moyen d'en apprendre davantage sur les ressources, en plus d'étudier les spécifications des ressources.
4. Changement facile entre les clusters et les espaces de noms
Lorsque kubectl effectue 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. En général, 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 pour tous ces clusters. Vous avez besoin d'une manière d'indiquer à la commande kubectl avec quel cluster vous travaillez.
À l'intérieur du cluster, vous pouvez créer plusieurs espaces de noms — un type de cluster virtuel à l'intérieur d'un cluster physique. Kubectl détermine quel espace de noms utiliser également à partir des données du fichier kubeconfig. Cela signifie que vous avez également besoin d'une manière d'indiquer à la commande kubectl avec quel espace de noms travailler.
Dans ce chapitre, nous expliquerons comment cela fonctionne et comment y parvenir efficacement.
Veuillez noter que vous pouvez avoir plusieurs fichiers kubeconfig listés dans la variable d'environnement KUBECONFIG. Dans ce cas, tous ces fichiers seront combinés en une seule configuration lors de l'exécution. Vous pouvez également modifier le fichier kubeconfig par défaut en lançant kubectl avec le paramètre --kubeconfig. Voir .
Fichiers kubeconfig
Voyons ce que le fichier kubeconfig contient exactement :

Comme vous pouvez le voir, le fichier kubeconfig contient un ensemble de contextes. Un contexte se compose de trois éléments :
- Cluster — URL de l'API du serveur de cluster.
- User — informations d'identification de l'utilisateur pour s'authentifier dans le cluster.
- Namespace — l'espace de noms utilisé lors de la connexion au cluster.
En pratique, on utilise souvent un seul contexte par cluster dans son fichier kubeconfig. Cependant, vous pouvez avoir plusieurs contextes pour un même cluster, différenciés par l'utilisateur ou l'espace de noms. Cette configuration avec plusieurs contextes est néanmoins rare, si bien qu'il existe généralement une correspondance univoque entre les clusters et les contextes.
À tout moment, l'un des contextes est actif :

Lorsque kubectl lit le fichier de configuration, il prend toujours les informations du contexte actif. Dans l'exemple ci-dessus, kubectl se connectera au cluster Hare.
Par conséquent, pour basculer vers un autre cluster, vous devez changer le contexte actif dans le fichier kubeconfig :

Désormais, kubectl se connectera au cluster Fox.
Pour changer d'espace de noms dans le même cluster, vous devez modifier la valeur de l'élément namespace pour le contexte actif :

Dans l'exemple ci-dessus, kubectl utilisera l'espace de noms Prod du cluster Fox (l'espace de noms Test a été configuré auparavant).
Notez que kubectl fournit également les paramètres --cluster, --user, --namespace et --context, qui permettent de remplacer des éléments individuels et le contexte actif lui-même, indépendamment de ce qui est défini dans le fichier kubeconfig. Voir options kubectl.
Théoriquement, vous pouvez modifier manuellement les paramètres dans le fichier kubeconfig. Mais cela est peu pratique. Pour simplifier ces opérations, il existe diverses utilitaires qui permettent de modifier les paramètres automatiquement.
Utilisez kubectx
Un utilitaire très populaire pour passer d'un cluster à un autre et changer d'espaces de noms.
L'outil propose les commandes kubectx et kubens pour changer le contexte actuel et l'espace de noms en conséquence.
Comme mentionné précédemment, changer le contexte actuel signifie changer de cluster, si vous n'avez qu'un seul contexte par cluster.
Voici un exemple de l'exécution de ces commandes :

Essentiellement, ces commandes modifient simplement le fichier kubeconfig, comme décrit ci-dessus.
Pour installer kubectx, suivez les instructions sur
Les deux commandes prennent en charge l'auto-complétion des noms de contextes et d'espaces de noms, ce qui permet de ne pas les saisir entièrement. Les instructions pour configurer l'auto-complétion .
Une autre fonction utile kubectx est . Il fonctionne en conjonction avec l'outil , qui doit être installé séparément. L'installation de fzf rend automatiquement le mode interactif disponible dans kubectx. En mode interactif, vous pouvez choisir le contexte et l'espace de noms via une interface interactive de recherche libre fournie par fzf.
Utilisation des alias de la ligne de commande
Vous n'avez pas besoin d'outils séparés pour changer le contexte actuel et l'espace de noms, car kubectl fournit également des commandes pour cela. Ainsi, la commande kubectl config fournit des sous-commandes pour éditer des 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: modifier l'élément du contexte.
Cependant, utiliser ces commandes directement n'est pas très pratique, car elles sont longues. Vous pouvez créer des alias pour la ligne de commande qui sont faciles à exécuter.
J'ai créé un ensemble d'alias basé sur ces commandes qui fournissent une fonctionnalité similaire à kubectx. Vous pouvez voir leur fonctionnement ici :

Notez que les alias utilisent fzf pour fournir une interface interactive de recherche libre (comme dans le mode interactif de kubectx). Cela signifie que vous devez , pour utiliser ces alias.
Voici les définitions des alias :
# Получить текущий контекст
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 installer ces alias, vous devez ajouter les définitions ci-dessus dans votre fichier ~\/bashrc ou ~/.zshrc et recharger votre shell.
Utilisation des plugins
Kubectl permet de charger des plugins qui s'exécutent de la même manière que les commandes principales. Par exemple, vous pouvez installer le plugin kubectl-foo et l'exécuter en utilisant la commande kubectl foo.
Il serait pratique de changer le contexte et l'espace de noms de cette manière, par exemple, en exécutant kubectl ctx pour changer le contexte et kubectl ns pour changer l'espace de noms.
J'ai écrit deux plugins qui le font :
Le fonctionnement des plugins est basé sur des alias du chapitre précédent.
Voici comment ils fonctionnent :

Notez que les plugins utilisent fzf pour fournir une interface interactive de recherche libre (comme en mode interactif kubectx). Cela signifie que vous devez, pour utiliser ces alias.
Pour installer les plugins, téléchargez les scripts shell nommés et dans n'importe quel répertoire de votre variable PATH et rendez-les exécutables, par exemple, avec chmod +x. Après cela, vous pourrez utiliser kubectl ctx et kubectl ns.
5. Raccourci de saisie avec auto-aliases
Les alias de commande shell sont une bonne opportunité pour accélérer la saisie. Le projet contient environ 800 raccourcis pour les commandes principales de kubectl.
Vous vous demandez peut-être comment se souvenir de 800 alias ? Mais il n'est pas nécessaire de tous les mémoriser, car ils sont construits selon un schéma simple, comme indiqué ci-dessous :

Par exemple :
- kgpooyaml — kubectl get pods oyaml
- ksysgsvcw — kubectl -n kube-system get svc w
- ksysrmcm — kubectl -n kube-system rm cm
- kgdepallsl — kubectl get deployment all sl
Comme vous pouvez le voir, les alias sont constitués de composants, chacun représentant un élément spécifique de la commande kubectl. Chaque alias peut avoir un composant pour la commande de base, l'opération et la ressource, et plusieurs composants pour les paramètres. Vous remplissez simplement ces composants de gauche à droite selon le schéma ci-dessus.
Le schéma détaillé actuel se trouve sur . Vous y trouverez également.
Par exemple, l'alias kgpooyamlall équivaut à la commande kubectl get pods -o yaml --all-namespaces.
L'ordre relatif des options n'est pas important : la commande kgpooyamlall est équivalente à la commande kgpoalloyaml.
Vous n'avez pas à utiliser tous les composants comme alias. Par exemple k, kg, klo, ksys, kgpo peuvent également être utilisés. De plus, dans la ligne de commande, vous pouvez combiner des alias et des commandes ou options standard :
Par exemple :
- Au lieu de
kubectl proxypeut être écritk proxy. - Au lieu de
kubectl get rolespeut être écritkg roles(il n'existe actuellement pas d'alias pour la ressource Roles). - Pour obtenir des données sur un pod spécifique, vous pouvez utiliser la commande
kgpo my-pod — kubectl get pod my-pod.
Notez que certains alias nécessitent un argument dans la ligne de commande. Par exemple, l'alias kgpol signifie kubectl get pods -l. L'option -l requiert un argument - la spécification de l'alias. Si vous utilisez un alias, il apparaîtra comme kgpol app=ui.
Comme certaines parties des alias nécessitent 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 pourrez intuitivement déduire des alias des commandes que vous souhaitez exécuter, ce qui vous fera gagner beaucoup de temps de saisie.
Installation
Pour installer kubectl-aliases, vous devez télécharger le fichier depuis GitHub et l'inclure dans le fichier ~\/bashrc ou ~/.zshrc:
source ~/.kubectl_aliasesAuto-complétion
Comme nous l'avons déjà mentionné, vous ajoutez souvent des mots supplémentaires à l'alias dans la ligne de commande. Par exemple :
$ kgpooyaml test-pod-d4b77b989Si vous utilisez l'auto-complétion de la commande kubectl, vous avez probablement utilisé l'auto-complétion pour des choses comme les noms de ressources. Mais peut-on faire cela lorsqu'on utilise des alias ?
C'est une question très importante, car si l'auto-complétion ne fonctionne pas, vous perdrez une partie des avantages des alias.
La réponse dépend de la shell que vous utilisez :
- Pour Zsh, l'auto-complétion pour les alias fonctionne "out of the box".
- Pour Bash, malheureusement, certaines actions sont nécessaires pour faire fonctionner l'auto-complétion.
Activation de l'auto-complétion 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). Comme vous n'avez pas de scripts de complétion pour les 800 alias, l'auto-complétion ne fonctionne pas.
Projet offre une solution générale à ce problème. Il se connecte au mécanisme de complétion pour les alias, complète l'alias en commande et renvoie les options de complétion pour la commande complétée. Cela signifie que la complétion pour un alias se comporte exactement comme pour une commande complète.
Je vais d'abord expliquer comment installer complete-alias, puis comment le configurer pour activer la complétion pour tous les alias de kubectl.
Installation de complete-alias
Tout d'abord, complete-alias dépend de . 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: tout comme le script de complétion kubectl, complete-alias ne fonctionne pas avec Bash 3.2, qui est utilisé par défaut dans MacOS. En particulier, complete-alias dépend de bash-completion v2 (brew install bash-completion@2), pour lequel Bash 4.1 est requis au minimum. Cela signifie que pour utiliser complete-alias sur MacOS, vous devez installer une version plus récente de Bash.
Vous devez télécharger le script de et l’inclure dans votre fichier ~\/bashrc:
source ~/bash_completion.shAprès avoir redémarré l’interpréteur de commande, complete-alias sera complètement installé.
Activation de l’autocomplétion pour les alias kubectl
Techniquement, complete-alias fournit une fonction de shell _complete_alias. Cette fonction vérifie l'alias et retourne des suggestions d'autocomplétion pour la commande d'alias.
Pour lier la fonction à un alias spécifique, vous devez utiliser le mécanisme intégré de Bash , pour définir _complete_alias comme fonction d’autocomplétion d’alias.
Prenons comme exemple l'alias k, représentant la commande kubectl. Pour définir _complete_alias comme fonction d’autocomplétion pour cet alias, vous devez exécuter la commande suivante :
$ complete -F _complete_alias k Ce résultat signifie que chaque fois que vous utilisez l’autocomplétion pour l'alias k, la fonction _complete_alias, qui vérifie l'alias et retourne des suggestions d'autocomplétion pour la commande, est appelée. kubectl.
Pour un deuxième exemple, prenons l'alias kg, qui représente kubectl get:
$ complete -F _complete_alias kg Tout comme dans l’exemple précédent, lorsque vous utilisez l’autocomplétion pour kg, vous obtenez les mêmes suggestions d'autocomplétion que celles que vous auriez pour kubectl get.
Notez qu'il est possible d’utiliser complete-alias pour n’importe quel alias de votre système.
Ainsi, pour activer l’autocomplétion pour tous les alias kubectl, vous devez exécuter la commande mentionnée ci-dessus pour chacun d'eux. Le fragment suivant le fait exactement à condition que vous ayez installé kubectl-aliases dans ~/ .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 l'interpréteur de commande et l’autocomplétion sera disponible pour tous les 800 alias kubectl.
6. Extension de kubectl avec des plugins
À partir de , kubectl prend en charge , qui permet d'étendre ses fonctionnalités avec des commandes supplémentaires.
Si vous êtes familier avec , les plugins kubectl sont construits selon le même principe.
Dans ce chapitre, nous allons expliquer 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 fichiers exécutables simples avec des noms de type kubectl-x. Le préfixe kubectl- est obligatoire, suivi d'une nouvelle sous-commande kubectl qui permet d'appeler le plugin.
Par exemple, le plugin hello sera distribué sous la forme d'un fichier nommé kubectl-hello.
Pour installer le plugin, il faut copier le fichier kubectl-x dans n'importe quel répertoire dans votre variable PATH et le rendre exécutable, par exemple en utilisant chmod +x. Juste après cela, vous pouvez appeler le plugin avec kubectl x.
Vous pouvez utiliser la commande suivante pour afficher la liste de tous les plugins actuellement installés sur votre système :
$ kubectl plugin listCette commande affiche également des avertissements si vous avez plusieurs plugins avec les mêmes noms, ou s'il y a un fichier de plugin qui n'est pas exécutable.
Recherche et installation de plugins avec Krew
Les plugins Kubectl sont destinés à être partagés ou réutilisés comme des paquets logiciels. Mais où pouvez-vous trouver les plugins partagés par d'autres ?
vise à fournir une solution unifiée pour le partage, la recherche, l'installation et la gestion des plugins kubectl. Le projet se décrit comme un « gestionnaire de paquets pour les plugins kubectl » (Krew est similaire à ).
Krew est une liste de plugins kubectl que vous pouvez choisir et installer. Krew est également un plugin pour kubectl.
Cela signifie que l'installation de Krew fonctionne essentiellement comme l'installation de tout autre plugin kubectl. Vous pouvez trouver des instructions détaillées sur .
Les commandes Krew les plus importantes :
# Поиск в списке плагинов
$ 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 avec Krew n'empêche pas l'installation de plugins de la manière standard décrite ci-dessus.
Notez que la commande kubectl krew list affiche uniquement les plugins qui ont été installés avec Krew, tandis que la commande kubectl plugin list énumère tous les plugins, c'est-à-dire ceux qui ont été installés avec Krew et ceux qui ont été installés par d'autres moyens.
Recherche de plugins ailleurs
Krew est un jeune projet, à l'heure actuelle, son compte environ 30 plugins. Si vous ne trouvez pas ce que vous cherchez, vous pouvez trouver des plugins ailleurs, par exemple sur GitHub.
Je recommande de consulter la section GitHub . Là, vous trouverez plusieurs dizaines de plugins disponibles qui valent la peine d'être examinés.
Écriture de vos propres plugins
Vous pouvez créer vous-même — ce n'est pas difficile. Vous devez créer un fichier exécutable qui fait ce dont vous avez besoin, et le nommer comme kubectl-x et l'installer comme décrit ci-dessus.
Le fichier peut être un script bash, un script python ou une application compilée en go — peu importe. La seule condition est qu'il puisse être exécuté directement dans le système d'exploitation.
Créons un exemple de plugin tout de suite. Dans la section précédente, vous avez utilisé la commande kubectl pour afficher la liste des conteneurs pour chaque pod. Vous pouvez facilement transformer cette commande en un plugin que vous pouvez appeler, par exemple, avec kubectl img.
Créez un fichier kubectl-img avec 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 dans n'importe quel répertoire de votre PATH. Juste après cela, 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 de shell, il est avantageux de pouvoir facilement appeler kubectl depuis le plugin. Cependant, vous pouvez écrire des plugins plus complexes dans de vrais langages de programmation, en utilisant . Si vous utilisez Go, vous pouvez également utiliser , qui est spécifiquement conçue pour écrire des plugins kubectl.
Comment partager vos plugins
Si vous pensez que vos plugins peuvent être utiles aux autres, n'hésitez pas à les partager sur GitHub. Assurez-vous de les ajouter à un sujet .
Vous pouvez également demander l'ajout de votre plugin dans . Des instructions sur la façon de procéder sont disponibles dans .
Autocomplétion des commandes
Actuellement, les plugins ne supportent pas l'autocomplétion. Cela signifie que vous devez entrer le nom complet du plugin et les noms complets des arguments.
Dans le dépôt GitHub de kubectl, cette fonction a une . Ainsi, il est possible que cette fonctionnalité soit mise en œuvre un jour à l'avenir.
Bonne chance !!!
Suggestions de lecture supplémentaires:
- .
- .
- .
Source : habr.com







