In a micro-service architecture, with a lot of small services listening on the same port number, port forwarding to a globally unique IP (like that of minikube) causes collisions.
I'd like to be able to opt out of port-forwarding in skaffold.yaml. Right now I cannot (that I've found)
Furthermore, and out of scope for this issue; it would be more sane for us to port-forward to service as per #1245 (support svc port forwarding) instead of deployments/pods.
There are warnings about conflicting ports.
@haf you can use skaffold dev --port-forward=false or SKAFFOLD_PORT_FORWARD=false skaffold dev
@haf Thanks, I worked around this lacking feature with that flag, in fact. However, we want 'happy path' via skaffold dev without flags, so it's still a relevant feature IMO.
we could add a field to the skaffold global config to control port forwarding on a per-context or global basis. see https://github.com/GoogleContainerTools/skaffold/pull/1355
skaffold config set port-forward false or skaffold config set port-forward false --global
@nkubala I don't think that addresses the 'happy path' behavior as @haf suggested. Another option would be to disable port-forwarding by default and make it an opt-in feature instead of an opt-out feature.
Was there a particular reason to enable it by default?
@nkubala Does that command change skaffold.yaml? Otherwise, it's not what I'm asking.
Also, would it not be more user-friendly to port-forward service ports based on an annotation that opts in? That way I don't have to override # replicas with helm templating and can use the same k8s manifests for local dev machines and the staging environment. /cc @corneliusweig
@haf That command would change your global ~/.skaffold/config file.
I don't think port-forwarding of services instead of pods is better per-se. It depends on what one actually tries to debug. I don't like your suggested marker annotations, though. It's too complicated and it would leak tooling annotations into your business code. There has to be a better way.
In my opinion, a feature that opens a bunch of ports in a surprising way should be explicitly opted in. Here are two examples what happened in our team already:
A local service (webpack dev server) on port 8080 was functional / bound depending on the startup order of skaffold dev and webpack.
A second k8s service with same port 8080 was introduced in the dev setup masking the port forwarding of the first one.
My ideas go into the following direction:
Disable port forwarding by default. Enabling port forwarding yields current default behavior. In addition, a port forwarding section allows specifying service:port -> local port mappings that are active when using skaffold dev (Maybe requiring the port forward flag as well?)
With this, the following scenarios are covered:
related to #1245
@martinhoefling I'm not so sure that a configuration for port forwarding is viable. After all, the skaffold pipeline config defines artifacts which may have many replicas. IMHO port assignment should happen automatically.
However, I'm all for disabling the surprising port forwarding by default. I also like the idea to forward services, because it opens other possibilities for debugging. Maybe we could change the semantics of the port-forwarding flag to:
--port-forward=pods: current behavior of forwarding all pod ports--port-forward=services: forward all services (new)--port-forward=true/false: support this to transition away from the current semantics--port-forward=pods,servicesHey @haf as of #2115 port forwarding is off by default. Additionally, skaffold will automatically port forward services instead of pods for skaffold dev (#2215) and additional resources for port forwarding can be specified in the skaffold config (#1311). These changes should be available in the next release, so I'm going to go ahead and close this issue. Please comment or reopen if you need!
Most helpful comment
@nkubala I don't think that addresses the 'happy path' behavior as @haf suggested. Another option would be to disable port-forwarding by default and make it an opt-in feature instead of an opt-out feature.
Was there a particular reason to enable it by default?