Networking CLI
Reference for `rune get ingress`, `rune get netpolicy`, and `rune get network` — the CLI surface for the networking layer.
This page is the operator reference for the networking-layer CLI. It covers what each command does, the flags it accepts, and the JSON shape it emits when you ask for -o json.
For the conceptual picture, see Concepts: Networking. For task-oriented walkthroughs, see Expose a service and Write a network policy.
Ingress
Inspect ingress + TLS certificate state. Read-only — these commands never mutate cluster state.
rune get ingresses
List every service whose spec.expose.host is set, with its TLS mode, certificate state, and time-to-expiry.
rune get ingresses [-n <namespace>] [-A] [-o table|json|yaml]
| Flag | Description |
|---|---|
-n, --namespace | Restrict to one namespace. Defaults to the context's default namespace. |
-A, --all | List across all namespaces. |
-o, --output | table (default), json, or yaml. |
Sample output:
NAMESPACE SERVICE HOST TLS CERT EXPIRES
default api api.example.com acme ready 89d
default admin admin.example.io manual ready 12d
jobs worker jobs.example.com acme pending -
Sort order is stable: namespace, then host, then service. Diff-friendly across runs.
The JSON form returns one object per row:
[
{
"namespace": "default",
"service": "api",
"host": "api.example.com",
"path": "",
"port": "http",
"tlsMode": "acme",
"cert": {
"state": "ready",
"host": "api.example.com",
"issuedAt": "2026-02-08T14:21:00Z",
"expiresAt": "2026-05-09T14:21:00Z"
}
}
]
rune get ingress <service>
Show the full IngressCertStatus for one service.
rune get ingress <service> [-n <namespace>] [-o table|json|yaml]
$ rune get ingress api -n default
service: default/api
host: api.example.com
port: http
tls mode: acme
cert:
state: ready
host: api.example.com
issued: 2026-02-08T14:21:00Z
expires: 2026-05-09T14:21:00Z (in 89d)
When a request is failing, Last error and Next retry populate. The orchestrator retries with exponential backoff; existing certificates keep serving traffic during the retry loop.
Network policy
Inspect compiled ServiceNetworkPolicy rules attached to a service. Read-only.
rune get netpolicy <service>
Render the compiled rule table for a service the way the in-process evaluator sees it.
rune get netpolicy <service> [-n <namespace>] [-o table|json|yaml]
$ rune get netpolicy api -n default
service: default/api
policy: default/api
default-deny ingress=true egress=false
ingress rules:
[0] peers=[service=default/web service=jobs/worker cidr=10.0.0.0/8] ports=[http]
service ... no policy (open) means the service has no networkPolicy block yet. As soon as one is present, the relevant direction flips to default-deny. See default-deny semantics.
Validating a policy file
Use rune lint to compile-check a service YAML/JSON document — CIDR parsing, port format, and peer validation — without talking to the server. Run it in CI on every PR to catch typos before they land in the store.
rune lint api.service.yaml
Cluster network state
Read-only view of cluster-level networking state.
rune get network
Show the bootstrapped cluster CIDR, capacity, and current VIP allocation.
$ rune get network
CIDR: 10.96.0.0/16
Capacity: 65533 usable IPs
Allocated: 12
Free list size: 3
Pending releases: 0 (cooldown)
| Field | Meaning |
|---|---|
| CIDR | The bootstrapped cluster CIDR (set once at first start, immutable thereafter). |
| Capacity | Total usable /32s in the CIDR (excluding network + broadcast). |
| Allocated | VIPs currently assigned to services. |
| Free list size | Released VIPs available for immediate reuse. |
| Pending releases | VIPs in cooldown after a service deletion (prevents stale-DNS-answer bugs). |
If Allocated + Pending releases approaches Capacity, you're running out of VIPs — bump the CIDR (requires re-bootstrapping a new cluster) or audit deleted services that haven't released yet.
Common workflows
"Did my certificate just renew?"
watch rune get ingresses
State will move pending → ready and the expiry counter will jump to in 89d.
"Why can't service A reach service B?"
rune get netpolicy B -n <ns>
# look for service A in the ALLOW list; if missing, write a policy
Cross-reference with rune_policy_drops_total{service="B",reason=...} on /metrics to confirm packets are being dropped (and why).
"Am I about to run out of VIPs?"
rune get network
Or alert on the Prometheus gauge:
rune_vip_allocated / rune_vip_capacity > 0.9
What's not here yet
A few commands are designed but deferred to follow-up tickets:
rune trace network <service>— packet-path tracer from the proxy down through nftables. Needs a server-side gRPC endpoint.rune get endpoints <service>— read back the OrderedLogendpoints/keyspace as resolved by the agent. Needs the watch service to expose it.
Both are tracked and will land before Phase 2.