解决 Anthos Service Mesh 中的规范化服务问题

注意:Anthos Service Mesh 1.6.8 及更高版本会自动支持规范化服务。

本部分介绍常见的 Anthos Service Mesh 问题以及如何解决这些问题。如果您需要其他帮助,请参阅获取支持

不显示没有相应 Kubernetes 服务的 Kubernetes 工作负载

如果您看到“不显示没有相应 Kubernetes 服务的 Kubernetes 工作负载。请为每个工作负载创建 Kubernetes 服务,以便在下面查看”,则您需要手动迁移到规范化服务。

此问题有两个主要原因:

  1. 网状网中的集群正在运行旧版 Anthos Service Mesh (<1.6.8)
  2. 定义了 SLO 的服务与规范化服务之间没有一一对应的关系

网状网中的集群正在运行旧版 Anthos Service Mesh

如果您的任何集群正在运行早期版本的 ASM (<1.6.8),则您无法使用基于规范化服务的信息中心。您必须将所有集群升级到 Anthos Service Mesh 1.6.8 或更高版本才能使用规范化服务。如需了解详情,请参阅将 Anthos Service Mesh 升级到最新版本(如果您的集群位于 GKE 上)或在本地升级 Anthos Service Mesh(如果您的集群位于本地)。

定义了 SLO 的服务与规范化服务之间没有一一对应的关系

在迁移到规范服务之前,Anthos Service Mesh 显示了 Kubernetes Service 的信息中心。虽然 Kubernetes Service 和默认规范化服务通常一致,但 Kubernetes Service 可能无法自动与其对应的规范化服务匹配,或者可能不需要默认规范化服务边界。

如果您在无法自动与默认规范化服务匹配的现有服务上设置了服务等级目标 (SLO),则无法迁移这些现有服务。如需开始使用规范化服务,您需要删除有问题服务的 SLO。如果需要,您可以在删除旧 SLO 之前为与该服务最为匹配的规范化服务创建新的 SLO

信息中心中不包含我需要的内容

Service Mesh 服务信息中心的每个范围均限定为服务网格中的规范化服务,规范化服务是一种跨所有相关工作负载、区域等的高级逻辑服务概念。

默认情况下,每个工作负载实例(Pod 或 WorkloadEntry)中的现有标签定义了规范化服务,并遵循以下优先级递减的规则:

  1. service.istio.io/canonical-name 标签已明确设置。无需执行进一步操作。
  2. 否则,系统会添加 service.istio.io/canonical-name 标签,并将其值设置为 app.kubernetes.io/name 标签的值。
  3. 否则,系统会添加 service.istio.io/canonical-name 标签,并将其值设置为 app 标签的值。
  4. 否则,系统会添加 service.istio.io/canonical-name 标签,并将其值设置为自有工作负载的 name。如果 Pod 是独立部署的,或者是 Deployment、StatefulSet 等,并且如果使用更高级层的编排,则在本例中为“自有工作负载”。

对于 Kubernetes 和 Kube Run/Knative 的大多数惯用用户,这些规则直接对应于您已管理服务和工作负载的方式。

但是,在其他一些自定义或更复杂的用例中,默认启发法无法适当地捕获您的服务,而您看到的 Anthos Service Mesh 信息中心中不包含您需要的内容。

这可以通过手动定义规范化服务范围来解决。

手动定义服务范围

如果可能,我们建议您使用自动默认分组机制。但是,如果您要替换这些默认分组,只需将 service.istio.io/canonical-name Kubernetes 标签应用于 Kubernetes Pod 和 WorkloadEntry 配置即可。

如需了解详情,请参阅手动定义规范化服务