Copia de seguridad y restauración de la infraestructura del clúster de carga de trabajo y de administración en vSphere (vista previa técnica)

En este tema se explica cómo realizar una copia de seguridad y restaurar la infraestructura del clúster para Tanzu Kubernetes Grid (TKG) con un clúster de administración independiente en vSphere:

  • Usar Velero para realizar copias de seguridad y restaurar objetos del clúster de carga de trabajo en el clúster de administración independiente, y
  • Volver a crear el clúster de administración independiente desde sus archivos de configuración
Nota

  • VMware no admite el uso de Velero para realizar copias de seguridad de clústeres de administración independientes de TKG.
  • Si se vuelve a configurar un clúster de administración independiente después de implementarlo, es posible que al volver a crearlo como se describe aquí no se recuperen todos sus recursos.

Para realizar una copia de seguridad y restaurar las cargas de trabajo y los volúmenes de almacenamiento dinámicos alojados en clústeres de carga de trabajo de Tanzu Kubernetes Grid (TKG) con un clúster de administración independiente, consulte Copia de seguridad y restauración de cargas de trabajo de clúster.

Para realizar una copia de seguridad y restaurar clústeres de vSphere with Tanzu, incluidos los clústeres de supervisor y los clústeres de carga de trabajo que crean, consulte Realizar copias de seguridad y restaurar vSphere with Tanzu en la documentación de VMware vSphere 8.0.

Precaución

  • Esta función se encuentra en el estado de vista previa técnica no compatible; consulte Estados de funciones de TKG.

  • La autenticación de Pinniped a los clústeres de carga de trabajo no funciona después de que se vuelva a crear el clúster de administración.

Configurar Velero

Puede utilizar Velero, una herramienta estándar de comunidad de código abierto, para realizar copias de seguridad y restaurar cargas de trabajo e infraestructuras de clúster de administración independiente de TKG.

Velero admite diversos proveedores de almacenamiento para almacenar sus copias de seguridad. Velero también admite:

  • Enlaces previos y posteriores para copias de seguridad y restauraciones para ejecutar procesos personalizados antes o después de los eventos de copia de seguridad y restauración.
  • Sin incluir aspectos del estado de la carga de trabajo o del clúster que no son adecuados para copias de seguridad o restauraciones.

Una suscripción de Tanzu Kubernetes Grid incluye compatibilidad con la distribución probada y compatible de Velero de VMware disponible en la página de descargas de Tanzu Kubernetes Grid.

Para realizar una copia de seguridad y restaurar clústeres de TKG, necesita:

Después de completar los requisitos previos anteriores, también puede utilizar Velero para migrar cargas de trabajo entre clústeres. Para obtener instrucciones, consulte Migración de clústeres y Filtrado de recursos en la documentación de Velero.

Instalar la CLI de Velero

Precaución

Si ya instaló la CLI de Velero v1.8.1 o una versión anterior, como se distribuyó con versiones anteriores de TKG, debe actualizar a la versión 1.9.5. Las versiones anteriores de Velero no funcionan con los CRD utilizados en la versión 1.9 y posteriores.

