Photo by Mabel Amber
En la entrada Gogs - Cómo crear tu propio servicio de hospedaje de repositorios Git describía cómo montar un servicio como GitHub usando Gogs.
Hoy he intentado montar lo mismo sobre la Raspberry Pi aprovechando que Gogs ofrece una imagen específica: gogs/gogs-rpi,
En la entrada anterior API server detenido: The connection to the server was refused encontré problemas con la tarjeta microSD que sirve de almacenamiento para el nodo master del clúster de Kubernetes.
La solución al problema pasaba por realizar un análisis de la tarjeta para repararla. Sin embargo, al intentarlo, no ha habido manera de formatear y reinstalar HypriotOS sobre la tarjeta.
El fallo de la tarjeta de memoria ha sido la gota final que me ha hecho abandonar el clúster multinodo en las Raspberry Pi (de momento). Así que he decidido instalar un clúster de un solo nodo en una de las Raspberri Pi 3.
En este artículo sigo las instrucciones oficiales para construir un clúster de Kubernetes usando kubeadm: Using kubeadm to Create a Cluster
En las entradas anteriores he descrito los problemas -tanto conceptuales como técnicos- que he encontrado al intentar llevar Dokuwiki a un contenedor.
En este artículo explico los pasos a seguir para construir una imagen con Caddy server y PHP, de manera que puedas servir tus aplicaciones PHP usando contenedores.
En la entrada anterior Dokuwiki en un contendor dejaba constancia de los problemas que encontré creando una imagen para ejecutar Dokuwiki en un contenedor.
Al final de la entrada indicaba que la creación de la misma imagen, pero para ARM sería tan sencillo como cambiar la imagen base. Pues no.
Como he tenido que revisar a fondo los pasos que seguí -en particular para configurar la carpeta desde donde Caddy publica los ficheros-, he introducido algunos cambios que simplifiquen y mejoren el uso de la imagen.
dnsmasq es un servidor de nombres de dominio (DNS) ligero y sencillo.
En esta entrada indico cómo ejecutar dnsmasq en un contenedor usando Docker.
En la entrada Troubleshooting Kubernetes (II) encontré restos de la instalación de Flannel en la Raspberry Pi. Eliminé los pods que hacían referencia a Flannel y conseguí que el nodo k2 no se volviera a colgar.
Sin embargo, el problema sigue dándose en el nodo k3.
Revisando el contenido de /var/lib/kubernetes/pods/ he visto que algunos pods hacían referencia, todavía, a Flannel.
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.
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
