14.11. Exécution des vérifications de la grappe

OpenShift Virtualization inclut des checkups prédéfinis qui peuvent être utilisés pour la maintenance et le dépannage des clusters.

Important

Le cadre de vérification des clusters d'OpenShift Container Platform 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 de les utiliser 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.

14.11.1. À propos du cadre de vérification des clusters d'OpenShift Container Platform

Un checkup est une charge de travail de test automatisée qui vous permet de vérifier si une fonctionnalité spécifique du cluster fonctionne comme prévu. Le cadre de vérification du cluster utilise les ressources natives de Kubernetes pour configurer et exécuter la vérification.

En utilisant des vérifications prédéfinies, les administrateurs et les développeurs de clusters peuvent améliorer la maintenabilité des clusters, dépanner les comportements inattendus, minimiser les erreurs et gagner du temps. Ils peuvent également examiner les résultats de la vérification et les partager avec des experts pour une analyse plus approfondie. Les fournisseurs peuvent rédiger et publier des checkups pour les fonctionnalités ou les services qu'ils proposent et vérifier que les environnements de leurs clients sont configurés correctement.

L'exécution d'un contrôle prédéfini dans un espace de noms existant implique la configuration d'un compte de service pour le contrôle, la création des objets Role et RoleBinding pour le compte de service, l'activation des autorisations pour le contrôle et la création de la carte de configuration d'entrée et de la tâche de contrôle. Vous pouvez exécuter un contrôle plusieurs fois.

Important

Vous devez toujours :

Vérifiez que l'image de contrôle provient d'une source fiable avant de l'appliquer.
Vérifiez les autorisations de contrôle avant de créer les objets Role et RoleBinding.

14.11.2. Vérification de la connectivité et de la latence du réseau pour les machines virtuelles sur un réseau secondaire

Vous utilisez un contrôle prédéfini pour vérifier la connectivité réseau et mesurer la latence entre deux machines virtuelles (VM) connectées à une interface réseau secondaire.

Pour effectuer un contrôle pour la première fois, suivez les étapes de la procédure.

Si vous avez déjà effectué un contrôle, passez à l'étape 5 de la procédure, car les étapes d'installation du cadre et d'activation des autorisations pour le contrôle ne sont pas nécessaires.

Conditions préalables

You installed the OpenShift CLI (oc).
La grappe compte au moins deux nœuds de travail.
Le plugin Multus Container Network Interface (CNI) est installé sur le cluster.
Vous avez configuré une définition d'attachement réseau pour un espace de noms.

Procédure

Créez un fichier manifeste contenant les objets ServiceAccount, Role et RoleBinding avec les autorisations requises par le checkup pour l'accès au cluster :

Exemple 14.3. Exemple de fichier manifeste des rôles

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: vm-latency-checkup-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kubevirt-vm-latency-checker
rules:
- apiGroups: ["kubevirt.io"]
  resources: ["virtualmachineinstances"]
  verbs: ["get", "create", "delete"]
- apiGroups: ["subresources.kubevirt.io"]
  resources: ["virtualmachineinstances/console"]
  verbs: ["get"]
