kubectl tips and tricks 3

Posted by

Déjà le numéro 3 pour les kubectl tips and tricks !

Vous le savez peut être car j’en parle abondamment, mais j’utilise Kubernetes quotidiennement, en particulier kubectl ! Certes il y a des UI sympas pour améliorer l’expérience utilisateur de la ligne de commande avec Kubernetes, mais j’aime bien savoir exactement ce que je fais et souvent je préfère reste au plus proche de l’outil (c’est personnel). Je collecte donc de petites astuces qu’on ne trouve pas toujours quand on débute dans kube, que je vous partage ici.

Note: numéro 3 signifie bien entendu un n°1 et un n°2, que vous pourrez retrouver ici :

Et aussi dans la même veine :

Qu’est ce qui bouffe mes ressources !

Un inconditionnel lorsqu’on héberge des applications (et encore plus quand elles cohabitent) est savoir laquelle bouffe toutes les ressources et bloque les autres (ça marche aussi dans la vraie vie, en coloc) !

L’idéal est bien entendu de pouvoir compter sur une supervision complète (allez voir cet article sur Prometheus et Grafana si vous voulez en savoir plus), mais des fois, pour aller vite (ou si votre cluster est vraiment par terre et que Prom répond plus, avoir des outils intégrés permet de gagner du temps dans l’analyse du problème.

Heureusement pour nous, kubectl intègre une commande "top", qui, comme sa commande homonyme sous Linux, va nous permettre d’afficher les consommations de CPU et de RAM des objets dans notre cluster.

Il existe deux modes pour ce "top". Le premier permet de lister la consommation des nodes :

kubectl top node 
NAME                                                                         CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
zwindlerzzzz01-11111111-vmss000000     118m             3%        1274Mi                   10%       
zwindlerzzzz01-11111111-vmss000001     119m             3%        1777Mi                   14%       
zwindlerzzzz01-11111111-vmss000002     320m             8%        2611Mi                   20%       
zwindlermntr01-11111111-vmss000000     113m            2%        1653Mi                   6%        
zwindlerzone01-11111111-vmss000000     200m            5%        1559Mi                   12%       
zwindlerzone01-11111111-vmss000001     215m            5%        1510Mi                   11%     

On a à la fois les infos en terme de CPU (en cores ou millicores et en pourcentage total) ainsi que la consommation RAM (en Mio et en %age total de ce qu’il y a sur la machine).

Le second permet de lister les pods.

Un point d’attention cependant : contrairement aux nodes, qui sont des objets visibles dans tous les namespaces Kubernetes, les pods sont liés à un namespace particulier. Il sera donc nécessaire de spécifier le namespace qui vous intéresse ou alors d’ajouter un –all-namespaces.

kubectl top pod --all-namespaces
NAMESPACE     NAME                                      CPU(cores)    MEMORY(bytes)
default                 appli1-aaaaa                        1m                   36Mi
default                 appli2-aaaaa                        1m                   36Mi
default                 appli3-aaaaa                        1m                   36Mi
ingress                traefik-v2-aaaaa-aaaaa    3m                   17Mi

[Edit] Suite à une remarque de Thibault Le Reste, je me suis rappelé de 2 options dont je n’avais pas parlé initialement dans l’article --sort-by=cpu et --sort-by=memory.

A y repenser, je me suis souvenu pourquoi je n’en ai par parlé… c’est parce que cette option ne marchait pas quand j’ai écris l’article ;-)

En fait il y a un bug, fixé dans la version 1.18 de kubectl (issue Github 81270), donc si vous êtes à jour, vous pouvez utiliser ces deux options !

Logs

Un autre must dans l’hébergement d’applications, c’est comprendre pourquoi une application plante. Et il peut y avoir tellement de causes (pas seulement liées à Kubernetes) qu’il est important de garder une vision complète de toutes les sources de debugging à votre portée.

D’abord, l’application est peut être juste mal configurée. On pourrait simplement se connecter dessus mais il y a fort à craindre que le pod se kille tout seul le temps que vous tentiez de vous connecter.

Heureusement pour nous, la plupart des images sont pensées de telle sorte que les logs importants sont envoyés sur la sortie standard, sortie que nous pouvons récupérer avec la commande "logs", que vous connaissez sûrement.

kubectl --namespace=monitoring logs thanos-query-7bc9986f59-c7njv 
level=info ts=2020-05-06T15:23:35.600327763Z caller=main.go:168 msg="Tracing will be disabled"
level=info ts=2020-05-06T15:23:35.656544832Z caller=main.go:288 component=query msg="disabled TLS, key and cert must be set to enable"
level=info ts=2020-05-06T15:23:35.656572032Z caller=query.go:460 msg="starting query node"
level=info ts=2020-05-06T15:23:35.956571601Z caller=query.go:430 msg="Listening for query and metrics" address=0.0.0.0:10902

Cependant, ce que vous ignorez peut être c’est qu’il existe plusieurs flags très utiles qui permettent de reproduire les fonctions indispensable de tout admin linux qui lit des logs.

Par exemple, on peut faire l’équivalent d’un "tail -500" pour lister les 500 dernières lignes de log uniquement (très pratique si vous en avez des tartines) en ajoutant simplement le flag --tail=500.

On peut aussi faire l’équivalent du "tail -f" (suivre les lignes qui vont apparaître a posteriori en temps réel) avec le flag -f (tout simplement)