Para instalar la CLI de Velero v1.9.5, haga lo siguiente:

  1. Vaya a la página de descargas de Tanzu Kubernetes Grid e inicie sesión con sus credenciales de VMware Customer Connect.
  2. En Descargas de productos, haga clic en Ir a descargas.
  3. Desplácese hasta las entradas de Velero y descargue el archivo .gz de la CLI de Velero para el sistema operativo de la estación de trabajo. El nombre de archivo comienza con velero-linux-, velero-mac- o velero-windows64-.

  4. Utilice el comando gunzip o la herramienta de extracción de su elección para descomprimir el archivo binario:

    gzip -d <RELEASE-TARBALL-NAME>.gz

  5. Cambie el nombre del archivo binario de la CLI de su plataforma a velero y asegúrese de que sea ejecutable y agréguelo a PATH.

    • Plataformas de macOS y Linux:

      1. Mueva el archivo binario a la carpeta /usr/local/bin y cámbiele el nombre a velero.
      2. Haga que el archivo sea ejecutable:
      chmod +x /usr/local/bin/velero

    • Plataformas de Windows:

      1. Cree una nueva carpeta Program Files\velero y copie el archivo binario en ella.
      2. Cambie el nombre del archivo binario a velero.exe
      3. Haga clic con el botón secundario en la carpeta velero, seleccione Propiedades (Properties) > Seguridad (Security) y asegúrese de que su cuenta de usuario tenga el permiso Control completo (Full Control).
      4. Utilice Windows Search para buscar env.
      5. Seleccione Editar las variables de entorno del sistema (Edit the system environment variables) y haga clic en el botón Variables de entorno (Environment Variables).
      6. Seleccione la fila Path en Variables del sistema (System variables) y haga clic en Editar (Edit).
      7. Haga clic en Nueva para agregar una nueva fila e introduzca la ruta en el archivo binario velero.

Configurar un proveedor de almacenamiento

Para realizar una copia de seguridad del contenido del clúster de carga de trabajo de Tanzu Kubernetes Grid, necesita ubicaciones de almacenamiento para:

  • Copias de seguridad de almacenamiento de objetos de clúster para metadatos de Kubernetes en clústeres
  • Instantáneas de volumen para datos utilizados por clústeres

Consulte Ubicaciones de almacenamiento de copias de seguridad y Ubicaciones de instantáneas de volumen en la documentación de Velero. Velero admite diversos proveedores de almacenamiento, que pueden ser:

  • Un proveedor de almacenamiento en la nube conectado.
  • Un servicio de almacenamiento de objetos local, como MinIO, para entornos con proxy o aislados.

VMware recomienda dedicar un depósito de almacenamiento único a cada clúster.

Para configurar MinIO:

  1. Ejecute la imagen de contenedor minio con las credenciales de MinIO y una ubicación de almacenamiento, por ejemplo:

    $ docker run -d --name minio --rm -p 9000:9000 -e "MINIO_ACCESS_KEY=minio" -e "MINIO_SECRET_KEY=minio123" -e "MINIO_DEFAULT_BUCKETS=mgmt" gcr.io/velero-gcp/bitnami/minio:2021.6.17-debian-10-r7

  2. Guarde las credenciales en un archivo local para pasar a la opción --secret-file de velero install, por ejemplo:

    [default]
aws_access_key_id=minio
aws_secret_access_key=minio123

Almacenamiento para vSphere

En vSphere, las copias de seguridad de almacenamiento de objetos de clúster y las instantáneas de volumen se guardan en la misma ubicación de almacenamiento. Esta ubicación debe ser un almacenamiento externo compatible con S3 en Amazon Web Services (AWS) o un proveedor S3, como MinIO.

Para configurar el almacenamiento de Velero en vSphere, consulte Complemento de Velero para vSphere en Vanilla Kubernetes Cluster para el complemento v1.4.2.

Almacenamiento para y en AWS

Para configurar el almacenamiento para Velero on AWS, siga los procedimientos descritos en el repositorio de complementos de Velero para AWS:

  1. Crear un contenedor S3.

  2. Establecer permisos para Velero.

Configure el almacenamiento de S3 según sea necesario para cada complemento. El complemento de almacén de objetos almacena y recupera copias de seguridad de objetos del clúster y la instantánea de volumen almacena y recupera volúmenes de datos.

Almacenamiento para y en Azure

Para configurar el almacenamiento de Velero en Azure, siga los procedimientos descritos en los complementos de Velero para el repositorio de Azure:

  1. Crear una cuenta de almacenamiento de Azure y un contenedor de blob

  2. Obtener el grupo de recursos que contiene las máquinas virtuales y los discos

  3. Establecer permisos para Velero

Configure el almacenamiento de S3 según sea necesario para cada complemento. El complemento de almacén de objetos almacena y recupera copias de seguridad de objetos del clúster y la instantánea de volumen almacena y recupera volúmenes de datos.

Implementar el servidor Velero en el clúster de administración

