vpm et état du cluster

vpm est l’agent qui enregistre un Customer Edge auprès du tenant et supervise les conteneurs de la plateforme. Lorsqu’un nœud ne se met pas en ligne, son état est la première chose à établir.

systemctl-status-vpm

execcli systemctl-status-vpm

● vpm.service - VP Manager service
     Loaded: loaded (/etc/systemd/system/vpm.service; enabled; preset: disabled)
     Active: active (running) since Tue 2026-07-28 18:07:43 UTC; 2h 36min ago
   Main PID: 11329 (docker)
      Tasks: 10 (limit: 204889)
     Memory: 14.9M
        CPU: 496ms
     CGroup: /system.slice/vpm.service
             └─11329 /usr/bin/docker run --rm --name vpm --net=host --privileged -v /dev:/dev -v /bin/udevadm:/bin/udevadm -v /etc/:/hostetc/:rw -v /opt/:/hostopt/:rw -v /:/hostos/:ro -v /usr/bin/:/hostusr/bin/:ro -v /e…

Jul 28 20:40:47 f5-xc-ce-vm-01 vpm[11329]: etcd.go:123: Holding dictator lock for path /_lock/dictator
Jul 28 20:41:44 f5-xc-ce-vm-01 vpm[11329]: module.go:84: Running intra-cluster, type: node
Jul 28 20:41:44 f5-xc-ce-vm-01 vpm[11329]: pinger.go:38: Stats for connectivity-check: <name: intra-cluster, type: intra-cluster, success: true>
Jul 28 20:42:44 f5-xc-ce-vm-01 vpm[11329]: module.go:84: Running intra-cluster, type: node
Jul 28 20:42:44 f5-xc-ce-vm-01 vpm[11329]: module.go:90: Running intra-cluster, type: fabric
Jul 28 20:42:44 f5-xc-ce-vm-01 vpm[11329]: pinger.go:38: Stats for connectivity-check: <name: fabric, type: fabric, success: true>
Jul 28 20:42:44 f5-xc-ce-vm-01 vpm[11329]: pinger.go:38: Stats for connectivity-check: <name: intra-cluster, type: intra-cluster, success: true>
Jul 28 20:42:50 f5-xc-ce-vm-01 vpm[11329]: etcd.go:123: Holding dictator lock for path /_lock/dictator
Jul 28 20:43:44 f5-xc-ce-vm-01 vpm[11329]: module.go:84: Running intra-cluster, type: node
Jul 28 20:43:44 f5-xc-ce-vm-01 vpm[11329]: pinger.go:38: Stats for connectivity-check: <name: intra-cluster, type: intra-cluster, success: true>

Éléments à surveiller.

• Active: active (running) since … et le temps écoulé. Un vpm qui a redémarré il y a quelques minutes sur un nœud actif depuis des heures est le signal d’alerte — les échecs d’enregistrement se manifestent sous forme de boucles de redémarrage bien avant d’apparaître dans le tenant.
• Main PID est docker. vpm s’exécute en tant que conteneur Docker privilégié, et non en tant que processus natif, lancé avec --net=host --privileged et une longue liste de montages bind de l’hôte incluant /, /dev et /etc. Ainsi, vpm apparaît dans docker-ps et jamais dans crictl-ps — c’est également pourquoi un docker-ps à trois entrées sur un CE est complet plutôt qu’un symptôme.
• Les dernières lignes du journal. statusreporter.go: Status reporter loop has finished without error, sleeping for 5m… correspond à l’état stable et sain : vpm effectue son rapport selon un cycle d’environ cinq minutes. module.go: Running intra-cluster, type: node confirme qu’il a rejoint le cluster plutôt que de fonctionner en mode autonome.

Ce que cela ne vous indique pas. Rien sur le fait que le tenant ait accepté ou non l’enregistrement. Un vpm parfaitement sain boucle indéfiniment contre un plan de contrôle qui le refuse — lisez les lignes du journal pour en comprendre la raison.

systemctl-restart-vpm

execcli systemctl-restart-vpm

Perturbateur, et non capturé ici

Le redémarrage de vpm interrompt et rétablit la connexion du nœud au tenant. Cette commande figure sur la liste des refus du harnais de collecte, elle est donc documentée à partir de ses métadonnées de catalogue et n’est jamais exécutée. N’y recourez que sur instruction explicite.

etcdctl-cluster-member-status

Le cluster etcd qui soutient le plan de contrôle Kubernetes du CE, interrogé depuis le pod etcd sur ce nœud.

execcli etcdctl-cluster-member-status

+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT         |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| https://etcd-0.etcd:2379 | dc946acaf076bc59 |  3.5.11 |  2.8 MB |      true |      false |         3 |       1981 |               1981 |        |
+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

Éléments à surveiller. IS LEADER, RAFT TERM, et si RAFT INDEX et RAFT APPLIED INDEX concordent. Un écart persistant entre ces deux valeurs signifie que le membre applique les entrées en retard par rapport au journal. ERRORS vide correspond au cas sain.

Un seul membre, sur un déploiement à trois nœuds

Ce déploiement exécute trois nœuds CE, et la commande signale un seul membre — https://etcd-0.etcd:2379, IS LEADER: true. C’est ce que la commande a retourné, et il convient de l’énoncer clairement, car l’hypothèse naturelle est que trois nœuds CE impliquent un etcd à trois membres et qu’un tableau à une seule ligne signifie que deux membres sont manquants.

Ce qui n’a pas été établi, c’est la raison : soit chaque nœud exécute son propre etcd à membre unique, soit la requête --cluster n’atteint que le pod local. Les deux interprétations sont compatibles avec cette sortie. Ne lisez pas le tableau à une seule ligne comme une preuve de dégradation du cluster sans vérifier les deux autres nœuds.