Investigando las causas por las que los dos nodos con Raspberry Pi 3 se cuelgan, he encontrado múltiples apariciones de este mensaje en /var/log/messages:
Apr 30 06:40:42 k3 rsyslogd-2007: action 'action 17' suspended, next retry is Sun Apr 30 06:41:12 2017 [try http://www.rsyslog.com/e/2007 ]
De hecho, revisando el origen del problema he encontrado este comando que cuenta las apariciones del mensaje:
$ sudo grep "action.*suspend" /var/log/messages | wc -l
1394
Además de spamear los logs, provoca un montón de escrituras innecesarias sobre la tarjeta microSD, lo que puede acortar la vida útil de la misma.
No tengo claro si este puede ser la causa que hace que las dos Raspberry Pi 3 se cuelguen pasado un tiempo y que dejen de responder, lo que hace que deba reiniciarlas (desconectando/conectando el cable) para recuperarlas. Sin embargo, en el nodo master (Raspberry Pi 2 B+) no aparece el mensaje en los logs y no se cuelga (aunque la configuración de rsyslog es la misma).
Solución a los mensajes de rsyslog
El mensaje de error , es un problema de configuración de la aplicación rsyslog, que intenta mostrar mensajes en /dev/xconsole, pero falla.
La solución la explica Danny Tuppeny en su blog, en Removing [action ‘action 17’ suspended] rsyslog Spam on Raspberry Pi (Raspian Jessie). Él mismo abrió un bug en RPI-Distro: Default Raspbian Jessie Lite install spams syslog with “rsyslogd-2007: action ‘action 17’ suspended, next retry is #28 en él explicaba cómo había eliminado la línea que hace referencia a /dev/xconsole de la configuración de rasyslog y que el mensaje desaparecía (después de reiniciar).
Para comprobar si esta es la causa del cuelgue de la RPi 3, he modificado la configuración de rsyslog en el nodo k2 del clúster, pero no en el k3. De esta forma podré averiguar si la configuración de rsyslog es la causante del cuelgue.
También he actualizado el sistema (en todos los nodos) y kubelet, kubectl y kubeadm se han actualizado a la versión 1.6.2:
...
Setting up libldap-2.4-2:armhf (2.4.40+dfsg-1+deb8u2) ...
Setting up libicu52:armhf (52.1-8+deb8u5) ...
Setting up kubelet (1.6.2-00) ...
Setting up kubectl (1.6.2-00) ...
Setting up kubeadm (1.6.2-00) ...
Processing triggers for libc-bin (2.19-18+deb8u7)
...
$ kubectl get nodes
NAME STATUS AGE VERSION
k1 Ready 19d v1.6.2
k2 Ready 14d v1.6.2
k3 Ready 14d v1.6.2
Ahora sólo queda esperar -normalmente unas cuantas horas- a ver qué pasa: hay tres posibilidades:
- Se cuelga k3 pero no k2: La configuración de rsyslog era la causa.
- Se cuelga k2 pero no k3: ¿?
- No se cuelga ni k2 ni k3: Era un problema de alguno de los componetes actualizados que sólo afecta a la RPi 3.
Informaré en cuanto tenga resultados.
Unas horas después
Ya tenngo resultados: la configuración de rsyslog es la que causa el cuelgue del sistema en las RPi3.
Échale un vistazo a cómo solucionar este error en la entrada: El nodo k3 del clúster colgado de nuevo.