Solución de problemas de App Mesh para Kubernetes

En este tema se describen los problemas comunes que pueden ocurrir al usar App Mesh con Kubernetes.

Los recursos de App Mesh creados en Kubernetes no se encuentran en App Mesh

Síntomas

Has creado los recursos de App Mesh con la definición de recursos personalizada (CRD) de Kubernetes, pero los recursos que has creado no están visibles en App Mesh cuando utilizas las API o. AWS Management Console

Resolución

La causa probable es un error del controlador de Kubernetes para App Mesh. Para obtener más información, consulte Solución de problemas en. GitHub Compruebe los registros del controlador para ver si hay errores o advertencias que indiquen que el controlador no ha podido crear ningún recurso.

kubectl logs -n appmesh-system -f \
    $(kubectl get pods -n appmesh-system -o name | grep controller)

Si el problema sigue sin resolverse, considera abrir un GitHub problema o ponte en contacto con AWS Support.

Las comprobaciones de disponibilidad y vivacidad de los pods tienen errores después de inyectar el sidecar de Envoy

Síntomas

Los pods de su aplicación se ejecutaban correctamente anteriormente, pero una vez que se inyecta el sidecar de Envoy en un pod, las comprobaciones de disponibilidad y vivacidad comienzan a producir errores.

Resolución

Asegúrese de que el contenedor de Envoy que se inyectó en el pod se haya iniciado con el servicio de administración de Envoy de App Mesh. Puede verificar cualquier error consultando los códigos de error en Envoy se desconectó del servicio de administración de Envoy de App Mesh mostrando un texto de error. Puede usar el siguiente comando para examinar los registros de Envoy del pod correspondiente.

kubectl logs -n appmesh-system -f \
    $(kubectl get pods -n appmesh-system -o name | grep controller) \
    | grep "gRPC config stream closed"

Si el problema sigue sin resolverse, considera abrir un GitHub problema o ponte en contacto con AWS Support.

Los pods no se registran ni anulan el registro como instancias de AWS Cloud Map

Síntomas

Tus pods de Kubernetes no se registran ni se cancelan AWS Cloud Map como parte de su ciclo de vida. Es posible que un pod se inicie correctamente y esté listo para enviar tráfico, pero no para recibirlo. Cuando se cierra un pod, es posible que los clientes aún conserven su dirección IP e intenten enviarle tráfico, lo cual no funciona.

Resolución

Se trata de un problema conocido. Para obtener más información, consulta los pods no se registran o se cancelan automáticamente en Kubernetes con problemas. AWS Cloud Map GitHub Debido a la relación entre los pods, los nodos virtuales de App Mesh y los AWS Cloud Map recursos, el controlador App Mesh para Kubernetes puede desincronizarse y perder recursos. Por ejemplo, esto puede suceder si se elimina un recurso de nodo virtual de Kubernetes antes de cerrar los pods asociados.

Para mitigar este problema:

• Asegúrese de ejecutar la última versión del controlador de App Mesh para Kubernetes.

• Asegúrese de que las letras AWS Cloud Map namespaceName y serviceName sean correctas en la definición de su nodo virtual.

• Asegúrese de eliminar todos los pods asociados antes de eliminar la definición de su nodo virtual. Si necesita ayuda para identificar qué pods están asociados a un nodo virtual, consulte No es posible determinar dónde se ejecuta un pod para un recurso de App Mesh.

• Si el problema persiste, ejecute el siguiente comando para examinar los registros del controlador en busca de errores que puedan ayudar a descubrir el problema subyacente.

  kubectl logs -n appmesh-system \
      $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)

• Considere la posibilidad de usar el comando siguiente para reiniciar los pods de su controlador. Esto podría solucionar problemas de sincronización.

  kubectl delete -n appmesh-system \
      $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)

Si el problema sigue sin resolverse, considera abrir un GitHub problema o ponte en contacto con AWS Support.

No es posible determinar dónde se ejecuta un pod para un recurso de App Mesh

Síntomas

