Photo by Mabel Amber
No soy muy fan de insertar imágenes con capturas de pantalla en las entradas que escribo, excepto cuando es estrictamente necesario. Además, por la naturaleza de este blog y los temas que trato, para ilustrar es suficiente con copiar y pegar el texto de la consola o del editor de texto. Pero de vez en cuando, es necesario insertar una imagen… Y de pronto, las imágenes han desaparecido del blog.
Velero realiza copias de seguridad (puntuales o recurrentes) para recuperarnos con rapidez de un desastre en el clúster de Kubernetes.
En la entrada anterior Velero - Backup y Disaster Recovery para Kubernetes (II) Crear copia de seguridad desplegamos una aplicación de prueba en el clúster (dos réplicas de Nginx en el Namespace nginx-example). Simulamos la pérdida “accidental” del Namespace nginx-example para ver cómo recuperarnos usando la copia creada por Velero.
En la entrada anterior Velero - Backup y Disaster Recovery para Kubernetes (I) Instalación vimos cómo instalar Velero en Kubernetes. Usamos el comando velero install lanzado desde un Job en la línea de la filosofía GitOps.
En esta entrada veremos cómo crear copias de seguridad puntuales y recurrentes usando la herramienta de línea de comandos velero (lanzada desde un Job)
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.
En la entrada anterior, MinIO en Kubernetes, explicaba cómo desplegar MinIO en Kubernetes (de forma manual).
mc se puede usar como herramienta de línea de comandos o como contenedor minio/mc; sin embargo, en esta entrada veremos cómo usarlo en Jobs de Kubernetes para configurar el alias de un servidor de MinIO y crear un bucket.
MinIO proporciona almacenamiento de objetos compatible con AWS S3. Desde la última vez que revisé este producto, MinIO ha crecido hasta convertirse en una solución de calidad empresarial.
También han cambiado el logo, y por lo que veo, el “flamenco” o lo que sea el animal del logo ha quedado relegado al
favicony el footer de la página web…Yo mantendré por ahora el logo “antiguo” (que curiosamente, tiene al pájaro mirando hacia la izquierda¯\_(ツ)_/¯)
En este artículo, voy a desplegarlo sobre Kubernetes de forma manual con un sólo servidor. Usaremos el almacenamiento en MinIO como destino de las copias de seguridad del clúster de Kubernetes usando Velero (en un próximo artículo).
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.
En la entrada anterior KubeLinter: identifica malas configuraciones en los objetos de Kubernetes, KubeLinter identificaba dos errores que se solucionan usando las opciones: runAsUser y readOnlyRootFilesystem.
En esta entrada comparo los efectos de aplicar una u otra, así como qué pasa cuando se aplican las dos al mismo tiempo.
