Photo by Mabel Amber
Para tener un clúster de desarrollo con la versatilidad de poder hacer y deshacer cambios (usando los snapshots de una máquina virtual), lo más sencillo es disponer de un clúster de Kubernetes de un solo nodo.
En la pantalla de login en modo consola de los sistemas Linux se muestra un mensaje de bienvenida.
En este artículo se muestra cómo hacer que se muestre la IP del equipo.
Alpine Linux se ha convertido en la distribución por defecto con la que construir contenedores.
Alpine tiene sus propias particularidades, ya que no deriva de otra distribución, de manera que he pensado que sería una buena idea tener una máquina virtual con la que entrenarme.
En este artículo explico qué diferencias he encontrado en Alpine.
Después de estabilizar el clúster, el siguiente paso es poner en marcha aplicaciones. Pero ¿qué es exactamente lo que hay que desplegar?: ¿pods?, ¿replication controllers?, ¿deployments?
Muchos artículos empiezan creando el fichero YAML para un pod, después construyen el replication controller, etc… Sin embargo, revisando la documentación oficial, crear pods directamente en Kubernetes no tiene mucho sentido.
En este artículo intento determinar qué objetos son los que deben crearse en un clúster Kubernetes.
YAML es el lenguaje en el que se definen los pods, los deployments y demás estructuras en Kubernetes. Todos los artículos que he leído sobre cómo crear un fichero de definición del pod (deployment, etc) se centran en el contenido del fichero.
Pero en mi caso, echaba de menos una explicación de cómo se crea el fichero, qué reglas se siguen a la hora de describir la configuración en formato YAML.
Afortunadamente el lenguaje YAML es muy sencillo y basta con conocer un par de estructuras para crear los ficheros de configuración de Kubernetes.
El proceso desde la creación a la ejecución del contenedor se puede separar en varias fases:
Dockerfile)Para tener los diferentes ficheros implicados en el proceso organizados de forma homogénea, me he autoimpuesto las siguientes reglas a la hora de estructurar los repositorios.
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.
En el artículo Habilita el API remoto de Docker explicaba cómo configurar el acceso remoto al API de Docker. El problema es que de esta forma no hay manera de restringir el acceso.
En este artículo protegemos el acceso usando TLS de manera que sólo se permitan conexiones que presenten un certificado firmado por una CA de confianza.
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.