Cuando ejecuta App Mesh en un clúster de Kubernetes, un operador no puede determinar dónde se ejecuta una carga de trabajo, o pod, para un recurso de App Mesh determinado.

Resolución

Los recursos del pod de Kubernetes se anotan con la malla y el nodo virtual a los que están asociados. Puede consultar qué pods se están ejecutando para un nombre de nodo virtual determinado con el siguiente comando.

kubectl get pods --all-namespaces -o json | \
    jq '.items[] | { metadata } | select(.metadata.annotations."appmesh.k8s.aws/virtualNode" == "virtual-node-name")'

Si el problema sigue sin resolverse, considera abrir un GitHub problema o ponte en contacto con AWS Support.

No se puede determinar cómo qué recurso de App Mesh se está ejecutando un pod

Síntomas

Al ejecutar App Mesh en un clúster de Kubernetes, un operador no puede determinar cómo qué recurso de App Mesh se está ejecutando un pod determinado.

Resolución

Los recursos del pod de Kubernetes se anotan con la malla y el nodo virtual a los que están asociados. Puede generar los nombres de la malla y de los nodos virtuales consultando el pod directamente con el siguiente comando.

kubectl get pod pod-name -n namespace -o json | \
    jq '{ "mesh": .metadata.annotations."appmesh.k8s.aws/mesh", "virtualNode": .metadata.annotations."appmesh.k8s.aws/virtualNode" }'

Si el problema sigue sin resolverse, considera abrir un GitHub problema o ponte en contacto con AWS Support.

Los Envoys del cliente no pueden comunicar con el servicio de administración de Envoy de App Mesh con IMDSv1 deshabilitado

Síntomas

Cuando IMDSv1 está deshabilitado, los Envoys del cliente no pueden comunicar con el plano de control de App Mesh (servicio de administración de Envoy). IMDSv2 no es compatible con la versión de App Mesh Envoy anterior a la v1.24.0.0-prod.

Resolución

Para resolver este problema, puede elegir una de estas tres soluciones.

• Actualice a la versión v1.24.0.0-prod o posterior de App Mesh Envoy, que es compatible con IMDSv2.

• Vuelva a habilitar IMDSv1 en la instancia en la que se esté ejecutando Envoy. Para obtener instrucciones sobre la restauración de IMDSv1, consulte Configurar las opciones de metadatos de la instancia.

• Si sus servicios se ejecutan en Amazon EKS, se recomienda utilizar roles de IAM para cuentas de servicio (IRSA) para obtener las credenciales. Para obtener instrucciones sobre cómo habilitar IRSA, consulte Roles de IAM para cuentas de servicio.

Si el problema sigue sin resolverse, considera abrir un GitHub problema o ponte en contacto con AWS Support.

IRSA no funciona en el contenedor de aplicaciones cuando App Mesh está habilitada y Envoy está inyectado

Síntomas

Cuando App Mesh está habilitada en un clúster de Amazon EKS con la ayuda del controlador App Mesh para Amazon EKS, Envoy y los contenedores proxyinit se inyectan en el pod de la aplicación. La aplicación no puede asumir IRSA y, en su lugar, asume node role. Cuando describimos los detalles del pod, vemos que la variable de entorno AWS_WEB_IDENTITY_TOKEN_FILE o AWS_ROLE_ARN no está incluida en el contenedor de la aplicación.

Resolución

Si se define alguna de las variables de entorno AWS_WEB_IDENTITY_TOKEN_FILE o AWS_ROLE_ARN, el webhook omitirá el pod. No proporcione ninguna de estas variables y el webhook se encargará de inyectarlas por usted.

reservedKeys := map[string]string{
        "AWS_ROLE_ARN":                "",
        "AWS_WEB_IDENTITY_TOKEN_FILE": "",
    }
    ...
    for _, env := range container.Env {
        if _, ok := reservedKeys[env.Name]; ok {
            reservedKeysDefined = true
        }

Si el problema sigue sin resolverse, considera abrir un GitHub problema o ponte en contacto con AWS Support.