Deployment Models

When configuring a production deployment of Istio, you need to answer a number of questions.Will the mesh be confined to a single cluster or distributed acrossmultiple clusters? Will all the services be located in a single fully connected network, or willgateways be required to connect services across multiple networks? Is there a singlecontrol plane, potentially shared across clusters,or are there multiple control planes deployed to ensure high availability (HA)?If there is more than one cluster being deployed, and more specifically in isolated networks,are they going to be connected into a single multiclusterservice mesh or will they be federated into a multi-mesh deployment?

All of these questions, among others, represent independent dimensions of configuration for an Istio deployment.

• single or multiple cluster
• single or multiple network
• single or multiple control plane
• single or multiple meshAll combinations are possible, although some are more common than others andsome are clearly not very interesting (for example, multiple mesh in a single cluster).

In a production deployment involving multiple clusters, the deployment may use amix of patterns. For example, having more than one control plane is recommended for HA,but you could achieve this for a 3 cluster deployment by deploying 2 clusters witha single shared control plane and then adding the third cluster with a secondcontrol plane in a different network. All three clusters could then be configuredto share both control planes so that all the clusters have 2 sources of controlto ensure HA.

Choosing the right deployment model depends on the isolation, performance,and HA requirements for your use case. This guide describes the various options andconsiderations when configuring your Istio deployment.

Cluster models

The workload instances of your application run in one or moreclusters. For isolation, performance, andhigh availability, you can confine clusters to availability zones and regions.

Production systems, depending on their requirements, can run across multipleclusters spanning a number of zones or regions, leveraging cloud load balancersto handle things like locality and zonal or regional fail over.

In most cases, clusters represent boundaries for configuration and endpointdiscovery. For example, each Kubernetes cluster has an API Server which managesthe configuration for the cluster as well as servingservice endpoint information as pods are brought upor down. Since Kubernetes configures this behavior on a per-cluster basis, thisapproach helps limit the potential problems caused by incorrect configurations.

In Istio, you can configure a single service mesh to span any number ofclusters.

Single cluster

In the simplest case, you can confine an Istio mesh to a singlecluster. A cluster usually operates over asingle network, but it varies between infrastructureproviders. A single cluster and single network model includes a control plane,which results in the simplest Istio deployment.

A service mesh with a single cluster

Single cluster deployments offer simplicity, but lack other features, forexample, fault isolation and fail over. If you need higher availability, youshould use multiple clusters.

Multiple clusters

You can configure a single mesh to includemultiple clusters. Using amulticluster deployment within a single mesh affordsthe following capabilities beyond that of a single cluster deployment:

• Fault isolation and fail over: cluster-1 goes down, fail over to cluster-2.
• Location-aware routing and fail over: Send requests to the nearest service.
• Various control plane models: Support differentlevels of availability.
• Team or project isolation: Each team runs its own set of clusters.

A service mesh with multiple clusters

Multicluster deployments give you a greater degree of isolation andavailability but increase complexity. If your systems have high availabilityrequirements, you likely need clusters across multiple zones and regions. Youcan canary configuration changes or new binary releases in a single cluster,where the configuration changes only affect a small amount of user traffic.Additionally, if a cluster has a problem, you can temporarily route traffic tonearby clusters until you address the issue.

You can configure inter-cluster communication based on thenetwork and the options supported by your cloud provider. Forexample, if two clusters reside on the same underlying network, you can enablecross-cluster communication by simply configuring firewall rules.

Network models

Many production systems require multiple networks or subnets for isolationand high availability. Istio supports spanning a service mesh over a variety ofnetwork topologies. This approach allows you to select the network model thatfits your existing network topology.

Single network

In the simplest case, a service mesh operates over a single fully connectednetwork. In a single network model, allworkload instancescan reach each other directly without an Istio gateway.

A single network allows Istio to configure service consumers in a uniformway across the mesh with the ability to directly address workload instances.

A service mesh with a single network

Multiple networks

You can span a single service mesh across multiple networks; such aconfiguration is known as multi-network.

Multiple networks afford the following capabilities beyond that of single networks:

• Overlapping IP or VIP ranges for service endpoints
• Crossing of administrative boundaries
• Fault tolerance
• Scaling of network addresses
• Compliance with standards that require network segmentation

In this model, the workload instances in different networks can only reach eachother through one or more Istio gateways.Istio uses partitioned service discovery to provide consumers a differentview of service endpoints. The view depends on thenetwork of the consumers.

A service mesh with multiple networks

Control plane models

An Istio mesh uses the control plane to configure allcommunication between workload instances within the mesh. You can replicate thecontrol plane, and workload instances connect to any control plane instance toget their configuration.

In the simplest case, you can run your mesh with a control plane on a singlecluster.

A service mesh with a control plane

Multicluster deployments can also share control plane instances. In this case,the control plane instances can reside in one or more clusters.

A service mesh with two clusters sharing a control plane

For high availability, you should deploy a control plane across multipleclusters, zones, or regions.

A service mesh with control plane instances for each region

This model affords the following benefits:

• Improved availability: If a control plane becomes unavailable, the scope ofthe outage is limited to only that control plane.

• Configuration isolation: You can make configuration changes in one cluster,zone, or region without impacting others.

