App Mesh 虚拟服务名必须是DNS 可解析的

【以下的问题经过翻译处理】 当前文档对于服务名称有一个建议：

对于虚拟服务名称，请选择一个名称以表示您的虚拟服务。我们建议您使用您想要定位的真实服务的服务发现名称（例如 my-service.default.svc.cluster.local）。

文档并未明确指出服务名称应该是可解析的URL。我们有一个ECS/Fargate部署方案：

• 虚拟服务名称为 colorteller.default.svc.cluster.local
• 它由两个虚拟节点支持：
  • 使用服务发现选项的虚拟节点为 colorteller-red.default.svc.cluster.local
  • 使用服务发现选项的虚拟节点为 colorteller-blue.default.svc.cluster.local

应用容器在请求转发到envoy之前就失败了，因为它无法通过名称解析服务（因为只有红色和蓝色的URL能够通过Route53私有DNS解析）。

如果在Route 53中创建一个DNS A记录，并将 colorteller.default.svc.cluster.local 作为键，任意随机IP作为值，那么这将开始工作。现在应用容器可以解析服务名称，将其转发到envoy，然后envoy再次根据虚拟节点的服务发现名称进行实际查找，并开始正确路由流量。

假设上述情况是预期的行为，并且虚拟服务名称应该匹配至少一个虚拟节点的发现名称，那么进行蓝绿流量转换的推荐模式是什么？因为在这种情况下，部署将如下所示：

• 虚拟服务名称为 colorteller.default.svc.cluster.local
• 它由两个虚拟节点支持：
  • 虚拟节点 red 使用服务发现选项为 colorteller.default.svc.cluster.local（请注意这里没有Red）
  • 虚拟节点 blue 使用服务发现选项为 colorteller-blue.default.svc.cluster.local

当我们部署blue 虚拟节点 并基于权重的方式开始将所有的流量切换到它上面时, 我们并不能下线我们的 red 的Fargate服务, 因为这将从Route 53中取消注册对应的IP, 最终导致服务名解析失败