unixadmin.free.fr Handy Unix Plumbing Tips and Tricks

13déc/19Off

Comment administrer Gluster via le pod heketi-storage sous Openshift

Un bon conseil, si ton stockage Gluster est géré par Heketi, alors n'utilise jamais les commandes "gluster" via les serveurs de ton Gluster Storage. Le risque est que la base de donnée Heketi ne soit plus en phase avec la réalité.

Si comme moi tu utilises Gluster pour Openshift, connecte-toi sur ton cluster Openshift et identifie le pod heketi-storage. En principe on n'a pas a aller bricoler la dedans, mais ça peut servir.

$ oc login https://console.ocp311.exemple.com
$ oc get pod --all-namespaces | grep heketi
app-storage                         heketi-storage-1-dgzwx                                 1/1       Running                    0          2d

$ oc project app-storage

$ oc get pod
NAME                                          READY     STATUS    RESTARTS   AGE
glusterblock-storage-provisioner-dc-1-4dwnb   1/1       Running   0          2d
heketi-storage-1-dgzwx                        1/1       Running   0          2d

Connecte-toi sur le pod Heketi

$ oc rsh heketi-storage-1-dgzwx

Exporte la variable nécéssaire pour utiliser heketi-cli

sh-4.2# export HEKETI_CLI_KEY=$HEKETI_ADMIN_KEY ; export HEKETI_CLI_SERVER=http://localhost:8080 ; export HEKETI_CLI_USER=admin

Quelques commandes utiles

heketi-cli -h
 
heketi-cli topology info

heketi-cli cluster info ede5b53ee6c5d4c2b3d3096a07aa1536

heketi-cli node list

heketi-cli volume list

heketi-cli volume info 2746ccfc5a2050f0870f24437c50dca4

heketi-cli db check

heketi-cli db dump
Remplis sous: GLUSTER, OPENSHIFT Commentaires
18juil/19Off

identifier le container docker qui blinde /var/lib/docker

L'installation d'Openshift 3.9 ne paramètre pas de limite sur le fichier de log docker. Mais on peut également avoir une application qui log à mort un peu partout (merci au dev :) ), fluentd est un peu là pour récupérer tout ce p'tit merdier en principe.

Comment identifier le container docker qui blinde le stockage docker (non persistent).

Soit vous utilisez le classique "find" pour identifier les plus gros fichiers du /var/lib/docker
ou lsof pour identifier les plus gros fichiers ouvert et les fichiers "deleted" utile si le container docker tourne encore et ne libère pas l'espace.

Ouch! Un bon gros fichier de log docker de 59Go !

[root@node3003 ~]# find /var/lib/docker -size +100M
bla ...
[root@node3003 ~]#  lsof > /tmp/lsof
[root@node3003 ~]#  grep /var/lib/docker /tmp/lsof  | sort -nk8
ruby-time  66292  66467        root  117r      REG              253,3 63751211068    9498063 /var/lib/docker/containers/95e25b3e5cd8f820f4d5c6643170af6f183b0ca5991a5a0a1250c96849f13f02/95e25b3e5cd8f820f4d5c6643170af6f183b0ca5991a5a0a1250c96849f13f02-json.log

Récupérer l'id du container 95e25b3e5cd8f820f4d5c6643170af6f183b0ca5991a5a0a1250c96849f13f02 et rechercher à quel container il appartient.

[root@node3003 ~]# for i in $(docker ps -q)
 do
 echo  $i
 docker inspect $i | grep "95e25b3e5cd8f820f4d5c6643170af6f183b0ca5991a5a0a1250c96849f13f02"
 done
e905f5479339
0bfb4903ca32
95e25b3e5cd8
        "Id": "95e25b3e5cd8f820f4d5c6643170af6f183b0ca5991a5a0a1250c96849f13f02",
        "LogPath": "/var/lib/docker/containers/95e25b3e5cd8f820f4d5c6643170af6f183b0ca5991a5a0a1250c96849f13f02/95e25b3e5cd8f820f4d5c6643170af6f183b0ca5991a5a0a1250c96849f13f02-json.log",
32b2225571e8
4b363ec2f874

Le container docker est lié au pod foo-java du namespace prod-ns-foo

[root@node3003 ~]# docker ps | grep 95e25b3e5cd8
95e25b3e5cd8        docker-release.example.com/prod-ns-foo/foo@sha256:5f4e472c378877b4ce16a14133dea4d257bbed93f351537a0c0caf22a2887307                "/bin/sh -c 'java ..."   3 weeks ago         Up 3 weeks                              k8s_foo_foo-java-5-x4j5d_a3398ca4-70ed-11e9-aae8-005056b00427_0

Solution de contournement
pour libérer temporairement l'espace pris par le fichier de log du container sans impacter les autre pod => redémarer le pod poisseux

$ oc scale dc foo-java --replicas=0  
$ oc scale dc foo-java --replicas=1

Résolution:
ajouter l'option --log-opt max-size et --log-opt max-file au fichier de conf /etc/sysconfig/docker

# cat /etc/sysconfig/docker
OPTIONS='--insecure-registry=172.30.0.0/16 --selinux-enabled --log-opt max-size=50m --log-opt max-file=5'

Le redémarrage de docker est requis et va donc rebalancer les pod sur d'autre noeud app. on migre donc proprement tous les pods du noeud app

$ oc adm drain node3003 --force --delete-local-data --ignore-daemonsets
$ oc get node

Redémarrez docker ou en profiter pour redémarrer le noeud app, histoire de mettre tout à plat (éventuelles fuites mémoires insoupçonnées ou autre bizarrerie)

[root@node3003 ~]# systemctl restart docker
ou
[root@node3003 ~]# reboot

Configurer le noeud pour être "schedulable"

$ oc adm manage-node node3003 --schedulable=true
$ oc get node
Remplis sous: OPENSHIFT Commentaires