You can improve control plane availability through fail over. When a controlplane instance becomes unavailable, workload instances can connect toanother available control plane instance. Fail over can happen across clusters,zones, or regions.

A service mesh after a control plane instance fails

The following list ranks control plane deployment examples by availability:

• One cluster per region (lowest availability)
• Multiple clusters per region
• One cluster per zone
• Multiple clusters per zone
• Each cluster (highest availability)

Identity and trust models

When a workload instance is created within a service mesh, Istio assigns theworkload an identity.

The Certificate Authority (CA) creates and signs the certificates used to verifythe identities used within the mesh. You can verify the identity of the message senderwith the public key of the CA that created and signed the certificatefor that identity. A trust bundle is the set of all CA public keys used byan Istio mesh. With a mesh’s trust bundle, anyone can verify the sender of anymessage coming from that mesh.

Trust within a mesh

Within a single Istio mesh, Istio ensures each workload instance has anappropriate certificate representing its own identity, and the trust bundlenecessary to recognize all identities within the mesh and any federated meshes.The CA only creates and signs the certificates for those identities. This modelallows workload instances in the mesh to authenticate each other whencommunicating.

A service mesh with a certificate authority

Trust between meshes

If a service in a mesh requires a service in another, you must federate identityand trust between the two meshes. To federate identity and trust, you mustexchange the trust bundles of the meshes. You can exchange the trust bundleseither manually or automatically using a protocol such as SPIFFE Trust Domain Federation.Once you import a trust bundle to a mesh, you can configure local policies forthose identities.

Multiple service meshes with certificate authorities

Mesh models

Istio supports having all of your services in amesh, or federating multiple meshestogether, which is also known as multi-mesh.

Single mesh

The simplest Istio deployment is a single mesh. Within a mesh, service names areunique. For example, only one service can have the name mysvc in the foonamespace. Additionally, workload instances share a common identity sinceservice account names are unique within a namespace, just like service names.

A single mesh can span one or more clusters andone or more networks. Within a mesh,namespaces are used for tenancy.

Multiple meshes

Multiple mesh deployments result from mesh federation.

Multiple meshes afford the following capabilities beyond that of a single mesh:

• Organizational boundaries: lines of business
• Service name or namespace reuse: multiple distinct uses of the defaultnamespace
• Stronger isolation: isolating test workloads from production workloads

You can enable inter-mesh communication with mesh federation. When federating, each mesh can expose a set of services andidentities, which all participating meshes can recognize.

Multiple service meshes

To avoid service naming collisions, you can give each mesh a globally uniquemesh ID, to ensure that the fully qualified domainname (FQDN) for each service is distinct.

When federating two meshes that do not share the sametrust domain, you mustfederateidentity and trust bundles between them. See thesection on Multiple Trust Domains for an overview.

Tenancy models

In Istio, a tenant is a group of users that sharecommon access and privileges to a set of deployed workloads. Generally, youisolate the workload instances from multiple tenants from each other throughnetwork configuration and policies.

You can configure tenancy models to satisfy the following organizationalrequirements for isolation:

• Security
• Policy
• Capacity
• Cost
• Performance

Istio supports two types of tenancy models:

• Namespace tenancy
• Cluster tenancy

Namespace tenancy

Istio uses namespacesas a unit of tenancy within a mesh. Istio also works in environments that don’timplement namespace tenancy. In environments that do, you can grant a teampermission to deploy their workloads only to a given namespace or set ofnamespaces. By default, services from multiple tenant namespaces can communicatewith each other.

A service mesh with two isolated namespaces

To improve isolation, you can selectively choose which services to expose toother namespaces. You can configure authorization policies for exposed servicesto restrict access to only the appropriate callers.

A service mesh with two namespaces and an exposed service

When using multiple clusters, the namespaces in eachcluster sharing the same name are considered the same namespace. For example,Service B in the foo namespace of cluster-1 and Service B in thefoo namespace of cluster-2 refer to the same service, and Istio merges theirendpoints for service discovery and load balancing.

A service mesh with clusters with the same namespace

Cluster tenancy

Istio supports using clusters as a unit of tenancy. In this case, you can giveeach team a dedicated cluster or set of clusters to deploy theirworkloads. Permissions for a cluster are usually limited to the members of theteam that owns it. You can set various roles for finer grained control, forexample:

• Cluster administrator
• Developer

To use cluster tenancy with Istio, you configure each cluster as an independentmesh. Alternatively, you can use Istio to implement a group of clusters as asingle tenant. Then, each team can own one or more clusters, but you configureall their clusters as a single mesh. To connect the meshes of the various teamstogether, you can federate the meshes into a multi-mesh deployment.

Two isolated service meshes with two clusters and two namespaces

Since a different team or organization operates each mesh, service namingis rarely distinct. For example, the mysvc in the foo namespace ofcluster-1 and the mysvc service in the foo namespace ofcluster-2 do not refer to the same service. The most common example is thescenario in Kubernetes where many teams deploy their workloads to the defaultnamespace.

When each team has their own mesh, cross-mesh communication follows theconcepts described in the multiple meshes model.

See also

Istio Soft Multi-Tenancy Support

Using Kubernetes namespaces and RBAC to create an Istio soft multi-tenancy environment.