Resolving Canonical Service issues in Anthos Service Mesh

Note: Canonical Services are supported automatically in Anthos Service Mesh version 1.6.8 and higher.

This section explains common Anthos Service Mesh problems and how to resolve them. If you need additional assistance, see Getting support.

Clusters in your mesh are running an older version of Anthos Service Mesh

If any of your clusters are running an earlier version of ASM (<1.6.8) or a cluster is running ASM 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 Services, you must upgrade each cluster to Anthos Service Mesh 1.6.8 or higher and use the default install option which includes the Canonical Service controller. For more information, see Upgrading Anthos Service Mesh to the latest version if your clusters are on GKE or Upgrading Anthos Service Mesh on premises if your clusters are on premises.

Alternatively, 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.

For more information about enabling the Canonical Service controller, see Enabling the Canonical Service controller.

A service with defined SLOs does not map 1:1 with a Canonical Service

Prior to the shift to Canonical Service, Anthos Service Mesh showed dashboards for Kubernetes Services. While Kubernetes Services and default Canonical Services often line up, it is possible that a Kubernetes Service can't automatically be matched to its corresponding Canonical Service or that the default Canonical Service boundary is not desired.

If you have Service Level Objectives (SLOs) set up on existing services which cannot be automatically matched to a default Canonical Service, they cannot be migrated. To start using Canonical Services you will need to delete the SLO(s) for the problematic service. If you'd like, you may create new SLOs for the Canonical Service(s) that most closely match that service before deleting the old SLO.

My dashboard doesn't have the contents I expect

The Service Mesh service dashboards are each scoped to a Canonical Service in your service mesh, where a Canonical Service is a high-level logical service concept that spans all relevant workloads, regions, etc.

By default, existing labels in each workload instance (Pod or WorkloadEntry) define Canonical Services and follow these rules in decreasing priority:

  1. The service.istio.io/canonical-name label has already been explicitly set. No further action is taken.
  2. Otherwise, the service.istio.io/canonical-name label is added and its value is set to that of the app.kubernetes.io/name label.
  3. Otherwise, the service.istio.io/canonical-name label is added and its value is set to that of the app label.
  4. 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.

For most idiomatic users of Kubernetes and Kube Run / Knative, these rules map directly to how you already manage your services and workloads.

In some more custom or more complex use cases, however, the default heuristics do not capture your service appropriately, and in turn the Anthos Service Mesh dashboard you see does not include the contents you expect.

This can be fixed by manually defining Canonical Service scope.

Manually defining the scope of a service

Wherever possible, we recommend that you use the automatic default grouping mechanisms. If you want to override these default groupings, however, you can do so by applying the service.istio.io/canonical-name Kubernetes label to your Kubernetes Pod and WorkloadEntry configurations.

For details, see manually defining a Canonical Service.