Resolver problemas de servicios canónicos en Cloud Service Mesh

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

En esta sección se explican los problemas habituales de Cloud Service Mesh y cómo resolverlos. Si necesitas más ayuda, consulta el artículo Obtener 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 de servicio canónico inhabilitado, esos clústeres (y los servicios que se ejecutan en ellos) no aparecerán en la interfaz de usuario de Service Mesh. Para usar los servicios de Canonical, 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 de servicios de Canonical. Para obtener más información, consulta Actualizar Cloud Service Mesh a la versión más reciente si tus clústeres están en GKE o Actualizar Cloud Service Mesh on-premise.

Si prefieres no instalar el controlador en tus clústeres, puedes habilitar el controlador de servicio canónico gestionado (actualmente en versión preliminar) en tu malla.

Para obtener más información sobre cómo habilitar el controlador del servicio canónico, consulta Habilitar el controlador del servicio canónico.

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

Si Cloud Service Mesh no está instalado en ninguno de tus clústeres, estos no aparecerán en la interfaz de usuario de Service Mesh. Para obtener más información sobre cómo instalar Cloud Service Mesh, consulta la documentación de Cloud Service Mesh.

No has iniciado sesión en el clúster local

Si tienes un clúster local en la malla y no has iniciado sesión en el clúster, no podrás ver los servicios correspondientes a ese clúster. Para ver esos servicios en el panel de control, debes iniciar sesión en el clúster. Para obtener más información sobre cómo iniciar sesión en un clúster, consulta el artículo Iniciar sesión en un clúster desde la consola de Cloud.

No se puede acceder a tu 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 de control, asegúrate de que tu clúster esté en funcionamiento y conectado a Google Cloud. Para obtener más información sobre cómo conectar tu clúster a Google Cloud, consulta el artículo Información general sobre la conexión.

Un servicio con objetivos de nivel de servicio definidos no se corresponde de forma individual con un servicio canónico

Antes del cambio a Servicio canónico, Cloud Service Mesh mostraba paneles de control de los servicios de Kubernetes. Aunque los servicios de Kubernetes y los servicios canónicos predeterminados suelen coincidir, es posible que un servicio de Kubernetes no se pueda asociar automáticamente con su servicio canónico correspondiente o que no se quiera usar el límite del servicio canónico predeterminado.

Si has configurado objetivos de nivel de servicio en servicios que no se pueden asociar automáticamente a un servicio canónico predeterminado, no se podrán migrar. Para empezar a usar los servicios canónicos, tendrás que eliminar los SLOs del servicio problemático. Si quieres, puedes crear nuevos SLOs para los servicios canónicos que mejor se adapten a ese servicio antes de eliminar el SLO antiguo.

Mi panel de control no tiene el contenido que esperaba

Los paneles de control del servicio Service Mesh se limitan a un servicio canónico de tu malla de servicios. Un servicio canónico es un concepto de servicio lógico de alto nivel que abarca todas las cargas de trabajo, regiones, etc. relevantes.

De forma predeterminada, las etiquetas de cada instancia de carga de trabajo (Pod o WorkloadEntry) definen los servicios canónicos y siguen estas reglas en orden de prioridad descendente:

1. La etiqueta service.istio.io/canonical-name ya se ha definido explícitamente. No se tomarán más medidas.
2. De lo contrario, se añade la etiqueta service.istio.io/canonical-name y su valor se asigna al de la etiqueta app.kubernetes.io/name.
3. De lo contrario, se añade la etiqueta service.istio.io/canonical-name y su valor se asigna al de la etiqueta app.
4. De lo contrario, se añade la etiqueta service.istio.io/canonical-name y su valor se asigna al name de la carga de trabajo propietaria. En este caso, la "carga de trabajo propietaria" es el pod si se implementa solo, o la implementación, StatefulSet, etc. si se usa una orquestación de nivel superior.

Para la mayoría de los usuarios de Kubernetes y Kube Run o Knative, estas reglas se corresponden directamente con la forma en que ya gestionan sus 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 correctamente y, por lo tanto, el panel de control de Cloud Service Mesh que ves no incluye el contenido que esperas.

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

Definir manualmente el ámbito de un servicio

Siempre que sea posible, le recomendamos que utilice los mecanismos de agrupación predeterminados automáticos. Sin embargo, si quieres anular estas agrupaciones predeterminadas, puedes hacerlo aplicando la etiqueta de Kubernetes service.istio.io/canonical-name a tus configuraciones de Pod y WorkloadEntry de Kubernetes.

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

Resolver problemas con el controlador canónico gestionado

1. Comprobar el estado de la función: ejecuta el siguiente comando, donde FLEET_PROJECT_ID es el ID de tu proyecto de host de flota. Por lo general, el ID de proyecto de la flota se crea de forma predeterminada y tiene el mismo nombre que el proyecto.

  gcloud container fleet mesh describe --project FLEET_PROJECT_ID
  

Ejemplo:

      membershipStates:
        projects/<project-number>/locations/<location>/memberships/<membership-name>:
          state:
            code: OK
            description: 
              Revision(s) ready for use: istiod-asm-183-2.
              All Canonical Services have been reconciled successfully.

2. Toma medidas en función de state.code:

En el resultado del estado de la función, comprueba el estado de tu clúster. Examina el valor de state.code, que te ayudará a conocer el estado actual del CSC gestionado. En función del valor de state.code, implementa las acciones correspondientes:

• MISSING:

  1. Espera una hora para que se produzcan posibles retrasos en la inicialización.
  2. Vuelve a ejecutar el comando gcloud container fleet mesh describe --project <FLEET_PROJECT_ID>. Si sigues sin encontrar state.code, ponte en contacto con el equipo de Asistencia de Google Cloud para obtener ayuda.

• WARNING/ERROR:

  1. Consulta el servicemesh.conditions para obtener información detallada sobre el error.
  2. Si se encuentra la condición CANONICAL_SERVICE_ERROR, el controlador del servicio canónico gestionado tiene un problema. Si no es así, es probable que el problema sea externo al controlador del servicio canónico.
  3. En ambos casos, ponte en contacto con el equipo de Asistencia de Google Cloud para obtener más información sobre cómo solucionar el problema.

• OK: consulta la siguiente tabla para ver las acciones que se deben llevar a cabo en función del texto de state.description: