14.14. Runbooks de virtualisation OpenShift
Vous pouvez utiliser les procédures de ces runbooks pour diagnostiquer et résoudre les problèmes qui déclenchent des alertes OpenShift Virtualization.
Les alertes OpenShift Virtualization sont affichées sur la page Virtualization > Overview.
14.14.1. CDIDataImportCronOutdated
Signification
Cette alerte se déclenche lorsque DataImportCron
ne peut pas interroger ou importer les dernières versions des images de disque.
DataImportCron
ce processus permet de mettre à jour les images de disques Polls, de vérifier les dernières versions et d'importer les images en tant que réclamations de volumes persistants (PVC). Ce processus garantit que les PVC sont mis à jour à la dernière version afin qu'ils puissent être utilisés comme sources de clone fiables ou comme images dorées pour les machines virtuelles (VM).
Pour les images dorées, latest fait référence au dernier système d'exploitation de la distribution. Pour les autres images de disque, latest renvoie au dernier hachage de l'image disponible.
Impact
Les machines virtuelles peuvent être créées à partir d'images de disque obsolètes.
Les machines virtuelles peuvent ne pas démarrer parce qu'aucun PVC source n'est disponible pour le clonage.
Diagnostic
Vérifiez que le cluster dispose d'une classe de stockage par défaut :
$ oc get sc
La sortie affiche les classes de stockage avec
(default)
à côté du nom de la classe de stockage par défaut. Vous devez définir une classe de stockage par défaut, soit sur le cluster, soit dans la spécificationDataImportCron
, pour queDataImportCron
interroge et importe des images dorées. Si aucune classe de stockage n'est définie, le contrôleur DataVolume ne parvient pas à créer de PVC et l'événement suivant s'affiche :DataVolume.storage spec is missing accessMode and no storageClass to choose profile
.Obtenir l'espace de noms et le nom de
DataImportCron
:$ oc get dataimportcron -A -o json | jq -r '.items[] | \ select(.status.conditions[] | select(.type == "UpToDate" and \ .status == "False")) | .metadata.namespace + "/" + .metadata.name'
Si une classe de stockage par défaut n'est pas définie sur le cluster, vérifiez la spécification
DataImportCron
pour une classe de stockage par défaut :$ oc get dataimportcron <dataimportcron> -o yaml | \ grep -B 5 storageClassName
Exemple de sortie
url: docker://.../cdi-func-test-tinycore storage: resources: requests: storage: 5Gi storageClassName: rook-ceph-block
Obtenir le nom de l'objet
DataVolume
associé à l'objetDataImportCron
:$ oc -n <namespace> get dataimportcron <dataimportcron> -o json | \ jq .status.lastImportedPVC.name
Vérifiez les messages d'erreur dans le journal
DataVolume
:oc -n <namespace> get dv <datavolume> -o yaml
Définir la variable d'environnement
CDI_NAMESPACE
:$ export CDI_NAMESPACE="$(oc get deployment -A | \ grep cdi-operator | awk '{print $1}')"
Vérifiez les messages d'erreur dans le journal
cdi-deployment
:$ oc logs -n $CDI_NAMESPACE deployment/cdi-deployment
Atténuation
-
Définissez une classe de stockage par défaut, soit sur le cluster, soit dans la spécification
DataImportCron
, pour interroger et importer les images dorées. La mise à jour de Containerized Data Importer (CDI) résoudra le problème en quelques secondes. -
Si le problème n'est pas résolu, supprimez les volumes de données associés aux objets
DataImportCron
concernés. Le CDI recréera les volumes de données avec la classe de stockage par défaut. Si votre cluster est installé dans un environnement réseau restreint, désactivez la fonctionnalité
enableCommonBootImageImport
afin de ne pas recevoir de mises à jour automatiques :$ oc patch hco kubevirt-hyperconverged -n $CDI_NAMESPACE --type json \ -p '[{"op": "replace", "path": \ "/spec/featureGates/enableCommonBootImageImport", "value": false}]'
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.2. CDIDataVolumeUnusualRestartCount
Signification
Cette alerte se déclenche lorsqu'un objet DataVolume
redémarre plus de trois fois.
Impact
Les volumes de données sont responsables de l'importation et de la création d'un disque de machine virtuelle sur une revendication de volume persistant. Si un volume de données redémarre plus de trois fois, il est peu probable que ces opérations aboutissent. Vous devez diagnostiquer et résoudre le problème.
Diagnostic
Obtenir le nom et l'espace de noms du volume de données :
$ oc get dv -A -o json | jq -r '.items[] | \ select(.status.restartCount>3)' | jq '.metadata.name, .metadata.namespace'
Vérifiez l'état des pods associés au volume de données :
$ oc get pods -n <namespace> -o json | jq -r '.items[] | \ select(.metadata.ownerReferences[] | \ select(.name=="<dv_name>")).metadata.name'
Obtenir les coordonnées des nacelles :
oc -n <namespace> describe pods <pod>
Vérifiez les messages d'erreur dans les journaux de pods :
oc -n <namespace> describe logs <pod>
Atténuation
Supprimez le volume de données, résolvez le problème et créez un nouveau volume de données.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.3. CDINotReady
Signification
Cette alerte se déclenche lorsque l'importateur de données conteneurisées (CDI) est dans un état dégradé :
- Pas de progrès
- Non disponible à l'utilisation
Impact
CDI n'est pas utilisable, les utilisateurs ne peuvent donc pas construire de disques de machines virtuelles sur des réclamations de volumes persistants (PVC) en utilisant les volumes de données de CDI. Les composants de CDI ne sont pas prêts et ils ont cessé de progresser vers un état prêt.
Diagnostic
Définir la variable d'environnement
CDI_NAMESPACE
:$ export CDI_NAMESPACE="$(oc get deployment -A | \ grep cdi-operator | awk '{print $1}')"
Vérifier le déploiement du CDI pour les composants qui ne sont pas prêts :
$ oc -n $CDI_NAMESPACE get deploy -l cdi.kubevirt.io
Vérifier les détails du pod défaillant :
oc -n $CDI_NAMESPACE describe pods <pod>
Vérifiez les journaux du module défaillant :
$ oc -n $CDI_NAMESPACE logs <pod>
Atténuation
Essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.4. CDIOperatorDown
Signification
Cette alerte se déclenche lorsque l'opérateur de l'importateur de données conteneurisées (CDI) est hors service. L'opérateur CDI déploie et gère les composants de l'infrastructure CDI, tels que les contrôleurs de volumes de données et de réclamations de volumes persistants (PVC). Ces contrôleurs aident les utilisateurs à construire des disques de machines virtuelles sur des PVC.
Impact
Les composants CDI peuvent ne pas se déployer ou rester dans un état requis. L'installation du CDI peut ne pas fonctionner correctement.
Diagnostic
Définir la variable d'environnement
CDI_NAMESPACE
:$ export CDI_NAMESPACE="$(oc get deployment -A | grep cdi-operator | \ awk '{print $1}')"
Vérifier si le pod
cdi-operator
est en cours d'exécution :$ oc -n $CDI_NAMESPACE get pods -l name=cdi-operator
Obtenir les coordonnées de la nacelle
cdi-operator
:$ oc -n $CDI_NAMESPACE describe pods -l name=cdi-operator
Vérifiez si le journal du pod
cdi-operator
contient des erreurs :$ oc -n $CDI_NAMESPACE logs -l name=cdi-operator
Atténuation
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.5. CDIStorageProfilesIncomplete
Signification
Cette alerte se déclenche lorsqu'un profil de stockage Containerized Data Importer (CDI) est incomplet.
Si un profil de stockage est incomplet, le CDI ne peut pas déduire les champs PVC (persistent volume claim), tels que volumeMode
et accessModes
, qui sont nécessaires pour créer un disque de machine virtuelle (VM).
Impact
Le CDI ne peut pas créer de disque VM sur le PVC.
Diagnostic
Identifier le profil de stockage incomplet :
oc get storageprofile <storage_class> $ oc get storageprofile <storage_class>
Atténuation
Ajoutez les informations manquantes du profil de stockage comme dans l'exemple suivant :
$ oc patch storageprofile local --type=merge -p '{"spec": \ {"claimPropertySets": [{"accessModes": ["ReadWriteOnce"], \ "volumeMode": "Filesystem"}]}}'
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.6. CnaoDown
Signification
Cette alerte se déclenche lorsque le Cluster Network Addons Operator (CNAO) est hors service. Le CNAO déploie des composants réseau supplémentaires au-dessus du cluster.
Impact
Si l'ACAO n'est pas en cours d'exécution, le cluster ne peut pas réconcilier les modifications apportées aux composants des machines virtuelles. Par conséquent, les modifications risquent de ne pas être prises en compte.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get deployment -A | \ grep cluster-network-addons-operator | awk '{print $1}')"
Vérifier l'état du pod
cluster-network-addons-operator
:$ oc -n $NAMESPACE get pods -l name=cluster-network-addons-operator
Vérifiez les messages d'erreur dans les journaux de
cluster-network-addons-operator
:$ oc -n $NAMESPACE logs -l name=cluster-network-addons-operator
Obtenir les informations sur les nacelles du site
cluster-network-addons-operator
:$ oc -n $NAMESPACE describe pods -l name=cluster-network-addons-operator
Atténuation
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.7. HPPNotReady
Signification
Cette alerte se déclenche lorsqu'une installation de Hostpath Provisioner (HPP) est dans un état dégradé.
Le HPP provisionne dynamiquement les volumes du chemin d'accès de l'hôte afin de fournir un stockage pour les réclamations de volumes persistants (PVC).
Impact
Le HPP n'est pas utilisable. Ses composants ne sont pas prêts et ne progressent pas vers un état de préparation.
Diagnostic
Définir la variable d'environnement
HPP_NAMESPACE
:$ export HPP_NAMESPACE="$(oc get deployment -A | \ grep hostpath-provisioner-operator | awk '{print $1}')"
Vérifier les composants HPP qui ne sont pas encore prêts :
$ oc -n $HPP_NAMESPACE get all -l k8s-app=hostpath-provisioner
Obtenir les coordonnées de la nacelle défaillante :
oc -n $HPP_NAMESPACE describe pods <pod>
Vérifiez les journaux du module défaillant :
$ oc -n $HPP_NAMESPACE logs <pod>
Atténuation
Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.8. HPPOperatorDown
Signification
Cette alerte est déclenchée lorsque l'opérateur HPP (hostpath provisioner) est en panne.
L'opérateur HPP déploie et gère les composants de l'infrastructure HPP, tels que le jeu de démons qui approvisionne les volumes des chemins d'accès à l'hôte.
Impact
Les composants HPP risquent de ne pas se déployer ou de ne pas rester dans l'état requis. Par conséquent, l'installation HPP peut ne pas fonctionner correctement dans le cluster.
Diagnostic
Configurez la variable d'environnement
HPP_NAMESPACE
:$ HPP_NAMESPACE="$(oc get deployment -A | grep \ hostpath-provisioner-operator | awk '{print $1}')"
Vérifier si le pod
hostpath-provisioner-operator
est en cours d'exécution :$ oc -n $HPP_NAMESPACE get pods -l name=hostpath-provisioner-operator
Obtenir les coordonnées de la nacelle
hostpath-provisioner-operator
:$ oc -n $HPP_NAMESPACE describe pods -l name=hostpath-provisioner-operator
Vérifiez si le journal du pod
hostpath-provisioner-operator
contient des erreurs :$ oc -n $HPP_NAMESPACE logs -l name=hostpath-provisioner-operator
Atténuation
Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.9. HPPSharingPoolPathWithOS
Signification
Cette alerte se déclenche lorsque le hostpath provisioner (HPP) partage un système de fichiers avec d'autres composants critiques, tels que kubelet
ou le système d'exploitation (OS).
HPP fournit dynamiquement des volumes de chemin d'accès à l'hôte pour assurer le stockage des réclamations de volumes persistants (PVC).
Impact
Un pool de chemins d'accès partagés exerce une pression sur les disques du nœud. Les performances et la stabilité du nœud peuvent se dégrader.
Diagnostic
Configurez la variable d'environnement
HPP_NAMESPACE
:$ export HPP_NAMESPACE="$(oc get deployment -A | \ grep hostpath-provisioner-operator | awk '{print $1}')"
Obtenir l'état du démon
hostpath-provisioner-csi
set pods :$ oc -n $HPP_NAMESPACE get pods | grep hostpath-provisioner-csi
Consultez les journaux de
hostpath-provisioner-csi
pour identifier le pool partagé et le chemin d'accès :oc -n $HPP_NAMESPACE logs <csi_daemonset> -c hostpath-provisioner
Exemple de sortie
I0208 15:21:03.769731 1 utils.go:221] pool (<legacy, csi-data-dir>/csi), shares path with OS which can lead to node disk pressure
Atténuation
À l'aide des données obtenues dans la section Diagnostic, essayez d'empêcher le partage du chemin d'accès au pool avec le système d'exploitation. Les étapes spécifiques varient en fonction du nœud et d'autres circonstances.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.10. KubeMacPoolDown
Signification
KubeMacPool
est en panne. KubeMacPool
est responsable de l'attribution des adresses MAC et de la prévention des conflits d'adresses MAC.
Impact
Si KubeMacPool
est en panne, les objets VirtualMachine
ne peuvent pas être créés.
Diagnostic
Définir la variable d'environnement
KMP_NAMESPACE
:$ export KMP_NAMESPACE="$(oc get pod -A --no-headers -l \ control-plane=mac-controller-manager | awk '{print $1}')"
Définir la variable d'environnement
KMP_NAME
:$ export KMP_NAME="$(oc get pod -A --no-headers -l \ control-plane=mac-controller-manager | awk '{print $2}')"
Obtenir les coordonnées du pod
KubeMacPool-manager
:$ oc describe pod -n $KMP_NAMESPACE $KMP_NAME
Vérifiez les messages d'erreur dans les journaux de
KubeMacPool-manager
:$ oc logs -n $KMP_NAMESPACE $KMP_NAME
Atténuation
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.11. KubeMacPoolDuplicateMacsFound
Signification
Cette alerte se déclenche lorsque KubeMacPool
détecte des adresses MAC en double.
KubeMacPool
est responsable de l'attribution des adresses MAC et de la prévention des conflits d'adresses MAC. Au démarrage de KubeMacPool
, il recherche dans le cluster les adresses MAC des machines virtuelles (VM) dans les espaces de noms gérés.
Impact
Les adresses MAC en double sur le même réseau local peuvent causer des problèmes de réseau.
Diagnostic
Obtenir l'espace de noms et le nom du pod
kubemacpool-mac-controller
:$ oc get pod -A -l control-plane=mac-controller-manager --no-headers \ -o custom-columns=":metadata.namespace,:metadata.name"
Obtenir les adresses MAC dupliquées à partir des journaux
kubemacpool-mac-controller
:$ oc logs -n <namespace> <kubemacpool_mac_controller> | \ grep "already allocated"
Exemple de sortie
mac address 02:00:ff:ff:ff:ff already allocated to vm/kubemacpool-test/testvm, br1, conflict with: vm/kubemacpool-test/testvm2, br1
Atténuation
- Mettez à jour les machines virtuelles pour supprimer les adresses MAC en double.
Redémarrez le pod
kubemacpool-mac-controller
:oc delete pod -n <namespace> <kubemacpool_mac_controller>
14.14.12. KubeVirtComponentExceedsRequestedCPU (composant KubeVirt)
Signification
Cette alerte se déclenche lorsque l'utilisation de l'unité centrale d'un composant dépasse la limite demandée.
Impact
L'utilisation des ressources de l'unité centrale n'est pas optimale et le nœud pourrait être surchargé.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Vérifier la limite de demande de l'unité centrale du composant :
oc -n $NAMESPACE get deployment <component> -o yaml | grep requests : -A 2
Vérifiez l'utilisation réelle de l'unité centrale à l'aide d'une requête PromQL :
node_namespace_pod_container:container_cpu_usage_seconds_total:sum_rate {namespace="$NAMESPACE",container="<component>"}
Voir la documentation Prometheus pour plus d'informations.
Atténuation
Mettre à jour la limite de demande de CPU dans la ressource personnalisée HCO
.
14.14.13. KubeVirtComponentExceedsRequestedMemory (Dépasse la mémoire demandée)
Signification
Cette alerte se déclenche lorsque l'utilisation de la mémoire d'un composant dépasse la limite demandée.
Impact
L'utilisation des ressources mémoire n'est pas optimale et le nœud peut être surchargé.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Vérifier la limite de demande de mémoire du composant :
$ oc -n $NAMESPACE get deployment <component> -o yaml | \ grep requests: -A 2
Vérifiez l'utilisation réelle de la mémoire à l'aide d'une requête PromQL :
container_memory_usage_bytes{namespace="$NAMESPACE",container="<component>"}
Voir la documentation Prometheus pour plus d'informations.
Atténuation
Mettre à jour la limite de demande de mémoire dans la ressource personnalisée HCO
.
14.14.14. KubevirtHyperconvergedClusterOperatorCRModification
Signification
Cette alerte se déclenche lorsqu'un opérande de l'opérateur de cluster hyperconvergé (HCO) est modifié par quelqu'un ou quelque chose d'autre que HCO.
HCO configure OpenShift Virtualization et ses opérateurs de support d'une manière fondée sur l'opinion et écrase ses opérandes lorsqu'il y a un changement inattendu à leur égard. Les utilisateurs ne doivent pas modifier les opérandes directement. La ressource personnalisée HyperConverged
est la source de vérité pour la configuration.
Impact
La modification manuelle des opérandes entraîne une fluctuation de la configuration du cluster et peut conduire à une instabilité.
Diagnostic
Vérifiez la valeur
component_name
dans les détails de l'alerte pour déterminer le type d'opérande (kubevirt
) et le nom de l'opérande (kubevirt-kubevirt-hyperconverged
) qui sont modifiés :Labels alertname=KubevirtHyperconvergedClusterOperatorCRModification component_name=kubevirt/kubevirt-kubevirt-hyperconverged severity=warning
Atténuation
Ne modifiez pas directement les opérandes HCO. Utilisez les objets HyperConverged
pour configurer le cluster.
L'alerte se résout d'elle-même après 10 minutes si les opérandes ne sont pas modifiés manuellement.
14.14.15. KubevirtHyperconvergedClusterOperatorInstallationNotCompletedAlert (alerte d'installation non terminée)
Signification
Cette alerte se déclenche lorsque l'opérateur de cluster hyperconvergé (HCO) fonctionne pendant plus d'une heure sans ressource personnalisée (CR) HyperConverged
.
Cette alerte a les causes suivantes :
-
Au cours de la procédure d'installation, vous avez installé le HCO mais vous n'avez pas créé le CR
HyperConverged
. -
Au cours du processus de désinstallation, vous avez supprimé le CR
HyperConverged
avant de désinstaller le HCO et le HCO est toujours en cours d'exécution.
Atténuation
L'atténuation dépend de l'installation ou de la désinstallation du HCO :
Terminez l'installation en créant un CR
HyperConverged
avec ses valeurs par défaut :$ cat <<EOF | oc apply -f - apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: hco-operatorgroup namespace: kubevirt-hyperconverged spec: {} EOF
- Désinstallez le HCO. Si le processus de désinstallation continue de s'exécuter, vous devez résoudre ce problème afin d'annuler l'alerte.
14.14.16. KubevirtHyperconvergedClusterOperatorUSModification
Signification
Cette alerte se déclenche lorsqu'une annotation JSON Patch est utilisée pour modifier un opérande de l'opérateur de cluster hyperconvergé (HCO).
HCO configure OpenShift Virtualization et ses opérateurs de support d'une manière fondée sur l'opinion et écrase ses opérandes lorsqu'il y a un changement inattendu à leur égard. Les utilisateurs ne doivent pas modifier les opérandes directement.
Toutefois, si une modification est nécessaire et qu'elle n'est pas prise en charge par l'API du HCO, vous pouvez forcer le HCO à définir une modification dans un opérateur à l'aide d'annotations JSON Patch. Ces modifications ne sont pas annulées par le HCO au cours de son processus de réconciliation.
Impact
L'utilisation incorrecte des annotations JSON Patch peut conduire à des résultats inattendus ou à un environnement instable.
La mise à jour d'un système avec des annotations JSON Patch est dangereuse car la structure des ressources personnalisées des composants peut changer.
Diagnostic
Consultez le site
annotation_name
dans les détails de l'alerte pour identifier l'annotation JSON Patch :Labels alertname=KubevirtHyperconvergedClusterOperatorUSModification annotation_name=kubevirt.kubevirt.io/jsonpatch severity=info
Atténuation
Il est préférable d'utiliser l'API HCO pour modifier un opérande. Toutefois, si la modification ne peut être effectuée qu'à l'aide d'une annotation JSON Patch, il convient de procéder avec prudence.
Supprimer les annotations JSON Patch avant la mise à jour pour éviter les problèmes potentiels.
14.14.17. KubevirtVmHighMemoryUsage
Signification
Cette alerte se déclenche lorsqu'un conteneur hébergeant une machine virtuelle (VM) dispose de moins de 20 Mo de mémoire libre.
Impact
La machine virtuelle s'exécutant dans le conteneur est arrêtée par le moteur d'exécution si la limite de mémoire du conteneur est dépassée.
Diagnostic
Obtenir les coordonnées du pod
virt-launcher
:$ oc get pod <virt-launcher> -o yaml
Identifier les processus du conteneur
compute
qui utilisent beaucoup de mémoire dans le podvirt-launcher
:oc exec -it <virt-launcher> -c compute -- top
Atténuation
Augmentez la limite de mémoire dans la spécification
VirtualMachine
comme dans l'exemple suivant :spec: running: false template: metadata: labels: kubevirt.io/vm: vm-name spec: domain: resources: limits: memory: 200Mi requests: memory: 128Mi
14.14.18. KubeVirtVMIExcessiveMigrations
Signification
Cette alerte se déclenche lorsqu'une instance de machine virtuelle (VMI) migre en direct plus de 12 fois sur une période de 24 heures.
Ce taux de migration est anormalement élevé, même lors d'une mise à niveau. Cette alerte peut indiquer un problème dans l'infrastructure du cluster, comme des perturbations du réseau ou des ressources insuffisantes.
Impact
Une machine virtuelle (VM) qui migre trop fréquemment risque de voir ses performances se dégrader car des erreurs de page mémoire se produisent pendant la transition.
Diagnostic
Vérifiez que le nœud de travail dispose de ressources suffisantes :
$ oc get nodes -l node-role.kubernetes.io/worker= -o json | \ jq .items[].status.allocatable
Exemple de sortie
{ "cpu": "3500m", "devices.kubevirt.io/kvm": "1k", "devices.kubevirt.io/sev": "0", "devices.kubevirt.io/tun": "1k", "devices.kubevirt.io/vhost-net": "1k", "ephemeral-storage": "38161122446", "hugepages-1Gi": "0", "hugepages-2Mi": "0", "memory": "7000128Ki", "pods": "250" }
Vérifier l'état du nœud de travail :
$ oc get nodes -l node-role.kubernetes.io/worker= -o json | \ jq .items[].status.conditions
Exemple de sortie
{ "lastHeartbeatTime": "2022-05-26T07:36:01Z", "lastTransitionTime": "2022-05-23T08:12:02Z", "message": "kubelet has sufficient memory available", "reason": "KubeletHasSufficientMemory", "status": "False", "type": "MemoryPressure" }, { "lastHeartbeatTime": "2022-05-26T07:36:01Z", "lastTransitionTime": "2022-05-23T08:12:02Z", "message": "kubelet has no disk pressure", "reason": "KubeletHasNoDiskPressure", "status": "False", "type": "DiskPressure" }, { "lastHeartbeatTime": "2022-05-26T07:36:01Z", "lastTransitionTime": "2022-05-23T08:12:02Z", "message": "kubelet has sufficient PID available", "reason": "KubeletHasSufficientPID", "status": "False", "type": "PIDPressure" }, { "lastHeartbeatTime": "2022-05-26T07:36:01Z", "lastTransitionTime": "2022-05-23T08:24:15Z", "message": "kubelet is posting ready status", "reason": "KubeletReady", "status": "True", "type": "Ready" }
Connectez-vous au nœud de travail et vérifiez que le service
kubelet
est en cours d'exécution :$ systemctl status kubelet
Vérifiez les messages d'erreur dans le journal
kubelet
:$ journalctl -r -u kubelet
Atténuation
Assurez-vous que les nœuds de travail disposent de ressources suffisantes (CPU, mémoire, disque) pour exécuter les charges de travail des VM sans interruption.
Si le problème persiste, essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.19. KubeVirtVMStuckInErrorState
Signification
Cette alerte se déclenche lorsqu'une machine virtuelle (VM) est dans un état d'erreur pendant plus de 5 minutes.
États d'erreur :
- CrashLoopBackOff
- Inconnu
- Insaisissable
- ErrImagePull
- ImagePullBackOff
- PvcNotFound
- Erreur de volume de données
Cette alerte peut indiquer un problème au niveau de la configuration de la VM, par exemple une réclamation de volume persistant manquante, ou un problème au niveau de l'infrastructure du cluster, par exemple des perturbations du réseau ou des ressources insuffisantes au niveau des nœuds.
Impact
Il n'y a pas d'impact immédiat. Cependant, si l'alerte persiste, vous devez rechercher la cause première et résoudre le problème.
Diagnostic
Vérifiez les détails de l'instance de machine virtuelle (VMI) :
$ oc describe vmi <vmi> -n <namespace>
Exemple de sortie
Name: testvmi-hxghp Namespace: kubevirt-test-default1 Labels: name=testvmi-hxghp Annotations: kubevirt.io/latest-observed-api-version: v1 kubevirt.io/storage-observed-api-version: v1alpha3 API Version: kubevirt.io/v1 Kind: VirtualMachineInstance ... Spec: Domain: ... Resources: Requests: Cpu: 5000000Gi Memory: 5130000240Mi ... Status: ... Conditions: Last Probe Time: 2022-10-03T11:11:07Z Last Transition Time: 2022-10-03T11:11:07Z Message: Guest VM is not reported as running Reason: GuestNotRunning Status: False Type: Ready Last Probe Time: <nil> Last Transition Time: 2022-10-03T11:11:07Z Message: 0/2 nodes are available: 2 Insufficient cpu, 2 Insufficient memory. Reason: Unschedulable Status: False Type: PodScheduled Guest OS Info: Phase: Scheduling Phase Transition Timestamps: Phase: Pending Phase Transition Timestamp: 2022-10-03T11:11:07Z Phase: Scheduling Phase Transition Timestamp: 2022-10-03T11:11:07Z Qos Class: Burstable Runtime User: 0 Virtual Machine Revision Name: revision-start-vm-3503e2dc-27c0-46ef-9167-7ae2e7d93e6e-1 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 27s virtualmachine-controller Created virtual machine pod virt-launcher-testvmi-hxghp-xh9qn
Vérifier les ressources du nœud :
$ oc get nodes -l node-role.kubernetes.io/worker= -o json | jq '.items | \ .[].status.allocatable'
Exemple de sortie
{ "cpu": "5", "devices.kubevirt.io/kvm": "1k", "devices.kubevirt.io/sev": "0", "devices.kubevirt.io/tun": "1k", "devices.kubevirt.io/vhost-net": "1k", "ephemeral-storage": "33812468066", "hugepages-1Gi": "0", "hugepages-2Mi": "128Mi", "memory": "3783496Ki", "pods": "110" }
Vérifier que le nœud ne présente pas de conditions d'erreur :
$ oc get nodes -l node-role.kubernetes.io/worker= -o json | jq '.items | \ .[].status.conditions'
Exemple de sortie
[ { "lastHeartbeatTime": "2022-10-03T11:13:34Z", "lastTransitionTime": "2022-10-03T10:14:20Z", "message": "kubelet has sufficient memory available", "reason": "KubeletHasSufficientMemory", "status": "False", "type": "MemoryPressure" }, { "lastHeartbeatTime": "2022-10-03T11:13:34Z", "lastTransitionTime": "2022-10-03T10:14:20Z", "message": "kubelet has no disk pressure", "reason": "KubeletHasNoDiskPressure", "status": "False", "type": "DiskPressure" }, { "lastHeartbeatTime": "2022-10-03T11:13:34Z", "lastTransitionTime": "2022-10-03T10:14:20Z", "message": "kubelet has sufficient PID available", "reason": "KubeletHasSufficientPID", "status": "False", "type": "PIDPressure" }, { "lastHeartbeatTime": "2022-10-03T11:13:34Z", "lastTransitionTime": "2022-10-03T10:14:30Z", "message": "kubelet is posting ready status", "reason": "KubeletReady", "status": "True", "type": "Ready" } ]
Atténuation
Essayez d'identifier et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.20. KubeVirtVMStuckInMigratingState
Signification
Cette alerte se déclenche lorsqu'une machine virtuelle (VM) est en état de migration pendant plus de 5 minutes.
Cette alerte peut indiquer un problème dans l'infrastructure de la grappe, comme des perturbations du réseau ou des ressources insuffisantes au niveau des nœuds.
Impact
Il n'y a pas d'impact immédiat. Cependant, si l'alerte persiste, vous devez rechercher la cause première et résoudre le problème.
Diagnostic
Vérifier les ressources du nœud :
$ oc get nodes -l node-role.kubernetes.io/worker= -o json | jq '.items | \ .[].status.allocatable'
Exemple de sortie
{ "cpu": "5", "devices.kubevirt.io/kvm": "1k", "devices.kubevirt.io/sev": "0", "devices.kubevirt.io/tun": "1k", "devices.kubevirt.io/vhost-net": "1k", "ephemeral-storage": "33812468066", "hugepages-1Gi": "0", "hugepages-2Mi": "128Mi", "memory": "3783496Ki", "pods": "110" }
Vérifier les conditions d'état du nœud :
$ oc get nodes -l node-role.kubernetes.io/worker= -o json | jq '.items | \ .[].status.conditions'
Exemple de sortie
[ { "lastHeartbeatTime": "2022-10-03T11:13:34Z", "lastTransitionTime": "2022-10-03T10:14:20Z", "message": "kubelet has sufficient memory available", "reason": "KubeletHasSufficientMemory", "status": "False", "type": "MemoryPressure" }, { "lastHeartbeatTime": "2022-10-03T11:13:34Z", "lastTransitionTime": "2022-10-03T10:14:20Z", "message": "kubelet has no disk pressure", "reason": "KubeletHasNoDiskPressure", "status": "False", "type": "DiskPressure" }, { "lastHeartbeatTime": "2022-10-03T11:13:34Z", "lastTransitionTime": "2022-10-03T10:14:20Z", "message": "kubelet has sufficient PID available", "reason": "KubeletHasSufficientPID", "status": "False", "type": "PIDPressure" }, { "lastHeartbeatTime": "2022-10-03T11:13:34Z", "lastTransitionTime": "2022-10-03T10:14:30Z", "message": "kubelet is posting ready status", "reason": "KubeletReady", "status": "True", "type": "Ready" } ]
Atténuation
Vérifiez la configuration de la migration de la machine virtuelle pour vous assurer qu'elle est adaptée à la charge de travail.
Vous définissez une configuration de migration à l'échelle du cluster en modifiant la strophe MigrationConfiguration
de la ressource personnalisée KubeVirt
.
Vous définissez une configuration de migration pour une portée spécifique en créant une politique de migration.
Vous pouvez déterminer si une VM est liée à une politique de migration en consultant son paramètre vm.Status.MigrationState.MigrationPolicyName
.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.21. KubeVirtVMStuckInStartingState (état de démarrage)
Signification
Cette alerte se déclenche lorsqu'une machine virtuelle (VM) est dans un état de démarrage pendant plus de 5 minutes.
Cette alerte peut indiquer un problème dans la configuration de la VM, comme une classe de priorité mal configurée ou un périphérique réseau manquant.
Impact
Il n'y a pas d'impact immédiat. Cependant, si l'alerte persiste, vous devez rechercher la cause première et résoudre le problème.
Diagnostic
Vérifiez les détails de l'instance de machine virtuelle (VMI) pour les conditions d'erreur :
$ oc describe vmi <vmi> -n <namespace>
Exemple de sortie
Name: testvmi-ldgrw Namespace: kubevirt-test-default1 Labels: name=testvmi-ldgrw Annotations: kubevirt.io/latest-observed-api-version: v1 kubevirt.io/storage-observed-api-version: v1alpha3 API Version: kubevirt.io/v1 Kind: VirtualMachineInstance ... Spec: ... Networks: Name: default Pod: Priority Class Name: non-preemtible Termination Grace Period Seconds: 0 Status: Conditions: Last Probe Time: 2022-10-03T11:08:30Z Last Transition Time: 2022-10-03T11:08:30Z Message: virt-launcher pod has not yet been scheduled Reason: PodNotExists Status: False Type: Ready Last Probe Time: <nil> Last Transition Time: 2022-10-03T11:08:30Z Message: failed to create virtual machine pod: pods "virt-launcher-testvmi-ldgrw-" is forbidden: no PriorityClass with name non-preemtible was found Reason: FailedCreate Status: False Type: Synchronized Guest OS Info: Phase: Pending Phase Transition Timestamps: Phase: Pending Phase Transition Timestamp: 2022-10-03T11:08:30Z Runtime User: 0 Virtual Machine Revision Name: revision-start-vm-6f01a94b-3260-4c5a-bbe5-dc98d13e6bea-1 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedCreate 8s (x13 over 28s) virtualmachine-controller Error creating pod: pods "virt-launcher-testvmi-ldgrw-" is forbidden: no PriorityClass with name non-preemtible was found
Atténuation
Assurez-vous que la VM est configurée correctement et qu'elle dispose des ressources nécessaires.
L'état Pending
indique que la VM n'a pas encore été planifiée. Vérifiez les causes possibles suivantes :
-
Le pod
virt-launcher
n'est pas programmé. - Les indications topologiques pour l'IMV ne sont pas à jour.
- Le volume de données n'est pas provisionné ou prêt.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.22. LowKVMNodesCount
Signification
Cette alerte se déclenche lorsque moins de deux nœuds de la grappe disposent de ressources KVM.
Impact
La grappe doit comporter au moins deux nœuds dotés de ressources KVM pour la migration en direct.
Les machines virtuelles ne peuvent pas être planifiées ou exécutées si aucun nœud ne dispose de ressources KVM.
Diagnostic
Identifier les nœuds disposant de ressources KVM :
$ oc get nodes -o jsonpath='{.items[*].status.allocatable}' | \ grep devices.kubevirt.io/kvm
Atténuation
Installez KVM sur les nœuds ne disposant pas de ressources KVM.
14.14.23. LowReadyVirtControllersCount (Nombre de contrôleurs de protection prêts à l'emploi)
Signification
Cette alerte se déclenche lorsqu'un ou plusieurs pods virt-controller
sont en cours d'exécution, mais qu'aucun de ces pods n'a été dans l'état Ready
au cours des 5 dernières minutes.
Un dispositif virt-controller
surveille les définitions de ressources personnalisées (CRD) d'une instance de machine virtuelle (VMI) et gère les pods associés. Le dispositif crée des pods pour les VMI et gère leur cycle de vie. Ce dispositif est essentiel pour la fonctionnalité de virtualisation à l'échelle de la grappe.
Impact
Cette alerte indique qu'une défaillance au niveau du cluster risque de se produire. Les actions liées à la gestion du cycle de vie des VM, telles que le lancement d'une nouvelle VMI ou l'arrêt d'une VMI existante, échoueront.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Vérifiez qu'un dispositif
virt-controller
est disponible :$ oc get deployment -n $NAMESPACE virt-controller \ -o jsonpath='{.status.readyReplicas}'
Vérifiez l'état du déploiement de
virt-controller
:$ oc -n $NAMESPACE get deploy virt-controller -o yaml
Obtenez les détails du déploiement de
virt-controller
pour vérifier les conditions d'état, telles que les pods en panne ou les échecs d'extraction d'images :$ oc -n $NAMESPACE describe deploy virt-controller
Vérifiez si des problèmes sont survenus avec les nœuds. Par exemple, ils peuvent être dans l'état
NotReady
:$ oc get nodes
Atténuation
Cette alerte peut avoir des causes multiples, notamment les suivantes :
- La mémoire du cluster est insuffisante.
- Les nœuds sont en panne.
- Le serveur API est surchargé. Par exemple, le planificateur peut être très sollicité et n'est donc pas entièrement disponible.
- Il y a des problèmes de réseau.
Essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.24. LowReadyVirtOperatorsCount (Nombre d'opérateurs prêts à fonctionner)
Signification
Cette alerte se déclenche lorsqu'un ou plusieurs pods virt-operator
sont en cours d'exécution, mais qu'aucun de ces pods n'a été en état Ready
au cours des 10 dernières minutes.
Le virt-operator
est le premier opérateur à démarrer dans un cluster. Le déploiement virt-operator
a une réplique par défaut de deux pods virt-operator
.
Ses principales responsabilités sont les suivantes
- Installation, mise à jour en direct et mise à niveau en direct d'un cluster
-
Surveiller le cycle de vie des contrôleurs de premier niveau, tels que
virt-controller
,virt-handler
,virt-launcher
, et gérer leur rapprochement - Certaines tâches à l'échelle de la grappe, telles que la rotation des certificats et la gestion de l'infrastructure
Impact
Une panne au niveau de la grappe peut se produire. Les fonctionnalités de gestion critiques à l'échelle de la grappe, telles que la rotation des certifications, la mise à niveau et le rapprochement des contrôleurs, peuvent devenir indisponibles. Un tel état déclenche également l'alerte NoReadyVirtOperator
.
Le site virt-operator
n'est pas directement responsable des machines virtuelles (VM) dans le cluster. Par conséquent, son indisponibilité temporaire n'affecte pas de manière significative les charges de travail des machines virtuelles.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Obtenir le nom du déploiement
virt-operator
:$ oc -n $NAMESPACE get deploy virt-operator -o yaml
Obtenir les détails du déploiement de
virt-operator
:$ oc -n $NAMESPACE describe deploy virt-operator
Vérifier l'absence de problèmes au niveau du nœud, tels que l'état de
NotReady
:$ oc get nodes
Atténuation
Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.25. LowVirtAPICount
Signification
Cette alerte se déclenche lorsqu'un seul pod virt-api
disponible est détecté au cours d'une période de 60 minutes, alors qu'au moins deux nœuds sont disponibles pour la planification.
Impact
Une interruption des appels API peut se produire lors de l'éviction d'un nœud, car le pod virt-api
devient un point de défaillance unique.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Vérifier le nombre d'unités disponibles sur le site
virt-api
:$ oc get deployment -n $NAMESPACE virt-api \ -o jsonpath='{.status.readyReplicas}'
Vérifiez l'état du déploiement de
virt-api
pour voir s'il n'y a pas de conditions d'erreur :$ oc -n $NAMESPACE get deploy virt-api -o yaml
Vérifiez que les nœuds ne présentent pas de problèmes, par exemple s'ils sont dans l'état
NotReady
:$ oc get nodes
Atténuation
Essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.26. LowVirtControllersCount
Signification
Cette alerte se déclenche lorsqu'un faible nombre de pods virt-controller
est détecté. Au moins un pod virt-controller
doit être disponible pour assurer une haute disponibilité. Le nombre de répliques par défaut est de 2.
Un dispositif virt-controller
surveille les définitions de ressources personnalisées (CRD) d'une instance de machine virtuelle (VMI) et gère les pods associés. Le dispositif crée des pods pour les VMI et gère le cycle de vie des pods. Ce dispositif est essentiel pour la fonctionnalité de virtualisation à l'échelle du cluster.
Impact
La réactivité d'OpenShift Virtualization pourrait être affectée négativement. Par exemple, certaines demandes pourraient être manquées.
En outre, si une autre instance virt-launcher
se termine de manière inattendue, OpenShift Virtualization peut ne plus répondre du tout.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Vérifiez que les pods
virt-controller
en cours d'exécution sont disponibles :$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-controller
Vérifiez les messages d'erreur dans les journaux de
virt-launcher
:oc -n $NAMESPACE logs <virt-launcher>
Obtenez les détails du pod
virt-launcher
pour vérifier les conditions d'état telles qu'une terminaison inattendue ou un étatNotReady
.oc -n $NAMESPACE describe pod/<virt-launcher>
Atténuation
Cette alerte peut avoir diverses causes, notamment
- Mémoire insuffisante sur le cluster
- Les nœuds sont hors service
- Le serveur API est surchargé. Par exemple, le planificateur peut être très sollicité et n'est donc pas entièrement disponible.
- Questions relatives à la mise en réseau
Identifiez la cause première et corrigez-la, si possible.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.27. LowVirtOperatorCount
Signification
Cette alerte se déclenche lorsqu'un seul pod virt-operator
dans l'état Ready
a fonctionné au cours des 60 dernières minutes.
Le site virt-operator
est le premier opérateur à démarrer dans une grappe. Ses principales responsabilités sont les suivantes
- Installation, mise à jour en direct et mise à niveau en direct d'un cluster
-
Surveiller le cycle de vie des contrôleurs de premier niveau, tels que
virt-controller
,virt-handler
,virt-launcher
, et gérer leur rapprochement - Certaines tâches à l'échelle de la grappe, telles que la rotation des certificats et la gestion de l'infrastructure
Impact
Le site virt-operator
ne peut pas assurer la haute disponibilité (HA) du déploiement. HA nécessite au moins deux pods virt-operator
dans un état Ready
. Le déploiement par défaut est de deux modules.
Le site virt-operator
n'est pas directement responsable des machines virtuelles (VM) dans le cluster. Par conséquent, sa baisse de disponibilité n'affecte pas de manière significative les charges de travail des machines virtuelles.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Vérifier l'état des cosses
virt-operator
:$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator
Examinez les journaux des pods
virt-operator
concernés :oc -n $NAMESPACE logs <virt-operator>
Obtenir les détails des pods
virt-operator
concernés :oc -n $NAMESPACE describe pod <virt-operator>
Atténuation
Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les artefacts recueillis au cours de la procédure de diagnostic.
14.14.28. NetworkAddonsConfigNotReady
Signification
Cette alerte se déclenche lorsque la ressource personnalisée (CR) NetworkAddonsConfig
de l'opérateur de modules complémentaires du réseau de grappes (CNAO) n'est pas prête.
CNAO déploie des composants réseau supplémentaires sur le cluster. Cette alerte indique qu'un des composants déployés n'est pas prêt.
Impact
La fonctionnalité du réseau est affectée.
Diagnostic
Vérifiez les conditions d'état de la CR
NetworkAddonsConfig
pour identifier le déploiement ou l'ensemble de démons qui n'est pas prêt :$ oc get networkaddonsconfig \ -o custom-columns="":.status.conditions[*].message
Exemple de sortie
DaemonSet "cluster-network-addons/macvtap-cni" update is being processed...
Vérifiez que le pod du composant ne contient pas d'erreurs :
oc -n cluster-network-addons get daemonset <pod> -o yaml
Vérifiez les journaux du composant :
$ oc -n cluster-network-addons logs <pod>
Vérifier les détails du composant pour les conditions d'erreur :
$ oc -n cluster-network-addons describe <pod>
Atténuation
Essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.29. NoLeadingVirtOperator
Signification
Cette alerte se déclenche lorsqu'aucun pod virt-operator
avec un bail de leader n'a été détecté pendant 10 minutes, bien que les pods virt-operator
soient dans un état Ready
. L'alerte indique qu'aucun pod leader n'est disponible.
Le site virt-operator
est le premier opérateur à démarrer dans une grappe. Ses principales responsabilités sont les suivantes
- Installation, mise à jour en direct et mise à niveau en direct d'un cluster
-
Surveiller le cycle de vie des contrôleurs de premier niveau, tels que
virt-controller
,virt-handler
,virt-launcher
, et gérer leur rapprochement - Certaines tâches à l'échelle de la grappe, telles que la rotation des certificats et la gestion de l'infrastructure
Le déploiement virt-operator
a une réplique par défaut de 2 pods, avec un pod détenant un bail de leader.
Impact
Cette alerte indique une défaillance au niveau de la grappe. En conséquence, les fonctionnalités critiques de gestion de la grappe, telles que la rotation des certifications, la mise à niveau et le rapprochement des contrôleurs, risquent de ne pas être disponibles.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A -o \ custom-columns="":.metadata.namespace)"
Obtenir l'état des pods
virt-operator
:$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator
Consultez les journaux du pod
virt-operator
pour déterminer l'état du leader :$ oc -n $NAMESPACE logs | grep lead
Exemple d'un pod leader :
{"component":"virt-operator","level":"info","msg":"Attempting to acquire leader status","pos":"application.go:400","timestamp":"2021-11-30T12:15:18.635387Z"} I1130 12:15:18.635452 1 leaderelection.go:243] attempting to acquire leader lease <namespace>/virt-operator... I1130 12:15:19.216582 1 leaderelection.go:253] successfully acquired lease <namespace>/virt-operator {"component":"virt-operator","level":"info","msg":"Started leading", "pos":"application.go:385","timestamp":"2021-11-30T12:15:19.216836Z"}
Exemple de pod non leader :
{"component":"virt-operator","level":"info","msg":"Attempting to acquire leader status","pos":"application.go:400","timestamp":"2021-11-30T12:15:20.533696Z"} I1130 12:15:20.533792 1 leaderelection.go:243] attempting to acquire leader lease <namespace>/virt-operator...
Obtenir les détails des pods
virt-operator
concernés :oc -n $NAMESPACE describe pod <virt-operator>
Atténuation
Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez de trouver la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.30. NoReadyVirtController
Signification
Cette alerte se déclenche lorsqu'aucun dispositif virt-controller
n'a été détecté pendant 5 minutes.
Les dispositifs virt-controller
contrôlent les définitions de ressources personnalisées des instances de machines virtuelles (VMI) et gèrent les pods associés. Les dispositifs créent des pods pour les VMI et gèrent le cycle de vie des pods.
Par conséquent, les dispositifs virt-controller
sont essentiels pour toutes les fonctionnalités de virtualisation à l'échelle de la grappe.
Impact
Toutes les actions liées à la gestion du cycle de vie des machines virtuelles échouent. Il s'agit notamment du lancement d'une nouvelle VMI ou de l'arrêt d'une VMI existante.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Vérifiez le nombre d'appareils
virt-controller
:$ oc get deployment -n $NAMESPACE virt-controller \ -o jsonpath='{.status.readyReplicas}'
Vérifiez l'état du déploiement de
virt-controller
:$ oc -n $NAMESPACE get deploy virt-controller -o yaml
Obtenez les détails du déploiement de
virt-controller
pour vérifier les conditions d'état telles que les pods en panne ou l'impossibilité d'extraire des images :$ oc -n $NAMESPACE describe deploy virt-controller
Obtenir les informations sur les nacelles du site
virt-controller
:$ get pods -n $NAMESPACE | grep virt-controller
Vérifiez les journaux des pods
virt-controller
pour les messages d'erreur :oc logs -n $NAMESPACE <virt-controller>
Vérifiez que les nœuds ne présentent pas de problèmes, tels que l'état
NotReady
:$ oc get nodes
Atténuation
Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez de trouver la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.31. NoReadyVirtOperator
Signification
Cette alerte se déclenche lorsqu'aucun pod virt-operator
en état Ready
n'a été détecté pendant 10 minutes.
Le site virt-operator
est le premier opérateur à démarrer dans une grappe. Ses principales responsabilités sont les suivantes
- Installation, mise à jour en direct et mise à niveau en direct d'un cluster
-
Surveiller le cycle de vie des contrôleurs de premier niveau, tels que
virt-controller
,virt-handler
,virt-launcher
, et gérer leur rapprochement - Certaines tâches à l'échelle de la grappe, telles que la rotation des certificats et la gestion de l'infrastructure
Le déploiement par défaut est constitué de deux pods virt-operator
.
Impact
Cette alerte indique une défaillance au niveau du cluster. Les fonctionnalités essentielles de gestion des clusters, telles que la rotation des certifications, la mise à niveau et le rapprochement des contrôleurs, risquent de ne pas être disponibles.
Le site virt-operator
n'est pas directement responsable des machines virtuelles dans le cluster. Par conséquent, son indisponibilité temporaire n'affecte pas de manière significative les charges de travail.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Obtenir le nom du déploiement
virt-operator
:$ oc -n $NAMESPACE get deploy virt-operator -o yaml
Générer la description du déploiement de
virt-operator
:$ oc -n $NAMESPACE describe deploy virt-operator
Vérifier l'absence de problèmes au niveau du nœud, tels que l'état de
NotReady
:$ oc get nodes
Atténuation
Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les artefacts recueillis au cours de la procédure de diagnostic.
14.14.32. OrphanedVirtualMachineInstances (substances de machines virtuelles orphelines)
Signification
Cette alerte se déclenche lorsqu'une instance de machine virtuelle (VMI), ou un pod virt-launcher
, s'exécute sur un nœud qui n'a pas de pod virt-handler
en cours d'exécution. Une telle VMI est appelée orphaned.
Impact
Les IMV orphelines ne peuvent pas être gérées.
Diagnostic
Vérifiez l'état des pods
virt-handler
pour connaître les nœuds sur lesquels ils s'exécutent :$ oc get pods --all-namespaces -o wide -l kubevirt.io=virt-handler
Vérifiez l'état des IMV pour identifier les IMV en cours d'exécution sur des nœuds qui n'ont pas de pod
virt-handler
en cours d'exécution :$ oc get vmis --all-namespaces
Vérifiez l'état du démon
virt-handler
:$ oc get daemonset virt-handler --all-namespaces
Exemple de sortie
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE ... virt-handler 2 2 2 2 2 ...
Le jeu de démons est considéré comme sain si les colonnes
Desired
,Ready
, etAvailable
contiennent la même valeur.Si le jeu de démons
virt-handler
n'est pas sain, vérifiez si le jeu de démonsvirt-handler
ne présente pas de problèmes de déploiement de pods :$ oc get daemonset virt-handler --all-namespaces -o yaml | jq .status
Vérifiez que les nœuds ne présentent pas de problèmes tels que l'état
NotReady
:$ oc get nodes
Vérifiez la strophe
spec.workloads
de la ressource personnalisée (CR)KubeVirt
pour une politique de placement des charges de travail :$ oc get kubevirt kubevirt --all-namespaces -o yaml
Atténuation
Si une stratégie de placement des charges de travail est configurée, ajoutez le nœud avec la VMI à la stratégie.
Les causes possibles de la suppression d'un pod virt-handler
d'un nœud sont notamment les modifications apportées aux taches et tolérances du nœud ou aux règles de programmation d'un pod.
Essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.33. Charges de travail d'instances de machines virtuelles périmées
Signification
Cette alerte se déclenche lorsque des instances de machines virtuelles (VMI) en cours d'exécution dans des pods virt-launcher
obsolètes sont détectées 24 heures après la mise à jour du plan de contrôle d'OpenShift Virtualization.
Impact
Les IMV obsolètes peuvent ne pas avoir accès aux nouvelles fonctionnalités d'OpenShift Virtualization.
Les IMV obsolètes ne recevront pas les correctifs de sécurité associés à la mise à jour du pod virt-launcher
.
Diagnostic
Identifier les IMV périmés :
$ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces
Vérifiez la ressource personnalisée (CR)
KubeVirt
pour déterminer siworkloadUpdateMethods
est configuré dans la stropheworkloadUpdateStrategy
:$ oc get kubevirt kubevirt --all-namespaces -o yaml
Vérifier chaque IMV obsolète pour déterminer s'il est possible de le migrer en direct :
$ oc get vmi <vmi> -o yaml
Exemple de sortie
apiVersion: kubevirt.io/v1 kind: VirtualMachineInstance ... status: conditions: - lastProbeTime: null lastTransitionTime: null message: cannot migrate VMI which does not use masquerade to connect to the pod network reason: InterfaceNotLiveMigratable status: "False" type: LiveMigratable
Atténuation
Configuration des mises à jour automatisées de la charge de travail
Mettre à jour le CR HyperConverged
pour activer les mises à jour automatiques de la charge de travail.
Arrêt d'une VM associée à une VMI non migrable en direct
Si une IMV n'est pas migrable en direct et si
runStrategy: always
est défini dans l'objetVirtualMachine
correspondant, vous pouvez mettre à jour l'IMV en arrêtant manuellement la machine virtuelle (VM) :virctl stop --namespace <namespace> <vm>
Un nouveau VMI démarre immédiatement dans un pod virt-launcher
mis à jour pour remplacer le VMI arrêté. C'est l'équivalent d'une action de redémarrage.
L'arrêt manuel d'une VM live-migratable est destructeur et déconseillé car il interrompt la charge de travail.
Migration d'une VMI migrable en direct
Si une IMV est migrable en direct, vous pouvez la mettre à jour en créant un objet VirtualMachineInstanceMigration
qui cible une IMV spécifique en cours d'exécution. L'IMV est migrée dans un pod virt-launcher
mis à jour.
Créez un manifeste
VirtualMachineInstanceMigration
et enregistrez-le sousmigration.yaml
:apiVersion: kubevirt.io/v1 kind: VirtualMachineInstanceMigration metadata: name: <migration_name> namespace: <namespace> spec: vmiName: <vmi_name>
Créer un objet
VirtualMachineInstanceMigration
pour déclencher la migration :$ oc create -f migration.yaml
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.34. SSPCommonTemplatesModificationReverted
Signification
Cette alerte se déclenche lorsque l'opérateur SSP (Scheduling, Scale, and Performance) annule les modifications apportées aux modèles communs dans le cadre de sa procédure de réconciliation.
L'opérateur SSP déploie et réconcilie les modèles communs et le validateur de modèle. Si un utilisateur ou un script modifie un modèle commun, les modifications sont annulées par l'opérateur SSP.
Impact
Les modifications apportées aux modèles communs sont écrasées.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \ awk '{print $1}')"
Vérifiez les journaux de
ssp-operator
pour les modèles dont les modifications ont été annulées :$ oc -n $NAMESPACE logs --tail=-1 -l control-plane=ssp-operator | \ grep 'common template' -C 3
Atténuation
Essayez d'identifier et de résoudre la cause des changements.
Veillez à ce que les modifications ne soient apportées qu'aux copies des modèles, et non aux modèles eux-mêmes.
14.14.35. SSPFailingToReconcile (défaut de réconciliation)
Signification
Cette alerte se déclenche lorsque le cycle de rapprochement de l'opérateur SSP (Scheduling, Scale and Performance) échoue à plusieurs reprises, bien que l'opérateur SSP soit en cours d'exécution.
L'opérateur SSP est responsable du déploiement et du rapprochement des modèles communs et du validateur de modèles.
Impact
Les composants dépendants peuvent ne pas être déployés. Les modifications apportées aux composants peuvent ne pas être rapprochées. Par conséquent, les modèles communs ou le validateur de modèles peuvent ne pas être mis à jour ou réinitialisés en cas d'échec.
Diagnostic
Exporter la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \ awk '{print $1}')"
Obtenir les informations sur les nacelles du site
ssp-operator
:$ oc -n $NAMESPACE describe pods -l control-plane=ssp-operator
Vérifiez si des erreurs se sont produites sur le site
ssp-operator
:$ oc -n $NAMESPACE logs --tail=-1 -l control-plane=ssp-operator
Obtenir l'état des pods
virt-template-validator
:$ oc -n $NAMESPACE get pods -l name=virt-template-validator
Obtenir les informations sur les nacelles du site
virt-template-validator
:$ oc -n $NAMESPACE describe pods -l name=virt-template-validator
Vérifiez si des erreurs se sont produites sur le site
virt-template-validator
:$ oc -n $NAMESPACE logs --tail=-1 -l name=virt-template-validator
Atténuation
Essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.36. SSPHighRateRejectedVms
Signification
Cette alerte se déclenche lorsqu'un utilisateur ou un script tente de créer ou de modifier un grand nombre de machines virtuelles (VM) à l'aide d'une configuration non valide.
Impact
Les machines virtuelles ne sont ni créées ni modifiées. Par conséquent, l'environnement peut ne pas se comporter comme prévu.
Diagnostic
Exporter la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \ awk '{print $1}')"
Vérifiez les journaux de
virt-template-validator
pour les erreurs qui pourraient indiquer la cause :$ oc -n $NAMESPACE logs --tail=-1 -l name=virt-template-validator
Exemple de sortie
{"component":"kubevirt-template-validator","level":"info","msg":"evalution summary for ubuntu-3166wmdbbfkroku0:\nminimal-required-memory applied: FAIL, value 1073741824 is lower than minimum [2147483648]\n\nsucceeded=false", "pos":"admission.go:25","timestamp":"2021-09-28T17:59:10.934470Z"}
Atténuation
Essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.37. SSPOperatorDown
Signification
Cette alerte se déclenche lorsque tous les pods de l'opérateur SSP (Scheduling, Scale and Performance) sont hors service.
L'opérateur SSP est responsable du déploiement et du rapprochement des modèles communs et du validateur de modèles.
Impact
Les composants dépendants peuvent ne pas être déployés. Les modifications apportées aux composants peuvent ne pas être rapprochées. Par conséquent, les modèles communs et/ou le validateur de modèles peuvent ne pas être mis à jour ou réinitialisés en cas d'échec.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \ awk '{print $1}')"
Vérifier l'état des pods
ssp-operator
.$ oc -n $NAMESPACE get pods -l control-plane=ssp-operator
Obtenir les informations sur les nacelles du site
ssp-operator
:$ oc -n $NAMESPACE describe pods -l control-plane=ssp-operator
Vérifiez les messages d'erreur dans les journaux de
ssp-operator
:$ oc -n $NAMESPACE logs --tail=-1 -l control-plane=ssp-operator
Atténuation
Essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.38. SSPTemplateValidatorDown
Signification
Cette alerte se déclenche lorsque tous les modules du validateur de modèle sont hors service.
Le validateur de modèles vérifie les machines virtuelles (VM) pour s'assurer qu'elles ne violent pas leurs modèles.
Impact
Les machines virtuelles ne sont pas validées par rapport à leurs modèles. Par conséquent, les machines virtuelles peuvent être créées avec des spécifications qui ne correspondent pas à leurs charges de travail respectives.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \ awk '{print $1}')"
Obtenir l'état des pods
virt-template-validator
:$ oc -n $NAMESPACE get pods -l name=virt-template-validator
Obtenir les informations sur les nacelles du site
virt-template-validator
:$ oc -n $NAMESPACE describe pods -l name=virt-template-validator
Vérifiez les messages d'erreur dans les journaux de
virt-template-validator
:$ oc -n $NAMESPACE logs --tail=-1 -l name=virt-template-validator
Atténuation
Essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.39. VirtAPIDown
Signification
Cette alerte se déclenche lorsque tous les pods du serveur API sont hors service.
Impact
Les objets OpenShift Virtualization ne peuvent pas envoyer d'appels API.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Vérifier l'état des pods
virt-api
:$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-api
Vérifiez l'état du déploiement de
virt-api
:$ oc -n $NAMESPACE get deploy virt-api -o yaml
Vérifiez les détails du déploiement de
virt-api
pour des problèmes tels que des pods en panne ou des échecs d'extraction d'image :$ oc -n $NAMESPACE describe deploy virt-api
Vérifiez si des nœuds se trouvent dans l'état
NotReady
:$ oc get nodes
Atténuation
Essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.40. VirtApiRESTErrorsBurst
Signification
Plus de 80 % des appels REST ont échoué dans les pods virt-api
au cours des 5 dernières minutes.
Impact
Un taux très élevé d'échecs des appels REST à virt-api
peut entraîner une lenteur de réponse et d'exécution des appels d'API, voire un rejet total des appels d'API.
Toutefois, les charges de travail des machines virtuelles en cours d'exécution ne devraient pas être affectées.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Obtenez la liste des pods
virt-api
sur votre déploiement :$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-api
Vérifiez les messages d'erreur dans les journaux de
virt-api
:oc logs -n $NAMESPACE <virt-api>
Obtenir les informations sur les nacelles du site
virt-api
:oc describe -n $NAMESPACE <virt-api>
Vérifiez si des problèmes sont survenus avec les nœuds. Par exemple, ils peuvent être dans l'état
NotReady
:$ oc get nodes
Vérifiez l'état du déploiement de
virt-api
:$ oc -n $NAMESPACE get deploy virt-api -o yaml
Obtenir les détails du déploiement de
virt-api
:$ oc -n $NAMESPACE describe deploy virt-api
Atténuation
Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.41. VirtApiRESTErrorsHigh
Signification
Plus de 5 % des appels REST ont échoué dans les pods virt-api
au cours des 60 dernières minutes.
Impact
Un taux élevé d'échecs des appels REST à virt-api
peut entraîner un ralentissement de la réponse et de l'exécution des appels API.
Toutefois, les charges de travail des machines virtuelles en cours d'exécution ne devraient pas être affectées.
Diagnostic
Définissez la variable d'environnement
NAMESPACE
comme suit :$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Vérifier l'état des pods
virt-api
:$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-api
Consultez les journaux de
virt-api
:$ oc logs -n $NAMESPACE <virt-api>
Obtenir les informations sur les nacelles du site
virt-api
:oc describe -n $NAMESPACE <virt-api>
Vérifiez si des problèmes sont survenus avec les nœuds. Par exemple, ils peuvent être dans l'état
NotReady
:$ oc get nodes
Vérifiez l'état du déploiement de
virt-api
:$ oc -n $NAMESPACE get deploy virt-api -o yaml
Obtenir les détails du déploiement de
virt-api
:$ oc -n $NAMESPACE describe deploy virt-api
Atténuation
Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez d'identifier la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.42. VirtControllerDown
Signification
Aucun pod virt-controller
en cours de fonctionnement n'a été détecté pendant 5 minutes.
Impact
Toutes les actions liées à la gestion du cycle de vie des machines virtuelles (VM) échouent. Il s'agit notamment du lancement d'une nouvelle instance de machine virtuelle (VMI) ou de l'arrêt d'une VMI existante.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Vérifiez l'état du déploiement de
virt-controller
:$ oc get deployment -n $NAMESPACE virt-controller -o yaml
Examinez les journaux du pod
virt-controller
:$ oc get logs <virt-controller>
Atténuation
Cette alerte peut avoir diverses causes, dont les suivantes :
- Épuisement des ressources du nœud
- Mémoire insuffisante sur le cluster
- Les nœuds sont hors service
- Le serveur API est surchargé. Par exemple, le planificateur peut être très sollicité et n'est donc pas entièrement disponible.
- Questions relatives à la mise en réseau
Identifiez la cause première et corrigez-la, si possible.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.43. VirtControllerRESTErrorsBurst
Signification
Plus de 80 % des appels REST dans les pods virt-controller
ont échoué au cours des 5 dernières minutes.
Le site virt-controller
a probablement perdu complètement la connexion avec le serveur API.
Cette erreur est souvent due à l'un des problèmes suivants :
- Le serveur API est surchargé, ce qui entraîne des dépassements de délai. Pour vérifier si c'est le cas, vérifiez les métriques du serveur API et affichez ses temps de réponse et le nombre total d'appels.
-
Le pod
virt-controller
ne peut pas atteindre le serveur API. Cela est généralement dû à des problèmes de DNS sur le nœud et à des problèmes de connectivité réseau.
Impact
Les mises à jour d'état ne sont pas propagées et les actions telles que les migrations ne peuvent pas avoir lieu. Cependant, les charges de travail en cours d'exécution ne sont pas affectées.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Liste des pods
virt-controller
disponibles :$ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-controller
Vérifiez dans les journaux de
virt-controller
les messages d'erreur lors de la connexion au serveur API :$ oc logs -n $NAMESPACE <virt-controller>
Atténuation
Si le module
virt-controller
ne peut pas se connecter au serveur API, supprimez le module pour forcer un redémarrage :oc delete -n $NAMESPACE <virt-controller>
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.44. VirtControllerRESTErrorsHigh
Signification
Plus de 5 % des appels REST ont échoué sur virt-controller
au cours des 60 dernières minutes.
Cela est probablement dû au fait que virt-controller
a partiellement perdu la connexion avec le serveur API.
Cette erreur est souvent due à l'un des problèmes suivants :
- Le serveur API est surchargé, ce qui entraîne des dépassements de délai. Pour vérifier si c'est le cas, vérifiez les métriques du serveur API et affichez ses temps de réponse et le nombre total d'appels.
-
Le pod
virt-controller
ne peut pas atteindre le serveur API. Cela est généralement dû à des problèmes de DNS sur le nœud et à des problèmes de connectivité réseau.
Impact
Les actions liées aux nœuds, telles que le démarrage, la migration et la planification des machines virtuelles, sont retardées. Les charges de travail en cours d'exécution ne sont pas affectées, mais la communication de leur état actuel peut être retardée.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Liste des pods
virt-controller
disponibles :$ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-controller
Vérifiez dans les journaux de
virt-controller
les messages d'erreur lors de la connexion au serveur API :$ oc logs -n $NAMESPACE <virt-controller>
Atténuation
Si le module
virt-controller
ne peut pas se connecter au serveur API, supprimez le module pour forcer un redémarrage :oc delete -n $NAMESPACE <virt-controller>
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.45. VirtHandlerDaemonSetRolloutFailing
Signification
Le jeu de démons virt-handler
n'a pas réussi à se déployer sur un ou plusieurs nœuds de travail après 15 minutes.
Impact
Cette alerte est un avertissement. Elle n'indique pas que tous les ensembles de démons virt-handler
n'ont pas été déployés. Par conséquent, le cycle de vie normal des machines virtuelles n'est pas affecté, sauf si le cluster est surchargé.
Diagnostic
Identifiez les nœuds de travail qui n'ont pas de pod virt-handler
en cours d'exécution :
Exporter la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Vérifiez l'état des pods
virt-handler
pour identifier les pods qui n'ont pas été déployés :$ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-handler
Obtenir le nom du nœud de travail du pod
virt-handler
:oc -n $NAMESPACE get pod <virt-handler> -o jsonpath='{.spec.nodeName}'
Atténuation
Si les pods virt-handler
n'ont pas pu être déployés en raison de ressources insuffisantes, vous pouvez supprimer d'autres pods sur le nœud de travail affecté.
14.14.46. VirtHandlerRESTErrorsBurst
Signification
Plus de 80 % des appels REST ont échoué sur virt-handler
au cours des 5 dernières minutes. Cette alerte indique généralement que les pods virt-handler
ne peuvent pas se connecter au serveur API.
Cette erreur est souvent due à l'un des problèmes suivants :
- Le serveur API est surchargé, ce qui entraîne des dépassements de délai. Pour vérifier si c'est le cas, vérifiez les métriques du serveur API et affichez ses temps de réponse et le nombre total d'appels.
-
Le pod
virt-handler
ne peut pas atteindre le serveur API. Cela est généralement dû à des problèmes de DNS sur le nœud et à des problèmes de connectivité réseau.
Impact
Les mises à jour d'état ne sont pas propagées et les actions liées au nœud, telles que les migrations, échouent. Cependant, les charges de travail en cours d'exécution sur le nœud affecté ne sont pas affectées.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Vérifier l'état du pod
virt-handler
:$ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-handler
Vérifiez dans les journaux de
virt-handler
les messages d'erreur lors de la connexion au serveur API :$ oc logs -n $NAMESPACE <virt-handler>
Atténuation
Si le site
virt-handler
ne peut pas se connecter au serveur API, supprimez le module pour forcer un redémarrage :oc delete -n $NAMESPACE <virt-handler>
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.47. VirtHandlerRESTErrorsHigh
Signification
Plus de 5 % des appels REST ont échoué sur virt-handler
au cours des 60 dernières minutes. Cette alerte indique généralement que les pods virt-handler
ont partiellement perdu la connexion au serveur API.
Cette erreur est souvent due à l'un des problèmes suivants :
- Le serveur API est surchargé, ce qui entraîne des dépassements de délai. Pour vérifier si c'est le cas, vérifiez les métriques du serveur API et affichez ses temps de réponse et le nombre total d'appels.
-
Le pod
virt-handler
ne peut pas atteindre le serveur API. Cela est généralement dû à des problèmes de DNS sur le nœud et à des problèmes de connectivité réseau.
Impact
Les actions liées aux nœuds, telles que le démarrage et la migration des charges de travail, sont retardées sur le nœud sur lequel virt-handler
est exécuté. Les charges de travail en cours d'exécution ne sont pas affectées, mais la communication de leur état actuel peut être retardée.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Vérifier l'état du pod
virt-handler
:$ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-handler
Vérifiez dans les journaux de
virt-handler
les messages d'erreur lors de la connexion au serveur API :$ oc logs -n $NAMESPACE <virt-handler> oc logs -n $NAMESPACE <virt-handler>
Atténuation
Si le site
virt-handler
ne peut pas se connecter au serveur API, supprimez le module pour forcer un redémarrage :oc delete -n $NAMESPACE <virt-handler>
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.48. VirtOperatorDown
Signification
Cette alerte se déclenche lorsqu'aucun pod virt-operator
dans l'état Running
n'a été détecté pendant 10 minutes.
Le site virt-operator
est le premier opérateur à démarrer dans une grappe. Ses principales responsabilités sont les suivantes
- Installation, mise à jour en direct et mise à niveau en direct d'un cluster
-
Surveiller le cycle de vie des contrôleurs de premier niveau, tels que
virt-controller
,virt-handler
,virt-launcher
, et gérer leur rapprochement - Certaines tâches à l'échelle de la grappe, telles que la rotation des certificats et la gestion de l'infrastructure
Le déploiement virt-operator
a une réplique par défaut de 2 pods.
Impact
Cette alerte indique une défaillance au niveau de la grappe. Les fonctionnalités critiques de gestion à l'échelle de la grappe, telles que la rotation des certifications, la mise à niveau et le rapprochement des contrôleurs, peuvent ne pas être disponibles.
Le site virt-operator
n'est pas directement responsable des machines virtuelles (VM) dans le cluster. Par conséquent, son indisponibilité temporaire n'affecte pas de manière significative les charges de travail des machines virtuelles.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Vérifiez l'état du déploiement de
virt-operator
:$ oc -n $NAMESPACE get deploy virt-operator -o yaml
Obtenir les détails du déploiement de
virt-operator
:$ oc -n $NAMESPACE describe deploy virt-operator
Vérifier l'état des pods
virt-operator
:$ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-operator
Vérifier l'absence de problèmes au niveau du nœud, tels que l'état de
NotReady
:$ oc get nodes
Atténuation
Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez de trouver la cause première et de résoudre le problème.
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.49. VirtOperatorRESTErrorsBurst
Signification
Cette alerte se déclenche lorsque plus de 80 % des appels REST dans les modules virt-operator
ont échoué au cours des 5 dernières minutes. Cela indique généralement que les modules virt-operator
ne peuvent pas se connecter au serveur API.
Cette erreur est souvent due à l'un des problèmes suivants :
- Le serveur API est surchargé, ce qui entraîne des dépassements de délai. Pour vérifier si c'est le cas, vérifiez les métriques du serveur API et affichez ses temps de réponse et le nombre total d'appels.
-
Le pod
virt-operator
ne peut pas atteindre le serveur API. Cela est généralement dû à des problèmes de DNS sur le nœud et à des problèmes de connectivité réseau.
Impact
Les actions au niveau du cluster, telles que la mise à niveau et le rapprochement des contrôleurs, peuvent ne pas être disponibles.
Toutefois, les charges de travail telles que les machines virtuelles (VM) et les instances VM (VMI) ne devraient pas être affectées.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Vérifier l'état des pods
virt-operator
:$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator
Vérifiez dans les journaux de
virt-operator
les messages d'erreur lors de la connexion au serveur API :oc -n $NAMESPACE logs <virt-operator>
Obtenir les coordonnées de la nacelle
virt-operator
:oc -n $NAMESPACE describe pod <virt-operator>
Atténuation
Si le module
virt-operator
ne peut pas se connecter au serveur API, supprimez le module pour forcer un redémarrage :oc delete -n $NAMESPACE <virt-operator>
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.50. VirtOperatorRESTErrorsHigh
Signification
Cette alerte se déclenche lorsque plus de 5 % des appels REST dans les pods virt-operator
ont échoué au cours des 60 dernières minutes. Cela indique généralement que les modules virt-operator
ne peuvent pas se connecter au serveur API.
Cette erreur est souvent due à l'un des problèmes suivants :
- Le serveur API est surchargé, ce qui entraîne des dépassements de délai. Pour vérifier si c'est le cas, vérifiez les métriques du serveur API et affichez ses temps de réponse et le nombre total d'appels.
-
Le pod
virt-operator
ne peut pas atteindre le serveur API. Cela est généralement dû à des problèmes de DNS sur le nœud et à des problèmes de connectivité réseau.
Impact
Les actions au niveau du cluster, telles que la mise à niveau et le rapprochement des contrôleurs, peuvent être retardées.
Toutefois, les charges de travail telles que les machines virtuelles (VM) et les instances VM (VMI) ne devraient pas être affectées.
Diagnostic
Définir la variable d'environnement
NAMESPACE
:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
Vérifier l'état des pods
virt-operator
:$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator
Vérifiez dans les journaux de
virt-operator
les messages d'erreur lors de la connexion au serveur API :oc -n $NAMESPACE logs <virt-operator>
Obtenir les coordonnées de la nacelle
virt-operator
:oc -n $NAMESPACE describe pod <virt-operator>
Atténuation
Si le module
virt-operator
ne peut pas se connecter au serveur API, supprimez le module pour forcer un redémarrage :oc delete -n $NAMESPACE <virt-operator>
Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.
14.14.51. VMCannotBeEvicted
Signification
Cette alerte se déclenche lorsque la stratégie d'éviction d'une machine virtuelle (VM) est définie sur LiveMigration
mais que la VM n'est pas migrable.
Impact
Les machines virtuelles non migrables empêchent l'éviction des nœuds. Cette condition affecte les opérations telles que la vidange et la mise à jour des nœuds.
Diagnostic
Vérifier la configuration VMI pour déterminer si la valeur de
evictionStrategy
estLiveMigrate
:$ oc get vmis -o yaml
Vérifiez l'état
False
dans la colonneLIVE-MIGRATABLE
pour identifier les IMV qui ne sont pas migrables :$ oc get vmis -o wide
Obtenez les détails de l'IMV et consultez le site
spec.conditions
pour identifier le problème :$ oc get vmi <vmi> -o yaml
Exemple de sortie
status: conditions: - lastProbeTime: null lastTransitionTime: null message: cannot migrate VMI which does not use masquerade to connect to the pod network reason: InterfaceNotLiveMigratable status: "False" type: LiveMigratable
Atténuation
Réglez le site evictionStrategy
de la VMI sur shutdown
ou résolvez le problème qui empêche la VMI de migrer.