Anthos Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la Descripción general de Cloud Service Mesh.

Se usó la API de Cloud Translation para traducir esta página.

Resuelve problemas de servicios canónicos en Cloud Service Mesh

Nota: Los servicios canónicos se admiten automáticamente en Cloud Service Mesh 1.6.8 y versiones posteriores.

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 la 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 una clúster ejecuta Cloud Service Mesh con el controlador del servicio canónico inhabilitado, por lo que esos clústeres (y los servicios que se ejecutan en ellos) no aparecerán en la IU de Service Mesh. Para usar la versión canónica Debes actualizar cada clúster a la versión 1.6.8 o superior de Cloud Service Mesh 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, estos se no aparecen en la IU de Service Mesh. Para obtener más información sobre la instalación 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. Más información sobre cómo conectar tu clúster a Google Cloud, consulta Descripción general de Connect.

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

Antes del cambio al servicio canónico, Cloud Service Mesh mostró 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:

La etiqueta service.istio.io/canonical-name ya se estableció de forma explícita. No es necesario que realice ninguna otra acción.
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.
De lo contrario, se agrega la etiqueta service.istio.io/canonical-name y su valor se establece en la de la etiqueta app.
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 más complejos, la heurística predeterminada no capturan tu servicio adecuadamente y, a su vez, la malla de servicios 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.