Support for TCP Canary Deployments

[swys]

Describe the feature

Would be great if Flagger was able to support Canary deployments for TCP services too!

I found this comment buried inside of an issue: #1021 (comment)

It was not clear to me from reading any of the documentation that Flagger doesn't currently support Canary deployments for TCP services (maybe I missed it somewhere though. If it is stated clearly I would love if someone could provide a link since I was unable to find any information other than the issue that I linked above).

What problem are you trying to solve?

My company has the need to perform automated Canary deployments for both HTTP and TCP based services. I have been using Flagger to perform Canaries on HTTP services and it works very well! But I wasn't able to get it working for TCP services. I tried a few different meshProvider configs in Flagger (and setup those different providers. Appmesh/Nginx Ingress Controller/Istio) but was never able to get TCP services to work and I did not realize that Flagger itself doesn't support TCP services.

My latest testing was with Istio and I found that Flagger only operates on the http key in the virtualService document. And checking through the istio related Flagger code I saw only references to istiov1alpha3.HTTP* istio APIs. No references any TCP related istio apis. So when Flagger deployed the virtualService doc it would always include the http key when I needed the tcp key config to be setup for routing to work on a TCP based service.

Proposed solution

I don't have a specific solution other than to ask that for the meshProviders that do support TCP services (for example, Nginx Ingress Controller itself doesn't support Canary for TCP services, only HTTP so that would not work) could be enabled.

It seems like it is not that far from working with TCP, at least for istio (and from my basic understanding of what it is doing). I did some minor testing where I updated the virtualService document that Flagger created and I removed the http key section and added the needed tcp section and immediately after this update, routing started working. So it seems, if Flagger would be able to manage the tcp section too it would be able to adjust the weights and progress the Canary along the same way it handles the http section.

What do you want to happen? Add any considered drawbacks.

I am not sure what the reasoning was behind Flagger not supporting non HTTP Canary deployments. Not sure if that was done on purpose to avoid any specific issues. Since not every meshProvider that is supported by Flagger supports TCP services, maybe that was the reason?

Any alternatives you've considered?

I am currently looking for another solution but none are that appealing to me.
I found that spinnaker has some support: https://spinnaker.io/docs/setup/other_config/canary/ just not sure if it supports both HTTP and TCP services. And to be honest, not to excited about setting up spinnaker just to support Canaries for TCP services.

I really like the way Flagger allows for such a nice and clean Canary setup. So far I have not found a good alternative, which is why I am wondering if this is something the Flagger maintainers would consider supporting.

Is there another way to solve this problem that isn't as good a solution?

Manually deploy the virtualService doc and adjust the weights in the tcp section, the same way Flagger does for http section. Would still need an automated way to analyze the metrics like Flagger does though.

[kubroid]

PR #1564