การวินิจฉัย Customer Edge

Customer Edge (CE) คือโนด F5 Distributed Cloud ที่รีโพซิทอรีนี้จัดเตรียมขึ้นใน Azure — terraform/modules/ce-node ซึ่งสร้างจากอิมเมจ volterraedgeservices/volterra-node บนตลาดกลาง

โนดนี้รัน data plane (Argo), control plane (Vega), พร็อกซี Envoy, สแตก Kubernetes และ vpm ซึ่งเป็นเอเจนต์ที่ลงทะเบียนโนดและจัดการทุกสิ่งอย่างอื่นบน โนดนั้น

เมื่อ CE ทำงานผิดปกติ Site CLI คือเครื่องมือที่ใช้ การตัดสินใจแรกคือเส้นทางการเข้าถึงใดที่ใช้ได้ และหากเลือกผิดก็จะเสียเวลาไปในลักษณะที่ดูเหมือนว่าโนด เสียหาย

เส้นทางการเข้าถึงสี่แบบ และไม่สามารถใช้แทนกันได้

Debug APIFor a node that is ONLINE. Scriptable, read-only, and covers 34 commands.

Site ConsoleF5's own per-node troubleshooting UI, over an Azure Bastion tunnel. No SSH key, no jump host.

SSHThe full on-box Site CLI. Needs a key present from first boot and a host inside the VNet.

Serial consoleFor a node that never registered. The only route when the node has no network path.

debug API เข้าถึงโนด ผ่าน control plane ของ F5 Distributed Cloud นั่นคือเหตุผลทั้งหมดที่การแยกแยะนี้สำคัญ: API สามารถตอบได้เมื่อโนดได้ ลงทะเบียนแล้วและรายงานสถานะ ONLINE เท่านั้น

โนดที่ลงทะเบียนไม่สำเร็จ — cloud-init ผิดพลาด, โทเคนหมดอายุ, ไม่มีเส้นทางไปยัง register.ves.volterra.io — คือกรณีที่คุณต้องการการวินิจฉัยพอดี และ เป็นกรณีที่ API ไม่สามารถให้บริการได้พอดีเช่นกัน

Site Console เป็นตัวเลือกที่ควรลองก่อนเมื่อคุณต้องการ UI สำหรับ การแก้ปัญหาของ F5 เองมากกว่าคำสั่งเฉพาะเจาะจง มันเรียกร้องจากคุณน้อยที่สุด — ไม่ต้องใช้คีย์ ไม่ต้องใช้ jump host ไม่ต้องมี public IP บนโนด — เพราะการกำหนดว่าใครเชื่อมต่อได้กลายเป็นการตัดสินใจของ Azure RBAC และ มันตอบได้ไม่ว่าไซต์จะลงทะเบียนแล้วหรือไม่ มันต้องใช้ Azure Bastion ซึ่งการดีพลอย นี้ควบคุมไว้ด้วย enable_bastion และไม่ได้ถูกดีพลอยโดยค่าเริ่มต้น

SSH เป็นเส้นทางเดียวที่เข้าถึงพื้นผิวคำสั่งทั้งหมดของแอปพลายแอนซ์ได้ — debug API เปิดเผยคำสั่ง 34 คำสั่ง ในขณะที่ตัวโนดเองมีคำสั่งมากกว่านั้นอีกมาก มีสองสิ่งที่จำกัด มัน sshd ตอบสนองเฉพาะบนที่อยู่ภายใน (SLI) ของโนดเท่านั้น จึงต้องมีโฮสต์อยู่ภายใน VNet และคีย์ถูกเขียนโดย cloud-init ตอนบูตครั้งแรก เพราะฟิลด์ ssh_key บนอ็อบเจ็กต์ ไซต์นั้นไม่มีผล — vpm ข้ามผู้ใช้ admin และไม่เคยนำไปใช้ ดังนั้นการเปิดใช้งานบน โนดที่กำลังทำงานอยู่จึงเท่ากับการแทนที่โนดเหล่านั้น

ดังนั้น: หากไซต์อยู่ในสถานะ ONLINE และคำสั่ง 34 คำสั่งเพียงพอ ให้ใช้ debug API หากต้องการ UI หรือสำหรับ โนดที่ไม่เคยลงทะเบียนแต่ยังมีเส้นทางเครือข่ายอยู่ ให้ใช้ Site Console หากคุณต้องการพื้นผิวคำสั่ง ส่วนที่เหลือและสามารถเข้าถึง VNet ได้ ให้ใช้ SSH หากโนดไม่มีเส้นทางเครือข่าย ที่ใช้งานได้เลย serial console คือทางเดียวที่จะเข้าถึงได้

ตรวจสอบสถานะไซต์ก่อน — และตรวจสอบว่าคุณกำลังถามเทแนนต์ที่ถูกต้อง

คำขอเดียวจะบอกคุณว่าคุณอยู่บนเส้นทางใด:

curl -sS -H "Authorization: APIToken $XCSH_API_TOKEN" \
  "$XCSH_API_URL/api/config/namespaces/system/sites/<site>" \
  | jq -r '.spec.site_state'

