Resuelve problemas del servicio canónico en Cloud Service Mesh

Nota: Los servicios canónicos son compatibles de forma automática con la versión 1.6.8 y versiones posteriores de Cloud Service Mesh.

En esta sección, se explican los problemas comunes de Cloud Service Mesh y cómo resolverlos. Si necesitas asistencia adicional, consulta Obtén asistencia.

Los clústeres de tu malla ejecutan una versión anterior de Cloud Service Mesh.

Si alguno de tus clústeres ejecuta una versión anterior de Cloud Service Mesh (<1.6.8) o un clúster ejecuta Cloud Service Mesh con el controlador canónico de servicio inhabilitado, esos clústeres (y servicios que se ejecutan en ellos) no aparecerán en la IU de Service Mesh. Para usar los servicios canónicos, debes actualizar cada clúster a Cloud Service Mesh 1.6.8 o una versión posterior y usar la opción de instalación predeterminada que incluye el controlador del servicio canónico. Para obtener más información, consulta Actualiza Cloud Service Mesh a la versión más reciente si tus clústeres están en GKE o Actualiza Cloud Service Mesh de forma local.

Como alternativa, si prefieres no instalar el controlador en los clústeres, puedes habilitar el controlador de servicios canónicos administrados (en este momento, en la vista previa) para tu malla.

Si deseas obtener más información para habilitar el controlador del servicio canónico, consulta Habilita el controlador del servicio canónico.

La malla de servicios de Cloud no está instalada en el clúster.

Si Cloud Service Mesh no está instalado en ninguno de tus clústeres, esos clústeres no aparecerán en la IU de Service Mesh. Si deseas obtener más información para instalar Cloud Service Mesh, consulta la documentación de Cloud Service Mesh.

No accediste al clúster local

Si tienes un clúster local en la malla y no accediste al clúster, no podrás ver los servicios correspondientes a ese clúster. Para ver esos servicios en el panel, debes acceder al clúster. Para obtener más información sobre cómo acceder a un clúster, consulta Accede a un clúster desde la consola de Cloud.

No se puede acceder al clúster local

Si tienes un clúster local en la malla y no se puede acceder a él a través del agente de conexión, no podrás ver los servicios correspondientes a ese clúster. Para ver esos servicios en el panel, asegúrate de que tu clúster esté en ejecución y conectado a Google Cloud. Para obtener más información sobre cómo conectar tu clúster a Google Cloud, consulta Descripción general de la conexión.

Un servicio con SLO definidos no mapea un 1:1 con un servicio canónico

Antes del cambio a Servicio canónico, Cloud Service Mesh mostraba paneles para los servicios de Kubernetes. Si bien los servicios de Kubernetes y los servicios canónicos predeterminados a menudo están alineados, es posible que un servicio de Kubernetes no pueda coincidir automáticamente con su servicio canónico correspondiente o que no se desee el límite predeterminado del servicio canónico.

Si tienes objetivos de nivel de servicio (SLO) configurados en servicios existentes que no tengan concordancia automática con un servicio canónico predeterminado, no se pueden migrar. Si quieres comenzar a usar los servicios canónicos, deberás borrar los SLO del servicio problemático. Si lo deseas, puedes crear SLO nuevos para los servicios canónicos que coincidan más con ese servicio antes de borrar el SLO anterior.

Mi panel no tiene el contenido que esperaba

Cada panel de servicio de la malla de servicios tiene un alcance de un servicio canónico, que es un concepto de servicio lógico de alto nivel que abarca todas las cargas de trabajo relevantes, regiones, etcétera.

De manera predeterminada, las etiquetas existentes en cada instancia de carga de trabajo (Pod o WorkloadEntry) definen los servicios canónicos y siguen estas reglas con prioridad más baja:

  1. La etiqueta service.istio.io/canonical-name ya se estableció de forma explícita. No es necesario que realice ninguna otra acción.
  2. De lo contrario, se agrega la etiqueta service.istio.io/canonical-name y su valor se establece en la de la etiqueta app.kubernetes.io/name.
  3. De lo contrario, se agrega la etiqueta service.istio.io/canonical-name y su valor se establece en la de la etiqueta app.
  4. De lo contrario, se agrega la etiqueta service.istio.io/canonical-name y su valor se establece en el name de la carga de trabajo propia. La “carga de trabajo de propietario” en este caso si el Pod se implementa solo o la Deployment, StatefulSet, etc., si se usa la organización de nivel superior.

Para la mayoría de los usuarios idiomáticos de Kubernetes y Kube Run / Knative, estas reglas se asignan directamente a la forma en la que ya administras tus servicios y cargas de trabajo.

Sin embargo, en algunos casos de uso más personalizados o complejos, la heurística predeterminada no captura el servicio de manera adecuada y, a su vez, el panel de Cloud Service Mesh que ves no incluye el contenido que esperas.

Para solucionar este problema, define manualmente el alcance del servicio canónico.

Define el alcance de un servicio de forma manual

Siempre que sea posible, te recomendamos que uses los mecanismos automáticos de agrupación predeterminada. Sin embargo, si deseas anular estas agrupaciones predeterminadas, puedes aplicar la etiqueta de Kubernetes service.istio.io/canonical-name a las configuraciones de Pod de Kubernetes y WorkloadEntry.

Para obtener más información, consulta define manualmente un servicio canónico.