Skip to content
You are viewing the documentation for Solo Enterprise for Istio, formerly known as Gloo Mesh (OSS APIs).

For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

Install the UI

EnterpriseAlpha
Page as Markdown
Install the Solo UI alongside your service mesh in one cluster or across a multicluster service mesh.
The Solo UI is an alpha feature in version 1.30. Alpha features are likely to change, are not fully tested, and are not supported for production. For more information, see Solo feature maturity.
This feature requires an Enterprise-level license for Solo Enterprise for Istio. Contact your account representative to obtain a valid license. If you have a Premium license, or use a sidecar mesh setup, see Gloo UI.
The Solo UI deploys alongside your Istio ambient mesh environment in single or multicluster environments, and can discover existing ambient mesh installations across clusters and infrastructure providers. The UI works with ambient service meshes, whether you use community Istio images or Solo distributions of Istio.
Known limitations

Multicluster services are exposed on *.mesh.internal hostnames with auto-allocated virtual IPs (PILOT_ENABLE_IP_AUTOALLOCATE). Istio assigns both an IPv4 and an IPv6 VIP to each of these services. On a single-stack IPv4 cluster, pods have no usable IPv6 address, so a client that prefers IPv6 tries the IPv6 VIP first, fails, and falls back to the IPv4 VIP. You might see warnings like the following in client logs, such as the Solo UI telemetry relay or collectors:
dial tcp [2001:2::2]:4316: connect: network is unreachable
Note
This is expected and not a failure on its own. The connection falls back to IPv4 and traffic flows normally. Some clients, such as gRPC-based ones, log the IPv6 attempt repeatedly while still sending data over IPv4. To suppress the warnings on a cluster with no usable IPv6, set the IPV6_ENABLED environment variable to false on ztunnel (the default is true); ztunnel then returns only the IPv4 VIP.
Single cluster

Deploy the Solo UI alongside your service mesh in one cluster.
  1. If you have not already, install an ambient mesh in your cluster and deploy apps to the mesh.
  2. Save the following details in environment variables.
    • SOLO_UI_VERSION: The Solo UI version. This example uses the latest version. You can find other versions in the version reference.
    • cluster1: The name of the Kubernetes or OpenShift cluster where you deployed an ambient mesh.
    • SOLO_ISTIO_LICENSE_KEY: Your Enterprise-level license key for Solo Enterprise for Istio. If you do not have one, contact an account representative. If you prefer to specify license keys in a secret instead, see Licensing.
    export SOLO_UI_VERSION=0.5.3
export cluster1=<cluster_name>
export SOLO_ISTIO_LICENSE_KEY=<license_key>
  3. Create the solo-enterprise namespace and label it for inclusion in the ambient mesh.
    kubectl create namespace solo-enterprise
kubectl label namespace solo-enterprise istio.io/dataplane-mode=ambient
  4. Install the UI. The following options enable all settings that are required for a single-cluster installation. To see all possible fields for the Helm chart, review the Helm values reference.
    • oidc.issuer="" enables the auto identity provider, a built-in IdP with hardcoded users for development and testing. To use your own OIDC provider instead, set this value to your OIDC issuer URL.
    • With products.mesh.enabled=true, any authenticated user can view the mesh UI views (Fleet Graph, Global Services, and Dashboard) without a mapped RBAC role. This is controlled by the rbac.roleMapping.defaultRoles Helm value, which defaults to ["global.Authenticated"] when the mesh product is enabled. Reading an individual resource’s YAML from the Fleet Graph still requires the global.Reader role. To require an explicitly mapped role for all access, set rbac.roleMapping.defaultRoles=[]. For all available options, see the Helm values reference.
    helm upgrade -i solo-management \
oci://us-docker.pkg.dev/solo-public/solo-enterprise-helm/charts/management \
-n solo-enterprise \
--version ${SOLO_UI_VERSION} \
--set cluster=${cluster1} \
--set licensing.licenseKey=${SOLO_ISTIO_LICENSE_KEY} \
--set oidc.issuer="" \
--set products.mesh.enabled=true
  5. Verify that the UI component pods have a status of Running.
    kubectl get po -n solo-enterprise
    • The telemetry-collector pod runs the OpenTelemetry (OTel) collector that scrapes Istio metrics, collects traces and events, and writes all telemetry data to ClickHouse.
    • The ui pod runs five containers: the UI backend and frontend, the tunnel server for multicluster connectivity, a dedicated OTel collector for Kubernetes object snapshots, and a built-in identity provider. For a description of each container, see Architecture.
    • The clickhouse pod runs a ClickHouse database for local data storage.
    NAME                                    READY   STATUS    RESTARTS   AGE
solo-enterprise-telemetry-collector-0   1/1     Running   0          4s
solo-enterprise-ui-76c85c7d6b-xftcj     5/5     Running   0          4s
solo-management-clickhouse-shard0-0     1/1     Running   0          4s

  6. Launch the Solo UI to evaluate the health of your service mesh.
    1. Get the IP address or hostname for the solo-enterprise-ui service.
      export UI_ADDRESS=http://$(kubectl get svc -n solo-enterprise solo-enterprise-ui -o jsonpath="{.status.loadBalancer.ingress[0]['hostname','ip']}")
