解决 Cloud Service Mesh 中的规范化服务问题
注意：Cloud Service Mesh 1.6.8 及更高版本会自动支持规范化服务。
本部分介绍常见的 Cloud Service Mesh 问题以及如何解决这些问题。如果您需要其他帮助，请参阅获取支持。
网格中的集群正在运行旧版 Cloud Service Mesh
如果您的任何集群正在运行 Cloud Service Mesh 的早期版本（低于 1.6.8）或 集群正在运行且已停用规范服务控制器的 Cloud Service Mesh，则这些集群（及其上运行的服务）不会显示在 Service Mesh 界面中。要使用 Canonical 您必须将每个集群升级到 Cloud Service Mesh 1.6.8 或更高版本， 请使用包含 Canonical Service 控制器的默认安装选项。 如需了解详情，请参阅将 Cloud Service Mesh 升级到最新版本 您的集群是在 GKE 上运行 在本地升级 Cloud Service Mesh。
或者，如果您不想在集群中安装控制器，则可以为网格启用代管式规范化服务控制器（目前为预览版）。
如需详细了解如何启用规范化服务控制器，请参阅启用规范化服务控制器。
集群上未安装 Cloud Service Mesh
如果任何集群上未安装 Cloud Service Mesh，这些集群 不会出现在 Service Mesh 界面中。如需详细了解如何安装 Cloud Service Mesh，请参阅 Cloud Service Mesh 文档。
您尚未登录本地集群
如果您在网状网内有一个本地集群，并且您没有登录该集群，则您将无法查看与该集群对应的服务。您必须登录集群，才能在信息中心内查看这些服务。如需详细了解如何登录集群，请参阅从 Cloud 控制台登录集群。
您的本地集群不可达
如果您在网状网内有一个本地集群，并且无法通过连接代理访问，则无法查看与该集群对应的服务。要在信息中心中查看这些服务，请确保您的集群正在运行并且已连接到 Google Cloud。如需详细了解如何将集群连接到 Google Cloud，请参阅 Connect 概览。
定义了 SLO 的服务与规范化服务之间没有一一对应的关系
在迁移到规范服务之前，Cloud Service Mesh 显示了 Kubernetes Service 的信息中心。虽然 Kubernetes Service 和默认规范化服务通常一致，但 Kubernetes Service 可能无法自动与其对应的规范化服务匹配，或者可能不需要默认规范化服务边界。
如果您在无法自动与默认规范化服务匹配的现有服务上设置了服务等级目标 (SLO)，则无法迁移这些现有服务。如需开始使用规范化服务，您需要删除有问题服务的 SLO。如果需要，您可以在删除旧 SLO 之前为与该服务最为匹配的规范化服务创建新的 SLO。
信息中心中不包含我需要的内容
Service Mesh 服务信息中心的每个范围均限定为服务网格中的规范化服务，规范化服务是一种跨所有相关工作负载、区域等的高级逻辑服务概念。
默认情况下，每个工作负载实例（Pod 或 WorkloadEntry）中的现有标签定义了规范化服务，并遵循以下优先级递减的规则：
service.istio.io/canonical-name标签已明确设置。无需执行进一步操作。- 否则，系统会添加
service.istio.io/canonical-name标签，并将其值设置为app.kubernetes.io/name标签的值。 - 否则，系统会添加
service.istio.io/canonical-name标签，并将其值设置为app标签的值。 - 否则，系统会添加
service.istio.io/canonical-name标签，并将其值设置为自有工作负载的name。如果 Pod 是独立部署的，或者是 Deployment、StatefulSet 等，并且如果使用更高级层的编排，则在本例中为“自有工作负载”。
对于 Kubernetes 和 Kube Run/Knative 的大多数惯用用户，这些规则直接对应于您已管理服务和工作负载的方式。
然而，在一些更自定义或更复杂的用例中，默认的启发式算法 未正确捕获服务，而 Cloud Service Mesh 信息中心未包含您期望的内容。
这可以通过手动定义规范化服务范围来解决。
手动定义服务范围
如果可能，我们建议您使用自动默认分组机制。但是，如果您要替换这些默认分组，只需将 service.istio.io/canonical-name Kubernetes 标签应用于 Kubernetes Pod 和 WorkloadEntry 配置即可。
如需了解详情，请参阅手动定义规范化服务。