@kubernetes/sig-cli-misc

The CLI part of the proposal looks fine to me, being concise with kubectl proxy. Adding @kubernetes/sig-api-machinery-misc for the client-go bits.

/sig cli
/sig api-machinery

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

Hi,
I'd be pretty interested in this feature. Is someone currently working on it? @goblain's explanations are spot-on and I could apply them if noone else feels like it.

#46517 has implementation (needs a rebase after all that time) but it was put on hold due to feedback from @smarterclayton . No idea if the blocking work was completed so awaiting for confirmation before I invest time in the rebase/refactor.

I have no idea how I missed that PR, I'll follow that.

Thanks for the work too, it would really be a nice feature to have!

@goblain The work has been completed:
#33684

And implemented in the java client at least:
kubernetes-client/java#91

Its frustrating that this very reasonable change was blocked because "other stuff is happening" - other stuff is always happening, and not being able to control the binding address is ridiculous.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

/remove-lifecycle stale

+1

well, I've stopped rebasing the #46517 pull request cause it seems there is no will to merge it in foreseeable future.

@goblain are you planning to keep pushing for this to get merged ? I think this is still needed. Just ran into that issue.

the decision to go with this is way above me, so I am unable to influence this further. Seems like there simply is no will to merge this into upstream in near future

+1 here too

Has anyone worked out a reliable workaround in the meantime?

+1. Till this is implemented or merged, ssh tunneling can be used on a (yet another) separate terminal (assuming port 8000 is not used on any interface on the host and assuming kubectl port-forward a-pod 8888:8080 executed before):
sudo ssh -N -L 0.0.0.0:8000:localhost:8888 userID@host

and then go to your web-browser and type: http://host:8000

+1 need this feature as well.

+1 need the feature ASAP

Was able to create a workaround as mentioned by @Baykonur .

Follow the below to work with the actual port itself instead of another temporary one.

kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath='{.items[0].metadata.name}') 3002:3000 &

ssh -N -L 0.0.0.0:3000:localhost:3002 userID@host

I ran into this issue myself today. Made me very sad sniffle. Especially considering kubectl proxy has all the bells and whistles already :(

      --accept-hosts='^localhost$,^127\.0\.0\.1$,^\[::1\]$': Regular expression for hosts that the proxy should accept.
      --address='127.0.0.1': The IP address on which to serve on.

To workaround this feature not yet being implemented/merged... you can port-forward your already port-forwarded port using socat in another terminal...

socat tcp-listen:9222,fork tcp:127.0.0.1:9223

^ where e.g.

• 127.0.0.1:9223 is the interface:port kubectl port-forward opened locally
• and 9222 is the port you want to open on all interfaces (0.0.0.0)

I ran into this, too. kube-proxy does the right thing, why not kube-port-forward?
My use case is "I run a linux VM where I run all the kubectl commands (affecting a cluster hosted in AWS,) and the VM lives inside a Windows host where I run my web browser."
When I want to spin up a new pod in the cluster, and test it out locally without exposing a service to other pods, nor a public address on the cluster, not being able to bind to 0.0.0.0 on my VM is highly inconvenient!

Another slight variation on the work-arounds described above using ssh tunnels.

In my case, I'm running minikube with an http web service deployed on NodePort 30003.
I can make it accessible externally on port 80 by running:

sudo ssh -v -i ~/.ssh/id_rsa -N -L 0.0.0.0:80:localhost:30003 ${USER}@$(hostname)

Looks like there is finally some progress on #46517 again, thanks @goblain for all your efforts.