Resolver problemas de Cloud Service Mesh gestionado

En este documento se explican los problemas habituales de Cloud Service Mesh y cómo resolverlos, como cuando se inserta istio.istio-system en un pod, la herramienta de instalación genera errores como códigos de estado HTTP 400 y errores de pertenencia al clúster.

Si necesitas más ayuda para solucionar problemas de Cloud Service Mesh, consulta Obtener asistencia.

Las revisiones muestran un error de estado incorrecto

Es posible que veas un error genérico Revision(s) reporting unhealthy si el agente de servicio de la malla de servicios de Cloud gestionada no tiene el rol de Gestión de Identidades y Accesos (IAM) necesario. Por lo general, esto ocurre cuando Terraform, Puppet o la reconfiguración de CI/CD revocan el rol.

Los pasos necesarios para solucionar este error dependen de si usas la Google Cloud consola o la CLI de Google Cloud.

Google Cloud consola

  1. En la Google Cloud consola, ve a IAM y administración > IAM.

  2. Selecciona Incluir concesiones de roles proporcionadas por Google.

  3. Revisa la lista Principal (Principal).

    Si ves el agente de servicio con el rol de gestión de identidades y accesos necesario en la lista, significa que está configurado correctamente.

    Si la lista no incluye el agente de servicio y el rol necesario, continúa con el siguiente paso.

  4. Asigna el rol Agente de servicio de Anthos Service Mesh (roles/anthosservicemesh.serviceAgent) al agente de servicio de Cloud Service Mesh en el proyecto. Para obtener instrucciones, consulta el artículo Gestionar acceso a proyectos, carpetas y organizaciones.

Google Cloud CLI

  1. En la CLI de Google Cloud, ejecuta el siguiente comando para comprobar si se ha concedido el rol de gestión de identidades y accesos necesario:

    gcloud projects get-iam-policy PROJECT_ID  \
    --flatten="bindings[].members" \
    --filter="bindings.members:serviceAccount:service-PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com AND bindings.role:roles/anthosservicemesh.serviceAgent" \
    --format='table(bindings.role)'
    
  2. Revisa la lista ROLE.

    Si ves algún rol en la lista, significa que está configurado correctamente.

    Si no ve ningún rol en la lista, significa que se ha revocado el rol necesario.

  3. Para asignar el rol necesario al agente de servicio, ejecuta el siguiente comando:

     gcloud projects add-iam-policy-binding PROJECT_ID \
     --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
     --role="roles/anthosservicemesh.serviceAgent"
    

La herramienta de instalación genera errores HTTP 400

La herramienta de instalación puede generar errores HTTP 400 como los siguientes:

HealthCheckContainerError, message: Cloud Run error: Container failed to start.
Failed to start and then listen on the port defined by the PORT environment
variable. Logs for this revision might contain more information.

Este error puede producirse si no has habilitado Identidad de carga de trabajo en tu clúster de Kubernetes. Para hacerlo, puedes usar el siguiente comando:

export CLUSTER_NAME=...
export PROJECT_ID=...
export LOCATION=...
gcloud container clusters update $CLUSTER_NAME --zone $LOCATION \
    --workload-pool=$PROJECT_ID.svc.id.goog

Estado del plano de datos gestionado

El siguiente comando muestra el estado del plano de datos gestionado:

gcloud container fleet mesh describe --project PROJECT_ID

En la siguiente tabla se enumeran todos los estados posibles del plano de datos gestionado:

Estado Código Descripción
ACTIVE OK El plano de datos gestionado funciona con normalidad.
DISABLED DISABLED El plano de datos gestionado estará en este estado si no se ha configurado ningún espacio de nombres ni ninguna revisión para usarlo. Sigue las instrucciones para habilitar Cloud Service Mesh gestionado mediante la API de flota o habilitar el plano de datos gestionado después de aprovisionar Cloud Service Mesh gestionado con asmcli. Ten en cuenta que los informes de estado del plano de datos gestionado solo están disponibles si has habilitado el plano de datos gestionado añadiendo una anotación a un espacio de nombres o a una revisión. Si anotas pods individuales, estos se gestionarán, pero con el estado de la función DISABLED si no se anota ningún espacio de nombres ni ninguna revisión.
FAILED_PRECONDITION MANAGED_CONTROL_PLANE_REQUIRED El plano de datos gestionado requiere un plano de control de Cloud Service Mesh gestionado activo.
PROVISIONING PROVISIONING Se está aprovisionando el plano de datos gestionado. Si este estado persiste durante más de 10 minutos, es probable que se haya producido un error y debas ponerte en contacto con el equipo de Asistencia.
STALLED INTERNAL_ERROR El plano de datos gestionado no puede funcionar debido a un error interno. Si el problema persiste, ponte en contacto con el equipo de Asistencia.
NEEDS_ATTENTION UPGRADE_FAILURES El plano de datos gestionado requiere una intervención manual para que el servicio vuelva a su estado normal. Para obtener más información sobre cómo resolver este problema, consulta el estado NEEDS_ATTENTION.