kubectl --namespace=monitoring logs thanos-query-7bc9986f59-c7njv --tail=1 -f
level=info ts=2020-05-06T15:26:18.048901191Z caller=storeset.go:266 component=storeset msg="adding new store to query storeset" address=prom-thanos-sidecar-zwindlerk8s.monitoring.svc.cluster.local:10901
[et là le prompt attend jusqu'à ce qu'une nouvelle ligne apparaisse ou que vous Ctrl-C]

Dans le cas d’un plantage en boucle, il arrive qu’on ait pas eu le temps de voir la trace du conteneur précédent avant que Kube en lance un nouveau. Vous pouvez accéder aux logs du conteneur précédent avec le -p !

kubectl logs pod-qui-crashe-en-boucle -p
Content root path: /app
Now listening on: http://[::]:80
Application started. Press Ctrl+C to shut down.
Application is shutting down...

Dans le cas où vous avez besoin de voir rapidement la date a laquelle a été écrite une ligne de log et que vous n’avez pas l’information dans le log lui même, sachez qu’il existe un --timestamps.

Lorsque vous ajoutez ce flag, il va preppend un timestamp devant chaque ligne.

kubectl --context=k8s11-euw-dev --namespace=cutting-room logs scanner-parameters-7bfd6b656d-cl2gl --timestamps
2020-06-23T08:00:08.578320749Z {"logType":"Debug","timestamp":"2020-06-23T08:00:08.575Z","level":"Info",[...]

Le mieux étant bien sûr d’externaliser toutes les lignes de log dans un système centralisé comme fluentd ou splunk pour faciliter les recherches, bien entendu…

Et enfin, un dernier flag très très cool : vous avez la possibilité de n’afficher que les messages les plus récents, mais sur un temps donné plutôt que sur un nombre de ligne de log. --since=5m vous affichera les logs des 5 dernières minutes uniquement !

Events

Je pense qu’on a fait le tour pour ce qui était des logs applicatif avec kubectl. Cependant, il existe une autre catégorie de logs dans Kubernetes : les Events. Les Events, c’est un peu les logs interne de l’API server. Ca va vous donner tout un tas d’informations sur ce qui se passe sur vos objets. Un Pod est créé, un Pod meurt car il répond pas à la Liveness Probe, une Image est pull… la tuyauterie technique de kube en somme.

Les Events sont des objets Kubernetes à part entière, comme les Pods, les Nodes, etc. Ils sont liés à un namespace et on les liste avec un kubectl get events, on peut obtenir les informations complètes d’un Event avec un kubectl describe events, etc.

kubectl --namespace=kube-system get events
LAST SEEN   TYPE      REASON      OBJECT                             MESSAGE
40s         Warning   Unhealthy   pod/omsagent-rs-758cbf9987-fb5zf   Liveness probe failed:
30m         Normal    Killing     pod/omsagent-rs-758cbf9987-fb5zf   Container omsagent failed liveness probe, will be restarted
10m         Warning   BackOff     pod/omsagent-rs-758cbf9987-fb5zf   Back-off restarting failed container
9s          Warning   Unhealthy   pod/omsagent-v7w8w                 Liveness probe failed:
25m         Normal    Killing     pod/omsagent-v7w8w                 Container omsagent failed liveness probe, will be restarted
5m45s       Warning   BackOff     pod/omsagent-v7w8w                 Back-off restarting failed container

Mais… vous voyez pas un truc chelou ?

C’est trié N’IMPORTE COMMENT !!!

Le mieux dans cette histoire, c’est que c’est "by design". Donc vous allez devoir garder cette astuce là sous le coude car je l’utilise à peu près tout le temps.

Pour modifier le comportement par défaut de kubectl get events pour que les événements soient triés par date de dernière occurrence (c’est souvent ce qu’on veut), retenez donc que vous allez devoir ajouter à chaque fois --sort-by='{.lastTimestamp}'

kubectl get events --sort-by='{.lastTimestamp}' 
LAST SEEN   TYPE      REASON      OBJECT                             MESSAGE
36m         Normal    Killing     pod/omsagent-rs-758cbf9987-fb5zf   Container omsagent failed liveness probe, will be restarted
16m         Warning   BackOff     pod/omsagent-rs-758cbf9987-fb5zf   Back-off restarting failed container
11m         Warning   BackOff     pod/omsagent-v7w8w                 Back-off restarting failed container
6m27s       Warning   Unhealthy   pod/omsagent-rs-758cbf9987-fb5zf   Liveness probe failed:
5m56s       Warning   Unhealthy   pod/omsagent-v7w8w                 Liveness probe failed:
85s         Normal    Pulled      pod/omsagent-rs-758cbf9987-fb5zf   Container image "mcr.microsoft.com/azuremonitor/containerinsights/ciprod:ciprod03022020" already present on machine
56s         Normal    Killing     pod/omsagent-v7w8w                 Container omsagent failed liveness probe, will be restarted

Conclusion

Voilà, j’arrête ici car j’en ai plein d’autres mais ça commence à faire beaucoup. La prochaine fois je parlerai très certainement de la façon dont vous allez pouvoir customiser les colonnes que vous voulez voir afficher, ainsi que des filtres.

Mais en attendant, amusez vous bien avec ça ;-)


Vous aimez ce blog ? Partagez-le avec vos amis !   Twitter Facebook Linkedin email

Vous pouvez également soutenir le blog financièrement :
Tipeee

2 comments

Leave a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.