Photo by Mabel Amber
En el artículo Portainer para gestionar tus contenedores en Docker usamos Portainer para gestionar el Docker Engine local.
En el artículo Habilita el API remoto de Docker habilitamos el acceso remoto al API de Docker Engine.
En este artículo configuramos Portainer para conectar con un endpoint remoto (el API expuesta de un Docker Engine).
Portainer permite gestionar endpoints remotos para Docker (y Docker Swarm) mediante el API REST de Docker Engine. El problema es que el API está desactivado por defecto.
A continuación indico cómo activar y verificar el acceso remoto al API de Docker Engine.
Sigo con el troubleshooting del cuelgue de los nodos sobre Raspberry Pi 3 del clúster.
Ayer estuve haciendo limpieza siguiendo vagamente la recomendación de esta respuesta en el hilo Kubernetes memory consumption explosion.
Una de las cosas que más me sorprenden de Kubernetes es que es necesario instalar una capa de red sobre el clúster.
En el caso concreto del que he obtenido las capturas de pantalla, el clúster corre sobre máquinas virtuales con Debian Jessie.
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.