Skip to main content
BlogConteneurs (Kubernetes, Docker)5 astuces du shell Kubernetes

5 astuces pour le shell Kubernetes

5ShellTricks_BlogImages_Blog_1920x1008

Bonjour ! Ici Andrew, développeur chez Linode. Au cours du processus de construction d'une solution Kubernetes gérée, j'ai découvert et créé plusieurs astuces que j'utilise pour faciliter les tâches quotidiennes avec Kubernetes. Je voulais partager ces cinq astuces avec vous et j'espère que vous les trouverez aussi utiles que moi.

1. L'astuce de la méta-coquille

J'ai vu cette astuce pour la première fois dans la conférence d'Olive Power sur la préparation CKA à la KubeCon Europe de cette année.

kubectl <command> --help | grep kubectl

Chaque commande kubectl contient un certain nombre d'exemples dans sa sortie d'aide, et c'est un moyen rapide de les voir tous en même temps. Ces exemples peuvent vous donner des idées sur la façon de combiner les paramètres et les drapeaux d'une manière utile qui pourrait ne pas être évidente à la lecture de la documentation.

Actuellement, c'est la commande kubectl run qui donne le plus grand nombre d'exemples : 18. Cependant, la commande que j'utilise le plus souvent est kubectl get. Jetons un coup d'œil à l'un de ses exemples :

kubectl get pod test-pod -o custom-columns=CONTAINER:.spec.containers[0].name,IMAGE:.spec.containers[0].image

Cette commande transforme la sortie de kubectl get, vous donnant seulement la version du conteneur déployé pour ce pod. Avec quelques légères modifications, vous pouvez rendre la sortie beaucoup plus utile. Notez qu'elle demande le nom et l'image du premier conteneur (containers[0]). En utilisant la syntaxe JSONPath supportée par kubectl, vous pouvez lister toutes les versions de tous les conteneurs dans tous les pods.

kubectl get pod -o custom-columns=CONTAINER:.spec.containers[*].name,IMAGE:.spec.containers[*].image -A

