stato di vpm e del cluster

vpm è l’agente che registra un Customer Edge con il tenant e supervisiona i container della piattaforma. Quando un nodo non si connette, il suo stato è la prima cosa da verificare.

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>

Cosa cercare.

• Active: active (running) since … e il tempo trascorso. Un vpm che si è riavviato pochi minuti fa su un nodo attivo da ore è il segnale — i fallimenti di registrazione si manifestano come cicli di riavvio molto prima che appaiano nel tenant.
• Main PID è docker. vpm viene eseguito come container Docker privilegiato, non come processo nativo, avviato con --net=host --privileged e un lungo elenco di bind mount dell’host tra cui /, /dev e /etc. Pertanto vpm appare in docker-ps e mai in crictl-ps — motivo per cui un docker-ps con tre voci su un CE è completo e non un sintomo.
• Le righe del journal finali. statusreporter.go: Status reporter loop has finished without error, sleeping for 5m… è lo stato stabile normale: vpm effettua il report con un ciclo di circa cinque minuti. module.go: Running intra-cluster, type: node conferma che si è unito al cluster anziché essere in esecuzione in modalità standalone.

Cosa non indica. Nulla riguardo al fatto che il tenant abbia accettato la registrazione. Un vpm perfettamente funzionante andrà in loop indefinitamente contro un piano di controllo che lo rifiuta — leggere le righe del journal per individuarne il motivo.

systemctl-restart-vpm

execcli systemctl-restart-vpm

Operazione invasiva, non acquisita qui

Il riavvio di vpm interrompe e ristabilisce la connessione del nodo con il tenant. È presente nell’elenco dei rifiuti dell’harness di raccolta, pertanto viene documentato dai metadati del catalogo e non viene mai eseguito. Ricorrervi solo se espressamente indicato.

etcdctl-cluster-member-status

Il cluster etcd che supporta il piano di controllo Kubernetes del CE, interrogato dal pod etcd su questo 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 |        |
+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

Cosa cercare. IS LEADER, RAFT TERM, e se RAFT INDEX e RAFT APPLIED INDEX concordano. Un divario persistente tra questi due valori indica che il membro sta applicando in ritardo rispetto al log. ERRORS vuoto è la condizione normale.

Un solo membro, su un deployment a tre nodi

Questo deployment esegue tre nodi CE, e il comando riporta un singolo membro — https://etcd-0.etcd:2379, IS LEADER: true. Questo è ciò che il comando ha restituito, ed è opportuno affermarlo chiaramente perché l’assunzione naturale è che tre nodi CE corrispondano a un etcd a tre membri e che una tabella con una sola riga significhi che due membri mancano.

Ciò che non è stato stabilito è il motivo: se ogni nodo esegue il proprio etcd a membro singolo, oppure se la query --cluster raggiunge sempre e solo il pod locale. Entrambe le ipotesi sono compatibili con questo output. Non interpretare la tabella con una sola riga come prova di un cluster degradato senza aver verificato gli altri due nodi.