Para realizar copias de seguridad de los objetos del clúster de carga de trabajo, instale el servidor Velero v1.9.5 en el clúster de administración independiente y compruebe las instalaciones.

Opciones de instalación de Velero

Para instalar Velero, ejecute velero install con las siguientes opciones:

  • --provider $PROVIDER: Por ejemplo, aws
  • --plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.5.3_vmware.1
  • --bucket $BUCKET: El nombre del contenedor S3
  • --backup-location-config region=$REGION: La región de AWS en la que se encuentra el contenedor
  • --snapshot-location-config region=$REGION: La región de AWS en la que se encuentra el contenedor
  • (Opcional) --kubeconfig para instalar el servidor de Velero en un clúster que no sea el predeterminado actual.

  • (Opcional) --secret-file ./VELERO-CREDS una forma de dar acceso de Velero a un contenedor S3 es pasar a esta opción un archivo VELERO-CREDS local similar al siguiente:

    [default]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>

  • Para obtener más opciones, consulte Instalar e iniciar Velero.

La ejecución del comando velero install crea un espacio de nombres denominado velero en el clúster, y coloca una implementación denominada velero en él.

Se requieren los siguientes ajustes:

  • Complemento del clúster de administración (Management cluster plugin): Se requiere el siguiente complemento. Esta opción pausa los clústeres y recopila los recursos relacionados con los clústeres de los que se está realizando la copia de seguridad.
    --plugins projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.1.0_vmware.1
    Nota

    Puede agregar varias opciones separadas por comas. Por ejemplo:

    --plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.5.3_vmware.1,projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.1.0_vmware.1
  • Sin ubicación de instantánea (No snapshot location): Para realizar una copia de seguridad de la infraestructura del clúster, no establezca --snapshot-location-config

Comprobar la instalación de Velero

Una vez completado el comando velero install, compruebe que Velero se haya instalado correctamente:

  1. Compruebe que el estado del pod de Velero es Running:

    kubectl -n velero get pod
NAME                      READY   STATUS    RESTARTS   AGE
velero-78fdbcd446-v5cqr   1/1     Running   0          3h41m

  2. Verifique que la ubicación de la copia de seguridad esté en la fase Available:

    velero backup-location get
NAME      PROVIDER   BUCKET/PREFIX   PHASE       LAST VALIDATED                  ACCESS MODE   DEFAULT
default   aws        mgmt            Available   2022-11-11 05:55:55 +0000 UTC   ReadWrite     true

Copia de seguridad de objetos del clúster de carga de trabajo

Para realizar una copia de seguridad de todos los objetos del clúster de carga de trabajo administrados por un clúster de administración independiente, ejecute:

velero backup create my-backup --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --wait

Notas

  • --exclude-namespaces tkg-system excluye el propio clúster de administración.

  • --include-resources cluster.cluster.x-k8s.io incluye los objetos del clúster de carga de trabajo

  • VMware recomienda realizar una copia de seguridad de los clústeres de carga de trabajo inmediatamente después de realizar cualquier cambio estructural, como un escalado vertical o descendente. Esto evita que los objetos de copia de seguridad y la infraestructura física no coincidan, lo que puede provocar errores en el proceso de restauración.

Programar copias de seguridad

Cuando se cambian los objetos del clúster después de la copia de seguridad más reciente, el estado del sistema después de una restauración no coincide con el estado deseado más reciente. Este problema se denomina "desfase". Consulte la sección Gestionar desfase a continuación para obtener información sobre cómo recuperarse de algunos tipos comunes de desfase.

Para mitigar las desviaciones, VMware recomienda utilizar Velero para programar copias de seguridad periódicas. Por ejemplo, para realizar una copia de seguridad diaria de todos los clústeres de carga de trabajo y conservar cada copia de seguridad durante 14 días:

velero create schedule daily-bak --schedule="@every 24h"  --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --ttl 336h0m0s

Para obtener más opciones de instalación de Velero, consulte Programar copia de seguridad en la documentación de Velero.

