Installer et débugger Kubernetes dans LXD

Nous avons récemment déployé des clusters Kubernetes avec le besoin de collocalliser les clusters sur des noeuds physiques au sein de nos infrastructures. Nous aurions pu utiliser des machines virtuelles qui auraient fournis de plus fortes garanties d’isolation mais, dans notre cas, nous avons privilégié les performances avec des conteneurs Linux.

Notre environnement est constitué de noeuds physiques installés avec Ubuntu 19.10. LXD est déployé en version 3.19 avec ZFS comme système de stockage. Dans cet article, nous nous concentrerons sur quelques erreurs que nous avons rencontrées lors de l’installation de Kubernetes avec kubeadm dans les conteneurs LXC. Pour en savoir plus sur Kubernetes ou LXC/LXD, veuillez lire les articles suivants :

FATAL : Module configs not found in directory /lib/modules

Le premier problème rencontré fut à l’exécution de la commande kubeadm init ..., une vérification initiale (preflight check). L’erreur affichée est :

[ERROR SystemVerification]: failed to parse kernel config: unable to load kernel module: "configs", output: "modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/5.0.0-38-generic/modules.dep.bin'\nmodprobe: FATAL: Module configs not found in directory /lib/modules/5.0.0-38-generic\n", err: exit status 1
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`

Le problème survient lorsque LXC ne peut pas charger les modules Kernel par défaut dans le conteneur (situés dans /lib/modules). Cet échange explique ce qu’il est nécessaire de faire pour charger les modules Kernel avec lxc config set mycontainer linux.kernel_modules overlay mais dans notre cas, cela n’a pas suffit.

Par la suite, un nouveau pépin s’est ajouté. La version de Docker, installée selon la documentation recommandée par Kubernetes à ce moment là, venait avec une dépendance sur linux-modules-5.0.0-1033-oem-osp1 qui n’est pas cohérente avec la version Kernel de notre machine hôte :

uname -r
5.0.0-38-generic

Il nous manquait donc les modules Kernel de la version 5.0.0-38-generic :

ls -l /lib/modules
total 9
drwxr-xr-x 5 root root 16 Feb  3 14:22 5.0.0-1033-oem-osp1

Pour résoudre ce problème, nous avons manuellement installé les modules Kernel corrects :

apt install linux-modules-5.0.0-38-generic

/dev/kmsg : no such file or directory

Ce problème était visible depuis le status du service kubelet :

journalctl -xeu kubelet

Jan 20 21:31:00 k8s-m-1 kubelet[22875]: E0120 21:31:00.269923   22875 kubelet.go:1302] Image garbage collection failed once. Stats initialization may not have completed yet: failed to get imageFs info: unable to find data
Jan 20 21:31:00 k8s-m-1 kubelet[22875]: E0120 21:31:00.270327   22875 event.go:272] Unable to write event: 'Post https://10.0.0.64:6443/api/v1/namespaces/default/events: dial tcp 10.0.0.64:6443: connect: connection refuse
Jan 20 21:31:00 k8s-m-1 kubelet[22875]: I0120 21:31:00.270527   22875 server.go:143] Starting to listen on 0.0.0.0:10250
Jan 20 21:31:00 k8s-m-1 kubelet[22875]: F0120 21:31:00.270954   22875 kubelet.go:1413] failed to start OOM watcher open /dev/kmsg: no such file or directory
Jan 20 21:31:00 k8s-m-1 systemd[1]: kubelet.service: Main process exited, code=exited, status=255/EXCEPTION
Jan 20 21:31:00 k8s-m-1 systemd[1]: kubelet.service: Failed with result 'exit-code'.

Selon la documentation Linux, “The /dev/kmsg character device node provides userspace access to the kernel’s printk buffer”.

Par défault, le device n’est pas créé dans un conteneur LXD. Il est possible de le faire en paramétrant lxc.kmsg à 1 dans la configuration du conteneur ou en créant manuellement un lien symbolic :

echo 'L /dev/kmsg - - - - /dev/console' > /etc/tmpfiles.d/kmsg.conf

Mount propagation

Nous avons suivi le guide kubernetes-lxd de Cornelius Weig dans lequel il est recommandé de créer deux volumes ZFS pour le stockage des espaces /var/lib/docker et /var/lib/kubelet.

Nous avons allor rencontré les problèmes suivant à la création de nos premiers pods :

Normal   Created    12m                  kubelet, k8s-wrk-2  Created container liveness-prometheus
Warning  Failed     12m (x2 over 12m)    kubelet, k8s-wrk-2  Error: failed to start container "csi-cephfsplugin": Error response from daemon: path /var/lib/kubelet/plugins is mounted on /var/lib/kubelet but it is not a shared mount
Normal   Created    12m (x4 over 12m)    kubelet, k8s-wrk-2  Created container csi-cephfsplugin
Normal   Pulled     12m (x3 over 12m)    kubelet, k8s-wrk-2  Container image "quay.io/cephcsi/cephcsi:v1.2.2" already present on machine
Warning  Failed     12m (x2 over 12m)    kubelet, k8s-wrk-2  Error: failed to start container "csi-cephfsplugin": Error response from daemon: path /var/lib/kubelet/pods is mounted on /var/lib/kubelet but it is not a shared mount
Warning  BackOff    3m3s (x44 over 12m)  kubelet, k8s-wrk-2  Back-off restarting failed container

Cette erreur indique que le montage /var/lib/kubelet n’est pas partagé. Il est possible de vérifier si un montage est shared ou private avec la commande suivante :

findmnt -o TARGET,PROPAGATION /var/lib/kubelet/
TARGET           PROPAGATION
/var/lib/kubelet private

On constate donc que le montage est actuellement en mode private. Par défault, LXD monte les volumes ainsi. Il est possible de changer ce comportement avec la configuration suivante :

devices:
  kubelet-volume:
    path: /var/lib/kubelet
    propagation: shared
    source: /dev/zvol/syspool/kubernetes/kubelet
    type: disk

On peut désormais constater que les changements ont été appliqués :

findmnt -o TARGET,PROPAGATION /var/lib/kubelet/
TARGET           PROPAGATION
/var/lib/kubelet shared

Sources

Partagez cet article