App Mesh Virtual Service name must be DNS resolvable
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 URL. We have a ECS/Fargate deployment scenario where:
- Virtual Service name is
colorteller.default.svc.cluster.local - it is backed by two Virtual 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
- Virtual Node with service discovery options as
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 URLs are resolvable via Route53 private DNS).
This starts working if a DNS A record is created in Route 53 with colorteller.default.svc.cluster.local as the key and any random IP as the value. Now the app container can resolve the service name, forward it to envoy and then envoy again does the actual lookup against the Virtual Node's 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 Virtual Nodes:
- Virtual Node
redwith service discovery options ascolorteller.default.svc.cluster.local(please note there is no Red here) - Virtual Node
bluewith service discovery options ascolorteller-blue.default.svc.cluster.local
- Virtual Node
Now after we deploy the blue Virtual Node and start routing all 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 Route 53 and the DNS lookup against service name will start failing.
(Cross-posted from aws/aws-app-mesh-roadmap#71)
- 新しい順
- 投票が多い順
- コメントが多い順
Currently all virtual service names need to be resolvable by DNS. The value of the A record does not need to point to a real place, just a non-loopback IP address. See Unable to resolve DNS name for a virtual service in the App Mesh Documentation for more details.
Hi, we ran into the same error for creating a virtual service(that had no matching DNS record) in our EKS cluster and instead of creating a record in Route53, we created a k8s service that points at nothing(giving us a DNS record inside of k8s). Once that fake k8s service DNS resolves, envoy can take over with what virtual node to route to based on the App mesh config you have set.
Here is our example we have in our setup(renamed to colorteller):
users hit http://colorteller.default:8400/${routeInVirtualRouter}
---
# This Service creates a DNS entry that the below VirtualService requires
apiVersion: v1
kind: Service
metadata:
name: colorteller
namespace: default
spec:
ports:
- protocol: TCP
port: 8400
targetPort: 8400
---
apiVersion: appmesh.k8s.aws/v1beta2
kind: VirtualService
metadata:
name: colorteller
namespace: default
spec:
awsName: colorteller.default
provider:
virtualRouter:
virtualRouterRef:
name: colorteller
---
apiVersion: appmesh.k8s.aws/v1beta2
kind: VirtualRouter
metadata:
name: colorteller
namespace: default
spec:
listeners:
- portMapping:
port: 8400
protocol: http
routes:
...
