You are viewing documentation for Anthos Service Mesh 1.8. View the latest documentation or select another available version:

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.

Kubernetes workloads without a Kubernetes Service are not displayed

If you see "Kubernetes workloads without a Kubernetes Service are not displayed. Create a Kubernetes Service for each workload to view them below," you need to manually migrate to Canonical Services.

There are two main causes of this issue:

  1. Clusters in your mesh are running an older version of Anthos Service Mesh (< 1.6.8)
  2. A service with defined SLOs does not map 1:1 with a Canonical Service

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), you are not eligible for Canonical-Service-based dashboards. In order to use Canonical Services, you must upgrade all clusters to Anthos Service Mesh 1.6.8 or higher. 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.

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.