ข้ามไปยังเนื้อหา
เครือข่ายมัลติคลาวด์

สถานะ vpm และคลัสเตอร์

vpm คือ agent ที่ลงทะเบียน Customer Edge กับ tenant และดูแลคอนเทนเนอร์ของแพลตฟอร์ม เมื่อโหนดไม่สามารถออนไลน์ได้ สถานะของโหนดคือสิ่งแรกที่ต้องตรวจสอบ

systemctl-status-vpm

หัวข้อที่มีชื่อว่า “systemctl-status-vpm”
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>

สิ่งที่ควรสังเกต

  • Active: active (running) since … และเวลาที่ผ่านไป หาก vpm รีสตาร์ทเมื่อไม่กี่นาทีที่ผ่านมาบนโหนดที่ทำงานมาหลายชั่วโมง นั่นคือสัญญาณเตือน — ความล้มเหลวในการลงทะเบียนจะปรากฏเป็นลูปการรีสตาร์ทก่อนที่จะปรากฏใน tenant
  • Main PID คือ docker. vpm รันในรูปแบบ Docker container แบบ privileged ไม่ใช่ process แบบ native โดยเปิดใช้งานด้วย --net=host --privileged และรายการ host bind mounts ยาวๆ รวมถึง /, /dev และ /etc ดังนั้น vpm จึงปรากฏใน docker-ps และไม่ปรากฏใน crictl-ps — นี่คือเหตุผลที่ docker-ps ที่มีสามรายการบน CE ถือว่าสมบูรณ์ ไม่ใช่อาการผิดปกติ
  • บรรทัด journal ท้ายสุด statusreporter.go: Status reporter loop has finished without error, sleeping for 5m… คือสถานะปกติที่ดี: vpm รายงานสถานะในรอบประมาณห้านาที module.go: Running intra-cluster, type: node ยืนยันว่าได้เข้าร่วมคลัสเตอร์แล้ว ไม่ใช่รันแบบ standalone

สิ่งที่คำสั่งนี้ไม่บอก ไม่มีข้อมูลว่า tenant ยอมรับ การลงทะเบียนหรือไม่ vpm ที่ทำงานปกติสมบูรณ์สามารถวนซ้ำได้อย่างไม่มีกำหนดกับ control plane ที่ปฏิเสธการเชื่อมต่อ — ให้อ่านบรรทัด journal เพื่อหาสาเหตุ

systemctl-restart-vpm

หัวข้อที่มีชื่อว่า “systemctl-restart-vpm”
Terminal window
execcli systemctl-restart-vpm

etcdctl-cluster-member-status

หัวข้อที่มีชื่อว่า “etcdctl-cluster-member-status”

คลัสเตอร์ etcd ที่รองรับ Kubernetes control plane ของ CE โดยสอบถามจาก etcd pod บนโหนดนี้

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

สิ่งที่ควรสังเกต IS LEADER, RAFT TERM และความสอดคล้องระหว่าง RAFT INDEX กับ RAFT APPLIED INDEX หากมีช่องว่างที่คงอยู่ระหว่างค่าทั้งสองหมายความว่าสมาชิกกำลัง apply ล้าหลัง log ERRORS ที่ว่างเปล่าคือสถานะปกติที่ดี