echo ${UI_ADDRESS}
    2. Open the UI in your browser.
      open ${UI_ADDRESS}
    1. Port-forward the solo-enterprise-ui service.
      kubectl port-forward svc/solo-enterprise-ui -n solo-enterprise 4000:80
    2. Open http://localhost:4000 in your browser.
Multicluster

Deploy the UI management components into one cluster, and the UI relay components into one or more connected clusters in the multicluster mesh.
  1. Save the names and kubeconfig contexts of each cluster. This guide uses two clusters as an example. You install the UI management components into cluster1 and the relay components into cluster2.
    export cluster1=<cluster1_name>
export context1=<cluster1_context>
export cluster2=<cluster2_name>
export context2=<cluster2_context>
  2. Save the following details in environment variables.
    • SOLO_UI_VERSION: The Solo UI version. This example uses the latest version. You can find other versions in the version reference.
    • SOLO_ISTIO_LICENSE_KEY: Your Enterprise-level license key for Solo Enterprise for Istio. If you do not have one, contact an account representative. If you prefer to specify license keys in a secret instead, see Licensing.
    export SOLO_UI_VERSION=0.5.3
export SOLO_ISTIO_LICENSE_KEY=<license_key>
  3. Install the Solo UI components. If the cluster where you want to deploy the UI is included in the multicluster ambient mesh, follow the steps in the Management cluster within the mesh tab. If you want to install the UI in a dedicated cluster that does not run an Istio ambient mesh, follow the steps in the Dedicated management cluster tab.
    Deploy the Solo UI management components on a cluster that runs an Istio ambient mesh and is connected to other clusters through the multicluster ambient mesh.
    1. If you have not already, you must first install a multicluster ambient mesh, deploy apps to the mesh, and optionally make the app services available across your clusters.
    2. Install the UI management chart in one cluster. The following options enable all settings that are required for a minimum management component installation. To see all possible fields for the Helm chart, review the Helm values reference.
      • oidc.issuer="" enables the auto identity provider, a built-in IdP with hardcoded users for development and testing. To use your own OIDC provider instead, set this value to your OIDC issuer URL.
      • With products.mesh.enabled=true, any authenticated user can view the mesh UI views (Fleet Graph, Global Services, and Dashboard) without a mapped RBAC role. This is controlled by the rbac.roleMapping.defaultRoles Helm value, which defaults to ["global.Authenticated"] when the mesh product is enabled. Reading an individual resource’s YAML from the Fleet Graph still requires the global.Reader role. To require an explicitly mapped role for all access, set rbac.roleMapping.defaultRoles=[]. For all available options, see the Helm values reference.
      helm upgrade -i solo-management \
oci://us-docker.pkg.dev/solo-public/solo-enterprise-helm/charts/management \
-n solo-enterprise --create-namespace \
--kube-context ${context1} \
--version ${SOLO_UI_VERSION} \
--set cluster=${cluster1} \
--set licensing.licenseKey=${SOLO_ISTIO_LICENSE_KEY} \
--set oidc.issuer="" \
--set products.mesh.enabled=true
    3. Verify that the UI component pods have a status of Running.
      kubectl get po -n solo-enterprise --context ${context1}
      • The telemetry-collector pod runs the OpenTelemetry (OTel) collector that scrapes Istio metrics, collects traces and events, and writes all telemetry data to ClickHouse.
      • The ui pod runs five containers: the UI backend and frontend, the tunnel server for multicluster connectivity, a dedicated OTel collector for Kubernetes object snapshots, and a built-in identity provider. For a description of each container, see Architecture.
      • The clickhouse pod runs a ClickHouse database for local data storage.
      NAME                                    READY   STATUS    RESTARTS   AGE
solo-enterprise-telemetry-collector-0   1/1     Running   0          4s
solo-enterprise-ui-76c85c7d6b-xftcj     5/5     Running   0          4s
solo-management-clickhouse-shard0-0     1/1     Running   0          4s

    4. Install the UI relay chart in cluster2. The following options enable all settings that are required for a minimum relay component installation. Note that the global hostnames of the tunnel server and telemetry gateway services, which are created for you by default, are included so that relay components in other clusters of the multicluster mesh can connect to the management components. To see all possible fields for the Helm chart, review the Helm values reference.
      helm upgrade -i solo-relay \
