Photo by Mabel Amber
Tras la alegría inicial pensando que la configuración de rsyslog era la causante de los cuelgues de las dos RPi 3 (El nodo k3 del clúster colgado de nuevo), pasadas unas horas los dos nodos k2 y k3 han dejado de responder de nuevo.
Así que es el momento de atacar el problema de forma algo más sistemática. Para ello seguiré las instrucciones que proporcina la página de Kubernetes Troubleshooting Clusters.
Los nodos k2 y k3 del clúster dejan de responder pasadas unas horas. La única manera de solucionarlo es reiniciar los nodos. Siguiendo con la revisión de logs, he encontrado que se genera una gran cantidad de entradas en syslog en referencia a orphaned pods. Además, el número de estos errores no para de crecer rápidamente.
En la entrada anterior Múltiples mensajes ‘action 17 suspended’ en los logs comentaba que estaba a la espera de obtener resultados; después de apenas unas horas, ya los tengo: k3 se ha vuelto a colgar mientras que k2 no.
Este resultado parece demostrar que la mala configuración de rsyslog es la causante de los cuelgues de las RPi 3 en el clúster de Kubernetes.
Actualización: El nodo k2 sobre RPi3 sigue colgándose :(
Actualización II: Parece solucionado
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 ]
Portainer es una herramienta ligera y open-source de gestión de contenedores sobre Docker (o Docker Swarm). Portainer ofrece una interfaz gráfica para gestionar el host Docker desde cualquier navegador, tiene soporte para Raspberry Pi y se puede desplegar como un simple contenedor.
Espero que este artículo ayude a todos aquellos que tengan ganas de probar Portainer y evitarles los problemas que me he encontrado yo.
Al lanzar la inicialización del clúster con kubeadm init en Debian Jessie, las comprobaciones inciales indican que no se encuentran los cgroups para la memoria (échale un vistazo al artículo La instalación de Kubernetes falla en Debian Jessie (missing cgroups: memory)). Los cgroups son una de las piezas fundamentales en las que se basa Docker para aislar los procesos de los contenedores, por lo que la inicialización del clúster de Kubernetes se detiene.
La solución es tan sencilla como habilitar los cgroups durante el arranque.
La instalación de Kubernetes se realiza de forma casi automática gracias al script kubeadm. Sólo hay que seguir las instrucciones de Installing Kubernetes on Linux with kubeadm y la salida por pantalla del propio script.
Después de realizar la instalación del nodo master del clúster Kubernetes, el siguiente paso es agregar nodos adicionales al clúster. Es en estos nodos donde se van a planificar los pods que realizan las funciones productivas del clúster (en el nodo master sólo realiza tareas de gestión del clúster).
Después de conseguir arrancar Kubernetes tras la instalación, al intentar ejecutar comandos vía kubectl obtengo el mensaje de error The connection to the server localhost:8080 was refused - did you specify the right host or port?
A continuación explico cómo solucionar el error y evitar que vuelva a mostrarse.
