Este artículo es la cuarta parte de nuestra serie sobre la protección de datos en Kubernetes:
1. Protección de Datos en Kubernetes con Kasten K10
2. Instalación y configuración de Kasten K10: Paso a Paso
3. Respaldo y restauración de aplicaciones en Kubernetes
4. Migrar una aplicación entre clusters de Kubernetes con Kasten K10

Para terminar nuestra serie de protección de datos, migraremos una aplicación en Kubernetes entre distintos clusters usando Kasten. Migraremos la aplicación del cluster local de minikube hacia un cluster en Amazon Web Services usando el servicio de EKS. Será necesario crear una cuenta y generar un par de llaves de acceso.

Para la movilidad de aplicaciones es necesario instalar Kasten en el cluster destino. Durante este post realizaremos la instalación del nuevo cluster y las configuraciones necesarias en ambos clusters para que compartan respaldos.

Exportar el respaldo en el cluster origen

Para exportar el respaldo y que pueda ser usado por otro cluster, crearemos un Perfil de Ubicación.

Estos se utilizan para crear copias de seguridad a partir de instantáneas, mover aplicaciones y sus datos entre clústeres y potencialmente entre diferentes nubes, y posteriormente importar estas copias de seguridad o exportaciones en otro clúster.

Kasten tiene soporte para los siguientes proveedores de almacenamiento de objetos:

• Amazon S3 o Almacenamiento Compatible con S3
• Almacenamiento de Azure
• Google Cloud Storage

K10 crea repositorios de Kopia en estas ubicaciones de almacenamiento de objetos. K10 utiliza Kopia como un transportador de datos que proporciona soporte implícito para deduplicar, cifrar y comprimir datos en reposo. K10 realiza mantenimiento periódico en estos repositorios para recuperar el almacenamiento liberado.

Para crear el perfil es necesario crear un bucket de almacenamiento. Crealo por línea de comandos o en la consola de AWS.

Para crear un perfil de ubicación, haz clic en “New profile”:

Elegimos la opción de S3 y completamos los datos del bucket que recién creamos, en este caso el bucket se llama backups-kasten.

Ahora, vamos a la aplicación, y elegimos la opción de exportar el respaldo:

Simplemente confirmamos el formulario:

Una vez que la exportación se completé, veremos el siguiente cuadro de dialogo:

Es muy importante tomar nota del ID que se genera, esto es necesario para poder importar el respaldo en el cluster destino. Resguarda el ID copiandolo.

Ahora estamos listos para importar el respaldo en otro cluster, crearemos el perfíl de ubicación tal cual lo hicimos en el origen, para que se pueda restaurar la aplicación en ese cluster.

Primero, desplegaremos el nuevo cluster e instalaremos Kasten ahí.

Desplegar cluster de EKS

Antes de comenzar con nuestro viaje en EKS, asegúrate de tener lo siguiente:

Cuenta de AWS: Si no tienes una, regístrate para obtener una cuenta de AWS.

AWS CLI y kubectl: Instala AWS CLI y eksctl en tu máquina local.

