12 Scaling Istio in your organization

 

This chapter covers

  • Scaling the service mesh in multiple clusters
  • Resolving the prerequisites to join two clusters
  • Setting up common trust between workloads of different clusters
  • Discovering cross-cluster workloads
  • Configuring Istio’s ingress gateway for east-west traffic

In the previous chapters, we have seen many of Istio’s features and the capabilities they enable within a mesh on a single cluster. However, a service mesh is not bound to a single cluster; it can span many clusters and provide the same capabilities across all of them. In fact, a mesh’s value increases when more workloads are part of it.

But when would we want a service mesh to span multiple clusters? What are the benefits of a multi-cluster service mesh compared to a single cluster? To answer those questions, let’s revisit the fictitious ACME Inc., which moved to a cloud platform and experienced all the networking complexities added by microservice architectures.

12.1 The benefits of a multi-cluster service mesh

Early in its cloud migration efforts, ACME had the dilemma of how to size its clusters. The company started with a single large cluster but quickly changed that decision. ACME decided on multiple smaller clusters due to their benefits:

12.2 Overview of multi-cluster service meshes

12.2.1 Istio multi-cluster deployment models

12.2.2 How workloads are discovered in multi-cluster deployments

12.2.3 Cross-cluster workload connectivity

12.2.4 Common trust between clusters

12.3 Overview of a multi-cluster, multi-network, multi-control-plane service mesh

12.3.1 Choosing the multi-cluster deployment model

12.3.2 Setting up the cloud infrastructure

12.3.3 Configuring plug-in CA certificates

12.3.4 Installing the control planes in each cluster

12.3.5 Enabling cross-cluster workload discovery

12.3.6 Setting up cross-cluster connectivity