本部分介绍了常见的 Cloud Service Mesh 问题以及如何解决这些问题。如果您需要其他帮助，请参阅获取支持。
网格中的集群正在运行旧版 Cloud Service Mesh
如果任何集群正在运行早期版本的 Cloud Service Mesh (<1.6.8)，或者某个集群正在运行停用了规范化服务控制器的 Cloud Service Mesh，则这些集群（及其上运行的服务）将不会显示在 Service Mesh 界面中。若要使用规范化服务，您必须将每个集群升级到 Cloud Service Mesh 1.6.8 或更高版本，并使用包含规范化服务控制器的默认安装选项。如需了解详情，请参阅将 Cloud Service Mesh 升级到最新版本（如果集群位于 GKE 上）或在本地升级 Cloud Service Mesh
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-11。"],[],[],null,["# Resolving Canonical Service issues in Cloud Service Mesh\n========================================================\n\n\n**Note:** Canonical Services are supported automatically in Cloud Service Mesh version 1.6.8 and higher.\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.19/docs/getting-support).\n\nClusters in your mesh are running an older version of Cloud Service Mesh\n------------------------------------------------------------------------\n\nIf any of your clusters are running an earlier version of Cloud Service Mesh (\\\u003c1.6.8) or a\ncluster is running Cloud Service Mesh with the Canonical Service controller disabled, then those clusters (and services running on them) will not appear in the Service Mesh UI. In order to use Canonical\nServices, you must upgrade each cluster to Cloud Service Mesh 1.6.8 or higher and\nuse the default install option which includes the Canonical Service controller.\nFor more information, see [Upgrading Cloud Service Mesh to the latest version](../upgrade-path-old-versions-gke)\nif your clusters are on GKE or\n[Upgrading Cloud Service Mesh on premises](../upgrade-path-old-versions-on-prem).\n\nAlternatively, if you prefer not to install the controller in your clusters, you can enable the Managed Canonical Service Controller (currently in Preview) for your mesh.\n\nFor more information about enabling the Canonical Service controller, see [Enabling the Canonical Service controller](/service-mesh/v1.19/docs/canonical-service-controller-enable-and-disable).\n\nCloud Service Mesh is not installed on the cluster\n--------------------------------------------------\n\nIf Cloud Service Mesh is not installed on any of your clusters, those clusters will\nnot appear in the Service Mesh UI. For more information on how to install\nCloud Service Mesh, see the [Cloud Service Mesh documentation](/service-mesh/v1.19/docs).\n\nYou are not logged into the on-premise cluster\n----------------------------------------------\n\nIf you have an on-premise cluster in the mesh and you are not logged in to the\ncluster, you will not be able to view the services corresponding to that cluster.\nIn order to view those services in the dashboard, you must log in to the cluster.\nFor more information on Logging into a cluster, see\n[Logging in to a cluster from the Cloud console](/anthos/multicluster-management/console/logging-in).\n\nYour on-premise cluster is not reachable\n----------------------------------------\n\nIf you have an on-premise cluster in the mesh and it is not reachable via the\nconnect agent, you will not be able to view the services corresponding to that\ncluster. In order to view those services in the dashboard, make sure your\ncluster is running and is connected to Google Cloud. For more information\non connecting your cluster to Google Cloud, see\n[Connect Overview](/anthos/multicluster-management/connect/overview).\n\nA service with defined SLOs does not map 1:1 with a Canonical Service\n---------------------------------------------------------------------\n\nPrior to the shift to [Canonical Service](/service-mesh/v1.19/docs/canonical-service),\nCloud Service Mesh showed dashboards for Kubernetes Services. While Kubernetes\nServices and default Canonical Services often line up, it is possible that a\nKubernetes Service can't automatically be matched to its corresponding Canonical\nService or that the default Canonical Service boundary is not desired.\n\nIf you have Service Level Objectives (SLOs) set up on existing services which\ncannot be automatically matched to a default Canonical Service, they cannot be\nmigrated. To start using Canonical Services you will need to delete the SLO(s)\nfor the problematic service. If you'd like, you may\n[create new SLOs](/service-mesh/v1.19/docs/observability/create-slo) for the Canonical\nService(s) that most closely match that service before deleting the old SLO.\n\nMy dashboard doesn't have the contents I expect\n-----------------------------------------------\n\nThe Service Mesh service dashboards are each scoped to a\n[Canonical Service](/service-mesh/v1.19/docs/canonical-service) in your service mesh,\nwhere a Canonical Service is a high-level logical service concept that spans\nall relevant workloads, regions, etc.\n\nBy default, existing labels in each workload instance (Pod or WorkloadEntry)\ndefine Canonical Services and follow these rules in decreasing\npriority:\n\n1. The `service.istio.io/canonical-name` label has already been explicitly set. No further action is taken.\n2. Otherwise, the `service.istio.io/canonical-name` label is added and its value is set to that of the `app.kubernetes.io/name` label.\n3. Otherwise, the `service.istio.io/canonical-name` label is added and its value is set to that of the `app` label.\n4. Otherwise, the `service.istio.io/canonical-name` label is added and its value is set to the `name` of the owning workload. The \"owning workload\" in this case if the Pod is deployed solo, or the Deployment, StatefulSet, etc. if using higher-level orchestration.\n\nFor most idiomatic users of Kubernetes and Kube Run / Knative, these rules map\ndirectly to how you already manage your services and workloads.\n\nIn some more custom or more complex use cases, however, the default heuristics\ndo not capture your service appropriately, and in turn the Cloud Service Mesh\ndashboard you see does not include the contents you expect.\n\nThis can be fixed by manually defining Canonical Service scope.\n\nManually defining the scope of a service\n----------------------------------------\n\nWherever possible, we recommend that you use the automatic default grouping\nmechanisms. If you want to override these default groupings, however, you can do\nso by applying the `service.istio.io/canonical-name` Kubernetes label to your\nKubernetes Pod and WorkloadEntry configurations.\n\nFor details, see [manually defining a Canonical Service](/service-mesh/v1.19/docs/observability/defining-canonical-service#manual)."]]
