All posts

Running Mosh with Kubernetes Ingress: Avoiding the UDP Pitfalls

Ingress resources are the gatekeepers of modern Kubernetes traffic management. Mosh, with its persistent SSH-like connection over UDP, doesn’t play by HTTP’s rules. That difference matters. Most Ingress controllers are built with HTTP and TLS termination in mind. Mosh asks for raw UDP traffic to flow directly, without translation or protocol meddling. If that isn’t configured right, your connection dies before the first keystroke lands. The key is understanding how Kubernetes Ingress resources

Free White Paper

Kubernetes RBAC: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

Ingress resources are the gatekeepers of modern Kubernetes traffic management. Mosh, with its persistent SSH-like connection over UDP, doesn’t play by HTTP’s rules. That difference matters. Most Ingress controllers are built with HTTP and TLS termination in mind. Mosh asks for raw UDP traffic to flow directly, without translation or protocol meddling. If that isn’t configured right, your connection dies before the first keystroke lands.

The key is understanding how Kubernetes Ingress resources interact with Services and how these layers handle TCP versus UDP. By default, an Ingress doesn’t handle UDP at all. For Mosh to work, you either bypass HTTP-oriented Ingress rules or use an Ingress controller that supports UDP load balancing. NGINX Ingress, for example, requires extra ConfigMap entries and a separate UDP service mapping. Other controllers solve it differently, but the concept is the same: Ingress won’t magically pass UDP unless you make it.

Another common trap is port allocation. Mosh works across a range of UDP ports, usually 60000–61000. Cluster firewalls, cloud security groups, and node-level rules all have to allow that range. Miss one layer and you’ll be staring at a frozen terminal wondering why packets vanish mid-stream. The simplest approach is to explicitly define a Service in Kubernetes that maps the Mosh UDP range, then point your Ingress or load balancer to it.

Continue reading? Get the full guide.

Kubernetes RBAC: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Scaling Mosh sessions through Ingress introduces another dimension. Persistent connections and roaming clients mean you need stable session affinity if traffic passes through multiple nodes. Without sticky sessions or UDP-aware routing, Mosh will reset when clients jump IPs or pods shuffle. Your design must prioritize that continuity.

Logs matter too. Mosh doesn’t log like HTTP apps, so Ingress logs won’t tell you much. Use packet capture, node-level logging, and Kubernetes event checks to verify connectivity. You’ll move faster when you see exactly where the UDP packets go.

If you configure it right, you can run Mosh seamlessly with Kubernetes Ingress resources without killing the low-latency, roaming-friendly magic that makes Mosh worth using. Done wrong, it silently breaks. The difference is a few clear configuration steps and a willingness to understand what’s happening between your client and pod.

You can set this up from scratch, but you don’t have to. With hoop.dev, you can watch it work live in minutes—without hand-rolling every config file yourself.

Get started

See hoop.dev in action

One gateway for every database, container, and AI agent. Deploy in minutes.

Get a demoMore posts