Review the following minimum requirements and other recommendations for your Gloo Mesh Enterprise setup.
Number of clusters
A typical, multicluster Gloo Mesh setup consists of one management cluster that the Gloo Mesh Enterprise management components are installed in, and one or more workload clusters that run service meshes which are registered with and managed by the management cluster. Many guides throughout the documentation use one management cluster and two workload clusters as an example setup.
By running the management components in a dedicated cluster, you can ensure that no workload pods consume cluster resources that might impede management processes. However, note that Gloo Mesh is fully functional when the management and agent components both run within the same cluster. If you choose to run them in the same cluster, such as in a single-cluster Gloo Mesh setup, ensure that you use the same name for the cluster during both the management component installation and cluster registration.
Review the following recommendations and considerations when creating clusters for your Gloo Mesh environment.
For any clusters that you plan to register as workload clusters, the cluster name cannot include underscores (
Additionally, cluster context names cannot include underscores. The context name is used as a SAN specification in the generated certificate that connects workload clusters to the management cluster, and underscores in SAN are not FQDN compliant. You can rename a context by running
kubectl config rename-context "<oldcontext>" <newcontext>.
Throughout the guides in this documentation, a three-cluster setup is used as an example. When example names are required, the names
cluster-2 are used. Otherwise, you can save the names of your clusters in the
$REMOTE_CLUSTER2 environment variables, and the contexts of your clusters in the
$REMOTE_CONTEXT2 environment variables.
Size and memory
The minimum recommended size for each cluster in your setup is at least 2vCPU and 8GB of memory per node.
For a more robust service mesh setup, the following sizes are recommended:
- Management cluster nodes - 2vCPU and 8GB memory
- Workload cluster nodes - 4vCPU and 16GB memory
The following versions of Gloo Mesh Enterprise are supported with the compatible open source project versions of Istio and Kubernetes. Later versions of the open source projects that are released after Gloo Mesh Enterprise might also work, but are not tested as part of the Gloo Mesh Enterprise release.
|Gloo Mesh Enterprise||Release date||Gloo Mesh Istio
|2.1||TBD||1.9 - 1.13||1.17 - 1.23|
|2.0||13 May 2022||1.9 - 1.13||1.17 - 1.23|
|1.2||4 Nov 2021||1.9 - 1.12||1.17 - 1.23|
Additionally, the following Gloo Mesh Enterprise features require specific versions.
|Gloo Mesh feature||Required versions|
||Gloo Mesh Istio 1.8
|Multicluster subset routing in traffic policies||Istio 1.8 or later|
|Rate limiting for Gloo Mesh Gateway||Gloo Mesh Istio 1.8
|XSLT filter||Istio 1.11 or later|
|Gloo Mesh-managed Istio installations||Istio 1.11 or earlier|
* Gloo Mesh Enterprise offers
n-4 security patching support only with Gloo Mesh Istio versions, not community Istio versions. Gloo Mesh Istio versions support the same patch versions as community Istio. You can review community Istio patch versions in the Istio release documentation. You must run the latest Gloo Mesh Enterprise patch version to get the backported Istio support. For more considerations when installing Gloo Mesh Istio, see Download a specific image.
† Istio and Kubernetes: Supported Kubernetes versions are dependent on Gloo Mesh API version compatibility and on the version of Istio that is installed. For example, you cannot use Gloo Mesh Enterprise with Istio 1.9 on a Kubernetes 1.22 cluster, because Istio 1.9 does not support Kubernetes 1.22. To review Istio support of Kubernetes versions, see the Istio documentation.
OpenShift and Kubernetes: The Istio and Kubernetes versions also determines which version of OpenShift you can run. For example, if you have Istio 1.11 you can run OpenShift 4.8, which uses Kubernetes 1.21. To review OpenShift Kubernetes support, see the OpenShift changelog documentation for the version you want to use.
Istio versions 1.13.0, 1.13.1, 1.13.2, and 1.13.3 have a known issue about service entry hostname expansion. The issue is resolved in Istio 1.13.4. Istio versions 1.8.0, 1.8.1, and 1.8.2 have a known issue where sidecar proxies might not start under specific circumstances. This bug might surface in sidecars configured by Failover Services. This issue is resolved in Istio 1.8.3.
For more information, see Supported versions.
Load balancer connectivity
To test access to the Istio ingress gateway in your Gloo Mesh environment, ensure that your cluster setup enables you to externally access LoadBalancer services on the workload clusters.
Port and repo access from cluster networks
If you have restrictions for your cluster networks in your cloud infrastructure provider, you must open ports, protocols, and image repositories to install Gloo Mesh Enterprise and to allow your Gloo Mesh installation to communicate with the Gloo Mesh APIs. For example, you might have firewalls set up on the public network of your clusters so that they do not have default access to all public endpoints. The following sections detail the required and optional ports and repositories that your management and workload clusters must access.
Need to install Gloo Mesh in a disconnected environment, such as an on-premises datacenter or clusters that run on an intranet or private network only? Check out Install Gloo Mesh in air-gapped environments.
Required: In your firewall or network rules for the management cluster, open the following required ports and repositories.
|Management server images||-||-||IP addresses of management cluster nodes||
|Redis image||-||-||IP addresses of management cluster nodes||
||Public||Allow the Redis image to be installed in the management cluster to store OIDC ID tokens for the Gloo Mesh UI.|
|Agent communication||9900||TCP||ClusterIPs of agents on workload clusters||IP addresses of management cluster nodes||Cluster network||Allow the
Optional: In your firewall or network rules for the management cluster, open the following optional ports as needed.
|Healthchecks||8090||TCP||Check initiator||IP addresses of management cluster nodes||Public or cluster network, depending on whether checks originate from outside or inside service mesh||Allow healthchecks to the management server.|
|Prometheus||9091||TCP||Scraper||IP addresses of management cluster nodes||Public||Scrape your Prometheus metrics from a different server, or a similar metrics setup.|
|Other tools||-||-||-||-||Public||For any other tools that you use in your Gloo Mesh environment, consult the tool's documentation to ensure that you allow the correct ports. For example, if you use tools such as
Required: In your firewall or network rules for the workload clusters, open the following required ports and repositories.
|Agent image||-||-||IP addresses of workload cluster nodes||
|Ingress gateway||80 and/or 443||HTTP, HTTPS||-||Gateway load balancer IP address||Public or private network||Allow incoming traffic requests to the Istio ingress gateway.|
|East-west gateway||15443||TCP||Node IP addresses of other workload clusters||Gateway load balancer IP address on one workload cluster||Cluster network||Allow services in one workload cluster to access the mesh's east-west gateway for services in another cluster. Repeat this rule for the east-west gateway on each workload cluster. Note that you can customize this port in the
Optional: In your firewall or network rules for the workload clusters, open the following optional ports as needed.
|Agent healthchecks||8090||TCP||Check initiator||IP addresses of workload cluster nodes||Public or cluster network, depending on whether checks originate from outside or inside service mesh||Allow healthchecks to the Gloo Mesh agent.|
|Istio Pilot||15017||HTTPS||IP addresses of workload cluster nodes||-||Public||Depending on your cloud provider, you might need to open ports for Istio to be installed. For example, in GKE clusters, you must open port 15017 for the Pilot discovery validation webhook. For more ports and requirements, see Ports used by Istio.|
|Istio healthchecks||15021||HTTP||Check initiator||IP addresses of workload cluster nodes||Public or cluster network, depending on whether checks originate from outside or inside service mesh||Allow healthchecks on path
|Envoy telemetry||15090||HTTP||Scraper||IP addresses of workload cluster nodes||Public||Scrape your Prometheus metrics from a different server, or a similar metrics setup.|
|VM onboarding||15012, 15443||TCP||Gateway load balancer IP addresses on workload clusters||VMs||Cluster network||To add virtual machines to your Gloo Mesh setup, allow traffic and updates through east-west routing from the workload clusters to the VMs.|
Port and repo access from local systems
If corporate network policies prevent access from your local system to public endpoints via proxies or firewalls:
- Allow access to
https://run.solo.io/meshctl/installto install the
- Allow access to the Gloo Mesh Helm respository,
https://storage.googleapis.com/gloo-mesh-enterprise/gloo-mesh-enterprise, to install Gloo Mesh Enterprise via the
Reserved ports and pod requirements
Review the following service mesh and platform docs that outline what ports are reserved, so that you do not use these ports for other functions in your apps. You might use other services such as a database or application monitoring tool that reserve additional ports.