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:
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.
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:
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.
PrecauciónSi 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.7. 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.7, haga lo siguiente:
.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-
.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
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:
/usr/local/bin
y cámbiele el nombre a velero
.chmod +x /usr/local/bin/velero
Plataformas de Windows:
Program Files\velero
y copie el archivo binario en ella.velero.exe
velero
, seleccione Propiedades (Properties) > Seguridad (Security) y asegúrese de que su cuenta de usuario tenga el permiso Control completo (Full Control).env
.Path
en Variables del sistema (System variables) y haga clic en Editar (Edit).velero
.Para realizar una copia de seguridad del contenido del clúster de carga de trabajo de Tanzu Kubernetes Grid, necesita ubicaciones de almacenamiento para:
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:
VMware recomienda dedicar un depósito de almacenamiento único a cada clúster.
Para configurar MinIO:
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
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
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.3.
Para configurar el almacenamiento para Velero on AWS, siga los procedimientos descritos en el repositorio de complementos de Velero para AWS:
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.
Para configurar el almacenamiento de Velero en Azure, siga los procedimientos descritos en los complementos de Velero para el repositorio de Azure:
Crear una cuenta de almacenamiento de Azure y un contenedor de blob
Obtener el grupo de recursos que contiene las máquinas virtuales y los discos
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.
Para realizar copias de seguridad de los objetos del clúster de carga de trabajo, instale el servidor Velero v1.9.7 en el clúster de administración independiente y compruebe las instalaciones.
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.5_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--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:
--plugins projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.1.0_vmware.1
NotaPuede agregar varias opciones separadas por comas. Por ejemplo:
--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.5.5_vmware.1,projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.1.0_vmware.1
--snapshot-location-config
Una vez completado el comando velero install
, compruebe que Velero se haya instalado correctamente:
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
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
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
Nota
--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 trabajoVMware 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.
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.
Para restaurar un clúster de administración independiente y los objetos de clúster de carga de trabajo que administra:
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.
NotaLos 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.
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.25.7---vmware.1-tkg.1 v1.25.7+vmware.1-tkg.1 True True
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.23.17---vmware.2-tkg.2 v1.23.17+vmware.2-tkg.2 True True
v1.24.11---vmware.1-tkg.1 v1.24.11+vmware.1-tkg.1 True True
v1.25.7---vmware.1-tkg.1 v1.25.7+vmware.1-tkg.1 True True
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.
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>
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.25.7+vmware.1 <none> prod v1.25.7---vmware.1-tkg.1
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
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.25.7+vmware.1 <none> prod v1.25.7---vmware.1-tkg.1
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.25.7+vmware.1 <none> v1.25.7---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.
Los casos de desfase pueden ser complicados, pero algunos patrones y mitigaciones comunes incluyen:
Nodos de trabajo obsoletos:
Infraestructura de nodo de trabajo fantasma:
Mitigación:
kubeconfig
y establézcalo como el contexto kubectl
.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.25.7+vmware.1
tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt Ready <none> 114m v1.25.7+vmware.1
tkg-vc-antrea-wdsfx-2hkxp Ready control-plane 116m v1.25.7+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.25.7+vmware.1 <none> v1.25.7---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
Para cada nodo de trabajo enumerado por kubectl
que no tiene una lista Workers
> Machine
de tanzu cluster get
:
Escale verticalmente los trabajos al valor esperado, por ejemplo:
tanzu cluster scale ${cluster_name} --worker-machine-count 2
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
Elimine el nodo fantasma del clúster:
kubectl delete node ${node_name}
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
Mitigación:
kubeconfig
y establézcalo como el contexto kubectl
.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.25.7+vmware.1
wc-2cjn4-4zljs Ready control-plane 26h v1.25.7+vmware.1
wc-2cjn4-59v95 Ready control-plane 26h v1.25.7+vmware.1
wc-2cjn4-ncgxb Ready control-plane 25h v1.25.7+vmware.1
wc-md-0-nl928-5df8b9bfbd-nww2w Ready <none> 26h v1.25.7+vmware.1
wc-md-1-j4m55-589cfcd9d6-jxmvc Ready <none> 26h v1.25.7+vmware.1
wc-md-2-sd4ww-7b7db5dcbb-crwdv Ready <none> 26h v1.25.7+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.25.7+vmware.1 <none> v1.25.7---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
Para cada nodo control-plane
enumerado por kubectl
que no tiene una lista ControlPlane
> Machine
de tanzu cluster get
:
Elimine el nodo:
kubectl delete node ${node_name}