Configurer les règles d'éviction pour les VM dans GDCV pour Bare Metal

Ce document s'adresse aux administrateurs de plate-forme qui exécutent des machines virtuelles (VM) dans GKE sur une solution Bare Metal. Ce document explique comment configurer la règle d'éviction qui contrôle la migration automatique des VM qui utilisent l'environnement d'exécution de VM sur GDC vers d'autres hôtes lors d'événements de maintenance. Ces paramètres de configuration vous permettent de continuer à exécuter des VM sur d'autres hôtes lorsque vous mettez à niveau un cluster ou effectuez une maintenance sur un hôte.

Avant de commencer

Pour terminer ce document, vous devez accéder à un cluster GKE sur Bare Metal version 1.12.0 (anthosBareMetalVersion: 1.12.0) ou ultérieure. Vous pouvez utiliser n'importe quel type de cluster capable d'exécuter des charges de travail. Si nécessaire, essayez GDCV pour Bare Metal sur Compute Engine ou consultez la présentation de la création de clusters.

Paramètres des règles d'éviction

GKE sur Bare Metal vous permet de configurer le comportement des nœuds lorsque vous mettez à niveau un cluster ou que vous les placez en mode maintenance. L'environnement d'exécution des VM sur GDC utilise une règle d'éviction qui contrôle la manière dont le cluster gère les VM exécutées lors de ces événements.

Lorsque cette option est activée, l'environnement d'exécution des VM sur GDC utilise la migration à chaud pour déplacer les charges de travail de VM vers un autre hôte par défaut. Ce comportement minimise les perturbations potentielles des charges de travail de VM. Avec la migration à chaud, les VM pouvant être migrées passent d'un hôte à un autre sans perturbation pour le système d'exploitation invité.

Les paramètres suivants peuvent être configurés pour les règles d'éviction :

Propriété Par défaut Valeurs valides
evictionStrategy LiveMigrate LiveMigrate, Restart
maxMigrationAttemptsPerVM 3 Entiers compris dans la plage [1,5]
migrationTargetInitializationTimeout 30s Toute chaîne de durée valide, telle que 1m, 2h ou 1h30m

evictionStrategy

Si cette valeur est définie sur LiveMigrate, l'environnement d'exécution de VM sur GDC tente de migrer toute VM pouvant être migrée depuis un nœud afin de l'expulser. La VM est placée sur un autre nœud du cluster et continue de s'exécuter.

Si cette valeur est définie sur Restart, l'environnement d'exécution de VM sur GDC ne tente pas de migrer les VM. Au lieu de cela, les VM sont arrêtées lorsque le nœud est mis en mode de maintenance, puis redémarrent lorsque les nœuds sont désactivés. La VM n'est pas disponible pendant l'événement de maintenance de l'hôte.

Lorsque vous choisissez la stratégie LiveMigrate, l'environnement d'exécution de VM sur GDC bascule sur la stratégie Restart pour les VM non transférables.

maxMigrationAttemptsPerVM

Ce paramètre contrôle le nombre maximal de tentatives de migration pouvant être effectuées pour une VM particulière avant que la stratégie Restart ne s'applique.

Ce paramètre est ignoré si evictionStrategy est défini sur Restart.

migrationTargetInitializationTimeout

Ce paramètre contrôle le délai maximal de démarrage d'une migration avant qu'elle soit considérée comme ayant échoué. Une migration qui prend trop de temps est comptabilisée dans le budget de migration en échec pour une charge de travail de VM.

Ce paramètre est ignoré si evictionStrategy est défini sur Restart.

Activer et configurer la règle d'éviction

Pour utiliser la règle d'éviction dans l'environnement d'exécution de VM sur GDC, le paramètre evictionPolicy doit être défini dans l'objet VMRuntime de votre cluster. Ce paramètre est activé par défaut dans les clusters Anthos sur solution Bare Metal version 1.12 et ultérieure. Si vous effectuez une mise à niveau à partir d'une version précédente, vous devez activer ce paramètre manuellement.

Un objet vide, tel que evictionPolicy: {}, active la règle d'éviction avec les paramètres par défaut. Pour modifier le comportement par défaut, ajoutez des options de configuration supplémentaires à l'objet evictionPolicy.

Pour activer et configurer la règle d'éviction, procédez comme suit :

  1. Modifiez la ressource personnalisée VMRuntime :

    kubectl edit vmruntime vmruntime

  2. Ajoutez ou mettez à jour la section evictionPolicy avec un objet vide pour utiliser les paramètres de règle d'éviction par défaut, ou ajoutez les paramètres souhaités :

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

    Si l'élément evictionPolicy n'est pas renseigné, tel que evictionPolicy: null, ou n'est pas inclus dans le fichier manifeste, aucune action spéciale n'est effectuée. Les VM sont supprimées de force.

    Les exemples de fichiers manifestes suivants montrent comment activer la migration à chaud des VM ou redémarrer les VM sur le même hôte une fois la maintenance terminée :

    Migration à chaud

    L'exemple de règle d'éviction suivant active la migration à chaud des VM. Le cluster peut relancer la migration à chaud jusqu'à trois fois, avec un délai de 30 secondes pour le processus à chaque démarrage :

    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

    Redémarrer

    L'exemple de règle d'éviction suivant ne tente aucune migration pour les VM pendant l'éviction. Les VM sont arrêtées sur leur hôte actuel et redémarrent une fois que l'événement de maintenance sur l'hôte est terminé :

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

  3. Enregistrez et fermez la ressource personnalisée VMRuntime dans votre éditeur.

    L'environnement d'exécution des VM sur GDC applique désormais la règle d'éviction aux VM de votre cluster.

Étapes suivantes