vpm y estado del clúster

vpm es el agente que registra un Customer Edge con el tenant y supervisa los contenedores de plataforma. Cuando un nodo no puede conectarse, su estado es lo primero que se debe establecer.

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>

Qué buscar.

• Active: active (running) since … y el tiempo transcurrido. Un vpm que se reinició hace minutos en un nodo que lleva horas activo es la señal — los fallos de registro aparecen como bucles de reinicio mucho antes de que se manifiesten en el tenant.
• Main PID es docker. vpm se ejecuta como un contenedor Docker con privilegios, no como un proceso nativo, lanzado con --net=host --privileged y una larga lista de montajes bind del host que incluye /, /dev y /etc. Por eso vpm aparece en docker-ps y nunca en crictl-ps — que es también la razón por la que un docker-ps con tres entradas en un CE es completo y no un síntoma.
• Las últimas líneas del journal. statusreporter.go: Status reporter loop has finished without error, sleeping for 5m… es el estado estable y saludable: vpm reporta aproximadamente cada cinco minutos. module.go: Running intra-cluster, type: node confirma que se ha unido al clúster en lugar de ejecutarse de forma independiente.

Lo que no indica. Nada sobre si el tenant aceptó el registro. Un vpm perfectamente saludable puede iterar indefinidamente contra un plano de control que lo está rechazando — lea las líneas del journal para conocer el motivo.

systemctl-restart-vpm

execcli systemctl-restart-vpm

Disruptivo y no capturado aquí

Reiniciar vpm interrumpe y restablece la conexión del nodo con el tenant. Está en la lista de rechazo del harness de recolección, por lo que se documenta a partir de sus metadatos del catálogo y nunca se ejecuta. Recurra a él solo cuando así se le indique.

etcdctl-cluster-member-status

El clúster etcd que respalda el plano de control de Kubernetes del CE, consultado desde el pod etcd en este nodo.

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 |        |
+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

Qué buscar. IS LEADER, RAFT TERM, y si RAFT INDEX y RAFT APPLIED INDEX coinciden. Una brecha persistente entre ambos significa que el miembro está aplicando registros con retraso respecto al log. ERRORS vacío es el caso saludable.

Un miembro, en un despliegue de tres nodos

Este despliegue ejecuta tres nodos CE, y el comando reporta un único miembro — https://etcd-0.etcd:2379, IS LEADER: true. Eso es lo que devolvió el comando, y vale la pena indicarlo claramente porque la suposición natural es que tres nodos CE implican un etcd de tres miembros y que una tabla de una sola fila significa que faltan dos miembros.

Lo que no se ha establecido es el motivo: si cada nodo ejecuta su propio etcd de un solo miembro, o si la consulta --cluster solo llega siempre al pod local. Ambas situaciones son consistentes con esta salida. No interprete la tabla de una sola fila como evidencia de un clúster degradado sin verificar los otros dos nodos.