Different service target port

[vbehar]

Hi,

the current behaviour when "duplicating" services is to use the canary.Spec.Service.Port for both the service port and the target port.

In all our apps we currently configure our services on port 80, and on container ports on something else (like 8080 for example).

I'd like to create a PR to allow a TargetPort in the canary spec, but before I wanted to check with you if there is a reason for using the same port for both the service and the container.

thanks

[stefanprodan]

The reason is simplicity. Flagger also does port discovery and maps all container ports in the ClusterIP service. I'm ok with adding service.targetPort as an optional field but please make sure this change doesn't break AppMesh, Linkerd and all the other integrations.

[vbehar]

ok, thanks

[nil-scan]

We also need this and I'd be happy to help testing the AppMesh side of things

[hollinwilkins]

Happy to test out with Linkerd here

[stefanprodan]

I've implemented this in #327 and added e2e tests for Istio, Linkerd, Gloo, NGINX and Kubernetes CNI.

I'm pretty confident using target port breaks App Mesh due to virtual nodes and virtual routers

To test this use weaveworks/flagger:target-port-2e79817 image and apply the CRD with:

kubectl apply -f https://raw.githubusercontent.com/weaveworks/flagger/target-port/kustomize/base/flagger/crd.yaml

[vbehar]

great, thanks @stefanprodan!