NEEDS_ATTENTION estado

Si el comando gcloud container fleet mesh describe muestra que el estado del plano de datos gestionado es NEEDS_ATTENTION y el código es UPGRADE_FAILURES, significa que el plano de datos gestionado no ha podido actualizar determinadas cargas de trabajo. Estas cargas de trabajo se etiquetarán con dataplane-upgrade: failed por el servicio de plano de datos gestionado para su posterior análisis. Los proxies deben reiniciarse manualmente para actualizarse. Para obtener la lista de pods que requieren atención, ejecuta el siguiente comando:

kubectl get pods --all-namespaces -l dataplane-upgrade=failed

Error de pertenencia al clúster (no se ha especificado ningún proveedor de identidades)

Es posible que la herramienta de instalación falle y muestre errores de pertenencia al clúster, como los siguientes:

asmcli: [ERROR]: Cluster has memberships.hub.gke.io CRD but no identity
provider specified. Please ensure that an identity provider is available for the
registered cluster.

Este error puede producirse si no tienes habilitado Workload Identity de GKE antes de registrar el clúster. Puedes volver a registrar el clúster en la línea de comandos mediante el comando gcloud container fleet memberships register --enable-workload-identity.

Comprobar el estado del plano de control gestionado

Para comprobar el estado del plano de control gestionado, ejecuta gcloud container fleet mesh describe --project FLEET_PROJECT_ID.

En la respuesta, el campo membershipStates[].servicemesh.controlPlaneManagement.details puede explicar el error específico.

Si necesitas más detalles, consulta el ControlPlaneRevisionrecurso personalizadoControlPlaneRevision del clúster, que se actualiza cuando se aprovisiona el plano de control gestionado o cuando falla el aprovisionamiento.

Para inspeccionar el estado del recurso, sustituye NAME por el valor correspondiente a cada canal: asm-managed, asm-managed-stable o asm-managed-rapid.

kubectl describe controlplanerevision NAME -n istio-system

La salida es similar a la siguiente:

    Name:         asm-managed

    …

    Status:
      Conditions:
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               The provisioning process has completed successfully
        Reason:                Provisioned
        Status:                True
        Type:                  Reconciled
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has finished
        Reason:                ProvisioningFinished
        Status:                True
        Type:                  ProvisioningFinished
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has not stalled
        Reason:                NotStalled
        Status:                False
        Type:                  Stalled

La condición Reconciled determina si el plano de control gestionado funciona correctamente. Si true, el plano de control se está ejecutando correctamente. Stalled determina si el proceso de aprovisionamiento del plano de control gestionado ha encontrado un error. Si Stalled, el campo Message contiene más información sobre el error específico. Consulta la sección Códigos detenidos para obtener más información sobre los posibles errores.

ControlPlaneRevision Stalled Codes

Hay varios motivos por los que la condición Stalled puede ser verdadera en el estado ControlPlaneRevisions.

Motivo Mensaje Descripción
PreconditionFailed Solo se admiten las pertenencias a GKE, pero ${CLUSTER_NAME} no es un clúster de GKE. El clúster actual no parece ser un clúster de GKE. El plano de control gestionado solo funciona en clústeres de GKE.
Nombre de ControlPlaneRevision no admitido: ${NAME} El nombre de ControlPlaneRevision debe ser uno de los siguientes:
  • Gestionado por ASM
  • asm-managed-rapid
  • asm-managed-stable
Espacio de nombres de ControlPlaneRevision no admitido: ${NAMESPACE} El espacio de nombres de ControlPlaneRevision debe ser istio-system.
Canal ${CHANNEL} no admitido para ControlPlaneRevision con el nombre${NAME}. Se esperaba ${OTHER_CHANNEL} El nombre de ControlPlaneRevision debe coincidir con el canal de ControlPlaneRevision con lo siguiente:
  • asm-managed -> regular
  • asm-managed-rapid -> rapid
  • asm-managed-stable -> stable