- apiGroups: ["k8s.cni.cncf.io"]
  resources: ["network-attachment-definitions"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubevirt-vm-latency-checker
subjects:
- kind: ServiceAccount
  name: vm-latency-checkup-sa
roleRef:
  kind: Role
  name: kubevirt-vm-latency-checker
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kiagnose-configmap-access
rules:
- apiGroups: [ "" ]
  resources: [ "configmaps" ]
  verbs: ["get", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kiagnose-configmap-access
subjects:
- kind: ServiceAccount
  name: vm-latency-checkup-sa
roleRef:
  kind: Role
  name: kiagnose-configmap-access
  apiGroup: rbac.authorization.k8s.io

Appliquer le manifeste des rôles de contrôle :
```
oc apply -n <target_namespace> -f <latency_roles>.yaml 1
```
1
<target_namespace> est l'espace de noms dans lequel le contrôle doit être exécuté. Il doit s'agir d'un espace de noms existant où réside l'objet NetworkAttachmentDefinition.
Créer un manifeste ConfigMap qui contient les paramètres d'entrée du contrôle. La carte de configuration fournit au cadre de travail les données d'entrée nécessaires à l'exécution du contrôle et stocke également les résultats de ce dernier.
Exemple de carte de configuration d'entrée
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: kubevirt-vm-latency-checkup-config
data:
  spec.timeout: 5m
  spec.param.network_attachment_definition_namespace: <target_namespace>
  spec.param.network_attachment_definition_name: "blue-network" 1
  spec.param.max_desired_latency_milliseconds: "10" 2
  spec.param.sample_duration_seconds: "5" 3
  spec.param.source_node: "worker1" 4
  spec.param.target_node: "worker2" 5
```
1
Le nom de l'objet NetworkAttachmentDefinition.
2
Facultatif : La latence maximale souhaitée, en millisecondes, entre les machines virtuelles. Si la latence mesurée dépasse cette valeur, le contrôle échoue.
3
Facultatif : La durée de la vérification de la latence, en secondes.
4
Facultatif : Lorsqu'il est spécifié, le temps de latence est mesuré entre ce nœud et le nœud cible. Si le nœud source est spécifié, le champ spec.param.target_node ne peut pas être vide.
5
Facultatif : Lorsqu'elle est spécifiée, la latence est mesurée entre le nœud source et ce nœud.
Appliquer le manifeste de la carte de configuration dans l'espace de noms cible :
```
oc apply -n <target_namespace> -f <latency_config_map>.yaml
```

Créez un objet Job pour exécuter le contrôle :

Exemple de manifeste d'emploi

apiVersion: batch/v1
kind: Job
metadata:
  name: kubevirt-vm-latency-checkup
spec:
  backoffLimit: 0
  template:
    spec:
      serviceAccountName: vm-latency-checkup-sa
      restartPolicy: Never
      containers:
        - name: vm-latency-checkup
          image: registry.redhat.io/container-native-virtualization/vm-network-latency-checkup:v4.12.0
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]
            runAsNonRoot: true
            seccompProfile:
              type: "RuntimeDefault"
          env:
            - name: CONFIGMAP_NAMESPACE
              value: <target_namespace>
            - name: CONFIGMAP_NAME
              value: kubevirt-vm-latency-checkup-config

Appliquez le manifeste Job. Le contrôle utilise l'utilitaire ping pour vérifier la connectivité et mesurer la latence.
```
oc apply -n <target_namespace> -f <latency_job>.yaml
```

Attendez que le travail soit terminé :

$ oc wait job kubevirt-vm-latency-checkup -n <target_namespace> --for condition=complete --timeout 6m

Examinez les résultats du contrôle de latence en exécutant la commande suivante. Si la latence maximale mesurée est supérieure à la valeur de l'attribut spec.param.max_desired_latency_milliseconds, le contrôle échoue et renvoie une erreur.

$ oc get configmap kubevirt-vm-latency-checkup-config -n <target_namespace> -o yaml

Exemple de sortie config map (succès)

apiVersion: v1
kind: ConfigMap
metadata:
  name: kubevirt-vm-latency-checkup-config
  namespace: <target_namespace>
data:
  spec.timeout: 5m
  spec.param.network_attachment_definition_namespace: <target_namespace>
  spec.param.network_attachment_definition_name: "blue-network"
  spec.param.max_desired_latency_milliseconds: "10"
  spec.param.sample_duration_seconds: "5"
  spec.param.source_node: "worker1"
  spec.param.target_node: "worker2"
  status.succeeded: "true"
  status.failureReason: ""
  status.completionTimestamp: "2022-01-01T09:00:00Z"
  status.startTimestamp: "2022-01-01T09:00:07Z"
  status.result.avgLatencyNanoSec: "177000"
  status.result.maxLatencyNanoSec: "244000" 1
  status.result.measurementDurationSec: "5"
  status.result.minLatencyNanoSec: "135000"
  status.result.sourceNode: "worker1"
  status.result.targetNode: "worker2"

1: La latence maximale mesurée en nanosecondes.

Facultatif : Pour afficher le journal détaillé du travail en cas d'échec du contrôle, utilisez la commande suivante :
```
oc logs job.batch/kubevirt-vm-latency-checkup -n <target_namespace>
```

Supprimez les ressources job et config map que vous avez créées précédemment en exécutant les commandes suivantes :

oc delete job -n <target_namespace> kubevirt-vm-latency-checkup

oc delete config-map -n <target_namespace> kubevirt-vm-latency-checkup-config

Facultatif : si vous ne prévoyez pas d'effectuer un autre contrôle, supprimez le rôle de contrôle et les fichiers manifestes du cadre.
```
oc delete -f <nom_du_fichier>.yaml
```

14.11.3. Ressources supplémentaires

Attacher une machine virtuelle à plusieurs réseaux

14.11. Exécution des vérifications de la grappe

14.11.1. À propos du cadre de vérification des clusters d'OpenShift Container Platform

14.11.2. Vérification de la connectivité et de la latence du réseau pour les machines virtuelles sur un réseau secondaire

14.11.3. Ressources supplémentaires

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Rendre l’open source plus inclusif

À propos de Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links