Permisos de IAM: Asegúrate de que tu usuario de IAM tenga los permisos necesarios para crear y gestionar clústeres de EKS. (https://docs.aws.amazon.com/eks/latest/userguide/service_IAM_role.html) para más detalles.

Paso 1: Configurar AWS CLI
Ejecuta el siguiente comando para configurar AWS CLI con tus credenciales:

aws configure

Ingresa tu ID de clave de acceso de AWS, tu clave secreta de acceso, el nombre de la región por defecto y el formato de salida.

Desplegaremos el cluster de EKS con el siguiente comando:

eksctl create cluster --version 1.29 --region us-east-2 --node-type t3.medium	 --nodes 1

Una vez que el cluster esté listo, podrás ver una salida similar a esta:

2024-08-13 17:54:47 [✔]  all EKS cluster resources for "ridiculous-wardrobe-1723592414" have been created
2024-08-13 17:54:47 [✔]  created 0 nodegroup(s) in cluster "ridiculous-wardrobe-1723592414"
2024-08-13 17:54:47 [ℹ]  nodegroup "ng-7e0a5774" has 1 node(s)
2024-08-13 17:54:47 [ℹ]  node "ip-192-168-55-195.us-east-2.compute.internal" is ready
2024-08-13 17:54:47 [ℹ]  waiting for at least 1 node(s) to become ready in "ng-7e0a5774"
2024-08-13 17:54:47 [ℹ]  nodegroup "ng-7e0a5774" has 1 node(s)
2024-08-13 17:54:47 [ℹ]  node "ip-192-168-55-195.us-east-2.compute.internal" is ready
2024-08-13 17:54:47 [✔]  created 1 managed nodegroup(s) in cluster "ridiculous-wardrobe-1723592414"
2024-08-13 17:54:48 [ℹ]  kubectl command should work with "/home/guillermo/.kube/config", try 'kubectl get nodes'
2024-08-13 17:54:48 [✔]  EKS cluster "ridiculous-wardrobe-1723592414" in "us-east-2" region is ready

Finalmente, para usar kubectl con este nuevo cluster:

aws eks --region us-east-2 update-kubeconfig --name ridiculous-wardrobe-1723592414
Added new context arn:aws:eks:us-east-2:339712754066:cluster/ridiculous-wardrobe-1723592414 to /home/guillermo/.kube/config

Listamos los nodos del cluster para verificar que el CLI está autenticado:

kubectl get nodes
NAME                                           STATUS   ROLES    AGE    VERSION
ip-192-168-55-195.us-east-2.compute.internal   Ready    <none>   4m7s   v1.29.6-eks-1552ad0

Instalar Kasten en cluster de EKS

Para instalar k10 es necesario tener instalado Helm. Primero, añade el repositorio de Helm de Kasten con el siguiente comando:

helm repo add kasten https://charts.kasten.io/

Antes de instalar Kasten K10, es recomendable realizar algunas verificaciones previas con la herramienta primer y kasten nos otorga un script para hacero. Esta herramienta se ejecuta en un pod del clúster y realiza las siguientes operaciones:

• Validación de Configuraciones: Verifica si las configuraciones de Kubernetes cumplen con los requisitos de K10.
• Catalogación de StorageClasses: Lista las StorageClasses disponibles.
• Validación de Capacidades CSI: Si existe un provisionador CSI, realiza una validación básica de las capacidades CSI del clúster y de cualquier objeto relevante requerido. Se recomienda encarecidamente usar la misma herramienta para una validación más exhaustiva de CSI siguiendo la documentación proporcionada.

Este script de verificación creará y posteriormente eliminará una ServiceAccount y ClusterRoleBinding para realizar comprobaciones de sanidad en el clúster de Kubernetes. La herramienta primer asume que Helm 3 está instalado y que el repositorio de Kasten Helm Charts está configurado.

Ejecuta el siguiente comando para desplegar la herramienta de verificación previa:

curl https://docs.kasten.io/tools/k10_primer.sh | bash

La salida esperada es como esta:

$ curl https://docs.kasten.io/tools/k10_primer.sh | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 10747  100 10747    0     0  93663      0 --:--:-- --:--:-- --:--:-- 94271
Namespace option not provided, using default namespace
Checking for tools
 --> Found kubectl
 --> Found helm
 --> Found jq
 --> Found cat
 --> Found base64
 --> Found tr
Checking if the Kasten Helm repo is present
 --> The Kasten Helm repo was found
Checking for required Helm version (>= v3.11.0)
 --> Helm binary version meet the requirements
K10Primer image
 --> Using Image (gcr.io/kasten-images/k10tools:7.0.6) to run test
Checking access to the Kubernetes context arn:aws:eks:us-east-2:339712754066:cluster/exciting-creature-1723594361
 --> Able to access the default Kubernetes namespace
K10 Kanister tools image
 --> Using Kanister tools image (gcr.io/kasten-images/k10tools:7.0.6) to run test

Running K10Primer Job in cluster with command
     ./k10tools primer 
serviceaccount/k10-primer created
clusterrolebinding.rbac.authorization.k8s.io/k10-primer created
job.batch/k10primer created
Pod k10primer-rmvml is in Pending phase
Pod k10primer-rmvml is in Pending phase
Pod Ready!
================================================================
Kubernetes Version Check:
  Valid kubernetes version (v1.29.7-eks-2f46c53)  -  OK

RBAC Check:
  Kubernetes RBAC is enabled  -  OK

Aggregated Layer Check:
  The Kubernetes Aggregated Layer is enabled  -  OK

CSI Capabilities Check:
  VolumeSnapshot CRD-based APIs are not installed  -  Error

Validating Provisioners: 
kubernetes.io/aws-ebs:
  Storage Classes:
    gp2
      Valid Storage Class  -  OK

Validate Generic Volume Snapshot:
  Pod created successfully  -  OK
  GVS Backup command executed successfully  -  OK
  Pod deleted successfully  -  OK
================================================================
serviceaccount "k10-primer" deleted
clusterrolebinding.rbac.authorization.k8s.io "k10-primer" deleted
job.batch "k10primer" deleted

Podemos observar un error indicando lo siguiente:

VolumeSnapshot CRD-based APIs are not installed - Error


Para resolverlo, instalaremos el plugin del controlador de snapshots:

eksctl create addon --cluster exciting-creature-1723594361 --name aws-ebs-csi-driver --version latest --profile kasten

eksctl create addon --cluster exciting-creature-1723594361 --name snapshot-controller --version latest

Ahora la salida del script de validación debe ser:

Kubernetes Version Check:
  Valid kubernetes version (v1.29.7-eks-2f46c53)  -  OK

RBAC Check:
  Kubernetes RBAC is enabled  -  OK

Aggregated Layer Check:
  The Kubernetes Aggregated Layer is enabled  -  OK

CSI Capabilities Check:
  Using CSI GroupVersion snapshot.storage.k8s.io/v1  -  OK

Validating Provisioners: 
kubernetes.io/aws-ebs:
  Storage Classes:
    gp2
      Valid Storage Class  -  OK

Validate Generic Volume Snapshot:
  Pod created successfully  -  OK
  GVS Backup command executed successfully  -  OK
  Pod deleted successfully  -  OK
================================================================
serviceaccount "k10-primer" deleted
clusterrolebinding.rbac.authorization.k8s.io "k10-primer" deleted
job.batch "k10primer" deleted

Ahora si después de pasar la validación, instalamos Kasten:

helm install k10 kasten/k10 --replace --namespace=kasten-io --set secrets.awsAccessKeyId="${AWS_ACCESS_KEY_ID}" --set secrets.awsSecretAccessKey="${AWS_SECRET_ACCESS_KEY}"

Importar respaldo

Para importar el respaldo en el cluster destino crearemos un Perfil de Ubicación tal cual lo hicimos en los pasos previos de este articulo cuando lo creamos para exportar el respaldo desde el cluster origen.

Una vez creado el perfil de ubicación, crearemos una politica que nos permita importar el respado. Vamos al menú de policies y creamos una:

Asignamos un nombre y como acción definimos que es una politica de import, en la frecuencia seleccionaremos On Demand, para ejecutarla cuando lo deseemos en lugar de hacerlo en una hora establecida.

En este punto, necesitaremos colocar en el campo Config Data for Import el valor que obtuvimos cuando hicimos la exportación del respaldo. Cuando lo colocamos nos despliega el perfil de ubicación de donde traerá el respaldo, lo tenemos que seleccionar.

Una vez creada, podremos ejecutarlo desde la opción Run Once:

Una vez que se ejecute, tendremos disponible un Restore Point para poder restaurar la aplicación.

Restaurar respaldo

Seleccionamos el punto de restauración y agregamos una transformación:

Elegiremos un nombre para la transformación y en las operaciones seleccionamos Replace, esto es que queremos reemplazar una definición. En nuestro caso es el storageclass del PVC.

Para el resource elegiremos:

persistentvolumeclaims

En el path colocamos:

/spec/storaClassName

En el valor elegiremos:

"gp2"

Con esto estamos reemplazando el storage class origen con el que está disponible en el destino. Es común que esto suceda entre diferentes clusters de Kubernetes.

Sobre los recursos a restaurar, omitiremos el storage class pues no nos interesa restaurarlo, así que no lo seleccionaremos:

Finalmente restauramos y al terminar podemos ver los recursos en el cluster:

$ kubectl get all  -n php-app
NAME                           READY   STATUS    RESTARTS   AGE
pod/mysql-5fdc4d7b9c-jmmwx     1/1     Running   0          5m30s
pod/php-app-5849f8b4d6-bbmfj   1/1     Running   0          5m30s

NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
service/mysql     ClusterIP   None            <none>        3306/TCP       6m34s
service/php-app   NodePort    10.100.253.58   <none>        80:32185/TCP   6m34s

NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/mysql     1/1     1            1           5m30s
deployment.apps/php-app   1/1     1            1           5m30s

NAME                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/mysql-5fdc4d7b9c     1         1         1       5m30s
replicaset.apps/php-app-5849f8b4d6   1         1         1       5m30s

De esta forma es que podemos explotar las funcionalidades de Kasten para migrar aplicaciones de un cluster origen a un o destino, en nuestro caso desde minikube hacia AWS EKS.

Para validar la aplicación en el nuevo cluster, hacemos la redirección del servicio hacia nuestro localhost con el comando:

kubectl --namespace php-app port-forward service/php-app 8000:80

Al ingresar a localhost:8000

La aplicación tiene los mismos datos que cuando se tomó el respaldo.

Con esto termina nuestra serie de posts sobre Kasten K10 en cuanto a sus funcionalidades principales y logramos hacer un ejercicio de inicio a fin.

Resumen:

1. Protección de Datos en Kubernetes con Kasten K10: Conceptos introductorios de Kasten.

2. Instalación y configuración de Kasten K10: Paso a Paso: Instalamos un laboratorio local de kubernetes con Minikube y realizamos la instalaciónde Kasten.

3. Respaldo y restauración de aplicaciones en Kubernetes: Desplegamos una aplicación ejemplo y realizamos el respaldo y posterior restauración.

4. Migrar una aplicación entre clusters de kubernetes con Kasten K10: . Exportamos un respaldo de la aplicación desde el cluster origen hacia S3, instalamos un nuevo cluster esta vez en AWS EKS, instalamos Kasten en el nuevo cluster e importamos el respaldo para migrar la aplicación entre clusters.

Realiza el tutorial completo y si tienes dudas no dejes de escribirnos.