En este documento, se explican los problemas comunes de Anthos Service Mesh y cómo resolverlos. Por ejemplo, cuando se inserta un pod con istio.istio-system
, la herramienta de instalación genera errores como los códigos de estado 400
HTTP y en la membresía del clúster.
Si necesitas asistencia adicional para solucionar problemas de Anthos Service Mesh, consulta Obtén asistencia.
Las revisiones se informan como errores de mal estado
Es posible que veas un error genérico Revision(s) reporting unhealthy
si Anthos Service Mesh administrado no tiene la cuenta de servicio administrada por Google requerida con las vinculaciones de funciones de Identity and Access Management (IAM) del agente de servicio de Anthos Service Mesh. Por lo general, esto ocurre cuando se revoca el permiso de la función de agente de servicio de Anthos Service Mesh mediante la reconfiguración de Terraform, Puppet o CI/CD.
Los pasos necesarios para solucionar este error dependen de si usas la consola de Google Cloud o Google Cloud CLI.
Consola de Google Cloud
En la consola de Google Cloud, navega a IAM y administración > IAM.
Selecciona Incluir asignaciones de roles proporcionadas por Google.
Revisa la lista de Principal.
Si ves la cuenta de servicio administrada con el rol de IAM necesario en la lista, entonces está configurada de forma correcta.
Si no ves la cuenta de servicio administrada requerida con el rol de IAM requerido en la lista, la vinculación de función de IAM necesaria para el agente de servicio de Anthos Service Mesh no existe en la cuenta de servicio administrada.
Otorga al agente de servicio de Anthos Service Mesh (
roles/anthosservicemesh.serviceAgent
) vinculaciones de funciones de IAM a la cuenta de servicio administrada de Anthos Service Mesh en la consola de Google Cloud.
Google Cloud CLI
En Google Cloud CLI, ejecuta el siguiente comando para verificar si se configuró el rol de IAM requerido:
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)'
Revisa la lista
ROLE
.Si ves algún rol en la lista, significa que está configurado correctamente.
Si no ves ningún rol en la lista, significa que se revocaron todos los roles de la cuenta de servicio administrada.
Ejecuta el siguiente comando para asignar las vinculaciones de función de IAM adecuadas a la cuenta de servicio administrada de Anthos Service Mesh:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role="roles/anthosservicemesh.serviceAgent"
El Pod se inyecta con istiod.istio-system
Esto puede suceder si no reemplazaste la etiqueta istio-injection: enabled
.
Además, usa el siguiente comando para verificar la configuración de webhooks de mutación:
kubectl get mutatingwebhookconfiguration
...
istiod-asm-managed
…
# may include istio-sidecar-injector
kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml
# Run debug commands
export T=$(echo '{"kind":"TokenRequest","apiVersion":"authentication.k8s.io/v1","spec":{"audiences":["istio-ca"], "expirationSeconds":2592000}}' | kubectl create --raw /api/v1/namespaces/default/serviceaccounts/default/token -f - | jq -j '.status.token')
export INJECT_URL=$(kubectl get mutatingwebhookconfiguration istiod-asmca -o json | jq -r .webhooks[0].clientConfig.url)
export ISTIOD_ADDR=$(echo $INJECT_URL | 'sed s/\/inject.*//')
curl -v -H"Authorization: Bearer $T" $ISTIOD_ADDR/debug/configz
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 ocurrir si no habilitaste Workload Identity en tu clúster de Kubernetes, lo que puedes hacer con 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 administrado
Con el siguiente comando, se muestra el estado del plano de datos administrado:
gcloud container fleet mesh describe --project PROJECT_ID
En la siguiente tabla, se enumeran todos los estados posibles del plano de datos administrado:
Estado | Código | Descripción |
---|---|---|
ACTIVE |
OK |
El plano de datos administrado se ejecuta con normalidad. |
DISABLED |
DISABLED |
El plano de datos administrado estará en este estado si no se configuró ningún espacio de nombres ni
revisión para usarlo. Sigue las instrucciones para
habilitar Anthos Service Mesh administrado mediante la API de la flota o
habilitar el plano de datos administrado después de aprovisionar Anthos Service Mesh administrado con asmcli .
Ten en cuenta que los informes de estado del plano de datos administrado solo están disponibles si habilitaste el plano de datos administrado mediante la anotación de un espacio de nombres o una revisión.
La anotación de Pods individuales hace que estos se administren, pero con un estado de función de DISABLED si no se anotan espacios de nombres ni revisiones. |
FAILED_PRECONDITION |
MANAGED_CONTROL_PLANE_REQUIRED |
El plano de datos administrado requiere un plano de control activo de Anthos Service Mesh. |
PROVISIONING |
PROVISIONING |
Se está aprovisionando el plano de datos administrado. Si este estado persiste por más de 10 minutos, es probable que se haya producido un error y deberías comunicarte con el equipo de asistencia. |
STALLED |
INTERNAL_ERROR |
El plano de datos administrado está bloqueado debido a una condición de error interna. Si el problema persiste, comunícate con el equipo de asistencia. |
NEEDS_ATTENTION |
UPGRADE_FAILURES |
El plano de datos administrado requiere una intervención manual para que el servicio vuelva al estado normal. Para obtener más información y cómo resolver este problema, consulta el estado NEEDS_ATTENTION . |
NEEDS_ATTENTION
state
Si el comando gcloud container fleet mesh describe
muestra que el estado del plano de datos administrado está en estado NEEDS_ATTENTION
y el código es UPGRADE_FAILURES
, el plano de datos administrado no pudo actualizar ciertas cargas de trabajo. El servicio del plano de datos administrado etiquetará estas cargas de trabajo con dataplane-upgrade: failed
para analizarlas en detalle. Los proxies se deben reiniciar de forma manual para que se actualicen. 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 membresía del clúster (no se especificó ningún proveedor de identidad)
La herramienta de instalación puede fallar con errores de membresía del 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.
El error puede ocurrir si no tienes habilitada la carga de trabajo de GKE Identity 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
.
Verifica el estado del plano de control administrado
Para verificar el estado del plano de control administrado, 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, verifica el recurso personalizado ControlPlaneRevision
en el clúster, que se actualiza cuando se aprovisiona el plano de control administrado o cuando falla el aprovisionamiento.
Para inspeccionar el estado del recurso, reemplaza NAME por el valor correspondiente a cada canal: asm-managed
, asm-managed-stable
o asm-managed-rapid
.
kubectl describe controlplanerevision NAME -n istio-system
El resultado es similar al 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 administrado se ejecuta de forma correcta. Si es true
, el plano de control se ejecuta de forma correcta.
Stalled
determina si el proceso de aprovisionamiento del plano de control administrado encontró un error. Si es Stalled
, el campo Message
contiene más información sobre el error específico. Consulta Códigos detenidos para obtener más información sobre los posibles errores.
Códigos detenidos de ControlPlaneRevision
Hay varias razones por las que la condición Stalled
podría convertirse en verdadera en el estado ControlPlaneRevisions
.
Motivo | Mensaje | Descripción |
---|---|---|
PreconditionFailed | Solo se admiten las membresías de GKE, pero ${CLUSTER_NAME} no es un clúster de GKE. | Parece que el clúster actual no es un clúster de GKE. El plano de control administrado solo funciona en los clústeres de GKE. |
Nombre de ControlPlaneRevision no admitido: ${NAME} | El nombre de ControlPlaneRevision debe ser uno de los siguientes:
|
|
Unsupported ControlPlaneRevision namespace: ${NAMESPACE} | El espacio de nombres de ControlPlaneRevision debe ser istio-system . |
|
El canal ${Channel} no se admite para ControlPlaneRevision con el nombre${NAME}. Se esperaba ${OTHER_Channel} | El nombre de ControlControleRevision debe coincidir con el canal de ControlPlaneRevision en función de la siguiente información:
|
|
No se debe omitir el canal ni dejarlo en blanco | Channel es un campo obligatorio en ControlPlaneRevision. Falta en el recurso personalizado o está vacío. |
|
Tipo de revisión del plano de control no compatible: ${TYPE} | managed_service es el único campo de permiso para el campo ControlPlaneRevisionType. |
|
Versión de Kubernetes no compatible: ${VERSION} | Las versiones de Kubernetes 1.15 y posteriores son compatibles. | |
La identidad de carga de trabajo no está habilitada. | Habilita la identidad de carga de trabajo en el clúster. | |
Grupo de cargas de trabajo no compatible: ${POOL} | El grupo de cargas de trabajo debe tener el formato ${PROJECT_ID}.svc.id.goog . |
|
El proyecto de clúster y el de Environ no coinciden | Los clústeres deben pertenecer al mismo proyecto en el que están registrados en la flota. | |
ProvisioningFailed | Se produjo un error mientras se actualizaban los recursos del clúster | Google no pudo actualizar los recursos en el clúster, como los CRD y los webhooks. |
MutatingWebhookConfiguration "istiod-asm-managed" contiene un webhook con la URL ${EXISTING_URL}, pero se espera ${EXPECTED_URL} | Google no reemplazará los webhooks existentes para evitar que se rompa la instalación. Actualiza esto de forma manual si deseas tener un comportamiento deseado. | |
ValidingWebhookConfiguration ${NAME} contiene un webhook con la URL ${EXISTING_URL}, pero se espera ${EXPECTED_URL} | Google no reemplazará los webhooks existentes para evitar que se rompa la instalación. Actualiza esto de forma manual si deseas tener un comportamiento deseado. |
Anthos Service Mesh administrado no puede conectarse al clúster de GKE
Entre junio y septiembre de 2022, Google completó el trabajo de seguridad relacionado con las redes autorizadas, Cloud Run y Cloud Functions en Google Kubernetes Engine (GKE). Los proyectos que antes usaban Anthos Service Mesh administrado, 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 esta situación, el aprovisionamiento administrado de Anthos 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 inserción de sidecar y la implementación de recursos personalizados de Kubernetes relacionados con Anthos 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 resolver el problema, sigue estos pasos:
Habilita la API de
connectgateway
requerida:gcloud services enable connectgateway.googleapis.com --project=[*PROJECT_ID*]
Realiza un reinicio progresivo de las cargas de trabajo.