Completar restauración

Para restaurar un clúster de administración independiente y los objetos de clúster de carga de trabajo que administra:

  1. Vuelva a crear el clúster de administración desde su archivo de configuración,mgmt-cluster-config.yaml aquí, como se describe en Implementar clústeres de administración desde un archivo de configuración.

    Nota

    Los cambios de configuración aplicados al clúster de administración después de su implementación deben reflejarse en el archivo de configuración o las variables de entorno, o bien no se restaurarán.

  2. Inmediatamente después de crear el clúster de administración, debe haber una sola TKR:

    tanzu kubernetes-release get
NAME                       VERSION                  COMPATIBLE  ACTIVE  UPDATES AVAILABLE
v1.24.10---vmware.1-tkg.1  v1.24.10+vmware.1-tkg.1  True        True

  3. Espere unos minutos hasta que estén disponibles todas las TKR que utilizan los clústeres de carga de trabajo con copia de seguridad:

    tanzu kubernetes-release get
NAME                       VERSION                  COMPATIBLE  ACTIVE  UPDATES AVAILABLE
v1.22.17---vmware.2-tkg.2  v1.22.17+vmware.2-tkg.2  True        True
v1.23.16---vmware.1-tkg.1  v1.23.16+vmware.1-tkg.1  True        True
v1.24.10---vmware.1-tkg.1   v1.24.10+vmware.1-tkg.1 True        True

  4. Instale Velero en el clúster de administración siguiendo las instrucciones anteriores Implementar servidor Velero en clústeres. Asegúrese de que las credenciales y las opciones de configuración de ubicación de copia de seguridad tengan los mismos valores que cuando se realizó la copia de seguridad.

  5. Después de instalar Velero, ejecute velero backup get hasta que se sincronicen las copias de seguridad y el comando muestre la copia de seguridad que desea utilizar:

    velero backup get
NAME                 STATUS      ERRORS   WARNINGS   CREATED                         EXPIRES   STORAGE LOCATION   SELECTOR
my-backup            Completed   0        0          2022-12-07 17:10:42 +0000 UTC   24d       default            <none>

  6. Ejecute velero restore create para restaurar los recursos del clúster de carga de trabajo. VMware recomienda utilizar la copia de seguridad más reciente:

    velero restore create my-restore --from-backup my-backup --wait

    Una vez completada la restauración, los clústeres tienen el estado createdStalled:

    tanzu cluster list
NAME                NAMESPACE  STATUS          CONTROLPLANE  WORKERS  KUBERNETES         ROLES   PLAN  TKR
tkg-vc-antrea       default    createdStalled  0/3           0/3      v1.24.10+vmware.1   <none>  prod  v1.24.10---vmware.1-tkg.1

  7. Aplique una revisión a los objetos del clúster para establecer su propiedad paused en false. Esto es necesario porque los objetos del clúster se vuelven a crear en un estado paused en el nuevo clúster de administración, para evitar que sus controladores intenten conciliar:

    • Para anular la pausa de un clúster después de restaurarlo, ejecute:

      kubectl -n my-namespace patch cluster CLUSTER-NAME --type merge -p '{"spec":{"paused":false}}'

    • Para anular la pausa de todos los clústeres en varios espacios de nombres, ejecute el script:

      #!/bin/bash

for ns in $(kubectl get ns -o custom-columns=":metadata.name" | grep -v "tkg-system");
do
      clusters=$(kubectl -n $ns get cluster -o name)
      if [[ -n $clusters ]];then
              kubectl -n $ns patch $clusters --type merge -p '{"spec":{"paused":false}}'
      fi
done

  8. Compruebe que todos los clústeres de carga de trabajo estén en el estado running, por ejemplo:

    tanzu cluster list
