SupportConsoleDéveloppeursCommencer un essaiContact

14.7. Surveillance de la santé des machines virtuelles

Une instance de machine virtuelle (IMV) peut devenir malsaine en raison de problèmes transitoires tels qu'une perte de connectivité, des blocages ou des problèmes liés à des dépendances externes. Un contrôle de santé effectue périodiquement des diagnostics sur une IMV en utilisant n'importe quelle combinaison de sondes de disponibilité et d'état d'avancement.

14.7.1. À propos des sondes de disponibilité et d'intégrité

Utilisez des sondes de disponibilité et de vivacité pour détecter et gérer les instances de machines virtuelles (VMI) en mauvaise santé. Vous pouvez inclure une ou plusieurs sondes dans la spécification de la VMI pour vous assurer que le trafic n'atteint pas une VMI qui n'est pas prête à l'accueillir et qu'une nouvelle instance est créée lorsqu'une VMI ne répond plus.

Une adresse readiness probe détermine si une IMV est prête à accepter des demandes de service. Si la sonde échoue, la VMI est retirée de la liste des points d'extrémité disponibles jusqu'à ce que la VMI soit prête.

Un site liveness probe détermine si une IMV est réactive. Si la sonde échoue, la VMI est supprimée et une nouvelle instance est créée pour rétablir la réactivité.

Vous pouvez configurer les tests de disponibilité et d'accessibilité en définissant les champs spec.readinessProbe et spec.livenessProbe de l'objet VirtualMachineInstance. Ces champs prennent en charge les tests suivants :

HTTP GET
La sonde détermine l'état de santé de l'IMV à l'aide d'un crochet Web. Le test est réussi si le code de réponse HTTP est compris entre 200 et 399. Vous pouvez utiliser un test HTTP GET avec des applications qui renvoient des codes d'état HTTP lorsqu'elles sont complètement initialisées.
Socket TCP
La sonde tente d'ouvrir une connexion avec l'IMV. L'IMV n'est considérée comme saine que si la sonde peut établir une connexion. Vous pouvez utiliser un test de socket TCP avec des applications qui ne commencent à écouter qu'une fois l'initialisation terminée.
Agent invité ping
La sonde utilise la commande guest-ping pour déterminer si l'agent invité QEMU est exécuté sur la machine virtuelle.

14.7.2. Définition d'une sonde de préparation HTTP

Définissez une sonde de préparation HTTP en définissant le champ spec.readinessProbe.httpGet de la configuration de l'instance de machine virtuelle (VMI).

Procédure

  1. Inclure les détails de la sonde de disponibilité dans le fichier de configuration de l'IMV.

    Exemple de sonde de préparation avec un test HTTP GET

    # ...
spec:
  readinessProbe:
    httpGet: 1
      port: 1500 2
      path: /healthz 3
      httpHeaders:
      - name: Custom-Header
        value: Awesome
    initialDelaySeconds: 120 4
    periodSeconds: 20 5
    timeoutSeconds: 10 6
    failureThreshold: 3 7
    successThreshold: 3 8
# ...

    1
    La requête HTTP GET à effectuer pour se connecter à l'IMV.
    2
    Le port de l'IMV que la sonde interroge. Dans l'exemple ci-dessus, la sonde interroge le port 1500.
    3
    Le chemin d'accès au serveur HTTP. Dans l'exemple ci-dessus, si le gestionnaire du chemin /healthz du serveur renvoie un code de réussite, l'IMV est considérée comme saine. Si le gestionnaire renvoie un code d'échec, l'IMV est supprimée de la liste des points d'extrémité disponibles.
    4
    Temps, en secondes, écoulé entre le démarrage de l'IMV et le lancement de la sonde d'état de préparation.
    5
    Délai, en secondes, entre l'exécution des sondes. Le délai par défaut est de 10 secondes. Cette valeur doit être supérieure à timeoutSeconds.
    6
    Le nombre de secondes d'inactivité après lesquelles la sonde s'arrête et la VMI est considérée comme ayant échoué. La valeur par défaut est 1. Cette valeur doit être inférieure à periodSeconds.
    7
    Le nombre de fois où la sonde est autorisée à échouer. La valeur par défaut est de 3. Après le nombre de tentatives spécifié, le pod est marqué Unready.
    8
    Nombre de fois où la sonde doit signaler un succès, après un échec, pour être considérée comme réussie. La valeur par défaut est 1.

  2. Créez la VMI en exécutant la commande suivante : 

    oc create -f <nom_du_fichier>.yaml

14.7.3. Définition d'une sonde de disponibilité TCP

Définissez une sonde de préparation TCP en définissant le champ spec.readinessProbe.tcpSocket de la configuration de l'instance de machine virtuelle (VMI).

Procédure

  1. Inclure les détails de la sonde d'état de préparation TCP dans le fichier de configuration de l'IMV.

    Exemple de sonde de disponibilité avec un test de socket TCP

    ...
spec:
  readinessProbe:
    initialDelaySeconds: 120 1
    periodSeconds: 20 2
    tcpSocket: 3
      port: 1500 4
    timeoutSeconds: 10 5
...

    1
    Temps, en secondes, écoulé entre le démarrage de l'IMV et le lancement de la sonde d'état de préparation.
    2
    Délai, en secondes, entre l'exécution des sondes. Le délai par défaut est de 10 secondes. Cette valeur doit être supérieure à timeoutSeconds.
    3
    L'action TCP à effectuer.
    4
    Le port de l'IMV que la sonde interroge.
    5
    Le nombre de secondes d'inactivité après lesquelles la sonde s'arrête et la VMI est considérée comme ayant échoué. La valeur par défaut est 1. Cette valeur doit être inférieure à periodSeconds.

  2. Créez la VMI en exécutant la commande suivante : 

    oc create -f <nom_du_fichier>.yaml

