RKE

Tema:

Restauracion de Rancher Kubernetes Engine v2

Introducción

La restauracion de Rancher kubernetes Engine es un proceso de suma importancia y debe de ser la manera en la que se recupera el estado de un cluster en un momento determinando, este procedimiento nos asegura que tenemos una forma para volver al estado anterior que esta totalmente soportada.

Muchas veces cuando se prueban actualizaciones de componentes o del mismo cluster ya sea la version de rancher o la version RKE2, puede que el cluster muestre comportamientos extraños como puede ser apis de kubernetes que fueron removidas y era utilizadas o componentes no compatibles con nuevas versiones o incluso peor que el cluser haya quedado inutilizado.

En este tema, veremos el proceso para poder primeramente realizar backups de nuestro cluster y en segunda instancia como restaurar esos backups en el mismo cluster.

Objetivo

Objetivo General:

Capacitar a los administradores de sistemas y equipos de DevOps en el proceso de backup y restauracion de Rancher Kubernetes Engine v2 (RKE2), asegurando que puedan llevar a cabo restauraciones de manera segura y eficiente. El objetivo es proporcionar los conocimientos y las mejores prácticas necesarios para planificar, ejecutar y verificar los backups de RKE2, garantizando que en el caso de un desastre se pueda restaurar el cluster con el menor tiempo de inactividad posible y manteniendo todas las configuraciones realizadas.

Laboratorio: Respaldo y Restauración de Rancher Kubernetes Engine v2

Antes de comenzar

Contar con el acceso al ambiente de laboratorio
Haber realizado la validación de conexión y funcionamiento
Finalizar las prácticas de laboratorio de las instalaciones de RKE2.

Inicio de laboratorio

Asegurarse de estar en el servidor bastion con el usuario student

student@lab-0-bastion:~>

Establecer una sesión como el usuario student al servidor: lab-#-master

student@lab-0-bastion:~> export LAB=X

student@lab-0-bastion:~> ssh student@lab-${LAB}-master

Cambiar al usuario root
```
student@lab-0-master:~> sudo -i
```
Los backups de rke2 se realizan tomando el estado de la base de datos del etcd, esta base de datos tiene el estado completo del cluster en el momento que se toma el snapshot. Aunque si bien es posible restaurar un cluster con snapshots a nivel de sistem operativo , esto es algo que no es recomendado pues no es un proceso transparente ni soportado. Estos backups por defecto son guardados en cada nodo control plane en el directorio de /var/lib/rancher/rke2. Como dato adicional la manera ideal de manejar estos snapshots es guardandolos en un storage de s3 como minio o aws cada cierto tiempo, como por ejemplo un backup diario. Adicionalmente si tenemos un cluster con varios nodos de etcd, se generara un snapshot en cada uno de estos, no hay diferencia mas de que nodo se ha tomado. Vamos a ingresar a la siguiente ubicacion y vamos a revisar los archivos que existen
```
cd /var/lib/rancher/rke2/server/db/snapshots
ls
```
Vamos a ver un archivo o varios con el nombre etcd-snapshot-* , este es un snapshot de rke2 que se toma por defecto cada 12 horas.
Ahora vamos a crear un nuevo snapshot manual de etcd con el siguiente comando.
```
rke2 etcd-snapshot save --name before-nginx
```
Este comando genera un snapshot en el directorio que nos encontramos con el prefijo de before-nginx. Ejecutar el siguinete comando para determinar la ubicación backup:
```
find /var/lib/rancher/rke2/server/ -name '*before-nginx*
```
Salida Ejemplo:
```
/var/lib/rancher/rke2/server/db/snapshots/before-nginx-lab-0-master.c.mx-g01.internal-XXXXX
```
Tomar nota de la ubicación del backup.

Ahora que tenemos un snapshot de nuestro cluster 1, vamos a crear una carga de trabajo en el cluster . Nos movemos al bastion con el usuario student y nos conectamos al cluster.

export KUBECONFIG=/home/student/rke2_conn/cluster1/cluster1_kubeconfig.yaml

Luego usaremos los siguientes comandos.

kubectl create ns nginx
kubectl create deployment nginx -n nginx --image=nginx

Obtenemos los pods del ns nginx

kubectl get pods -n nginx

NAME                     READY   STATUS    RESTARTS   AGE
nginx-76bff49d69-dpg59   1/1     Running   0          101s

En este punto tenemos un nuevo recurso creado en nuestro cluster desde que hicimos nuestro snapshot, en este caso vamos a realizar una restauracion al snapshot que tomamos donde no existian los recursos creados anteriormente. Para eso vamos a ejecutar los siguientes comandos.
```
systemctl stop rke2-server #Detenemos el servicio de rke2
```
```
rke2 server --cluster-reset \ 
--cluster-reset-restore-path="/var/lib/rancher/rke2/server/db/snapshots/before-nginx-lab-0-master.c.mx-g01.internal-XXXXX"
# Colocar la ubicación absoluta correcta del backup
```
Esperamos a que el restore finalize hasta que nos de un mensaje como el siguiente
```
Managed etcd cluster membership has been reset, restart without --cluster-reset flag now. Backup and delete ${datadir}/server/db on each peer etcd server and rejoin the nodes
```
Una vez veamos este mensaje podemos iniciar el proceso de rke2 nuevamente
```
systemctl start rke2-server
```
Si el ambiente de rancher no conecta despues de 5 a 10 minutos podemos eliminar todos los pods del cluster con el comando.
```
kubectl delete pods --all -A
```
Obtenemos los pods del namespace nginx con el siguiente comando
```
kubectl get pods -n nginx
```
No debería de existir el Namespace ni el deployment realizado antes del Snapshot

Conclusión

En este tema, abordamos el proceso de restauración de Rancher Kubernetes Engine v2 (RKE2), un aspecto crucial para garantizar la continuidad del negocio y la resiliencia de las aplicaciones desplegadas en clústeres Kubernetes gestionados con RKE2.

La restauración de un clúster RKE2 es un componente crítico de la administración de Kubernetes. Una estrategia efectiva de respaldo y recuperación no solo minimiza el tiempo de inactividad, sino que también protege contra la pérdida de datos y garantiza la continuidad operativa.

Comprender y practicar el proceso de restauración prepara a los administradores para responder eficazmente a situaciones de desastre, fortaleciendo la resiliencia del ecosistema y brindando confianza en la capacidad del clúster para soportar fallos inesperados. Este conocimiento es fundamental para operar entornos productivos de manera confiable y segura.