El canal no debe omitirse ni estar en blanco Channel es un campo obligatorio en ControlPlaneRevision. Falta o está en blanco en el recurso personalizado.
Tipo de revisión del plano de control no admitido: ${TYPE} managed_service es el único campo permitido para el campo ControlPlaneRevisionType.
Versión de Kubernetes no compatible: ${VERSION} Se admiten las versiones 1.15 y posteriores de Kubernetes.
Workload Identity no está habilitado Habilita Workload Identity en tu clúster.
Grupo de cargas de trabajo no admitido: ${POOL} El grupo de cargas de trabajo debe tener el formato ${PROJECT_ID}.svc.id.goog.
ProvisioningFailed No se han podido actualizar los recursos del clúster Google no ha podido actualizar los recursos de tu clúster, como los CRDs y los webhooks.
MutatingWebhookConfiguration "istiod-asm-managed" contiene un webhook con la URL ${EXISTING_URL}, pero se esperaba ${EXPECTED_URL} Google no sobrescribirá los webhooks que ya tengas para no interrumpir tu instalación. Actualízalo manualmente si quieres que se comporte de esta forma.
ValidatingWebhookConfiguration ${NAME} contiene un webhook con la URL ${EXISTING_URL}, pero se esperaba ${EXPECTED_URL} Google no sobrescribirá los webhooks que ya tengas para no interrumpir tu instalación. Actualízalo manualmente si quieres que se comporte de esta forma.

Managed Cloud Service Mesh no puede conectarse al clúster de GKE

Entre junio y septiembre del 2022, Google completó el trabajo de seguridad relacionado con las redes autorizadas, Cloud Run y Cloud Run Functions en Google Kubernetes Engine (GKE). Los proyectos que usaban Cloud Service Mesh gestionado anteriormente, pero que dejaron de usarlo antes de la migración, no tienen la API necesaria para la comunicación entre Cloud Run y GKE.

En este caso, el aprovisionamiento gestionado de Cloud Service Mesh fallará y Cloud Logging mostrará el siguiente mensaje de error:

Connect Gateway API has not been used in project [*PROJECT_NUMBER*] before or it is disabled.
Enable it by visiting https://console.developers.google.com/apis/api/connectgateway.googleapis.com/overview?project=[*PROJECT_NUMBER*] then retry.
If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.

Filtra este mensaje con la siguiente consulta:

resource.type="istio_control_plane"
resource.labels.project_id=[*PROJECT_ID*]
resource.labels.location=[*REGION*]
severity=ERROR
jsonPayload.message=~"Connect Gateway API has not been used in project"

Mientras tanto, la inyección de sidecar y la implementación de cualquier recurso personalizado de Kubernetes relacionado con Cloud Service Mesh también fallarán y Cloud Logging mostrará el siguiente mensaje de advertencia:

Error creating: Internal error occurred: failed calling webhook
"rev.namespace.sidecar-injector.istio.io": failed to call webhook: an error on
the server ("unknown") has prevented the request from succeeding.

Filtra este mensaje con la siguiente consulta:

resource.type="k8s_cluster"
resource.labels.project_id=[*PROJECT_ID*]
resource.labels.location=[*REGION*]
resource.labels.cluster_name=[*CLUSTER_NAME*]
severity=WARNING
jsonPayload.message=~"Internal error occurred: failed calling webhook"

Para solucionar este problema, sigue estos pasos:

  1. Habilita la API connectgateway necesaria:

     gcloud services enable connectgateway.googleapis.com --project=[*PROJECT_ID*]
    
  2. Vuelve a instalar Cloud Service Mesh gestionado.

  3. Realiza un reinicio gradual de las cargas de trabajo.

Las APIs deGoogle Cloud no están habilitadas

Si tu flota de Cloud Service Mesh gestionada usa la TRAFFIC_DIRECTOR implementación del plano de control, debes habilitar determinadas APIs.

  1. Habilita todas las APIs necesarias, incluidas las que se indican como "Se pueden inhabilitar" cuando no se usa Cloud Service Mesh gestionado.

    gcloud services enable --project=[*PROJECT_ID*] \
        trafficdirector.googleapis.com \
        networkservices.googleapis.com \
        networksecurity.googleapis.com
    
  2. Asegúrate de que no tienes ninguna herramienta automatizada que deshaga este cambio. Si el error se repite, actualiza las configuraciones o listas de permitidos pertinentes.