En este documento, se muestra cómo configurar la política de alta disponibilidad para máquinas virtuales (VMs) que se ejecutan con el entorno de ejecución de VM en Google Distributed Cloud.
Cuando habilitas el entorno de ejecución de VM en Google Distributed Cloud, el clúster crea un objeto VMHighAvailabilityPolicy llamado default. Este objeto especifica la estrategia de recuperación predeterminada en caso de que falle un nodo de clúster que ejecuta una VM. Las posibles estrategias de recuperación predeterminadas son las siguientes:
- Reprogramar: Vuelve a programar la VM en otro nodo del clúster.
- Ignorar: No se hace nada.
Inicialmente, la estrategia de recuperación predeterminada se establece en Reschedule.
Una estrategia de recuperación predeterminada de Reschedule es adecuada en la siguiente situación:
Tu clúster debe tener al menos dos nodos trabajadores.
Tus discos de VM se aprovisionan mediante una clase de almacenamiento basada en archivos de red. Es decir, la clase de almacenamiento se basa en un sistema de archivos de red que coordina los bloqueos de archivos POSIX en diferentes clientes. El sistema de archivos de red (NFS) es un ejemplo de una clase de almacenamiento basada en archivos de red.
Si tus VM usan un almacenamiento local o un sistema de almacenamiento basado en bloques, te recomendamos que establezcas la estrategia de recuperación predeterminada en Ignore. Te recomendamos hacer esta recomendación por los siguientes motivos:
Si tus VM usan almacenamiento local y un nodo falla, no hay manera de recuperar los datos almacenados y moverlos a un nodo nuevo.
Si tus VM usan un sistema de almacenamiento basado en bloques, es posible que el almacenamiento no tenga suficientes garantías de desconexión. Esto podría provocar un acceso simultáneo al disco y daños en los datos durante la programación de VM.
Inspecciona el objeto VMHighAvailabilityPolicy
Verifica que haya un objeto VMHighAvailabilityPolicy:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get VMHighAvailabilityPolicy --namespace vm-system
Reemplaza USER_CLUSTER_KUBECONFIG con la ruta de tu archivo kubeconfig del clúster de usuario.
El resultado muestra que hay un objeto VMHighAvailabilityPolicy llamado default. En el resultado, también puedes ver el valor actual de defaultRecoveryStrategy. Por ejemplo, el siguiente resultado muestra que el valor actual de defaultRecoveryStrategy es Reschedule:
vm-system default 5m55s Reschedule 15s 1m30s
Obtén una vista detallada del objeto VMHighAvailabilityPolicy:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get VMHighAvailabilityPolicy \
--namespace vm-system --output yaml
Resultado de ejemplo:
apiVersion: vm.cluster.gke.io/v1alpha1
kind: VMHighAvailabilityPolicy
metadata:
...
labels:
app.kubernetes.io/component: kubevirt
app.kubernetes.io/managed-by: virt-operator
kubevirt.io: virt-api
name: default
namespace: vm-system
..
spec:
defaultRecoveryStrategy: Reschedule
nodeHeartbeatInterval: 15s
nodeMonitorGracePeriod: 1m30s
Cambia la estrategia de recuperación predeterminada
En algunas situaciones, te recomendamos que cambies la estrategia de recuperación predeterminada. Por ejemplo, si tus VM usan un almacenamiento local o un sistema de archivos que no se basa en archivos de red, te recomendamos que cambies el valor de defaultRecoveryStrategy a Ignore.
Para cambiar el valor de defaultRecoveryStrategy, abre el objeto VMHighAvailabilityPolicy para editarlo:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit VMHighAvailabilityPolicy \
default --namespace vm-system
En tu editor de texto, cambia el valor de defaultRecoveryStrategy por un valor de tu elección: Reschedule o Ignore. Cierra el editor de texto.
Anula la estrategia de recuperación predeterminada para una VM
La estrategia de recuperación predeterminada se aplica a todas las VM que se ejecutan en el clúster. Sin embargo, es posible que debas anular la estrategia de recuperación predeterminada para las VM individuales.
Por ejemplo, supongamos que la mayoría de tus VM se aprovisionan con una clase de almacenamiento basada en archivos de red, pero algunas se aprovisionan con una clase de almacenamiento basada en bloques. Para cada VM que usa almacenamiento basado en bloques, te recomendamos que anules la estrategia de recuperación predeterminada mediante la configuración de la estrategia de recuperación de la VM individual en Ignore.
Para anular la estrategia de recuperación predeterminada de una VM, agrega una anotación vm.cluster.gke.io/vm-ha-recovery-strategy al objeto VirtualMachineInstance (VMI) y al objeto GVM.
Por ejemplo, estos comandos establecen la estrategia de recuperación en Ignore para una VM llamada my-vm:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ annotate vmi my-vm \ vm.cluster.gke.io/vm-ha-recovery-strategy=Ignore --overwrite kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ annotate gvm my-vm \ vm.cluster.gke.io/vm-ha-recovery-strategy=Ignore --overwrite
Si deseas quitar las anotaciones más adelante, usa un guion al final del nombre de la anotación. Por ejemplo:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ annotate vmi my-vm \ vm.cluster.gke.io/vm-ha-recovery-strategy- kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ annotate gvm my-vm \ vm.cluster.gke.io/vm-ha-recovery-strategy-
Configuración avanzada
Además de configurar la estrategia de recuperación predeterminada, puedes configurar estos parámetros:
Intervalo de señal de monitoreo de funcionamiento del nodo: El tiempo que transcurre entre las señales de monitoreo de funcionamiento que envía cada nodo del clúster
Período de gracia del monitor de nodos: La cantidad máxima de tiempo que un nodo puede no enviar una señal de monitoreo de funcionamiento antes de que se considere en mal estado
En la mayoría de los casos, los valores predeterminados para el intervalo de señales de monitoreo de funcionamiento y el período de gracia son adecuados. Sin embargo, puedes elegir ajustar estos valores si deseas ajustar detalladamente la compensación entre la velocidad de recuperación y la sobrecarga. Un intervalo de señal de monitoreo de funcionamiento más corto acortará el tiempo de recuperación, pero también aumentará la sobrecarga. En un clúster grande, puedes elegir extender el intervalo de señal de monitoreo de funcionamiento, ya que las señales de monitoreo de funcionamiento frecuentes de muchos nodos podría crear una carga inaceptable en el servidor de la API de Kubernetes.
Mantén el intervalo de señal de monitoreo de funcionamiento más bajo que el período de gracia para evitar casos en los que una sola señal de monitoreo de funcionamiento faltante haga que un nodo se considere en mal estado.
Ejecuta kubectl edit a fin de abrir el objeto VMHighAvailabilityPolicy para editarlo. Establece nodeHeartbeatInterval y nodeMonitorGracePeriod en los valores que elijas.
spec: defaultRecoveryStrategy: Reschedule nodeHeartbeatInterval: 15s nodeMonitorGracePeriod: 1m30s