Kubernetes operator for rstream tunnels
rstream now has a Kubernetes operator for managing tunnels from cluster-native resources.
The operator introduces two custom resources. RstreamConnection describes how a namespace reaches rstream, usually by project endpoint so the operator can resolve the current engine through the Control plane. RstreamTunnel describes how a Kubernetes Service should be exposed, including protocol, Service port, publishing mode, HTTP settings, labels, and access policy.
This is useful when tunnel configuration should follow the same lifecycle as Deployments and Services. A preview environment can expose its HTTP Service as soon as the namespace is applied. An internal admin tool can keep a stable rstream address without an Ingress controller or inbound firewall rule. Homelab, field-device, embedded, robotics, and drone deployments can publish outbound-only services even when they sit behind NAT, cellular networks, or customer firewalls. A platform team can give application teams a small Kubernetes API while keeping the tunnel agent, RBAC, credentials, status, and runtime behavior standardized.
The operator creates a dedicated agent Deployment per tunnel. The manager reconciles Kubernetes resources and validates references; the agent opens the outbound rstream connection, forwards traffic to the Service, and writes readiness plus the forwarding address back to RstreamTunnel.status.
Self-hosted deployments are supported too. Hosted users normally set projectEndpoint and let the Control plane resolve the engine. Self-hosted users can set engine directly when no Control plane or project model exists.
For setup details, see Kubernetes Operator, Declarative Tunnels, and the step-by-step guide Expose a k3s Service with the rstream Kubernetes Operator.