ONLINE หมายความว่า debug API จะใช้งานได้ อย่างอื่นหมายความว่าต้องใช้ Site Console หรือ serial console

ไซต์ที่ ไม่มีอยู่ มีคำอธิบายที่สองก่อนจะสรุปว่า “มันไม่เคยลงทะเบียน”: คุณ ชี้ไปที่เทแนนต์ผิด การดีพลอยนี้อยู่ใน f5-sales-demo (https://<XC_TENANT>.console.ves.volterra.io) ซึ่งตรึงไว้ด้วย var.expected_xc_tenant — cd terraform && terraform output -raw xc_tenant จะบอกได้โดยไม่ต้องแตะต้องอะไรเลย เครดิเชียลที่สร้างขึ้นสำหรับเทแนนต์อื่นจะคืนค่า 401 เปล่า ๆ ซึ่งอ่านได้เหมือนโทเคนหมดอายุ

กฎด้านความปลอดภัย

กฎเหล่านี้ใช้กับทุกคำสั่งในทุกหน้าด้านล่าง

• อ่านอย่างเดียวเว้นแต่คุณจะมั่นใจ พื้นผิวคำสั่งถูกแบ่งเป็นสองระดับ สิทธิ์ และระดับ Exec นั้นไม่ว่าจะเปลี่ยนแปลงโนดหรืออ่านตัวบ่งชี้สถานะ ไม่มีสิ่งใดในหน้าเหล่านี้ที่รันคำสั่ง Exec และชุดเครื่องมือเก็บข้อมูลก็เช่นกัน
• อย่าสันนิษฐานว่าคำสั่งปลอดภัยจากชื่อของมัน ip-link-set อ่านดูเหมือน คำสั่งสอบถาม แต่มันปิดอินเทอร์เฟซ systemctl-restart-crio รีสตาร์ต container runtime ภายใต้ data plane ที่กำลังทำงานอยู่
• เลือกคำสั่งที่แคบที่สุดที่ตอบคำถามได้ health และ diagnosis สรุปสถานะโนดได้อย่างประหยัด ในขณะที่ flow-l ดัมป์ทุก flow ที่กำลังทำงาน และ flow-l-match ตอบคำถามเดียวกันสำหรับการเชื่อมต่อเดียว
• CE ให้บริการทราฟฟิกจริง สภาพแวดล้อมเหล่านี้เป็นสภาพแวดล้อมสาธิตที่ใช้ร่วมกัน สันนิษฐานว่ามีใคร กำลังนำเสนอจากไซต์ที่คุณกำลังดีบักอยู่

สิ่งที่จัดทำเป็นเอกสารไว้ที่นี่

ทุกคำสั่งที่เข้าถึงได้ผ่าน debug API บนซอฟต์แวร์บิลด์ที่เทแนนต์นี้รันอยู่ แต่ละคำสั่งมาพร้อมเอาต์พุตที่เก็บมาจากโนดจริง ไม่ใช่การคัดลอกมาจากที่อื่น

เอกสารอ้างอิงคำสั่ง แสดงรายการคำสั่งทั้งหมดพร้อมหมวดหมู่ ระดับสิทธิ์ และช่องทางการส่งข้อมูล ส่วนเวิร์กโฟลว์ ร้อยเรียงคำสั่งเหล่านั้นเป็นลำดับที่คุณ ใช้จริงเมื่อเกิดปัญหา

ส่วนของ Site CLI ที่ใช้ได้บนเครื่องเท่านั้น — configure, configure-network, factory-reset, upgrade และคำสั่ง ExecCLI อีกประมาณหกสิบคำสั่ง — ไม่ได้ ครอบคลุมไว้ เพราะเอาต์พุตของคำสั่งเหล่านั้นยังไม่ได้ถูกเก็บมาจากโนดจริงในแบบเดียวกับทุก หน้าด้านล่างนี้

อย่างไรก็ตาม คำสั่งเหล่านั้นไม่ได้อยู่เกินเอื้อมอีกต่อไป scripts/sitecli_ssh_harvest.py ขับเคลื่อน เมนูเติมคำสั่งอัตโนมัติของแอปพลายแอนซ์ผ่าน SSH และบันทึกคำอธิบายที่ แอปพลายแอนซ์ให้ไว้สำหรับแต่ละคำสั่ง เพื่อให้พื้นผิวคำสั่งสามารถวัดได้ ไม่ใช่แค่คาดเดา การทำงานของมันตั้งค่าเริ่มต้นเป็นปฏิเสธ — มันแจกแจงทุกอย่างแต่รันเฉพาะรายการที่อนุญาตไว้ — เพราะไวยากรณ์คำสั่งที่ไม่ได้รับการยืนยัน และ ผลกระทบ ของคำสั่งที่ไม่ได้รับการยืนยัน คือข้อบกพร่องที่ เอกสารนี้มีอยู่เพื่อหลีกเลี่ยงการเกิดซ้ำ