istio.DestinationRule host match subset ... Key attributes: Separate roles for proxy infrastructure, application definition; rich feature set based on Envoy
k8s.Service k8s.Service subset contour. IngressRoute Key attributes: Separate roles, recursive delegation + composability, additional features such as traffic splitting.
filtering gateways: [g1, g2] How to match Gateway and VirtualHost? • VirtualHost attaches to a Gateway • Gateway filters VirtualHosts -- wildcard allows for self-service.
API 100% portable Core MUST be supported. Extended Feature by feature. MAYBE supported, but MUST be portable. Part of k8s API schema. Custom No guarantee for portability, No k8s API schema. gravity...
API 100% portable Enforcement by conformance tests. Extended feature definition requires self-contained conformance. Require all extended features be checked statically? gravity...
of application in one Kubernetes cluster in one locality before rolling it out worldwide. • Low latency - Users get routed to the application backends that are closest to them geographically. • High availability - Users requests are served even if one cluster holding application backends is completely down. • Hybrid - Application spans multiple cloud providers or on-prem
load balancing across a global service that is deployed on Kubernetes clusters. • I want the ability to add / remove clusters from this load balancing based on business requirements. • I want teams in my organization (service owners) to manage their own ingress traffic but maintain a clear boundary between the “admin” and the “Kubernetes end user”. • I want my teams to use a native Kubernetes API to leverage default features (e.g namespacing, labels) & to reduce the learning curve.
alleviates the need for having to do the manual work of replicating their workload across clusters. ◦ Do not want to be opinionated on how users deploy their workloads. It’s not really the spirit of what the API is trying to provide. ◦ Best practices in this space are divided, no one-size fits all approach.
and assumptions are slightly different. • Federation v2 is opinionated on cross-cluster DNS & SD, deployment of workloads, etc. • Federation v2 is trying to target a much wider set of use cases, multi-cluster services are an “à la carte” offering Where does Istio’s Multicluster story fit? • Potential for existing API’s to support use case.