Cette astuce peut vous éviter de fouiller dans les ressources des pods individuels pour trouver une image canari ou un décalage de version dans votre cluster. Avec un alias de kgi (et le sélecteur d'espace de noms -A supprimé), vous pouvez utiliser la version de kube-apiserver en cours d'exécution dans votre cluster. Voir ci-dessous :

$ kgi -n kube-system -l component=component=kube-apiserver
CONTAINER        IMAGE
kube-apiserver   k8s.gcr.io/kube-apiserver:v1.14.5
kube-apiserver   k8s.gcr.io/kube-apiserver:v1.14.5
kube-apiserver   k8s.gcr.io/kube-apiserver:v1.14.5

La commande suivante permet d'imprimer une liste à jour de tous les exemples intégrés. Choisissez-en un avec des drapeaux que vous n'avez jamais vus auparavant et expérimentez !

for c in $(kubectl --help | egrep "^\s+([a-z-]+)" -o); do echo -e "$(kubectl $c --help | egrep '^\s+kubectl')"; done

2. Obtenir l'utilisation de la mémoire par espace de nommage

Certains d'entre nous savent que awk est bien plus que awk { print $1 }. Récemment, j'ai approfondi mes connaissances et appris les bases de ce langage incroyablement puissant qui nous a été transmis par certains des titans de l'histoire d'Unix. Voici un exemple de programme awk très utile, mais suffisamment court pour être aliasé en une ligne. Il additionne et imprime le nombre de MiB de mémoire utilisés par tous les pods dans chaque espace de noms, et utilise le printf d'awk pour une sortie propre, même si votre cluster contient de longs noms d'espaces de noms. Pensez à utiliser awk lorsque vous avez besoin d'une vue globale de la sortie de kubectl.

kubectl top pod -A --no-headers=true | awk '{a[$1] += $4} END {for (c in a) printf "%-35s %s\n", c, a[c]}'

3. Afficher les secrets en texte brut

Lorsque vous développez une application qui repose sur des secrets, cela peut être une corvée de trouver un moyen d'acheminer la sortie de kubectl vers base64. Vous avez peut-être écrit un pipeline shell ou un petit script pour les décoder. J'ai vu quelques options différentes avec divers inconvénients : ne pas prendre en charge la sortie multi-lignes, ajouter ou supprimer des nouvelles lignes en cours de route, ou perdre le contexte des noms de champs. Avec le plugin secret decode d'Ashley Schuett pour kubectl, vous pouvez voir les secrets sous une forme lisible dans la sortie get de kubectl et éviter tous ces problèmes.

La documentation du projet recommande d'utiliser curl pour récupérer le binaire sur GitHub et l'ajouter à notre chemin d'accès. Puisque cela touche une variété de données sensibles, je vous encourage à le compiler à partir des sources, et à examiner les sources d' abord. Heureusement, ce plugin consiste en un seul fichier source bien formaté :

git clone git@github.com:ashleyschuett/kubernetes-secret-decode.git
cd kubernetes-secret-decode
GO111MODULE=off go build -o $GOPATH/bin/kubectl-ksd

Le nom du binaire construit à la dernière étape doit commencer par kubectl- pour qu'il soit reconnu comme un plugin. Assurez-vous que $GOPATH/bin se trouve dans votre $PATH, et vous pourrez alors l'utiliser comme suit :

kubectl ksd get secret -n <namespace-name> <secret-name> -o yaml

4. Journaux récents et précédents

Si vous avez un service qui peut atteindre des semaines ou des mois de disponibilité, les journaux des conteneurs peuvent atteindre une taille telle que les commandes kubectl log typiques produisent une quantité ridicule de données. Vous pouvez avoir l'impression de tester les limites de la capacité de votre terminal à peindre du texte, ou être surpris par la quantité de trafic réseau générée par ce qui est censé être lisible par l'homme. Dans ces cas-là, il existe plusieurs façons de réduire la quantité de données produites et d'obtenir les messages que vous voulez voir.

La première est la --tail=N qui commence à imprimer les N lignes les plus récentes du fichier.

kubectl logs --tail=10 -f -n kube-system -l component=kube-apiserver

Il y a aussi --since=time qui accepte des intervalles de temps tels que 30s, 1h ou 5m pour se référer à un nombre de secondes, d'heures ou de minutes respectivement.

kubectl logs --since=5m -f -n kube-system -l component=kube-apiserver

Un autre drapeau de journalisation sur lequel j'ai appris à compter est -p. Il imprime les journaux de l'exécution précédente du conteneur ; les journaux d'un conteneur qui est sorti. Cela aurait rendu mes premiers jours avec Kubernetes beaucoup plus faciles, alors que j'essayais de redémarrer les pods et d'"attraper" leurs journaux, avec une action rapide de la souris et du clavier, avant qu'ils ne tombent à nouveau en panne.

kubectl logs -p -n kube-system -l component=etcd

5. Gagner du temps en attendant

Chaque fois que vous êtes tenté d'écrire une boucle avec une commande sleep, il y a généralement une meilleure façon de procéder. Quel que soit l'intervalle choisi, vous risquez de perdre une ou plusieurs secondes. Cela peut s'accumuler s'il s'agit d'un processus automatisé. C'est là que la commande kubectl wait et son paquetage apimachinery sont utiles. Cette commande vous permet de mettre vos scripts en pause pendant le temps nécessaire pour que la condition soit remplie dans votre cluster. Vous pouvez également l'utiliser pour poster des avertissements dans Slack au moment où une nouvelle version arrive sur le cluster. Amusez-vous bien avec cette commande.

Voici quelques exemples :

kubectl wait --for=condition=Available deployment/metrics-server
kubectl wait --for=condition=Initialized pod/csi-linode-controller-0

Les conditions disponibles varient en fonction du type de ressource et peuvent être découvertes à l'aide de kubectl describe sous "Conditions :". Une ressource donnée peut avoir plusieurs conditions différentes en même temps.

Trucs et astuces en prime !

Il arrive parfois que l'on regarde la sortie et que l'on souhaite que des informations supplémentaires sur le réseau ou d'autres informations soient affichées, n'est-ce pas ? Pour vous aider, ajoutez -owide à la commande. Cela fonctionne pour presque tous les types de ressources, et les colonnes affichées peuvent être personnalisées pour les définitions de ressources personnalisées (CRD). Exemples :

kubectl get pods -A -owide
kubectl get services -A -owide

Enfin, si vous ne l'avez pas encore remarqué, -A a été ajouté en tant qu'alias pour le drapeau --all-namespaces. Je pense que cette fonction a permis à elle seule d'économiser des millions de frappes depuis son introduction. Un autre moyen de gagner du temps est d'ajouter alias k=kubectl à votre shell rc.

Cet article a principalement abordé les fonctionnalités intégrées de kubectl. Pour aller encore plus loin, il y a le livre open source kubectl, lisible en ligne. Il se concentre sur l'utilisation de Kustomize, un outil intégré qui vous permet d'organiser et de composer vos ressources Kubernetes. Je le recommande vivement, surtout si vous avez cherché des cadres de projet Kubernetes avec une surface vulnérable minimale. Pour une collection d'autres commandes utiles, consultez Krew, le gestionnaire de paquets officiel pour les plugins kubectl.

Commentaires (2)

  1. Author Photo

    Great post Andrew, this is actually cool.

    #2, getting memory usage based on namespace is a nice hack, on #3, i’d prefer to use rancher to get most of these information.

    What do you think, have you tried rancher before?

  2. Andrew Sauber

    Thanks : )

    I have used Rancher before, in fact Linode has an official Rancher integration which you can read about here: https://www.linode.com/docs/kubernetes/how-to-deploy-kubernetes-on-linode-with-rancher-2-x/

    I do like Rancher for managing access to a cluster, the fact that each user gets a ServiceAccount token proxied through the Rancher deployment is very cool.

    For viewing secrets, I still use the technique in #3.

Laissez un commentaire

Votre adresse électronique ne sera pas publiée. Les champs obligatoires sont marqués d'un *.