[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[],[],null,["Resolving multi-cluster issues\n\nThis section explains common Cloud Service Mesh problems and how to resolve them.\nIf you need additional assistance, see [Getting support](/service-mesh/v1.20/docs/getting-support).\n\nMissing secrets\n\nCloud Service Mesh relies on a kubeconfig file embedded in the Kubernetes secret for\nproper remote endpoint discovery. Without the secrets, users will always see\nrequests hit pods in the local cluster during cross-cluster load balancing.\n\nVerify the secret has been created by running the following command in every\ncluster: \n\n kubectl get secret istio-remote-secret-\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e_i -n istio-system\n\nVerify the expected output: \n\n NAME TYPE DATA AGE\n istio-remote-secret-CLUSTER_NAME_i Opaque 1 44s\n\nTo recover from this, delete all the remote secrets and re-run the `create-mesh`\ncommand.\n\nUnreachable API server\n\nThe control plane of Cloud Service Mesh needs to reach the API server of the remote\ncluster. The following situations can cause the remote cluster to become\nunreachable:\n\n- The remote cluster is deleted.\n- The remote cluster is a [private cluster](/kubernetes-engine/docs/concepts/private-cluster-concept) that does not have [global access](/kubernetes-engine/docs/how-to/private-clusters#enabling_control_plane_private_endpoint_global_access) enabled.\n- The remote cluster is a [private cluster](/kubernetes-engine/docs/concepts/private-cluster-concept) with [Master Authorized Network](/kubernetes-engine/docs/how-to/authorized-networks) enabled but the Cloud Service Mesh control plane IP has not been properly allowed via the allow list.\n\nGiven an unreachable API server, Istiod will output error messages in the log.\nUsers will always see requests hit the local pod during cross-cluster load\nbalancing.\n\nIn the [Logs Explorer](/logging/docs/view/logs-explorer-interface) interface,\nset the query `resource.type` to `istio_control_plane`.\n\nCheck to see if there are any invalid secret errors.\n\nTo recover from the above situation, first fix the underlying API server\nreachability issue. Then, delete all the remote secrets in every cluster and\nre-run the `create-mesh` command.\n\nMissing firewall rule\n\nWithout the proper firewall rule, users will experience a 10-second delay\nfollowed by a timeout when doing cross-cluster load balancing.\n\nTo recover from this, follow the steps outlined in\n[Create firewall rule](/service-mesh/v1.20/docs/unified-install/gke-install-multi-cluster#create_firewall_rule)."]]