NAME                NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES         ROLES   PLAN  TKR
tkg-vc-antrea       default    running  3/3           3/3      v1.24.10+vmware.1  <none>  prod  v1.24.10---vmware.1-tkg.1

  9. Para cada clúster de carga de trabajo, ejecute tanzu cluster get CLUSTER-NAME para comprobar que todos los componentes estén en el estado running, por ejemplo:

    tanzu cluster get tkg-vc-antrea
  NAME           NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES   TKR
  tkg-vc-antrea  default    running  3/3           3/3      v1.24.10+vmware.1 <none>  v1.24.10---vmware.1-tkg.1

Details:

NAME                                                          READY  SEVERITY  REASON  SINCE  MESSAGE
/tkg-vc-antrea                                                True                     4h14m
├─ClusterInfrastructure - VSphereCluster/tkg-vc-antrea-s6kl5  True                     4h36m
├─ControlPlane - KubeadmControlPlane/tkg-vc-antrea-ch5hn      True                     4h14m
│ ├─Machine/tkg-vc-antrea-ch5hn-8gfvt                         True                     4h14m
│ ├─Machine/tkg-vc-antrea-ch5hn-vdcrp                         True                     4h23m
│ └─Machine/tkg-vc-antrea-ch5hn-x7nmm                         True                     4h32m
└─Workers
  ├─MachineDeployment/tkg-vc-antrea-md-0-8b8zn                True                     4h23m
  │ └─Machine/tkg-vc-antrea-md-0-8b8zn-798d5b8897-bnxn9       True                     4h24m
  ├─MachineDeployment/tkg-vc-antrea-md-1-m6dvh                True                     4h24m
  │ └─Machine/tkg-vc-antrea-md-1-m6dvh-79fb858b96-p9667       True                     4h28m
  └─MachineDeployment/tkg-vc-antrea-md-2-brm2m                True                     4h21m
    └─Machine/tkg-vc-antrea-md-2-brm2m-6478cffc5f-tq5cn       True                     4h23m

    Después de que todos los clústeres de carga de trabajo estén en ejecución, puede administrarlos con la CLI de Tanzu.

Gestionar desfase

Los casos de desfase pueden ser complicados, pero algunos patrones y mitigaciones comunes incluyen:

  • Nodos de trabajo obsoletos:

    • Nodos adicionales sin utilizar
    • Puede ocurrir si el recuento de nodos de trabajo se redujo después de la copia de seguridad
    • La mitigación a menudo no es necesaria. Después de la restauración, la comprobación de estado de la máquina elimina los objetos de máquina obsoletos y se crean nuevos nodos para cumplir con el número de máquinas deseado.

  • Infraestructura de nodo de trabajo fantasma:

    • Infraestructura superflua de nodo sin administrar
    • Puede ocurrir si el recuento de nodos de trabajo aumentó después de la copia de seguridad

    • Mitigación:

      1. Obtenga el clúster de carga de trabajokubeconfig y establézcalo como el contexto kubectl.

      2. Compare los resultados de los siguientes comandos kubectl y tanzu:

        # Get the actual worker nodes of the workload cluster
$ kubectl --context tkg-vc-antrea-admin@tkg-vc-antrea get node
NAME                                        STATUS   ROLES           AGE    VERSION
tkg-vc-antrea-md-0-p9vn5-645498f59f-42qh9   Ready    <none>          44m    v1.24.10+vmware.1
tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt   Ready    <none>          114m   v1.24.10+vmware.1
tkg-vc-antrea-wdsfx-2hkxp                   Ready    control-plane   116m   v1.24.10+vmware.1

