Configura las políticas de expulsión de las VMs en GDCV para Bare Metal

Este documento está destinado a los administradores de plataformas que ejecutan máquinas virtuales (VM) en GKE en Bare Metal. En este documento, se muestra cómo configurar la política de expulsión que controla cómo las VM que usan el entorno de ejecución de VM en GDC pueden migrar de forma automática a otros hosts durante los eventos de mantenimiento. Estos parámetros de configuración te permiten seguir ejecutando las VM en otros hosts cuando actualizas un clúster o realizas mantenimiento en un host.

Antes de comenzar

Para completar este documento, necesitas acceso a la versión 1.12.0 (anthosBareMetalVersion: 1.12.0) o superior de GKE en Bare Metal. Puedes usar cualquier tipo de clúster capaz de ejecutar cargas de trabajo. Si es necesario, prueba GDCV para Bare Metal en Compute Engine o consulta la descripción general de la creación de clústeres.

Configuración de la política de expulsión

GKE en Bare Metal te permite configurar el comportamiento de los nodos cuando actualizas clústeres o cuando colocas nodos en modo de mantenimiento. El entorno de ejecución de VM en GDC usa una política de expulsión que controla cómo el clúster controla las VM que se ejecutan durante estos eventos.

Cuando está habilitado, el entorno de ejecución de VM en GDC usa la migración en vivo para mover las cargas de trabajo de VM a otro host de forma predeterminada. Este comportamiento minimiza las posibles interrupciones en las cargas de trabajo de la VM. Con la migración en vivo, las VM que se pueden migrar se mueven de un host a otro sin interrupciones en el SO invitado.

La siguiente configuración de política de expulsión puede configurarse:

Propiedad Predeterminado Valores válidos
evictionStrategy LiveMigrate LiveMigrate, Restart
maxMigrationAttemptsPerVM 3 Números enteros en el rango [1,5]
migrationTargetInitializationTimeout 30s Cualquier string de duración válida, como 1m, 2h o 1h30m

evictionStrategy

Si este valor se establece en LiveMigrate, el entorno de ejecución de VM en GDC intentará migrar las VM que se puedan migrar de un nodo para expulsarlas. La VM se coloca en otro nodo del clúster y continúa ejecutándose.

Si este valor se establece en Restart, el entorno de ejecución de VM en GDC no intentará migrar las VM. En cambio, las VM se detienen cuando el nodo se pone en modo de mantenimiento, y las VM vuelven a iniciarse cuando el nodo sale del modo de mantenimiento. La VM no estará disponible durante el evento de mantenimiento del host.

Cuando eliges la estrategia LiveMigrate, el entorno de ejecución de VM en GDC recurre a la estrategia Restart para las VM que no se pueden migrar.

maxMigrationAttemptsPerVM

Esta configuración controla la cantidad máxima de intentos de migración que pueden ocurrir para una VM en particular antes de que se aplique la estrategia de Restart.

Esta configuración se ignora si evictionStrategy se establece en Restart.

migrationTargetInitializationTimeout

Esta configuración controla el tiempo máximo que puede tardar una migración en iniciarse antes de que se considere que falló. Una migración que lleva demasiado tiempo en iniciarse se considera dentro del presupuesto de migración con errores de una carga de trabajo de VM.

Esta configuración se ignora si evictionStrategy se establece en Restart.

Habilita y configura la política de expulsión

Para usar la política de expulsión en el entorno de ejecución de VM en GDC, se debe definir la configuración evictionPolicy en el objeto VMRuntime del clúster. Esta configuración está habilitada de forma predeterminada en los clústeres de Anthos en la versión 1.12 y posteriores de equipos físicos. Si actualizas desde una versión anterior, debes habilitar esta configuración de forma manual.

Un objeto vacío, como evictionPolicy: {}, habilita la política de expulsión con la configuración predeterminada. Para cambiar el comportamiento predeterminado, agrega opciones de configuración adicionales al objeto evictionPolicy.

Para habilitar y configurar la política de expulsión, completa los siguientes pasos:

  1. Edita el recurso personalizado VMRuntime:

    kubectl edit vmruntime vmruntime
    
  2. Agrega o actualiza la sección evictionPolicy con un objeto vacío para usar la configuración de la política de expulsión predeterminada o agrega la configuración que desees:

    apiVersion: vm.cluster.gke.io/v1
    kind: VMRuntime
    metadata:
      name: vmruntime
    spec:
      disableCDIUploadProxyVIP: false
      enabled: true
      evictionPolicy: {}
      useEmulation: false
    

    Si evictionPolicy no se propaga, como evictionPolicy: null, o no se incluye en el manifiesto, no se realiza ninguna acción especial. Las VMs se expulsan de manera forzada.

    En los siguientes manifiestos de ejemplo, se muestra cómo habilitar la migración en vivo de VM o reiniciar las VM en el mismo host después de que se complete el mantenimiento:

    Migración en vivo

    En la siguiente política de expulsión de ejemplo, se habilita la migración en vivo de las VM. El clúster puede reintentar la migración en vivo hasta 3 veces y con un tiempo de espera de 30 segundos en el proceso cada vez para iniciarse:

    apiVersion: vm.cluster.gke.io/v1
    kind: VMRuntime
    metadata:
      name: vmruntime
    spec:
      disableCDIUploadProxyVIP: false
      enabled: true
      evictionPolicy:
        evictionStrategy: LiveMigrate
        maxMigrationAttemptsPerVM: 3
        migrationTargetInitializationTimeout: 30s
      useEmulation: false
    

    Reiniciar

    En la siguiente política de expulsión de ejemplo, no se intenta migrar ninguna VM durante la expulsión. Las VM se detienen en su host actual y comienzan de nuevo cuando el host finaliza su evento de mantenimiento:

    apiVersion: vm.cluster.gke.io/v1
    kind: VMRuntime
    metadata:
      name: vmruntime
    spec:
      disableCDIUploadProxyVIP: false
      enabled: true
      evictionPolicy:
        evictionStrategy: Restart
      useEmulation: false
    
  3. Guarda y cierra el recurso personalizado VMRuntime en el editor.

    El entorno de ejecución de VM en GDC ahora aplica la política de expulsión a las VMs del clúster.

¿Qué sigue?