Aller au contenu

Diagnostics Customer Edge

Un Customer Edge (CE) est le nœud F5 Distributed Cloud que ce dépôt provisionne dans Azure — terraform/modules/ce-node, construit à partir de l’image de place de marché volterraedgeservices/volterra-node.

Il exécute le plan de données (Argo), le plan de contrôle (Vega), un proxy Envoy, une pile Kubernetes et vpm, l’agent qui enregistre le nœud et gère tout le reste sur celui-ci.

Lorsqu’un CE dysfonctionne, la Site CLI est l’instrument à utiliser. La première décision consiste à déterminer quel chemin d’accès s’applique, et se tromper fait perdre du temps d’une manière qui donne l’impression d’un nœud défaillant.

Quatre chemins d’accès, et ils ne sont pas interchangeables

Section intitulée « Quatre chemins d’accès, et ils ne sont pas interchangeables »

La debug API atteint le nœud via le plan de contrôle F5 Distributed Cloud. C’est toute la raison pour laquelle cette distinction importe : l’API ne peut répondre qu’une fois le nœud enregistré et signalé ONLINE.

Un nœud qui n’a pas réussi à s’enregistrer — cloud-init incorrect, jeton expiré, absence de route vers register.ves.volterra.io — correspond précisément au cas où vous avez besoin de diagnostics, et précisément au cas que l’API ne peut pas traiter.

Site Console est l’option à essayer en premier lorsque vous souhaitez l’interface de dépannage propre à F5 plutôt que des commandes spécifiques. C’est celle qui exige le moins de vous — aucune clé, aucun hôte de rebond, aucune IP publique sur le nœud — car la question de savoir qui peut se connecter devient une décision Azure RBAC, et elle répond que le site soit enregistré ou non. Elle nécessite Azure Bastion, que ce déploiement conditionne à enable_bastion et qui n’est pas déployé par défaut.

SSH est la seule voie qui atteint la totalité de la surface de commandes de l’appliance — la debug API expose 34 commandes et le nœud lui-même en offre bien davantage. Deux éléments la contraignent. sshd ne répond que sur l’adresse interne (SLI) du nœud, il faut donc un hôte au sein du VNet ; et la clé est écrite par cloud-init au premier démarrage, car le champ ssh_key de l’objet site est inerte — vpm ignore l’utilisateur admin et ne l’applique jamais. L’activer sur des nœuds en fonctionnement implique donc de les remplacer.

Donc : si le site est ONLINE et que 34 commandes suffisent, utilisez la debug API. Pour une interface, ou pour un nœud qui ne s’est jamais enregistré mais qui conserve un chemin réseau, utilisez Site Console. Si vous avez besoin du reste de la surface de commandes et que vous pouvez atteindre le VNet, utilisez SSH. Si le nœud n’a aucun chemin réseau fonctionnel, la console série est la seule entrée possible.

Elles s’appliquent à toutes les commandes de chacune des pages ci-dessous.

  • Lecture seule sauf si vous êtes certain. La surface de commandes est répartie en deux niveaux de privilèges, et le niveau Exec modifie le nœud ou lit un marqueur d’état. Rien sur ces pages n’exécute une commande Exec, et le harnais de capture n’en exécute pas davantage.
  • Ne présumez jamais qu’une commande est sûre d’après son nom. ip-link-set se lit comme une requête et désactive une interface. systemctl-restart-crio redémarre le runtime de conteneurs sous un plan de données actif.
  • Préférez la commande la plus restreinte qui réponde à la question. health et diagnosis résument le nœud à faible coût ; flow-l vide tous les flux actifs, et flow-l-match répond à la même question pour une seule connexion.
  • Un CE sert du trafic réel. Il s’agit d’environnements de démonstration partagés. Supposez que quelqu’un est en train de présenter depuis le site que vous déboguez.

Toutes les commandes accessibles via la debug API sur la version logicielle utilisée par ce tenant, chacune accompagnée d’une sortie capturée sur un nœud réel plutôt que transcrite d’ailleurs.

La référence des commandes les répertorie toutes avec leur catégorie, leur niveau de privilèges et leur transport ; les workflows les enchaînent dans les séquences que vous utilisez réellement lorsque quelque chose ne va pas.

Les parties de la Site CLI accessibles uniquement sur la machine — configure, configure-network, factory-reset, upgrade et environ soixante autres commandes ExecCLI — ne sont pas couvertes, car leur sortie n’a pas été capturée depuis un nœud réel comme l’a été celle de chaque page ci-dessous.

Elles ne sont toutefois plus hors de portée. scripts/sitecli_ssh_harvest.py pilote le menu de complétion de l’appliance via SSH et enregistre la description que l’appliance fournit pour chaque commande, de sorte que la surface peut être mesurée plutôt que devinée. Son exécution est refusée par défaut — elle énumère tout et n’exécute qu’une liste d’autorisation — car une syntaxe de commande non vérifiée, et des effets de commande non vérifiés, constituent le défaut que cette documentation existe pour éviter de reproduire.