You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because we still require some DNS entry for applications to resolve some IP before it will make a request that envoy can proxy, the examples end up duplicating names across service discovery and router service names/backends. This leads to confusion because it's implied there's some coordination between the two when there isn't.
We can fix our example apps by creating a private hosted zone for "#{meshName}.appmesh" with a wildcard entry to any IP. VirtualRouters will register on "colorgateway.#{meshName}.appmesh" and "colorteller.#{meshName}.appmesh" and the actual VNode service discovery can use existing kubedns/CloudMap names. I would expect this would be how we recommend customers configure things as well until we have a better solution for the DNS hole.
The text was updated successfully, but these errors were encountered:
Because we still require some DNS entry for applications to resolve some IP before it will make a request that envoy can proxy, the examples end up duplicating names across service discovery and router service names/backends. This leads to confusion because it's implied there's some coordination between the two when there isn't.
We can fix our example apps by creating a private hosted zone for "#{meshName}.appmesh" with a wildcard entry to any IP. VirtualRouters will register on "colorgateway.#{meshName}.appmesh" and "colorteller.#{meshName}.appmesh" and the actual VNode service discovery can use existing kubedns/CloudMap names. I would expect this would be how we recommend customers configure things as well until we have a better solution for the DNS hole.
The text was updated successfully, but these errors were encountered: