Introducción
En este tutorial, aprenderás cómo implementar TrilioVault para Kubernetes (o TVK) en tu clúster DOKS, crear copias de seguridad y recuperarte de una copia de seguridad en caso de algún problema. Puedes respaldar todo tu clúster, o elegir opcionalmente copias de seguridad basadas en espacio de nombres o etiquetas.
Ventajas de usar Trilio:
- Realiza copias de seguridad completas (o incrementales) de tu clúster y restaura en caso de pérdida de datos.
- Migra de un clúster a otro.
- Se admiten copias de seguridad de lanzamientos de Helm.
- Ejecuta pre y post-hooks para operaciones de copia de seguridad y restauración.
- Consola de gestión web que te permite inspeccionar detalladamente el estado de tus operaciones de copia de seguridad/restauración.
- Define políticas de retención para tus copias de seguridad.
- El ciclo de vida de la aplicación (es decir, TVK en sí mismo) puede ser gestionado a través de un Operador TrilioVault dedicado.
- Integración con Velero.
- Puedes respaldar y restaurar aplicaciones basadas en operadores.
Para obtener más información, consulta la documentación oficial de TVK CRDs.
Tabla de Contenidos
- Requisitos previos
- Paso 1 – Instalación de TrilioVault para Kubernetes
- Paso 2 – Creación de un destino de TrilioVault para almacenar copias de seguridad
- Paso 3 – Conociendo la consola de gestión web de TVK
- Paso 4 – Ejemplo de copia de seguridad y restauración a nivel de espacio de nombres
- Paso 5 – Ejemplo de copia de seguridad y restauración de todo el clúster
- Paso 6 – Copias de seguridad programadas
- Paso 7 – Política de retención de copias de seguridad
- Conclusión
Prerequisites
Para completar este tutorial, necesitas lo siguiente:
- A DO Spaces Bucket and access keys. Save the access and secret keys in a safe place for later use.
- A Git client to clone the Starter Kit repository.
- Helm, para gestionar las versiones y actualizaciones del Operador TrilioVault.
- Doctl para la interacción con la API de DigitalOcean.
- Kubectl para la interacción con Kubernetes.
Para que TrilioVault funcione correctamente y respalde sus PVC, DOKS necesita estar configurado para admitir la Interfaz de Almacenamiento de Contenedores (o CSI por sus siglas en inglés). Por defecto, viene con el controlador ya instalado y configurado. Puede verificar usando el siguiente comando:
La salida debería lucir similar al siguiente fragmento. Observe que el proveedor es dobs.csi.digitalocean.com.
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
do-block-storage (default) dobs.csi.digitalocean.com Delete Immediate true 10d
La instalación de TrilioVault también necesita la Definición de Recurso Personalizado (CRD) volumeSnapshot para una instalación exitosa. Puede verificar usando el siguiente comando:
La salida debería lucir similar al siguiente fragmento. Si la CRD VolumeSnapshot no está instalada, consulte Instalación de CRDs de VolumeSnapshot.
volumesnapshotclasses.snapshot.storage.k8s.io 2022-02-01T06:01:14Z
volumesnapshotcontents.snapshot.storage.k8s.io 2022-02-01T06:01:14Z
volumesnapshots.snapshot.storage.k8s.io 2022-02-01T06:01:15Z
También, asegúrese de que la CRD admita tanto las versiones de API v1beta1 como v1. Puede ejecutar el siguiente comando para verificar la versión de la API:
Al final del YAML de la CRD, debería ver una lista storedVersions, que contenga tanto los valores v1beta1 como v1 (si no está instalado, consulte Instalación de CRDs de VolumeSnapshot):
...
- lastTransitionTime: "2022-01-20T07:58:06Z"
message: approved in https://github.com/kubernetes-csi/external-snapshotter/pull/419
reason: ApprovedAnnotation
status: "True"
type: KubernetesAPIApprovalPolicyConformant
storedVersions:
- v1beta1
- v1
Paso 1 – Instalación de TrilioVault para Kubernetes
En este paso, aprenderás cómo implementar TrilioVault para DOKS y administrar las instalaciones de TVK a través de Helm. Los datos de respaldo se almacenarán en el depósito DO Spaces creado anteriormente en la sección Prerrequisitos.
La aplicación TrilioVault se puede instalar de muchas maneras:
- Mediante el Operador TrilioVault. Defines un CRD
TrilioVaultManagerque le indica al operadorTrilioVaultcómo manejar la instalación, los pasos de postconfiguración y las futuras actualizaciones de los componentes de la aplicación Trilio. - Mediante el gráfico triliovault-operator que está completamente gestionado por Helm (cubierto en este tutorial).
Instalación de TrilioVault usando Helm
El tutorial del Starter Kit utiliza el tipo de instalación de clúster para la aplicación TVK (el valor de Helm applicationScope se establece en “Cluster”). Todos los ejemplos de este tutorial dependen de este tipo de instalación para funcionar correctamente.
Primero, clona el repositorio Git del Starter Kit y cambia al directorio de tu copia local:
A continuación, agrega el repositorio Helm de TrilioVault y lista los gráficos disponibles:
La salida se verá similar a la siguiente:
NAME CHART VERSION APP VERSION DESCRIPTION
triliovault-operator/k8s-triliovault-operator 2.9.2 2.9.2 K8s-TrilioVault-Operator is an operator designe...
El gráfico de interés es triliovault-operator/k8s-triliovault-operator, que instalará TrilioVault para Kubernetes en el clúster junto con TrilioVault-Manager. Puede ejecutar helm show values triliovault-operator/k8s-triliovault-operator y exportarlo a un archivo para ver todas las opciones disponibles.
Luego, abra e inspeccione el archivo de valores de Helm de TrilioVault proporcionado en el repositorio del kit de inicio usando un editor de su elección (preferiblemente con soporte para lint de YAML).
Finalmente, instale TrilioVault para Kubernetes usando Helm:
–create-namespace \
El comando anterior instala tanto el Operador de TrilioVault como el Recurso Personalizado TriloVault Manager (TVM) utilizando los parámetros proporcionados en el archivo triliovault-values.yaml. La versión de TVK ahora está gestionada por el campo tag en el archivo 05-setup-backup-restore/assets/manifests/triliovault-values.yaml, por lo que el comando helm siempre tiene la última versión de TVK.
- Puede actualizar los siguientes campos en
values.yaml: installTVK.applicationScopepara la instalación de TVK en el ámbito, por ejemplo,ClusteroNamespacedinstallTVK.ingressConfig.hostpara el nombre de host de la interfaz de usuario de TVK, por ejemplo,tvk-doks.com
installTVK.ComponentConfiguration.ingressController.service.type para el tipo de servicio para acceder a la interfaz de usuario de TVK, por ejemplo, NodePort o LoadBalancer
Ahora, verifique su implementación de TVK:
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
triliovault-manager-tvk tvk 1 2022-06-08 08:30:08.490304959 +0000 UTC deployed k8s-triliovault-2.9.2 2.9.2
triliovault-operator tvk 1 2022-06-08 11:32:55.755395 +0300 EEST deployed k8s-triliovault-operator-2.9.2 2.9.2
La salida se parece al siguiente fragmento (STATUS columna debería mostrar implementado):
A continuación, verifica que TrilioVault esté activo y en funcionamiento:
NAME READY UP-TO-DATE AVAILABLE AGE
k8s-triliovault-admission-webhook 1/1 1 1 83s
k8s-triliovault-control-plane 1/1 1 1 83s
k8s-triliovault-exporter 1/1 1 1 83s
k8s-triliovault-ingress-nginx-controller 1/1 1 1 83s
k8s-triliovault-web 1/1 1 1 83s
k8s-triliovault-web-backend 1/1 1 1 83s
triliovault-operator-k8s-triliovault-operator 1/1 1 1 4m22s
La salida se parece al siguiente fragmento. Todos los pods de implementación deben estar en estado Ready.
Si la salida se ve así, has instalado TVK correctamente. A continuación, aprenderás cómo verificar el tipo y la validez de la licencia, así como cómo renovarla.
Licenciamiento de Aplicaciones TrilioVault
- De forma predeterminada, al instalar TVK a través de Helm, no se instala automáticamente una licencia de prueba gratuita. Siempre puedes ir al sitio web de Trilio y generar una nueva licencia para tu clúster que se adapte a tus necesidades (por ejemplo, puedes elegir el tipo de licencia básica que te permite ejecutar TrilioVault indefinidamente si la capacidad de tu clúster no supera los 10 nodos). Una licencia de prueba gratuita te permite ejecutar TVK durante un mes en nodos de clúster ilimitados.
- TrilioVault es gratuito para clústeres de Kubernetes con hasta 100000 nodos para usuarios de DigitalOcean. Pueden seguir los siguientes pasos para crear una licencia especial disponible solo para clientes de DO.
Los ejemplos del Kit de Inicio dependen de un tipo de licencia de Clúster para funcionar correctamente.
Creación y Verificación de Licencias de Aplicación TVK
Ejecute el siguiente comando para crear una nueva licencia para su clúster (se gestiona mediante el CRD de Licencia):
El comando anterior creará un trabajo job.batch/tvk-license-digitalocean que ejecutará un pod tvk-license-digitalocean-828rx para extraer la licencia del Servidor de Licencias de Trilio e instalarla en el clúster de DOKS. Después de que se complete el trabajo, se eliminará en 60 segundos.
Si está descargando una licencia gratuita desde el sitio web de Trilio, aplíquela usando este comando:
Por favor, ejecute el siguiente comando para ver si la licencia está instalada y en estado Activo en su clúster.
NAME STATUS MESSAGE CURRENT NODE COUNT GRACE PERIOD END TIME EDITION CAPACITY EXPIRATION TIME MAX NODES
test-license-1 Active Cluster License Activated successfully. 1 FreeTrial 100000 2023-02-25T00:00:00Z 1
La salida se parece a la siguiente. Observe el ESTADO que debería ser Activo, así como el tipo de licencia en la columna EDICIÓN y HORA DE EXPIRACIÓN.
La licencia se gestiona mediante un CRD especial llamado objeto Licencia. Puede inspeccionarlo ejecutando el siguiente comando:
La salida se parece a la siguiente. Observe los campos Mensaje y Capacidad, así como la Edición.
La salida anterior también te indicará cuándo va a expirar la licencia en el campo Marca de Tiempo de Expiración, y el Alcance (basado en Cluster en este caso). Puedes optar por un tipo de licencia a nivel de clúster o basado en espacio de nombres.
Renovación de la Licencia de Aplicación TVK
Para renovar la licencia, tendrás que solicitar una nueva desde el sitio web de Trilio navegando a la página de licencias para reemplazar la antigua. Después de completar el formulario, deberías recibir el manifiesto YAML de la Licencia, que se puede aplicar a tu clúster usando kubectl. Los siguientes comandos asumen que TVK está instalado en el espacio de nombres predeterminado tvk (por favor, reemplaza los marcadores <> según sea necesario):
# Obtén información sobre una licencia específica desde el espacio de nombres `tvk`
En el siguiente paso, aprenderás cómo definir el backend de almacenamiento para TrilioVault para almacenar copias de seguridad llamado objetivo.
Paso 2 – Creación de un Destino TrilioVault para Almacenar Copias de Seguridad
A typical Target definition looks like:
TrilioVault primero necesita saber dónde almacenar tus copias de seguridad. TrilioVault se refiere al backend de almacenamiento usando el término target, y se gestiona a través de un CRD especial llamado Target. Los siguientes tipos de destino son compatibles: S3 y NFS. Para DigitalOcean y con el propósito del Kit de Inicio, tiene sentido depender del tipo de almacenamiento S3 porque es económico y escalable. Para beneficiarse de un nivel mejorado de protección, puedes crear múltiples tipos de destino (tanto para S3 como para NFS), de modo que tus datos estén seguros en varios lugares, logrando así redundancia en las copias de seguridad.
- En esta configuración,
spec.type: Tipo de destino para el almacenamiento de copias de seguridad (S3 es un almacenamiento de objetos).spec.vendor: Proveedor de almacenamiento de terceros que aloja el destino (para DigitalOcean Spaces debes usarOtroen lugar deAWS).spec.enableBrowsing: Habilitar la navegación para el destino.spec.objectStoreCredentials: Define las credenciales requeridas (a través decredentialSecret) para acceder al almacenamientoS3, así como otros parámetros como la región y el nombre del bucket.
spec.thresholdCapacity: Capacidad máxima de umbral para almacenar datos de copia de seguridad.
# el valor debe estar codificado en base64
Observa que el nombre del secreto es trilio-s3-target y es referenciado por el campo spec.objectStoreCredentials.credentialSecret del CRD de Destino explicado anteriormente. El secreto puede estar en el mismo namespace donde se instaló TrilioVault (por defecto es tvk), o en otro namespace de tu elección. Solo asegúrate de hacer referencia al namespace correctamente. Por otro lado, asegúrate de proteger el namespace donde almacenas los secretos de TrilioVault a través de RBAC por razones de seguridad.
Pasos para crear un Destino para TrilioVault:
Primero, cambia al directorio donde se clonó el repositorio de Git del Kit de Inicio en tu máquina local:
A continuación, crea el secreto de Kubernetes que contiene las credenciales de tu cubo S3 de destino (por favor, reemplaza los marcadores <> según corresponda):
–from-literal=accessKey=“<TU_CLAVE_DE_ACCESO_A_DO_SPACES_AQUÍ>” \
–from-literal=secretKey=“<TU_CLAVE_SECRETA_DE_DO_SPACES_AQUÍ>”
Luego, abre e inspecciona el archivo de manifiesto de destino proporcionado en el repositorio del Kit de Inicio usando un editor de tu elección (preferiblemente con soporte para YAML lint).
Ahora, por favor reemplaza los marcadores <> según corresponda para tu bucket de Trilio en DO Spaces, como nombreDelBucket, región, URL y secretoDeCredenciales.
Finalmente, guarda el archivo de manifiesto y crea el objeto de Destino usando kubectl:
NAME TYPE THRESHOLD CAPACITY VENDOR STATUS BROWSING ENABLED
trilio-s3-target ObjectStore 10Gi Other Available
A continuación, TrilioVault generará un trabajo de trabajador llamado trilio-s3-target-validator responsable de validar tu bucket S3 (como disponibilidad, permisos, etc.). Si el trabajo finaliza con éxito, se considera que el bucket está saludable o disponible y el recurso de trabajo trilio-s3-target-validator se elimina posteriormente. Si algo malo sucede, el trabajo validador de destino S3 permanece en ejecución para que puedas inspeccionar los registros y encontrar el posible problema.
Ahora, por favor verifica si el recurso de Destino creado anteriormente está saludable:
# La salida se parece a:
...
INFO:root:2021-11-24 09:06:50.595166: waiting for mount operation to complete.
INFO:root:2021-11-24 09:06:52.595772: waiting for mount operation to complete.
ERROR:root:2021-11-24 09:06:54.598541: timeout exceeded, not able to mount within time.
ERROR:root:/triliodata is not a mountpoint. We can't proceed further.
Traceback (most recent call last):
File "/opt/tvk/datastore-attacher/mount_utility/mount_by_target_crd/mount_datastores.py", line 56, in main
utilities.mount_datastore(metadata, datastore.get(constants.DATASTORE_TYPE), base_path)
File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 377, in mount_datastore
mount_s3_datastore(metadata_list, base_path)
File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 306, in mount_s3_datastore
wait_until_mount(base_path)
File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 328, in wait_until_mount
base_path))
Exception: /triliodata is not a mountpoint. We can't proceed further.
...
#trilio-s3-target-validator-tio99a-6lz4q 1/1 En ejecución 0 104s
# Ahora, obtén los datos de registros
La salida será esta excepción:
A continuación, descubrirás la consola web de TVK, que es una adición útil para ayudarte a administrar fácilmente las operaciones de copia de seguridad y restauración, entre muchas otras.
Paso 3 – Conociendo la Consola de Administración Web de TVK
Aunque puedes administrar las operaciones de copia de seguridad y restauración desde la CLI completamente a través de kubectl y CRDs, TVK proporciona una Consola de Administración Web para realizar las mismas operaciones a través de la GUI. La consola de administración simplifica tareas comunes mediante operaciones de clics, proporciona una mejor visualización e inspección de los objetos del clúster de TVK, así como para crear planes de recuperación ante desastres (o DRP).
La instalación basada en Helm cubierta en Paso 1 – Instalación de TrilioVault para Kubernetes ya se encargó de instalar los componentes necesarios para la consola de administración web.
Obteniendo acceso a la Consola de Gestión Web de TVK
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
k8s-triliovault-admission-webhook ClusterIP 10.245.202.17 <none> 443/TCP 13m
k8s-triliovault-ingress-nginx-controller NodePort 10.245.192.140 <none> 80:32448/TCP,443:32588/TCP 13m
k8s-triliovault-ingress-nginx-controller-admission ClusterIP 10.3.20.89 <none> 443/TCP 13m
k8s-triliovault-web ClusterIP 10.245.214.13 <none> 80/TCP 13m
k8s-triliovault-web-backend ClusterIP 10.245.10.221 <none> 80/TCP 13m
triliovault-operator-k8s-triliovault-operator-webhook-service ClusterIP 10.245.186.59 <none> 443/TCP 16m
Para poder acceder a la consola y explorar las funciones que ofrece, es necesario reenviar el puerto del servicio del controlador de ingreso para TVK.
La salida se parece a lo siguiente. Busca la línea k8s-triliovault-ingress-nginx-controller y observa que escucha en el puerto 80 en la columna PORT(S).
127.0.0.1 tvk-doks.com
TVK está utilizando un Controlador de Ingreso Nginx para dirigir el tráfico a los servicios de la consola de gestión web. El enrutamiento se basa en el host, y el nombre de host es tvk-doks.com como se define en el archivo de valores de Helm del Kit de Inicio:
# El nombre de host a utilizar al acceder a la consola web a través del controlador de ingreso de Nginx de TVK
Finalmente, exporta el archivo kubeconfig para tu clúster DOKS. Este paso es necesario para que la consola web pueda autenticarte.
# Enumere los clústeres disponibles
# Guarde la configuración del clúster en YAML
Si solo tiene un clúster, ejecute el siguiente comando:
Después de seguir estos pasos, puede acceder a la consola en su navegador web navegando a: http://tvk-doks.com:8080. Cuando se le solicite el archivo kubeconfig, seleccione el que creó en el último comando de arriba.
Por favor, mantenga seguro el archivo kubeconfig generado porque contiene datos sensibles.
- Explorando la Interfaz de Usuario de la Consola Web de TVK
- Explore cada sección desde la izquierda, como:
- Administración de Clústeres: Esto muestra la lista de clústeres primarios y otros clústeres que tienen instancias de TVK, agregados al clúster OVH primario mediante la función de Gestión de Múltiples Clústeres.
- Copia de seguridad y recuperación: Este es el panel principal que te brinda una visión general del clúster completo, como los espacios de nombres descubiertos, las aplicaciones, la lista de planes de copia de seguridad, los objetivos, los ganchos, las políticas, etc.
Monitoreo: Esto tiene dos opciones: Monitoreo de TrilioVault y Monitoreo de Velero si el usuario tiene Velero configurado en su clúster OVH.
Recuperación de desastres: Te permite gestionar y realizar operaciones de recuperación de desastres.
Recuperación de desastres: Te permite gestionar y realizar operaciones de recuperación de desastres.
También puedes ver el objetivo S3 creado anteriormente, navegando a Copia de seguridad y recuperación -> Objetivos -> <Espacio de nombres> tvk desde el menú desplegable en la parte superior.
Para continuar, puedes explorar el objetivo y enumerar las copias de seguridad disponibles haciendo clic en el botón Acciones en la parte derecha, y luego seleccionando la opción Iniciar navegador del menú emergente. Para que esto funcione, el objetivo debe tener la bandera enableBrowsing establecida en true.
Para obtener más información y características disponibles, consulta la documentación oficial de la Consola de administración web de TVK.
A continuación, aprenderás cómo realizar operaciones de copia de seguridad y restauración para casos de uso específicos.
Paso 4 – Ejemplo de Respaldar y Restaurar con Espacios de Nombres
En este paso, aprenderás cómo crear un respaldo único para todo un espacio de nombres (ambassador en este caso) desde tu clúster DOKS y luego restaurarlo, asegurándote de que todos los recursos se recrean. TVK tiene una función que te permite realizar respaldos a un nivel más alto que solo los espacios de nombres.
- Creando el Respaldo de la Liberación de Helm de Ambassador
- Para realizar respaldos para una sola aplicación a nivel de espacio de nombres (o liberación de Helm), se requiere un Plan de Respaldo seguido por un CRD de Respaldo. El Plan de Respaldo es una definición de ‘qué’, ‘dónde’, ‘hacia’, y ‘cómo’ del proceso de respaldo, pero no realiza el respaldo real. El CRD de Respaldo es responsable de activar el proceso de respaldo real, según lo dictado por la especificación del Plan de Respaldo.
- En esta configuración,
A typical Backup CRD looks like below:
spec.backupConfig.target.name: Indica a TVK qué nombre de destino usar para almacenar respaldos.
spec.backupConfig.target.namespace: Indica a TVK en qué espacio de nombres se creó el destino.spec.backupComponents: Define una lista de recursos para hacer una copia de seguridad.
En esta configuración,
spec.type: Especifica el tipo de copia de seguridad.
spec.backupPlan: Especifica el BackupPlan que esta Copia de seguridad debe usar.
Pasos para iniciar la copia de seguridad única del lanzamiento de Ambassador Helm:
Primero, asegúrese de que Ambassador Edge Stack esté desplegado en su clúster siguiendo los pasos del tutorial Ambassador Ingress.
A continuación, cambie al directorio donde se clonó el repositorio Git del Kit de inicio en su máquina local:
Luego, abra e inspeccione los archivos de manifiesto del Plan de copia de seguridad y Copia de seguridad de Ambassador proporcionados en el repositorio del Kit de inicio utilizando un editor de su elección (preferiblemente con soporte para lint de YAML).
NAME TARGET ... STATUS
ambassador-helm-release-backup-plan trilio-s3-target ... Available
Finalmente, cree los recursos BackupPlan y Backup usando kubectl.
Ahora, inspeccione el estado del BackupPlan (apuntando al lanzamiento de Helm ambassador) usando kubectl:
NAME BACKUPPLAN BACKUP TYPE STATUS ...
ambassador-helm-release-full-backup ambassador-helm-release-backup-plan Full InProgress ...
La salida se parece a lo siguiente. Observe el valor de la columna STATUS que debería estar configurado en Available.
A continuación, verifique el estado del objeto Backup usando kubectl:
NAME BACKUPPLAN BACKUP TYPE STATUS ... PERCENTAGE
ambassador-helm-release-full-backup ambassador-helm-release-backup-plan Full Available ... 100
La salida se parece a lo siguiente. Observe el valor de la columna STATUS que debería estar configurado en InProgress, así como el BACKUP TYPE establecido en Full.
Después de que todos los componentes de la liberación del embajador Helm hayan terminado de cargarse en el destino S3, deberías obtener estos resultados:
2021-11-25 07:04 28 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/
2021-11-25 07:04 28 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/
2021-11-25 07:04 311 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backup-namespace.json.manifest.00000004
2021-11-25 07:04 302 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backup.json.manifest.00000004
2021-11-25 07:04 305 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backupplan.json.manifest.00000004
2021-11-25 07:04 28 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/
2021-11-25 07:04 28 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/metadata-snapshot/
2021-11-25 07:04 330 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/metadata-snapshot/metadata.json.manifest.00000002
...
# La salida se ve similar a (nota que el `ESTADO` cambió a `Disponible`, y `PORCENTAJE` es `100`)
Si la salida se ve así, has respaldado con éxito la liberación del Helm del embajador. Puedes proceder y ver cómo TrilioVault almacena los metadatos de Kubernetes enumerando el contenido del cubo S3 de TrilioVault. Por ejemplo, puedes usar s3cmd:
ambassador-helm-release-full-backup-metamover-mg9gl0--1-2d6wx 1/1 Running 0 4m32s
La salida se parece a lo siguiente. Observa que la lista contiene los manifiestos JSON y los UID, que representan objetos de Kubernetes.
En caso de que el respaldo no esté disponible, puedes inspeccionar los registros del Pod metamover para encontrar el problema:
...
{"component":"meta-mover","file":"pkg/metamover/snapshot/parser/commons.go:1366","func":"github.com/trilioData/k8s-triliovault/pkg/metamover/snapshot/parser.(*Component).ParseForDataComponents","level":"info","msg":"Parsing data components of resource rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding: [edge-stack]","time":"2022-06-14T06:20:56Z"}
{"component":"meta-mover","file":"pkg/metamover/snapshot/parser/commons.go:1366","func":"github.com/trilioData/k8s-triliovault/pkg/metamover/snapshot/parser.(*Component).ParseForDataComponents","level":"info","msg":"Parsing data components of resource rbac.authorization.k8s.io/v1, Kind=RoleBinding: [edge-stack-agent-config]","time":"2022-06-14T06:20:56Z"}
...
La salida se parece a:
Ahora, recupera los datos de los registros:
La salida se parece a lo siguiente.
Finalmente, también puedes verificar que el respaldo esté disponible en la consola web navegando a Administración de recursos -> Embajador -> Planes de respaldo. Observa que está en el estado Disponible y que la liberación del Helm del embajador fue respaldada en la subvista de Detalles del componente.
Eliminando la Liberación del Helm del Embajador y los Recursos
Ahora, procede a simular un desastre eliminando intencionalmente la liberación ambassador de Helm:
A continuación, verifica que los recursos del espacio de nombres hayan sido eliminados (el listado debería estar vacío):
- Finalmente, verifica que el endpoint de los servicios backend
echoyquoteestéDOWN. Consulta Creación de los Servicios Backend del Conjunto de Inicio de Ambassador Edge Stack respecto a las aplicaciones backend utilizadas en el tutorial del Conjunto de Inicio. Puedes usarcurlpara realizar la prueba (o puedes utilizar tu navegador web): - Restauración del Respaldo de la Liberación de Helm de Ambassador
- Importante
Si estás restaurando el mismo espacio de nombres, asegúrate de que los componentes de la aplicación original hayan sido eliminados. Especialmente el PVC de la aplicación.
Si está restaurando en otro clúster (escenario de migración), asegúrese de que TrilioVault for Kubernetes también se esté ejecutando en el espacio de nombres/clúster remoto. Para restaurar en un nuevo clúster (donde no existe el CR de respaldo), source.type debe establecerse en location. Consulte la Sección de Definición de Recursos Personalizados para Restaurar para ver un ejemplo de restauración por ubicación.
- Al eliminar el espacio de nombres
ambassador, el recurso del balanceador de carga asociado con el servicio de embajador también se eliminará. Entonces, al restaurar el servicioambassador, DigitalOcean volverá a crear el LB. El problema es que obtendrá una NUEVA DIRECCIÓN IP para su LB, por lo que necesitará ajustar losregistros Apara redirigir el tráfico a sus dominios alojados en el clúster. - Para restaurar una copia de seguridad específica, debe crear un CRD de
Restore. Un CRD de Restauración típico se ve así: - En esta configuración,
spec.source.type: Especifica qué tipo de respaldo restaurar.
spec.source.backup: Contiene una referencia al objeto de respaldo del cual restaurar.
spec.skipIfAlreadyExists: Especifica si se debe omitir la restauración de un recurso si ya existe en el espacio de nombres restaurado.
Restaurar te permite restaurar la última copia de seguridad exitosa para una aplicación. Se utiliza para restaurar un único espacio de nombres o lanzamiento de Helm, protegido por el CRD de Copia de Seguridad. El CRD de Copia de Seguridad se identifica por su nombre ambassador-helm-release-full-backup.
Primero, inspecciona el ejemplo del CRD de Restauración del repositorio Git del Kit de Inicio:
NAME STATUS DATA SIZE START TIME END TIME PERCENTAGE COMPLETED DURATION
ambassador-helm-release-restore Completed 0 2021-11-25T15:06:52Z 2021-11-25T15:07:35Z 100 43.524191306s
Luego, crea el recurso de Restauración usando kubectl:
Finalmente, inspecciona el estado del objeto de Restauración:
La salida se parece a lo siguiente. Observa la columna ESTADO establecida en Completado, así como el PORCENTAJE COMPLETADO establecido en 100.
Si la salida se ve así, entonces el proceso de restauración del lanzamiento de Helm ambassador se ha completado con éxito.
NAME READY STATUS RESTARTS AGE
pod/ambassador-5bdc64f9f6-42wzr 1/1 Running 0 9m58s
pod/ambassador-5bdc64f9f6-nrkzd 1/1 Running 0 9m58s
pod/ambassador-agent-bcdd8ccc8-ktmcv 1/1 Running 0 9m58s
pod/ambassador-redis-64b7c668b9-69drs 1/1 Running 0 9m58s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ambassador LoadBalancer 10.245.173.90 157.245.23.93 80:30304/TCP,443:30577/TCP 9m59s
service/ambassador-admin ClusterIP 10.245.217.211 <none> 8877/TCP,8005/TCP 9m59s
service/ambassador-redis ClusterIP 10.245.77.142 <none> 6379/TCP 9m59s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ambassador 2/2 2 2 9m59s
deployment.apps/ambassador-agent 1/1 1 1 9m59s
deployment.apps/ambassador-redis 1/1 1 1 9m59s
NAME DESIRED CURRENT READY AGE
replicaset.apps/ambassador-5bdc64f9f6 2 2 2 9m59s
replicaset.apps/ambassador-agent-bcdd8ccc8 1 1 1 9m59s
replicaset.apps/ambassador-redis-64b7c668b9 1 1 1 9m59s
Verificando la Integridad de las Aplicaciones después de la Restauración
Verifica que todos los recursos del espacio de nombres ambassador estén en su lugar y en ejecución:
NAME HOSTNAME STATE PHASE COMPLETED PHASE PENDING AGE
echo-host echo.starter-kit.online Ready 11m
quote-host quote.starter-kit.online Ready 11m
La salida se parece a:
Obtener hosts de ambassador:
NAME SOURCE HOST SOURCE PREFIX DEST SERVICE STATE REASON
ambassador-devportal /documentation/ 127.0.0.1:8500
ambassador-devportal-api /openapi/ 127.0.0.1:8500
ambassador-devportal-assets /documentation/(assets|styles)/(.*)(.css) 127.0.0.1:8500
ambassador-devportal-demo /docs/ 127.0.0.1:8500
echo-backend echo.starter-kit.online /echo/ echo.backend
quote-backend quote.starter-kit.online /quote/ quote.backend
La salida es similar a lo siguiente. El ESTADO debe ser Listo, así como la columna NOMBRE DE HOST apuntando al nombre de host totalmente calificado.
Obtener mapeos de ambassador:
La salida se parece a lo siguiente. Tenga en cuenta el echo-backend que está mapeado al host echo.starter-kit.online y al prefijo de origen /echo/, lo mismo para quote-backend.
Ahora, necesitas actualizar tus registros DNS A, porque el recurso del balanceador de carga de DigitalOcean fue recreado y tiene una nueva IP externa asignada.
Finalmente, verifica si las aplicaciones backend responden a las solicitudes HTTP también. Consulta Creación de los Servicios de Backend de Ambassador Edge Stack con respecto a las aplicaciones backend utilizadas en el tutorial del Starter Kit.
El siguiente paso trata sobre la copia de seguridad y restauración de todo el clúster.
Paso 5 – Ejemplo de Copia de Seguridad y Restauración del Clúster Completo
A typical ClusterBackupPlan manifest targeting multiple namespaces looks like this:
En este paso, simularás un escenario de recuperación ante desastres. Se eliminará todo el clúster de DOKS y luego se restaurarán las aplicaciones importantes desde una copia de seguridad anterior.
Creación de la Copia de Seguridad del Clúster DOKS
La idea principal aquí es realizar una copia de seguridad del clúster DOKS incluyendo todos los espacios de nombres importantes que contienen sus aplicaciones y configuraciones esenciales.
Observe que kube-system (u otros espacios de nombres relacionados con el clúster DOKS) no se incluye en la lista. Por lo general, no son necesarios, a menos que haya un caso especial que requiera que algunas configuraciones se mantengan en ese nivel.
Primero, cambie al directorio donde se clonó el repositorio de Git del Kit de Inicio en su máquina local:
Luego, abra e inspeccione los archivos de manifiesto ClusterBackupPlan y ClusterBackup proporcionados en el repositorio del Kit de Inicio usando un editor de su elección (preferiblemente con soporte para linting de YAML).
NAME TARGET ... STATUS
starter-kit-cluster-backup-plan trilio-s3-target ... Available
Finalmente, cree los recursos ClusterBackupPlan y ClusterBackup usando kubectl:
Ahora, inspeccione el estado de ClusterBackupPlan usando kubectl:
NAME BACKUPPLAN BACKUP TYPE STATUS ... PERCENTAGE COMPLETE
starter-kit-cluster-backup starter-kit-cluster-backup-plan Full Available ... 100
La salida se parece a lo siguiente. Observe el valor de la columna STATUS que debería estar establecido en Available.
A continuación, verifique el estado de ClusterBackup usando kubectl:
La salida se parece a lo siguiente. Observe el valor de la columna STATUS que debería estar establecido en Available, así como el valor de PERCENTAGE COMPLETE establecido en 100.
Si la salida se ve como se muestra arriba, entonces todos los espacios de nombres de aplicaciones importantes fueron respaldados correctamente.
La copia de seguridad completa del clúster puede tardar un tiempo en completarse, dependiendo de cuántos espacios de nombres y recursos asociados estén involucrados en el proceso.
También puedes abrir el panel de control principal de la consola web e inspeccionar la copia de seguridad multi-nombre de espacio (nota cómo se resaltan en color verde todos los nombres de espacio importantes que se respaldaron, en una estructura de panal de abeja):
Recreación del clúster DOKS y Restauración de Aplicaciones
Un aspecto importante a tener en cuenta es que cada vez que destruyes un clúster DOKS y luego lo restauras, se crea un nuevo Balanceador de Carga con una nueva IP externa también cuando TVK restaura tu controlador de ingreso. Así que, por favor, asegúrate de actualizar tus registros A de DNS de DigitalOcean en consecuencia.
Ahora, elimina todo el clúster DOKS (asegúrate de reemplazar los marcadores <> correspondientemente):
A continuación, recrea el clúster según se describe en Configurar Kubernetes de DigitalOcean.
Para realizar la operación de restauración, necesitas instalar la aplicación TVK según se describe en Paso 1 – Instalación de TrilioVault para Kubernetes. Es importante usar la misma versión del gráfico Helm.
Después de que la instalación finalice con éxito, configure el objetivo TVK como se describe en Paso 2 – Creación de un Objetivo TrilioVault para Almacenar Copias de Seguridad y apúntelo al mismo bucket de S3 donde se encuentran sus datos de copia de seguridad. Además, asegúrese de que la navegación del objetivo esté habilitada.
A continuación, verifique y active una nueva licencia como se describe en la sección Licencia de Aplicación TrilioVault.
Para acceder a la interfaz de usuario de la consola web, consulte la sección Acceso a la Consola de Gestión Web de TVK.
Luego, vaya a Gestión de Recursos -> Espacio de Nombres de TVK -> Objetivos (en caso de que sea un Kit de Inicio, el Espacio de Nombres de TVK es tvk):
Continuando, explore el objetivo y liste las copias de seguridad disponibles haciendo clic en el botón Acciones. Luego, seleccione la opción Iniciar Navegador del menú emergente. Para que esto funcione, el objetivo debe tener la bandera enableBrowsing configurada como true.
Ahora, haga clic en el elemento starter-kit-cluster-backup-plan de la lista, y luego haga clic y expanda el elemento starter-kit-cluster-backup de la subventana derecha:
Para iniciar el proceso de restauración, haga clic en el botón Restaurar.
Verificación del Estado de las Aplicaciones del Clúster DOKS
Primero, verifique todos los recursos de Kubernetes del clúster.
Luego, asegúrese de que sus registros A de DNS estén actualizados para apuntar a la nueva dirección IP externa del balanceador de carga.
Finalmente, las aplicaciones del backend deberían responder a las solicitudes HTTP también. Consulte Creación de los Servicios de Backend de Ambassador Edge Stack con respecto a las aplicaciones del backend utilizadas en el tutorial del Kit de Inicio.
En el próximo paso, aprenderá cómo realizar copias de seguridad programadas (o automáticas) para las aplicaciones de su clúster DOKS.
Realizar copias de seguridad automáticamente según un horario es una función realmente útil. Le permite rebobinar el tiempo y restaurar el sistema a un estado de funcionamiento anterior si algo sale mal. Esta sección proporciona un ejemplo de una copia de seguridad automática en un horario de 5 minutos (se eligió el espacio de nombres kube-system).
Primero, necesitas crear un CRD Policy de tipo Schedule que defina el horario de respaldo en formato cron (igual que el cron de Linux). Las políticas de programación pueden usarse para CRDs BackupPlan o ClusterBackupPlan. Un CRD típico de política de programación se ve así (define un horario de 5 minutos):
# disparar cada 5 minutos
Seguidamente, puedes aplicar la política de programación a un CRD ClusterBackupPlan, por ejemplo, como se muestra a continuación:
Puedes notar que es un CRD básico de ClusterBackupPlan, haciendo referencia al CRD Policy definido anteriormente mediante el campo spec.backupConfig.schedulePolicy. Puedes tener políticas separadas creadas para respaldos completos o incrementales, por lo tanto, se puede especificar fullBackupPolicy o incrementalBackupPolicy en el spec.
Ahora, por favor crea la política de horario utilizando el manifiesto de ejemplo proporcionado por el tutorial del Starter Kit.
NAME POLICY DEFAULT
scheduled-backup-every-5min Schedule false
Cambia al directorio donde se clonó el repositorio de Git del Starter Kit en tu máquina local.
Finalmente, crea los recursos para los respaldos programados en el espacio de nombres kube-system:
# Crea primero el plan de respaldo para el espacio de nombres kube-system
NAME TARGET ... FULL BACKUP POLICY STATUS
kube-system-ns-backup-plan-5min-schedule trilio-s3-target ... scheduled-backup-every-5min Available
# Crea y activa el respaldo programado para el espacio de nombres kube-system
Verifique el estado del plan de respaldo programado para kube-system:
NAME BACKUPPLAN BACKUP TYPE STATUS ...
kube-system-ns-full-backup-scheduled kube-system-ns-backup-plan-5min-schedule Full Available ...
La salida se ve similar a la siguiente. Observe el valor de FULL BACKUP POLICY establecido en el recurso de política de respaldo programado scheduled-backup-every-5min creado previamente, así como el STATUS que debería ser Available.
Verifique el estado del respaldo programado para kube-system:
La salida se ve similar a la siguiente. Observe el valor de BACKUPPLAN establecido en el recurso de plan de respaldo creado previamente, así como el STATUS que debería ser Available.
Ahora, puede verificar que los respaldos se realizan a intervalos regulares (cada 5 minutos), consultando el recurso de respaldo del clúster e inspeccionando la columna START TIME (kubectl get clusterbackup -n tvk). Debería reflejar el delta de 5 minutos, como se resalta en la imagen a continuación:
En el siguiente paso, aprenderá cómo configurar una política de retención para sus respaldos.
Paso 7 – Política de Retención de Respaldo
La política de retención le permite definir la cantidad de respaldos a retener y el ritmo para eliminar respaldos según los requisitos de cumplimiento. El CRD de política de retención proporciona una especificación YAML simple para definir la cantidad de respaldos a retener en términos de días, semanas, meses, años, los más recientes, etc.
- Usando políticas de retención
- Las políticas de retención pueden ser utilizadas para los CRDs
BackupPlanoClusterBackupPlan. Un manifiesto típico dePolicypara el tipo deRetentionse ve así: - La política de retención anterior se traduce a:
- Cada semana, mantener una copia de seguridad cada miércoles.
Cada mes, mantener una copia de seguridad el día 15.
A typical ClusterBackupPlan example configuration that has a retention set looks like:
Cada año, mantener una copia de seguridad cada marzo.
En general, deberían haber 2 más recientes copias de seguridad disponibles.
El flujo básico para crear un recurso de política de retención es el mismo que para las copias de seguridad programadas. Necesitas un CRD de BackupPlan o ClusterBackupPlan definido para hacer referencia a la política de retención, y luego tener un objeto de Backup o ClusterBackup para activar el proceso.
Observa que utiliza un campo de retentionPolicy para hacer referencia a la política en cuestión. Por supuesto, puedes tener un plan de respaldo que tenga ambos tipos de políticas configuradas, para que pueda realizar copias de seguridad programadas, así como para manejar estrategias de retención.
Usando políticas de limpieza
Necesitas una forma de recolectar toda esa basura que ya no se está utilizando. Para esto, necesitas introducir el CRD Política de Limpieza:
La política de limpieza mencionada anteriormente debe ser definida en el espacio de nombres de la instalación de TVK. Luego, se crea automáticamente un trabajo cron que se ejecuta cada 30 minutos y elimina las copias de seguridad fallidas basadas en el valor especificado para backupdays dentro del campo spec.
Conclusión
- En este tutorial, aprendiste cómo realizar copias de seguridad tanto únicas como programadas, y cómo restaurarlo todo.
- Todas las tareas y operaciones básicas explicadas en este tutorial tienen como objetivo brindarte una introducción básica y una comprensión de lo que TrilioVault for Kubernetes es capaz de hacer.
- Más Información
Copia de seguridad y restauración de datos de DOKS usando Velero