Support port-mapping when forwarding

[adamrodger]

With a manual kubectl port forward you can map a local port to a different service port, like this:

kubectl port-forward svc/my-service 8080:80

It would be great if kubefwd could support this also but I can't see a current option to do that. I frequently need to forward to pods on port 80 but also have something running locally on port 80 (e.g. running a web UI locally but forwarding to APIs on a cluster).

I don't think we need per-service mapping rules or anything, just a blanket "any service found using port X will be forwarded from local port Y", like:

kubefwd svc -n my-namespace -p 1234:80

Unfortunately I don't know Go otherwise I'd try and implement that myself.

[cjimti]

I am not completely against the idea however it does go against kubefwd central use case, to expose services as they are in the cluster.

kubefwd does set up many forwards to the same port, like web-site1:80, web-site2:80, it does this by using multiple loopback IPs. The problem is that a local service you are running on port 80 is likely bound to all loopback IPs (eg 0.0.0.0). Can you specify an interface for your local service such as 127.0.0.1:80? most applications allow you to do this.

[adamrodger]

One of the key things that ends up listening on port 80 on my work laptop is [BranchCache](https://docs.microsoft.com/en-us/windows-server/networking/branchcache/branchcache) which I can't change due to Group Policy. You're right that it must listen on all interfaces, but I can't change that. Given that Kubernetes is something that most people will be using in their work life rather than their personal life, and many people are using Windows with these sorts of Enterprise features, I imagine a number of people have the same problem. I think the default should obviously stay with the current behaviour of reusing the service ports, but having the option of remapping would solve those problems.

[cjimti]

I am not opposed to your feature request, however, I think it could cause confusion if not implemented clearly, kubfwd is not meant to be a kubectl replacement. kubectl port-forward does exactly what you need.

Many people use kubefwd in an enterprise environment right now. I am curious about how many people have port 80 bound on their workstation.

You might want to try using the Docker container, I know a few people who use it in environments where they don't have superuser access (low ports, etc)...

As for implementation... maybe forwarding maps like -m 8080:80 (meaning any 80 maps to 8080).

kubefwd svc -n proj1 -m 81:80 -m 3307:3306 -m 5601:5600"

BTW there are plenty of enterprises that don't make things like this a PIA for their developers. :)

[adamrodger]

Ha, yeah tell me about it 😂 It would be nice if the port mapping was the same way round as kubectl just to aid usability, so local:remote instead of remote:local. If the same flag could be used as well (-p) then even better. I much prefer kubefwd to managing my own kubectl for quite a few reasons (automatic hosts changing, automatically re-establishing connections, a single command/shell to manage) because it's a really great tool. This one final feature would make it absolutely perfect for my use case.

[cjimti]

@adamrodger you are correct regarding the order. I fixed my comment. Not sure how soon I'll be able to work on this but I see now how it could be helpful in situations like yours.

[adamrodger]

Thanks very much. I'll look forward to it.

[dobesv]

You can add another port on the service for port 8080 that uses the same target port on the pod. It seems a bit hackish but it's not too bad and it gets the job done. Or even add another entire service for this purpose if need be.

[adamrodger]

I think I'd prefer specifying the -p flag multiple times instead of a comma separated string with a special format. That matches general CLI conventions. So like: kubefwd svc -p 80:8080 -p 443:1443

…

On Sat, 6 Mar 2021, 03:40 ndj888, ***@***.***> wrote: Add port forwarding batch mapping. ex: kubefwd svc -n the-project -p "8080:80,3309:3306" kubefwd svc -n the-project -p "8080:80" — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#121 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD4FKX5DQZGNX5DODGKZ4LTCGP4TANCNFSM4NFYJ4FQ> .

[cjimti]

I am thinking that "p" might not be a great choice, maybe "m" or something like that. I don't fully understand the use-case since kubefwd uses separate IP addresses for each service. With docker or kubectl it makes sense that you need to specify a local port, especially for low ports like 80 and 443 or forwarding multiple services with the same port.

kubefwd aims to replicate the services as they are in the cluster for development purposes so xdb.accounting:3306 is the same on the cluster as it is local. I don't want to confuse users in thinking they need to (or even should) use this mapping like you would need to use -p for docker or kubectl.

I understand there is a use case where you have some software that listens on all interfaces, such as 0.0.0.0:3306 and is unable to be configured to use 127.0.0.1:3306 but this should be rare. My own team gets tripped up from time to time with local Docker runs, forgetting to specify a local IP docker run -p 8080:8080, and not docker run -p 127.0.0.1:8080:8080

I am ok with the new functionality if we using something other than -p, since port forwarding the service specified port is the implicit feature of kubefwd.

also agree with @adamrodger I think it should be something like kubefwd svc -m 80:8080 -m 443:1443.

[ndj888]

I am thinking that "p" might not be a great choice, maybe "m" or something like that. I don't fully understand the use-case since kubefwd uses separate IP addresses for each service. With docker or kubectl it makes sense that you need to specify a local port, especially for low ports like 80 and 443 or forwarding multiple services with the same port.

kubefwd aims to replicate the services as they are in the cluster for development purposes so xdb.accounting:3306 is the same on the cluster as it is local. I don't want to confuse users in thinking they need to (or even should) use this mapping like you would need to use -p for docker or kubectl.

I understand there is a use case where you have some software that listens on all interfaces, such as 0.0.0.0:3306 and is unable to be configured to use 127.0.0.1:3306 but this should be rare. My own team gets tripped up from time to time with local Docker runs, forgetting to specify a local IP docker run -p 8080:8080, and not docker run -p 127.0.0.1:8080:8080

I am ok with the new functionality if we using something other than -p, since port forwarding the service specified port is the implicit feature of kubefwd.

also agree with @adamrodger I think it should be something like kubefwd svc -m 80:8080 -m 443:1443.

That's a good suggestion. To this end I submitted a new pull request.

[cjimti]

@ndj888 thanks for work on this. see https://github.com/txn2/kubefwd/releases/tag/1.18.0