Canary on VirtualService with TCP breaks with deserialization error

[cinash]

Describe the bug

I have a legacy application that responds on a TCP port (with some custom serialization). I would like to create a canary that would be analyzed either by custom application metrics or by a webhook.

Problem is that if I define the VirtualService with a TCP route it breaks with deserialization error, because in Istio VirtualService TCP routes are a list, while in flagger it's a single element.

On the other hand, if I don't specify VirtualService, but leave just service - flagger will create the VirtualService, but with http route instead of tcp, which breaks the application connectivity.

To Reproduce

1. define deployment listening on TCP, k8s Service and Istio VirtualService with TCP route (no http route)
2. create canary referencing above
3. canary will fail with: reconcileVirtualService failed: VirtualService bm-canary-marcin-b4d-app.bm-canary-marcin get query error v1alpha3.VirtualService.Spec: v1alpha3.VirtualServiceSpec.Tcp: []v1alpha3.TCPRoute: v1alpha3.TCPRoute.Route: readObjectStart: expect { or n, but found [, error found in #10 byte of ...|,"route":[{"destinat|..., bigger context ...|:"bm-perlapp-2166333d-20210920143121"}}],"route":[{"destination":{"host":"bm-canary-marcin-b4d-app-p|...

Expected behavior

Flagger should adjust the VirtualService in similar fashion as it does for http routes

Additional context

• Flagger version: 1.14.0
• Kubernetes version: v1.21.2-eks-0389ca3
• Service Mesh provider: Istio 1.11.2

[somtochiama]

Hello, Can you paste what your canary looks like?

[cinash]

I create a tiny example project to reproduce the issue: https://github.com/cinash/flagger_1021_example/tree/main

Please let me know if something more is needed as this is my first time reporting such issue

[somtochiama]

Hey @cinash, Flagger currently doesn't support TCP. This feature will be considered in Flagger v2 @stefanprodan.