kubefwd
kubefwd copied to clipboard
txn2
Restart forwarding if there are any changes to the pods
Right now, I have to restart the kubefwd process when a new deployment happens or if there are any changes to the pods. It would be good to have this support directly built into kubefwd.
Right now, I have a wrapper script written in Node.js that listens to K8S events and restarts the kubefwd process, which has been working quite well. But it would be good to have this support in the tool directly.
Alternatively, I think this could be achieved by forwarding the port from the service directly instead of the pod, I am not sure if that is a valid possibility. I would love to hear your thoughts and/or assist with the development if you could point me in the right direction.
I noticed that there is code that listens for pod events, but its usage has been commented out, I would like to understand what can be done to revive that.
This is very important to us too. Could you share the script as a workaround @dhruvbaldawa?
@aaad Here you go, you can this script - https://gist.github.com/dhruvbaldawa/5a5f21bc6691d9d8693b59ab28b1d680
Alternatively, I think this could be achieved by forwarding the port from the service directly instead of the pod, I am not sure if that is a valid possibility. I would love to hear your thoughts and/or assist with the development if you could point me in the right direction.
Unfortunately, you can not forward to Services with the Kubernetes API (only Pods). Kubernetes uses socat on the nodes to forward to a container under the hood.
There are a lot of considerations in implementing this feature broadly since there are so many use cases. I, for one, would only want it as a flag. Because if I am developing against a Service, I often monitor the Pods my code is talking to; if they go down, I don't want it to start talking to a new pod automatically. As you see in the code, there were some attempts by others to implement a re-connect. However, it destabilized the app and sometimes caused random re-connects (breaking open database connections, etc). I reverted a lot of that code but some remains.
Other problems arise with race conditions for Pods that do not have startup and readiness probes. For example, the Pod could start and report Ready, but then the forward would fail to connect if the Port was not yet active because the internal workload had not started listening to the Port.
Kubefwd was never intended to be a long-running back-end service. Instead, it's tailored for quickly forwarding a bunch of services your local code needs to talk to while you are developing.
I am not against revisiting this in the future, but for now, I think the wrapper solutions are best because you can easily tailor them to your particular use case. Also... At the moment, limiting features helps keep the code-base manageable for me to maintain. Getting PRs for features is easy, but as soon as there is a bug in those features, it ends up on me.
