Chen Youxiong

@howardjohn any comment?

@howardjohn @hzxuzhonghu We plan to implement this function in Istio to support failover to a specified cluster. It makes sense to specify the failover cluster in the DestinationRule but would...

@hzxuzhonghu I tried the wildcard match but no luck ``` spec: gateways: - sample-gw hosts: - www.example.com http: - match: - port: 443 uri: prefix: /a name: test-a route: -...

@hzxuzhonghu What we expect is that, if endpoints in svc-a all goes down, then it should fallback to the svc-default, like the homepage for better user experience. User would be...

@hzxuzhonghu It's similar mechanism with locality load balancing. For each VirtualService route destination, we can append another set of endpoints which are from the fallback service, the default/fallback cluster(P1). So...

@hzxuzhonghu It's actually from the hardware loadbalancer to Istio migration. This is the default behavior in the hardware loadbalancer which is more user friendly especially for the public traffic. And...

@howardjohn The existing failover in Destination Rule doesn't fit for this case very well and there are some downsides: 1. Need to configure the Destination Rule for each route destination....

@howardjohn Essentially it's the failover capability by leveraging Envoy priority level. Difference is that, one is for locality failover within same service across different regions and another is the specified...

@howardjohn Is it possible to introduce an annotation `traffic.istio.io/defaultCluster` in VirtualService to support this feature? Thus we don't need api change and it can be backward compatible.

> We have two incentives: one from spring cloud, one from hardware loadbalancer. So i think we can extend our capabilities. A coarse thought is to add a fall back...