[AWS App Mesh] Non-FQDN virtual services not http routable

[vodwood]

On AWS App Mesh, when applying the canary definition from the how-to guide, the virtual services are created with names: appname appname-canary

Additionally, the appmesh controller actually appends a "namespace" to the final virtual service object, so the resulting virtual service objects are named as follows: appname.namespace appname-canary.namespace

I then attempt to make an http call to the "appname" service from a third-party application (with proper backend configured of course): wget -qO- http://appname/liveness This request does not get routed by the envoy sidecar and returns a default 404.

404 is also returned when calling http://appname.namespace.svc.cluster.local/liveness, http://service-ip:port/liveness etc.

With AWS support it was confirmed and reproduced, that in order to route the request out, a service name needs to be named exactly like the FQDN of the real underlying kubernetes service e.g. appname.namespace.svc.cluster.local.

In AWS documentation this approach is "recommended", but it was confirmed that this is the only way to go in reality.

A working "http routable" vanilla Virtual Service definition created via the controller might look like so:

apiVersion: appmesh.k8s.aws/v1beta2
kind: VirtualService
metadata:
  name: appname.namespace.svc.cluster.local
  namespace: namespace
spec:
  awsName: appname.namespace.svc.cluster.local
  provider:
    virtualNode:
      virtualNodeRef:
        name: appname-node

In Flagger, to my understanding, this model is impossible to follow currently. Therefor, it is impossible to use Flagger-created objects with AWS App Mesh.

Should this be potentially addressed in Flagger or should Flagger be able to take control of the "pre-created" App Mesh objects?

[hades1712]

same here , any suggestions ??

[g-traveller]

we have same problem here, change to FQDN is not acceptable in our code, is there solution to avoid that?