Resolving multi-cluster issues
This section explains common Anthos Service Mesh problems and how to resolve them. If you need additional assistance, see Getting support.
Anthos Service Mesh relies on a kubeconfig file embedded in the Kubernetes secret for proper remote endpoint discovery. Without the secrets, users will always see requests hit pods in the local cluster during cross-cluster load balancing.
Verify the secret has been created by running the following command in every cluster:
kubectl get secret istio-remote-secret-CLUSTER_NAME_i -n istio-system
Verify the expected output:
NAME TYPE DATA AGE istio-remote-secret-CLUSTER_NAME_i Opaque 1 44s
To recover from this, delete all the remote secrets and re-run the
Unreachable API server
The control plane of Anthos Service Mesh needs to reach the API server of the remote cluster. The following situations can cause the remote cluster to become unreachable:
- The remote cluster is deleted.
- The remote cluster is a private cluster that does not have global access enabled.
- The remote cluster is a private cluster with Master Authorized Network enabled but the Anthos Service Mesh control plane IP has not been properly allowed via 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 load balancing.
In the Logs Explorer interface,
set the query
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 and
Missing firewall rule
Without the proper firewall rule, users will experience a 10-second delay followed by a timeout when doing cross-cluster load balancing.
To recover from this, follow the steps outlined in Create firewall rule.