oci://us-docker.pkg.dev/solo-public/solo-enterprise-helm/charts/relay \
-n solo-enterprise --create-namespace \
--kube-context ${context2} \
--version ${SOLO_UI_VERSION} \
--set cluster=${cluster2} \
--set tunnel.fqdn=solo-enterprise-ui.solo-enterprise.mesh.internal \
--set telemetry.fqdn=solo-enterprise-telemetry-gateway.solo-enterprise.mesh.internal
    Deploy the Solo UI management components to a cluster that does not run an Istio ambient mesh. Workload clusters connect to the management cluster using the relay chart. This topology avoids an additional Istio license on the management cluster.
    1. Before you begin, verify the following prerequisites.
    2. Create the solo-enterprise namespace on the management cluster.
      kubectl create namespace solo-enterprise --context ${context1}
    3. Install the UI management chart. To see all possible fields for the Helm chart, review the Helm values reference.
      • oidc.issuer="" enables the auto identity provider, a built-in IdP with hardcoded users for development and testing. To use your own OIDC provider instead, set this value to your OIDC issuer URL.
      • With products.mesh.enabled=true, any authenticated user can view the mesh UI views (Fleet Graph, Global Services, and Dashboard) without a mapped RBAC role. This is controlled by the rbac.roleMapping.defaultRoles Helm value, which defaults to ["global.Authenticated"] when the mesh product is enabled. Reading an individual resource’s YAML from the Fleet Graph still requires the global.Reader role. To require an explicitly mapped role for all access, set rbac.roleMapping.defaultRoles=[]. For all available options, see the Helm values reference.
      helm upgrade -i solo-management \
oci://us-docker.pkg.dev/solo-public/solo-enterprise-helm/charts/management \
-n solo-enterprise \
--kube-context ${context1} \
--version ${SOLO_UI_VERSION} \
--set cluster=${cluster1} \
--set licensing.licenseKey=${SOLO_ISTIO_LICENSE_KEY} \
--set oidc.issuer="" \
--set products.mesh.enabled=true
    4. Verify that the UI component pods have a status of Running.
      kubectl get po -n solo-enterprise --context ${context1}
      • The telemetry-collector pod runs the OpenTelemetry (OTel) collector that scrapes Istio metrics, collects traces and events, and writes all telemetry data to ClickHouse.
      • The ui pod runs five containers: the UI backend and frontend, the tunnel server for multicluster connectivity, a dedicated OTel collector for Kubernetes object snapshots, and a built-in identity provider. For a description of each container, see Architecture.
      • The clickhouse pod runs a ClickHouse database for local data storage.
      NAME                                    READY   STATUS    RESTARTS   AGE
solo-enterprise-telemetry-collector-0   1/1     Running   0          4s
solo-enterprise-ui-76c85c7d6b-xftcj     5/5     Running   0          4s
solo-management-clickhouse-shard0-0     1/1     Running   0          4s

    5. Save the external addresses of the tunnel server and the OTel telemetry gateway. These services are exposed as load balancers and are the endpoints that relay components in workload clusters connect to.
      export TUNNEL_ADDRESS=$(kubectl get svc -n solo-enterprise solo-enterprise-ui --context ${context1} -o jsonpath="{.status.loadBalancer.ingress[0]['hostname','ip']}")
export TELEMETRY_ADDRESS=$(kubectl get svc -n solo-enterprise solo-enterprise-telemetry-gateway --context ${context1} -o jsonpath="{.status.loadBalancer.ingress[0]['hostname','ip']}")
echo "Tunnel: ${TUNNEL_ADDRESS}"
echo "Telemetry: ${TELEMETRY_ADDRESS}"
    6. For each workload cluster, install the relay chart. Set tunnel.fqdn and telemetry.fqdn to the external addresses you saved. To see all possible fields for the Helm chart, review the Helm values reference.
      export cluster2=<workload_cluster_name>
export context2=<workload_cluster_context>
helm upgrade -i solo-relay \
oci://us-docker.pkg.dev/solo-public/solo-enterprise-helm/charts/relay \
-n solo-enterprise --create-namespace \
--kube-context ${context2} \
--version ${SOLO_UI_VERSION} \
--set cluster=${cluster2} \
--set tunnel.fqdn=${TUNNEL_ADDRESS} \
--set telemetry.fqdn=${TELEMETRY_ADDRESS}
  4. Verify that the relay and telemetry collector pods have a status of Running.
    kubectl get po -n solo-enterprise --context ${context2}
    • The relay pod runs two containers: the tunnel client that connects to the tunnel server in the management cluster, and a dedicated OTel collector for Kubernetes object snapshots in the workload cluster.
    • The telemetry-collector pod collects data in the cluster to send to the OTel gateway in the management cluster.
    NAME                                     READY   STATUS    RESTARTS   AGE
solo-enterprise-relay-5d7f668848-h456h   2/2     Running   0          13s
solo-enterprise-telemetry-collector-0    1/1     Running   0          13s

  5. Launch the Solo UI to evaluate the health of your service mesh.
    1. Get the external IP address or hostname for the solo-enterprise-ui service.
      export UI_ADDRESS=http://$(kubectl get svc -n solo-enterprise solo-enterprise-ui --context ${context1} -o jsonpath="{.status.loadBalancer.ingress[0]['hostname','ip']}")
echo ${UI_ADDRESS}
    2. Open the UI in your browser.
      open ${UI_ADDRESS}
    1. Port-forward the solo-enterprise-ui service.
      kubectl port-forward svc/solo-enterprise-ui -n solo-enterprise 4000:80 --context ${context1}
    2. Open http://localhost:4000 in your browser.
Next

Explore the UI further to review your Istio workloads, traffic flows, resources, and more.
For help and support, check out the following resoures.
AboutExplore