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.
No se muestran las cargas de trabajo de Kubernetes que no tienen un servicio de Kubernetes.
Si ves el mensaje “No se muestran las cargas de trabajo de Kubernetes que no tienen un servicio de Kubernetes. Crea un servicio de Kubernetes para cada carga de trabajo a fin de que se visualicen a continuación”, debes migrar de forma manual a los servicios canónicos.
Existen dos causas principales de este problema:
- Los clústeres de tu malla ejecutan una versión anterior de Anthos Service Mesh (< 1.6.8)
- Un servicio con SLO definidos no mapea un 1:1 con un servicio canónico
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 ASM (<1.6.8), no cumples los requisitos de los paneles basados en servicios canónicos. Si quieres usar los servicios canónicos, debes actualizar todos los clústeres a Anthos Service Mesh 1.6.8 o versiones posteriores. 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 consulta Actualiza Anthos Service Mesh de forma local si tus clústeres están en el entorno local.
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-nameya 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-namey su valor se establece en la de la etiquetaapp.kubernetes.io/name. - De lo contrario, se agrega la etiqueta
service.istio.io/canonical-namey su valor se establece en la de la etiquetaapp. - De lo contrario, se agrega la etiqueta
service.istio.io/canonical-namey su valor se establece en elnamede 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.