Architecture
Local apps enter through sing-box. Only cluster destinations cross the SOCKS bridge into the Gateway.
Traffic path
Apps enter through sing-box and the local SOCKS bridge, then reach the in-cluster Gateway via the Kubernetes API Server port-forward.
- Browsers, IDEs, CLIs, and SDKs — no SOCKS settings per app.
- Split DNS and focused routes for Pod CIDR, Service CIDR, cluster.local, and optional Host Aliases.
- TCP and UDP sessions multiplexed toward the cluster path.
- port-forward only — no NodePort, LoadBalancer, or public ingress.
- Unprivileged dialer into Pods, Services, and CoreDNS.
Feature traffic paths
Every path has three actors — User, KubeLoop, and Kubernetes — with packets animated between them.
User app → KubeLoop localhost → Kubernetes Gateway → Pod / Service.
- User App connects to localhost:<port>
- KubeLoop tunnels the session into Kubernetes
- Gateway dials the target Pod or Service
Kubernetes client → Service → Gateway → KubeLoop → User App. ClusterIP / DNS stay the same.
- Kubernetes client dials the original Service
- Gateway delivers the stream to KubeLoop
- KubeLoop hands traffic to the User App
Kubernetes request enters KubeLoop, then forks: primary back to the original Pod; shadow copy to the User App.
- Kubernetes traffic reaches KubeLoop via Gateway
- Primary path returns to the original Pod in Kubernetes
- Shadow copy goes to the User App; replies are discarded
Kubernetes client → temporary Preview Service → Gateway → KubeLoop → User App.
- KubeLoop creates a temporary Service in Kubernetes
- Kubernetes client dials the Preview Service
- KubeLoop delivers the stream to the User App