14.7.4. Définition d'une sonde de vivacité HTTP

Définissez une sonde de disponibilité HTTP en définissant le champ spec.livenessProbe.httpGet de la configuration de l'instance de machine virtuelle (IMV). Vous pouvez définir des tests HTTP et TCP pour les sondes de validité de la même manière que pour les sondes de disponibilité. Cette procédure configure un exemple de sonde de disponibilité avec un test HTTP GET.

Procédure

  1. Inclure les détails de la sonde HTTP dans le fichier de configuration de l'IMV.

    Exemple de sonde de vivacité avec un test HTTP GET

    # ...
spec:
  livenessProbe:
    initialDelaySeconds: 120 1
    periodSeconds: 20 2
    httpGet: 3
      port: 1500 4
      path: /healthz 5
      httpHeaders:
      - name: Custom-Header
        value: Awesome
    timeoutSeconds: 10 6
# ...

    1
    Délai, en secondes, entre le démarrage de l'IMV et le lancement de l'enquête sur l'état de conservation.
    2
    Délai, en secondes, entre l'exécution des sondes. Le délai par défaut est de 10 secondes. Cette valeur doit être supérieure à timeoutSeconds.
    3
    La requête HTTP GET à effectuer pour se connecter à l'IMV.
    4
    Le port de l'IMV que la sonde interroge. Dans l'exemple ci-dessus, la sonde interroge le port 1500. L'IMV installe et exécute un serveur HTTP minimal sur le port 1500 via cloud-init.
    5
    Le chemin d'accès au serveur HTTP. Dans l'exemple ci-dessus, si le gestionnaire du chemin d'accès au serveur /healthz renvoie un code de réussite, l'IMV est considérée comme saine. Si le gestionnaire renvoie un code d'échec, la VMI est supprimée et une nouvelle instance est créée.
    6
    Le nombre de secondes d'inactivité après lesquelles la sonde s'arrête et la VMI est considérée comme ayant échoué. La valeur par défaut est 1. Cette valeur doit être inférieure à periodSeconds.

  2. Créez la VMI en exécutant la commande suivante : 

    oc create -f <nom_du_fichier>.yaml

14.7.5. Définition d'une sonde ping de l'agent invité

Définissez une sonde ping de l'agent invité en définissant le champ spec.readinessProbe.guestAgentPing de la configuration de l'instance de machine virtuelle (VMI).

Important

La sonde ping de l'agent invité est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas leur utilisation en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Conditions préalables

  • L'agent invité QEMU doit être installé et activé sur la machine virtuelle.

Procédure

  1. Inclure les détails de la sonde ping de l'agent invité dans le fichier de configuration de l'IMV. Par exemple, les détails de la sonde ping de l'agent invité dans le fichier de configuration de l'IMV :

    Exemple de sonde ping d'un agent invité

    # ...
spec:
  readinessProbe:
    guestAgentPing: {} 1
    initialDelaySeconds: 120 2
    periodSeconds: 20 3
    timeoutSeconds: 10 4
    failureThreshold: 3 5
    successThreshold: 3 6
# ...

    1
    La sonde ping de l'agent invité pour se connecter à la VMI.
    2
    Facultatif : Le temps, en secondes, après le démarrage de l'IMV avant que la sonde de l'agent invité ne soit lancée.
    3
    Facultatif : Délai, en secondes, entre l'exécution des sondes. Le délai par défaut est de 10 secondes. Cette valeur doit être supérieure à timeoutSeconds.
    4
    Facultatif : Le nombre de secondes d'inactivité après lequel la sonde s'arrête et la VMI est considérée comme ayant échoué. La valeur par défaut est 1. Cette valeur doit être inférieure à periodSeconds.
    5
    Facultatif : Le nombre de fois où la sonde est autorisée à échouer. La valeur par défaut est 3. Après le nombre de tentatives spécifié, le pod est marqué Unready.
    6
    Facultatif : Nombre de fois où la sonde doit signaler un succès, après un échec, pour être considérée comme réussie. La valeur par défaut est 1.

  2. Créez la VMI en exécutant la commande suivante : 

    oc create -f <nom_du_fichier>.yaml

14.7.6. Modèle : Fichier de configuration de la machine virtuelle pour la définition des contrôles de santé

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  labels:
    special: vm-fedora
  name: vm-fedora
spec:
  template:
    metadata:
      labels:
        special: vm-fedora
    spec:
      domain:
        devices:
          disks:
          - disk:
              bus: virtio
            name: containerdisk
          - disk:
              bus: virtio
            name: cloudinitdisk
        resources:
          requests:
            memory: 1024M
      readinessProbe:
        httpGet:
          port: 1500
        initialDelaySeconds: 120
        periodSeconds: 20
        timeoutSeconds: 10
        failureThreshold: 3
        successThreshold: 3
      terminationGracePeriodSeconds: 180
      volumes:
      - name: containerdisk
        containerDisk:
          image: kubevirt/fedora-cloud-registry-disk-demo
      - cloudInitNoCloud:
          userData: |-
            #cloud-config
            password: fedora
            chpasswd: { expire: False }
            bootcmd:
              - setenforce 0
              - dnf install -y nmap-ncat
              - systemd-run --unit=httpserver nc -klp 1500 -e '/usr/bin/echo -e HTTP/1.1 200 OK\\n\\nHello World!'
        name: cloudinitdisk

14.7.7. Ressources supplémentaires

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.