Aclaración, este método solo funciona durante 30 días después del borrado.

Si estamos desplegando en Kubernetes en probable que si algo sale mal y necesitamos hacer troubleshooting, entre las herramientas más útiles (quitando los logs) poder ejecutar un comando o “entrar” en un container puede ser muy útil. El problema es si nuestro ejecutable es el que hace que el Pod se reinicie y no podemos obtener acceso al bash del Pod, una forma de solucionar eso es sobre-escribir el comando por defecto, vamos a hablar de eso.

Los Pods en Kubernetes utilizan imágenes, y lo más probable es que estas imágenes estén en un registro fuera del cluster, y lo segundo más probable es que necesite autenticación. Entonces nos encontramos con la pregunta “Cómo hago para que un Pod o Deployment en Kubernetes se autentique para descargar una imagen desde un repositorio que no es público?”. Bien, es post es acerca de cómo resolver este caso en Azure Container Registry, pero podría ser cualquier otro repository.

oAuth es prácticamente la opción más utilizada para securizar aplicaciones modernas por diferentes motivos, éste es el primer de una serie de post sobre oAuth2, intentando aclarar cada concepto paso a paso. Si bien es un tema bastante complejo pero también muy importante y en lo personal creo que todo desarrollador debería comprenderlo bien.

En el post anterior Agregamos Persisten Volumens y Persisten Volume Claims para tener un persistencia más allá del ciclo de vida de los Pods, en este Post vamos a mover la configuración a ConfigMaps y Secrets.

En el post anterior vimos cómo ejecutar Wordpress (Wordpress + MySQL) en Kubernetes, del modo más básico, solo con dos Pods separados. En este post vamos a poner la persistencia en elementos externos (volúmenes) para que los datos tengan un ciclo de vida separado de los Pods.