Customer-Edge-Diagnose
Ein Customer Edge (CE) ist der F5 Distributed Cloud Knoten, den dieses Repository in
Azure bereitstellt — terraform/modules/ce-node, erstellt aus dem
Marktplatz-Image volterraedgeservices/volterra-node.
Er betreibt die Datenebene (Argo), die Steuerungsebene (Vega), einen Envoy-Proxy, einen
Kubernetes-Stack sowie vpm, den Agenten, der den Knoten registriert und alles Weitere
darauf verwaltet.
Wenn sich ein CE fehlerhaft verhält, ist die Site CLI das Instrument. Die erste Entscheidung betrifft den zutreffenden Zugriffsweg, und eine falsche Wahl kostet Zeit auf eine Weise, die wie ein defekter Knoten aussieht.
Vier Zugriffswege, und sie sind nicht austauschbar
Abschnitt betitelt „Vier Zugriffswege, und sie sind nicht austauschbar“ONLINE. Scriptable, read-only, and covers 34 commands.Die Debug API erreicht den Knoten über die Steuerungsebene von F5 Distributed Cloud.
Genau deshalb ist die Unterscheidung wichtig: Die API kann erst antworten, sobald sich der
Knoten registriert hat und ONLINE meldet.
Ein Knoten, dessen Registrierung fehlgeschlagen ist — fehlerhaftes cloud-init, ein
abgelaufenes Token, keine Route zu register.ves.volterra.io — ist genau der Fall, in dem
Sie Diagnose benötigen, und genau der Fall, den die API nicht bedienen kann.
Site Console sollten Sie zuerst versuchen, wenn Sie F5s eigene
Fehlerbehebungsoberfläche statt bestimmter Befehle wünschen. Sie verlangt am wenigsten von
Ihnen — kein Schlüssel, kein Jump-Host, keine öffentliche IP auf dem Knoten — weil die Frage,
wer sich verbinden darf, zu einer Azure-RBAC-Entscheidung wird, und sie antwortet unabhängig
davon, ob sich die Site registriert hat. Sie benötigt Azure Bastion, das diese Bereitstellung
hinter enable_bastion absichert und das standardmäßig nicht bereitgestellt wird.
SSH ist der einzige Weg, der die vollständige Befehlsoberfläche der Appliance
erreicht — die Debug API stellt 34 Befehle bereit, der Knoten selbst bietet weit mehr. Zwei
Dinge schränken ihn ein. sshd antwortet ausschließlich auf der internen (SLI-)Adresse des
Knotens, daher wird ein Host innerhalb des VNet benötigt; und der Schlüssel wird von cloud-init
beim ersten Start geschrieben, weil das Feld ssh_key am Site-Objekt wirkungslos ist — vpm
überspringt den Benutzer admin und wendet es nie an. Eine Aktivierung auf laufenden Knoten
ersetzt diese daher.
Also: Wenn die Site ONLINE ist und 34 Befehle genügen, verwenden Sie die Debug API. Für eine
Oberfläche oder für einen Knoten, der sich nie registriert hat, aber noch einen Netzwerkpfad
besitzt, verwenden Sie Site Console. Wenn Sie den Rest der Befehlsoberfläche benötigen und das
VNet erreichen können, verwenden Sie SSH. Wenn der Knoten überhaupt keinen funktionierenden
Netzwerkpfad hat, ist die serielle Konsole der einzige Weg hinein.
Sicherheitsregeln
Abschnitt betitelt „Sicherheitsregeln“Diese gelten für jeden Befehl auf jeder der nachfolgenden Seiten.
- Nur lesend, sofern Sie nicht absolut sicher sind. Die Befehlsoberfläche ist in zwei
Berechtigungsstufen unterteilt, und die
Exec-Stufe verändert entweder den Knoten oder liest einen Zustandsmarker. Nichts auf diesen Seiten führt einenExec-Befehl aus, und das Capture-Harness ebenso wenig. - Gehen Sie nie davon aus, dass ein Befehl aufgrund seines Namens ungefährlich ist.
ip-link-setliest sich wie eine Abfrage und legt eine Schnittstelle still.systemctl-restart-criostartet die Container-Laufzeitumgebung unter einer aktiven Datenebene neu. - Bevorzugen Sie den engsten Befehl, der die Frage beantwortet.
healthunddiagnosisfassen den Knoten kostengünstig zusammen;flow-lgibt jeden aktiven Flow aus, undflow-l-matchbeantwortet dieselbe Frage für eine einzelne Verbindung. - Ein CE bedient Live-Datenverkehr. Dies sind gemeinsam genutzte Demo-Umgebungen. Gehen Sie davon aus, dass jemand von der Site präsentiert, die Sie gerade debuggen.
Was hier dokumentiert ist
Abschnitt betitelt „Was hier dokumentiert ist“Jeder Befehl, der über die Debug API auf dem von diesem Mandanten betriebenen Software-Build erreichbar ist, jeweils mit Ausgaben, die von einem Live-Knoten erfasst und nicht von anderswo übernommen wurden.
Die Befehlsreferenz listet sie alle mit Kategorie, Berechtigungsstufe und Transport auf; die Workflows verketten sie zu den Abläufen, die Sie tatsächlich verwenden, wenn etwas nicht stimmt.
Die ausschließlich auf dem Gerät verfügbaren Teile der Site CLI — configure,
configure-network, factory-reset, upgrade und rund sechzig weitere ExecCLI-Befehle —
werden nicht behandelt, weil ihre Ausgaben nicht so von einem Live-Knoten erfasst wurden wie
bei jeder nachfolgenden Seite.
Sie sind jedoch nicht länger unerreichbar. scripts/sitecli_ssh_harvest.py steuert das
eigene Vervollständigungsmenü der Appliance über SSH und zeichnet die
Beschreibung auf, die die Appliance für jeden Befehl liefert, sodass die Oberfläche gemessen
statt geschätzt werden kann. Ihre Ausführung ist standardmäßig verweigert — sie zählt alles
auf und führt nur eine Positivliste aus — weil ungeprüfte Befehlssyntax und ungeprüfte
Befehlswirkungen genau der Mangel sind, dessen Wiederholung diese Dokumentation vermeiden
soll.