I’ve been building a native macOS Kubernetes desktop app, and one of the more surprisingly annoying parts was port-forwarding.
I originally thought it would be a small feature: open a local TCP socket, connect it to a pod, and pipe bytes in both directions. But that only covers the happy path.
I tried a few approaches first: shelling out to kubectl, wrapping higher-level client behavior, and treating port-forwarding as a simple local socket proxy. They all worked to some degree, but none of them felt like the right long-term abstraction once I needed many concurrent forwards, cancellation, reconnects, useful errors, proxies, and lifecycle management.
Under the hood, Kubernetes port-forward still uses upgraded SPDY-style streams with separate data and error channels. Once you own that protocol path directly, you have to deal with stream multiplexing, half-closed connections, cancellation, reconnect behavior, and the small edge cases kubectl usually hides.
So I ended up implementing the Kubernetes SPDY port-forward path directly in Rust. It was more work upfront, but it gives Krust much better control over state, UX, and integration with the native Swift/AppKit UI.
I’d be curious to hear from others building Kubernetes tooling: did you wrap kubectl, use client-go, or own the port-forward path directly? Are there trade-offs I’m missing?