Photo by Mabel Amber
Velero es una herramienta de código abierto que permite realizar copias de seguridad, restaurarlas y migrar recursos de Kubernetes entre clústers (lo que también permite recuperar un clúster en caso de desastre).
Velero soporta diferentes proveedores en los que almacenar las copias de seguridad que realiza. La lista completa y actualizada se encuentra en Providers. En mi caso, voy a utilizar MinIO, que es compatible con AWS S3 y que tengo desplegado localmente en Kubernetes.
Al hacer limpieza de uno de los clústers de desarrollo, he borrado dos namespaces y los dos se han quedado en estado Terminating
Idealmente, el análisis de los ficheros de definición de objetos (YAML) en Kubernetes debería realizarse antes de crear los objetos en el clúster. Para ello, uno de los stages del proceso de CI/CD debería incorporar KubeLinter (por ejemplo).
De forma paralela, también deberíamos tener un proceso periódico que revise los ficheros de definición de los objetos que tenemos almacenados en el repositorio para identificar, por ejemplo, el uso de versiones de la API desaconsejadas (deprecated) en proceso de eliminación de la API.
En este artículo vemos cómo configurar un Cronjob que ejecute KubeLinter para obtener los ficheros de un repositorio remoto y analizarlos.
La mayoría de los recursos de Kubernetes como los pods, los services, los replication controllers, etc están limitados al namespace en el que se despliegan. Así, dos recursos pueden tener el mismo nombre, etc si se encuentran en namespaces diferentes, ya que el namespace define el alcance de visibilidad para el recursos. El namespace es el límite del scope del recurso en Kubernetes.
Sin embargo, no todos los recursos en Kubernetes se encuentran “limitados” por el namespace; por ejemplo, el propio recurso namespace no está en un namespace, ni los persistentVolumes tampoco…
¿Cómo podemos obtener una lista de los recursos con alcance restringido al namespace en el que se encuentran?
Ya he hablado varias veces de Gitea en este sitio, así que no me repetiré (mucho) ; Gitea es una solución ligera de alojamiento de repositorios Git (a lo GitHub).
En esta entrada se indica el proceso que he seguido para la creación de los diferentes objetos necesarios para desplegar Gitea (usando SQLite como base de datos) en Kubernetes.
Puedes seguir los pasos de la documentación oficial para desplegar Gitea sobre Kubernetes usando Helm.
K3OS (y K3s) despliega Traefik como Ingress. Pero el problema es que el certificado autofirmado configurado por defecto caducó en 2017.
Probablemente se trata de una feature y no de un bug, para “animar” a cambiar el certificado desplegado por defecto por uno válido; en este artículo explico cómo hacerlo.
Hace unos días leía More Problems with GitOps — and How to Fix Them sobre los problemas asociados a GitOps, así que aprovecho para inaugurar esta nueva sección de reflexiones sobre artículos que considero interesantes.
Ya hace casi dos meses de la última entrada en el blog; en esta entrada explico en qué he estado trabajando y qué me ha mantenido apartado de la publicación en el blog.
Uno de los problemas de los entornos de laboratorio es que son fungibles, casi de “usar y tirar”. Un efecto colateral es que cosas como las credenciales no se gestionan correctamente, se pone la primera que se nos ocurre y después… pues no hay manera de volver a acceder.
En mi caso me he encontrado en esta situación con Gitea y en esta entrada voy a documentar cómo establecer una nueva contraseña para el usuario administrador.
Una de las cosas que no me resultó evidente al empezar a usar K3OS es que el sistema de ficheros tiene algunas particularidades con las que es absolutamente necesario estar familiarizado; por ejemplo, que toda la carpeta /etc es EFÍMERA.