# Get the worker nodes managed by the TKG
$ tanzu cluster get tkg-vc-antrea
  NAME           NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES   TKR
  tkg-vc-antrea  default    running  1/1           1/1      v1.24.10+vmware.1  <none>  v1.24.10---vmware.1-tkg.1-zshippable

  Details:

  NAME                                                          READY  SEVERITY  REASON  SINCE  MESSAGE
  /tkg-vc-antrea                                                True                     13m
  ├─ClusterInfrastructure - VSphereCluster/tkg-vc-antrea-b7fr9  True                     13m
  ├─ControlPlane - KubeadmControlPlane/tkg-vc-antrea-wdsfx      True                     13m
  │ └─Machine/tkg-vc-antrea-wdsfx-2hkxp                         True                     13m
  └─Workers
    └─MachineDeployment/tkg-vc-antrea-md-0-p9vn5                True                     13m
      └─Machine/tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt       True                     13m

      3. Para cada nodo de trabajo enumerado por kubectl que no tiene una lista Workers > Machine de tanzu cluster get:

        1. Escale verticalmente los trabajos al valor esperado, por ejemplo:

          tanzu cluster scale ${cluster_name} --worker-machine-count 2
        2. Utilice el clúster kubeconfig para drenar el nodo fantasma, que mueve sus cargas de trabajo a los nodos administrados por TKG:
          kubectl drain ${node_name} --delete-emptydir-data --ignore-daemonsets

        3. Elimine el nodo fantasma del clúster:

          kubectl delete node ${node_name}

        4. Inicie sesión en vSphere u otra infraestructura y elimine manualmente la máquina virtual.

  • Nodos obsoletos e infraestructura fantasma en el plano de control

    • Nodos sin utilizar e infraestructura de nodos superfluos para el plano de control
    • Puede ocurrir si el nodo del plano de control se reemplazó después de la copia de seguridad

    • Mitigación:

      1. Obtenga el clúster de carga de trabajokubeconfig y establézcalo como el contexto kubectl.

      2. Compare los resultados de los siguientes comandos kubectl y tanzu:

        # Get the actual control plane nodes of the workload cluster
$ kubectl --context wc-admin@wc get node
NAME                             STATUS   ROLES           AGE    VERSION
wc-2cjn4-4xbf8                   Ready    control-plane   107s   v1.24.10+vmware.1
wc-2cjn4-4zljs                   Ready    control-plane   26h    v1.24.10+vmware.1
wc-2cjn4-59v95                   Ready    control-plane   26h    v1.24.10+vmware.1
wc-2cjn4-ncgxb                   Ready    control-plane   25h    v1.24.10+vmware.1
wc-md-0-nl928-5df8b9bfbd-nww2w   Ready    <none>          26h    v1.24.10+vmware.1
wc-md-1-j4m55-589cfcd9d6-jxmvc   Ready    <none>          26h    v1.24.10+vmware.1
wc-md-2-sd4ww-7b7db5dcbb-crwdv   Ready    <none>          26h    v1.24.10+vmware.1

# Get the control plane nodes managed by the TKG
$ tanzu cluster get wc
NAME  NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES   TKR
wc    default    updating 4/3           3/3      v1.24.10+vmware.1 <none>  v1.24.10---vmware.1-tkg.1-zshippable

Details:

NAME                                               READY  SEVERITY  REASON  SINCE  MESSAGE
/wc                                                True                     24m
├─ClusterInfrastructure - VSphereCluster/wc-9nq7v  True                     26m
├─ControlPlane - KubeadmControlPlane/wc-2cjn4      True                     24m
│ ├─Machine/wc-2cjn4-4xbf8                         True                     24m
│ ├─Machine/wc-2cjn4-4zljs                         True                     26m
│ └─Machine/wc-2cjn4-59v95                         True                     26m
└─Workers
├─MachineDeployment/wc-md-0-nl928                True                     26m
│ └─Machine/wc-md-0-nl928-5df8b9bfbd-nww2w       True                     26m
├─MachineDeployment/wc-md-1-j4m55                True                     26m
│ └─Machine/wc-md-1-j4m55-589cfcd9d6-jxmvc       True                     26m
└─MachineDeployment/wc-md-2-sd4ww                True                     26m
  └─Machine/wc-md-2-sd4ww-7b7db5dcbb-crwdv       True                     26m

      3. Para cada nodo control-plane enumerado por kubectl que no tiene una lista ControlPlane > Machine de tanzu cluster get:

        1. Elimine el nodo:

          kubectl delete node ${node_name}
        2. Inicie sesión en vSphere u otra infraestructura y elimine manualmente la máquina virtual.
check-circle-line exclamation-circle-line close-line
Scroll to top icon