Customer Edge 진단

Customer Edge(CE)는 이 리포지토리가 Azure에 프로비저닝하는 F5 Distributed Cloud 노드입니다 — terraform/modules/ce-node, volterraedgeservices/volterra-node 마켓플레이스 이미지로 빌드됩니다.

이 노드는 데이터 플레인(Argo), 컨트롤 플레인(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.

디버그 API는 F5 Distributed Cloud 컨트롤 플레인을 통해 노드에 도달합니다. 이것이 바로 이 구분이 중요한 이유입니다. API는 노드가 등록을 완료하고 ONLINE을 보고한 이후에만 응답할 수 있습니다.

등록에 실패한 노드 — 잘못된 cloud-init, 만료된 토큰, register.ves.volterra.io로의 경로 없음 — 는 바로 진단이 필요한 경우이면서, 바로 API가 처리할 수 없는 경우입니다.

Site Console은 특정 명령이 아니라 F5 자체의 트러블슈팅 UI를 원할 때 가장 먼저 시도해볼 경로입니다. 요구 사항이 가장 적습니다 — 키도, 점프 호스트도, 노드의 공용 IP도 필요 없습니다 — 누가 연결할 수 있는지가 Azure RBAC 결정이 되기 때문이며, 사이트가 등록되었는지 여부와 관계없이 응답합니다. Azure Bastion이 필요하며, 이 배포에서는 enable_bastion으로 게이트되어 있고 기본적으로 배포되지 않습니다.

SSH는 어플라이언스의 전체 명령 영역에 도달하는 유일한 경로입니다 — 디버그 API는 34개 명령을 노출하지만 노드 자체는 훨씬 더 많은 명령을 제공합니다. 두 가지가 이를 제약합니다. sshd는 노드의 내부(SLI) 주소에서만 응답하므로 VNet 내부의 호스트가 필요합니다. 그리고 키는 첫 부팅 시 cloud-init에 의해 기록되는데, 사이트 객체의 ssh_key 필드는 작동하지 않기 때문입니다 — vpm은 admin 사용자를 건너뛰고 이를 적용하지 않습니다. 따라서 실행 중인 노드에서 이를 활성화하려면 노드를 교체해야 합니다.

정리하면: 사이트가 ONLINE이고 34개 명령으로 충분하다면 디버그 API를 사용하십시오. UI가 필요하거나, 등록되지 않았지만 네트워크 경로는 있는 노드라면 Site Console을 사용하십시오. 나머지 명령 영역이 필요하고 VNet에 도달할 수 있다면 SSH를 사용하십시오. 노드에 작동하는 네트워크 경로가 전혀 없다면 시리얼 콘솔이 유일한 진입 방법입니다.

한 번의 요청으로 어떤 경로에 있는지 알 수 있습니다:

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

ONLINE이면 디버그 API가 작동합니다. 그 외의 값이면 Site 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는 라이브 데이터 플레인 아래에서 컨테이너 런타임을 재시작합니다.
질문에 답하는 가장 좁은 범위의 명령을 선택하십시오. health와 diagnosis는 노드를 저렴하게 요약합니다. flow-l은 모든 라이브 플로우를 덤프하고, flow-l-match는 하나의 연결에 대해 동일한 질문에 답합니다.
CE는 라이브 트래픽을 처리합니다. 이들은 공유 데모 환경입니다. 디버깅 중인 사이트에서 누군가 발표하고 있다고 가정하십시오.

여기에 문서화된 내용

이 테넌트가 실행하는 소프트웨어 빌드에서 디버그 API를 통해 접근할 수 있는 모든 명령이며, 각각의 출력은 다른 곳에서 전사한 것이 아니라 라이브 노드에서 캡처한 것입니다.

명령 참조는 모든 명령을 카테고리, 권한 계층 및 전송 방식과 함께 나열합니다. 워크플로는 문제가 발생했을 때 실제로 사용하는 순서로 이들을 연결합니다.

Site CLI의 온박스 전용 부분 — configure, configure-network, factory-reset, upgrade 및 약 60여 개의 추가 ExecCLI 명령 — 은 다루지 않습니다. 아래 모든 페이지와 달리 그 출력이 라이브 노드에서 캡처되지 않았기 때문입니다.

그러나 더 이상 손에 닿지 않는 것은 아닙니다. scripts/sitecli_ssh_harvest.py는 SSH를 통해 어플라이언스 자체의 자동 완성 메뉴를 구동하고 어플라이언스가 각 명령에 대해 제공하는 설명을 기록하므로, 그 영역을 추측하는 대신 측정할 수 있습니다. 실행은 기본적으로 거부됩니다 — 모든 것을 열거하되 허용 목록에 있는 것만 실행합니다 — 검증되지 않은 명령 구문과 검증되지 않은 명령 효과가 바로 이 문서가 반복을 피하기 위해 존재하는 결함이기 때문입니다.