vpm und Cluster-Zustand

vpm ist der Agent, der einen Customer Edge beim Mandanten registriert und die Plattform-Container überwacht. Wenn ein Knoten nicht online kommt, ist sein Zustand das Erste, was ermittelt werden muss.

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>

Worauf zu achten ist.

• Active: active (running) since … und die vergangene Zeit. Ein vpm, das auf einem Knoten, der seit Stunden läuft, erst vor wenigen Minuten neu gestartet wurde, ist das Signal — Registrierungsfehler erscheinen als Neustartschleifen, lange bevor sie im Mandanten sichtbar werden.
• Main PID ist docker. vpm läuft als privilegierter Docker-Container, nicht als nativer Prozess, gestartet mit --net=host --privileged und einer langen Liste von Host-Bind-Mounts, einschließlich /, /dev und /etc. Daher erscheint vpm in docker-ps und niemals in crictl-ps — was auch der Grund ist, warum ein docker-ps mit drei Einträgen auf einem CE vollständig und kein Symptom ist.
• Die abschließenden Journal-Zeilen. statusreporter.go: Status reporter loop has finished without error, sleeping for 5m… ist der gesunde Normalzustand: vpm meldet sich in einem ungefähr fünfminütigen Zyklus. module.go: Running intra-cluster, type: node bestätigt, dass es dem Cluster beigetreten ist und nicht eigenständig läuft.

Was es nicht verrät. Nichts darüber, ob der Mandant die Registrierung akzeptiert hat. Ein vollständig gesundes vpm wird unbegrenzt gegen eine Control-Plane schleifen, die es ablehnt — die Journal-Zeilen enthalten den Grund dafür.

systemctl-restart-vpm

execcli systemctl-restart-vpm

Unterbrechend und hier nicht erfasst

Das Neustarten von vpm beendet die Verbindung des Knotens zum Mandanten und stellt sie neu her. Es steht auf der Ablehnungsliste des Harvest-Harness, ist daher anhand seiner Katalog-Metadaten dokumentiert und wird niemals ausgeführt. Greifen Sie nur dann darauf zurück, wenn Sie dazu angewiesen werden.

etcdctl-cluster-member-status

Das etcd-Cluster, das die Kubernetes-Control-Plane des CE unterstützt, abgefragt vom etcd-Pod auf diesem Knoten.

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

Worauf zu achten ist. IS LEADER, RAFT TERM und ob RAFT INDEX und RAFT APPLIED INDEX übereinstimmen. Eine anhaltende Lücke zwischen diesen beiden bedeutet, dass das Mitglied hinter dem Log anwendet. ERRORS leer ist der gesunde Zustand.

Ein Mitglied bei einer Drei-Knoten-Bereitstellung

Diese Bereitstellung betreibt drei CE-Knoten, und der Befehl meldet ein einzelnes Mitglied — https://etcd-0.etcd:2379, IS LEADER: true. Das ist das Ergebnis, das der Befehl zurückgegeben hat, und es ist es wert, klar ausgesprochen zu werden, da die natürliche Annahme ist, dass drei CE-Knoten ein drei Mitglieder umfassendes etcd bedeuten und eine einzeilige Tabelle bedeutet, dass zwei Mitglieder fehlen.

Was nicht geklärt wurde, ist der Grund: ob jeder Knoten sein eigenes Einzelmitglied-etcd betreibt oder ob die --cluster-Abfrage immer nur den lokalen Pod erreicht. Beides ist mit dieser Ausgabe vereinbar. Lesen Sie die einzeilige Tabelle nicht als Beweis für ein degradiertes Cluster, ohne die anderen beiden Knoten zu überprüfen.