Resolving multi-cluster issues

This section explains common Cloud Service Mesh problems and how to resolve them.If you need additional assistance, seeGetting support.

Missing secrets

Cloud Service Mesh relies on a kubeconfig file embedded in the Kubernetes secret forproper remote endpoint discovery. Without the secrets, users will always seerequests hit pods in the local cluster during cross-cluster load balancing.

Verify the secret has been created by running the following command in everycluster:

kubectl get secret istio-remote-secret-CLUSTER_NAME_i -n istio-system

Verify the expected output:

NAME                                   TYPE     DATA   AGEistio-remote-secret-CLUSTER_NAME_i   Opaque   1      44s

To recover from this, delete all the remote secrets and re-run thecreate-meshcommand.

Unreachable API server

The control plane of Cloud Service Mesh needs to reach the API server of the remotecluster. The following situations can cause the remote cluster to becomeunreachable:

• The remote cluster is deleted.
• The remote cluster is aprivate clusterthat does not haveglobal accessenabled.
• The remote cluster is aprivate clusterwithMaster Authorized Networkenabled but the Cloud Service Mesh control plane IP has not been properly allowedvia the allow list.

Given an unreachable API server, Istiod will output error messages in the log.Users will always see requests hit the local pod during cross-cluster loadbalancing.

In theLogs Explorer interface,set the queryresource.type toistio_control_plane.

Check to see if there are any invalid secret errors.

To recover from the above situation, first fix the underlying API server reachability issue. Then, delete all the remote secrets in every cluster andre-run thecreate-mesh command.

Missing firewall rule

Without the proper firewall rule, users will experience a 10-second delayfollowed by a timeout when doing cross-cluster load balancing.

To recover from this, follow the steps outlined inCreate firewall rule.