Pular para o conteúdo

vpm e estado do cluster

vpm é o agente que registra um Customer Edge no tenant e supervisiona os contêineres da plataforma. Quando um nó não consegue ficar online, seu estado é a primeira coisa a ser verificada.

Terminal window
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>

O que observar.

  • Active: active (running) since … e o tempo decorrido. Um vpm que reiniciou há minutos em um nó que está ativo há horas é o sinal — falhas de registro aparecem como loops de reinicialização muito antes de aparecerem no tenant.
  • Main PID é docker. O vpm é executado como um contêiner Docker privilegiado, não como um processo nativo, iniciado com --net=host --privileged e uma longa lista de montagens bind do host, incluindo /, /dev e /etc. Portanto, o vpm aparece em docker-ps e nunca em crictl-ps — o que também explica por que um docker-ps com três entradas em um CE é completo, e não um sintoma.
  • As linhas de journal no final. statusreporter.go: Status reporter loop has finished without error, sleeping for 5m… é o estado saudável normal: o vpm reporta em um ciclo de aproximadamente cinco minutos. module.go: Running intra-cluster, type: node confirma que ele ingressou no cluster em vez de executar de forma standalone.

O que ele não informa. Nada sobre se o tenant aceitou o registro. Um vpm perfeitamente saudável fará loops indefinidamente contra um plano de controle que está recusando — leia as linhas do journal para identificar o motivo.

Terminal window
execcli systemctl-restart-vpm

O cluster etcd que suporta o plano de controle Kubernetes do CE, consultado a partir do pod etcd neste nó.

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

O que observar. IS LEADER, RAFT TERM, e se RAFT INDEX e RAFT APPLIED INDEX estão de acordo. Uma diferença persistente entre esses dois valores significa que o membro está aplicando atrás do log. ERRORS vazio é o caso saudável.