App-mesh Virtual Service name must be fully qualified domain name (FQDN)

[shashanktomar]

The current documentation has a recommendation about the service name:

For Virtual service name, choose a name for your virtual service. We recommend that you use the service discovery name of the real service that you're targeting (such as my-service.default.svc.cluster.local)

It does not clearly state that the service name should be a resolvable FQDN. We have a ECS Fargate deployment scenario where:

• virtual service name is colorteller.default.svc.cluster.local
• it is backed by two nodes:
  • virtual node with service-discovery options as colorteller-red.default.svc.cluster.local
  • virtual node with service-discovery options as colorteller-blue.default.svc.cluster.local

The app container fails even before request is forwarded to envoy because it can't resolve the service by its name (as only red and blue url's are resolvable via Route53 private DNS).

This starts working if a DNS A name entry is created in Route53 with colorteller.default.svc.cluster.local as key and any random IP as value. Now the app container can resolve the service name, forward it to envoy and then envoy again does the actual lookup against node service-discovery name and start routing traffic properly.

---

Assuming the above scenario is expected behavior and the virtual-service name should match at least one virtual-node discovery name, what are the recommended patterns for doing blue-green traffic transitions? Because in this scenario the deployment would look like:

• virtual service name is colorteller.default.svc.cluster.local
• it is backed by two nodes:
  • virtual node red with service-discovery options as colorteller.default.svc.cluster.local (please note there is no Red here)
  • virtual node blue with service-discovery options as colorteller-blue.default.svc.cluster.local

Now after we deploy the blue virtual-node and start routing all the traffic to it based on the weight, we can't bring down our Fargate service running red tasks as it will de-register the IP from Route53 and the DNS lookup against service name will start failing.

[bcelenza]

Hey @shashanktomar, thanks for bring this to our attention. We can improve the documentation on this limitation. As just a general heads up, we're hoping to allow any hostname or FQDN to be used in the future, which I've documented in #65, and our current approach to that depends on envoyproxy/envoy#6748.

[shashanktomar]

Thanks @bcelenza for the quick response, I have changed the heading and content to make it more clear and compatible with the other issue.

[bcelenza]

No worries, sorry for the confusion. If it's alright with you, I'll close this in favor of #65 once our documentation is updated to clear up this gotcha.

[shashanktomar]

Sounds good to me @bcelenza, feel free to close it.

[bcelenza]

Updated documentation for this can be found here: https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_services.html

[stowns]

this issue drove me insane for hours. I couldn't understand why the colorteller-white virtual-service was being assigned the colorteller.* domain. I assumed the router would somehow be represented as colorteller.*