ork proxy

Forward ports for deployed Orkestra components to localhost.

ork proxy
ork proxy --for cc
ork proxy --for runtime,cc
ork proxy -n my-platform-ns

Inspired by kubectl proxy, ork proxy replaces manual kubectl port-forward invocations when working with a Helm-deployed Orkestra. It discovers each component by its orkestra.orkspace.io/komponent label, resolves the right pod, and keeps all forwards alive with automatic reconnection. For the Runtime, it resolves the elected leader via the orkestra-konductor Lease so requests always reach the pod with authoritative state.

Flags

Component names (--for)

Examples

# Forward all three components
ork proxy

# Control Center only
ork proxy --for cc

# Runtime and Control Center, custom namespace
ork proxy --for runtime,cc -n my-platform-ns

# Use a non-default port for Runtime (e.g. avoid conflict)
ork proxy --runtime-port 9090

# Forward against a specific kubeconfig context
ork proxy --context staging-context

What it does

1. Reads the active kubeconfig (respecting --kubeconfig and --context)
2. Discovers each selected component’s Service by the orkestra.orkspace.io/komponent label
3. For Runtime: reads the orkestra-konductor Lease to resolve the elected leader pod
4. For CC and Gateway: selects a running pod from the Service’s selector
5. Pre-checks that each local port is free — errors before opening any tunnel
6. Opens a SPDY port-forward per component and prints the local URL
7. Watches each forwarded pod independently — when a pod disappears, reconnection starts immediately without waiting for traffic to surface the broken tunnel
8. For Runtime: probes /health after the tunnel is established to confirm the new leader is serving before declaring connected (guards against the Lease transition window)
9. Exits cleanly on Ctrl+C, or automatically if no selected components are deployed

Notes

• ork proxy requires a Helm-deployed Orkestra. For local development use ork run directly.
• The Runtime forward always targets the leader pod, not a random replica. This matters when inspecting live reconciler state or the /katalog API.
• Port conflicts are reported before any tunnel opens — use --runtime-port, --cc-port, or --gateway-port to remap.
• The Gateway forward uses plain HTTP on the local side; TLS is handled inside the cluster by the Gateway itself.