Versión 1.17

Versiones disponibles

<ph1-3-14.2-14.2-14.19-20.2.19-20.2.-2.-3.3.3.3.-3.2.-3.3.3.3.3.<.<.<ph1.9-2.-3.3.9.9. o.-3.-.<.<.<.

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

Resuelve problemas de servicios canónicos en Anthos Service Mesh

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

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

Los clústeres de tu malla están ejecutando una versión anterior de Anthos Service Mesh

Si alguno de tus clústeres ejecuta una versión anterior de Anthos Service Mesh (<1.6.8) o un clúster ejecuta Anthos Service Mesh con el controlador de servicio canónico inhabilitado, esos clústeres (y servicios que se ejecutan en ellos) no aparecerán en la IU de la malla de servicios. Para usar los servicios canónicos, debes actualizar cada uno de los clústeres a Anthos Service Mesh 1.6.8 o versiones posteriores, 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 Anthos Service Mesh a la versión más reciente si tus clústeres están en GKE o Actualiza Anthos 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.

Anthos Service Mesh no está instalado en el clúster

Si Anthos Service Mesh no está instalado en ninguno de tus clústeres, esos clústeres no aparecerán en la IU de Service Mesh. Si quieres obtener más información para instalar Anthos Service Mesh, consulta la documentación de Anthos 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 de hacer el cambio al servicio canónico, Anthos Service Mesh mostró paneles de 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 prácticos más personalizados o complejos, las heurísticas predeterminadas no capturan tu servicio de manera correcta y, a su vez, el panel de Anthos Service Mesh no incluye los contenidos que esperabas.

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.