Using the CLI

Lace ships a single lace binary that answers two questions: what Lace intends across the cluster, and what a node actually programmed. The two live in different places, so the CLI reaches them differently.

Global vs. node state

• Global state is derived from the cluster’s networking resources and answers reachability questions — which Networks and Services a Network can reach, and which pods are bound to it. lace describe computes this against the API server, so you run it from anywhere with a kubeconfig. See Global state.
• Node state is what a node’s data plane holds in its BPF maps — routing, delivery, services, policy, and live connections. It only exists inside each lace-node pod, so you reach it with lace exec. See Node state.

Reaching a node with lace exec

lace exec locates the lace-node pod on a given node and forwards a lace node … command into it, streaming output back and propagating the exit code:

lace exec --node worker-3 -- node bpf show routing

Everything after -- is passed verbatim to the lace binary in the pod. The exec flags go before it:

• --node <name> — the node whose pod to target (required).
• -n, --namespace <ns> — namespace to search for the pod (default: all namespaces).
• -l, --selector <sel> — label selector for the lace-node pod, if you run a non-default install.
• --kubeconfig <path>, --context <name> — pick the cluster and context, like kubectl.

Inside the pod the node name and API server address are already set, so the forwarded command targets that node and resolves IDs to cluster resource names automatically. Flags for the node command (--numeric, --limit, --endpoints, …) go after -- alongside it.