Webinar Recap – Multi-Cluster Istio Management with Virtual Mesh
Last week’s webinar featured Christian Posta to dig into the recent announcement of Service Mesh Hub. In it we released new features, support for the latest Istio 1.5, and open sourced Service Mesh Hub to foster innovation with the broader service mesh community.
Service Mesh Hub is the industry’s first unified dashboard for installing, discovering, operating and extending a single service mesh or group of meshes. Launched last May at KubeCon EU, we have been working with end users and the community to understand their preferred deployment patterns for service mesh and the operational challenges they are looking to solve.
That feedback drove the latest set of enhancements including virtual mesh capabilities to group multiple clusters of meshes together, discovery of meshes and services, API simplification and CLI tooling to streamline management of multiple service mesh clusters.
Enjoy the replay here and register for our upcoming webinar on May 28th to dig into multi-cluster architectural patterns.
Watch the replay here
Highlights from the Q&A
Other than the Traffic Routing, what are the use cases for federating service meshes?
The reason to federate them is to simplify the operations of the multiple clusters of service meshes. To enable things like failover, global service discovery, global mTLS, and a unified management plane for observability across the different clusters.
What are the network requirements between the two clusters? Do we need a flat network or just need to be able to access the Istio gateway?
In this particular model of multi cluster, we went with an assumption that there was no flat network. These were different networks but there was connectivity to the gateways, so we could reach them. There are other models for multi clusters patterns with pros and cons for each of the different architectures. This is a much longer discussion so we scheduled another webinar for May 28th to specifically cover it — register here.
Security Question – In the demo is there mTLS between the workloads in the two clusters?
Yes, mTLS is enabled in the demo and in the demo they are both part of the same root trust domain. mTLS is happening between the services within their own individual clusters and when they go across clusters (since they are part of the same root), the ingress gateway does a little SNI routing directly to the workload so the mTLS is uninterrupted. This creates end to end mTLS from the workload in cluster 1 to the workload in cluster 2.
Security Question – Is the trust federation built on or an implementation of SPIFFE/SPIRE federation? e.g. trust bundle exchanges?
Currently the identity model used to federate the identity between the meshes is based on the underlying mesh’s implementation. In the case of the demo, it is Istio and Istio uses SPIFEE. This starts to get interesting when we get into situations with Istio and AWS App Mesh or Istio and Linkerd or Consul running because we will start to federate those different meshes and there has to be an exchange and transformation of identity and trust — this is something we are building into Service Mesh Hub so stay tuned.
Can Gloo act as an interface to redirect traffic to different cloud (AWS,GKS,etc) application services ?
Yes. Gloo can be used for all kinds of cross cloud and cross zone routing. We intentionally named this product Gloo because it fundamentally glues together different environments.
Out of the box Gloo will automatically discover services that it can route to. For example, if you’re running Kubernetes, Gloo will query the Kubernetes API. If you have configured it with HashiCorp Consul, then Gloo will discover services running in Consul and you can also point it to AWS and Gloo can automatically discover workloads EC2, EKS or Lambda. If you do not want to use the auto-discovery feature, you can statically register the different services directly into Gloo.
Foundational to the Gloo control plane and service mesh hub is that everything is plugins. If there is a registry or you want to do automatic registration using a registry that we don’t already support then it can easily be added and extended into the control plane.
Download the presentation
[featured_boxes class=”featured-box”]
Learn More
About Service Mesh Hub, and request a personalized demo
Read the announcement and technical blog
Check out the project on GitHub
Start a discussion in the Solo.io community
[/featured_boxes]
